Tag Archives: UML

USE CASES IN UML AND OBJECT ORIENTED PROGRAMMING

When I took a Object Oriented Programming Class in my second semester in college, I was not able to understand a lot of concepts essential to software design and architecture. I was new to the concept of Classes, relationships between classes, API and exposing methods and attributes. Of course, that’s why I was taking the class. I could program some fundamental programs in pascal before this and i loved global variables (the fact of the matter is I still love them but probably somebody who is debugging a problem or a bug in my code, probably would not like them). So coming back to the point, the first concept in any Software development methodology is a requirement. Business Analysts would talk to the potential customers and figure out a bunch of requirements. Software Architects or Software Designers would view the requirements and model the requirements in a way that would make sense to a Software Developer. Sometimes a business analyst would be talking to the customer and doing a design, there are no hard and fast rules. The main purpose of UML is to specify requirements and design in a standard format so in a team other people can relate to the requirements and design and write efficient code. In my software development experience, good requirements mean 50% less work and also it would save the rework and costs in terms of testing time, and no hacks in code. Overtime a piece of code gets modified multiple times by different people who like to code differently, so more clear the requirement is, most relevant
code you can write to begin with.

What is a use case ?
I would not go too much technical detail on exactly how it is defined. To me its a functional requirement and that’s what I have read in books as well. Functional requirements of a system can be described using Use cases and Use Case Models.By functional requirement I mean that we would use a USE CASE to describe a feature of the system we are trying to design. It will usually involve describing an event that will happen as a result of user or system doing something.
If Use case defines a requirement then a Use Case Model pretty much describe the overall working of the system by showing a collection of requirements and the relationships that exists between them. Lets say we are designing

Let me give you an example, you love Facebook right ? Right or wrong ?? he-he, lets say you have to describe the event of “Sending a friendship request to another member” how that will happen ? There are some business rules that will govern how. First thing is the person browsing Facebook needs to be logged in, second thing is you should be able to find the profile where you want to send the friendship request to. Then there should be a button or a link or some User Interface that the person would be able to click to be able to send a friendship request. After the button or link is clicked, Facebook will do its thing and display if it was able to send your friendship request or “Sorry No Donuts for You”, I guess ORKUT did that, not guessing I am pretty sure ! So in the scenario I just described there are a bunch of components that will make up the use case and I will describe them as I go.

The Aim or Goal or Description of the Use case is to be able to send a friendship request to another member of Facebook. You can give it a short and sweet name and be fancy like “Sending a Friendship request”. So the name/title of the USE CASE would be “sending a friendship request” and the goal/aim/description would be “The system/website/Facebook should be able to send friendship requests to other members with a profile on the system/website/Facebook. So now you know what is the title and description (description is a wordy extension of the title). Next thing would be to identify who is initiating this behavior of the system and by doing what ? A user is initiating the action by clicking on a link. The Primary actor/stake holder of the use case is the “USER” and “Clicking the Send Friendship Request Link” is the Trigger. After clicking since the system/Facebook will do something and say whether it was successful or not and actually send the request “SYSTEM” can be thought of as Secondary actor. So now we are down 5 trashy terms (Title,Description, Primary Actor,Secondary Actor and Trigger). Now there are some conditions that should be fulfilled before the Action/Description can happen like the person sending the friendship request should be signed in to Facebook and be able to locate the profile of the person where the request would be sent and be able to click on the correct link. These are the Preconditions of the Use Case. So the conditions that should be fulfilled before the scenario described in the use case are its preconditions. Usually they can be represented as a numbered list on a Use Case. Similarly after the scenario described in the USE CASE is completed, something will happen that would be the POST CONDITION. Either the friendship request is sent or Sorry No Donuts for you :P. Now comes the main flow or happy scenario or the USE CASE which would define a sequence of events and action that would describe the Use Case. For example

1. User A found User B on Facebook and is able to stalk
2. User A clicks on the “Send Friendship Request” link
3. System sends a friendship request to User B and also sends a notification email

This scenario is happy because whatever we are trying to achieve we did so successfully. Similarly since the system will not be happy all the time, you can have an alternate scenario. Alternate scenarios are also called USE CASE Extensions

1. User A found User B on Facebook and is able to stalk
2. User A Clicks on the “Send Friendship Request” link
3. System was unable to send a friendship request due to some error and displays a message “Sorry No donuts for you since cookies are disabled in the browser !”

I would recommend text from UML Distilled and anything written by Martin Fowler on this subject.

Advertisements

Leave a comment

Filed under Software Design

Object Oriented Design – A Class Diagram Walkthrough

Making a Class Diagram with UML Notation – Explained Step by Step:

 Note: Your feedback , issues are warmly welcomed and I would be happy to assist you with any problem you might be having .Class diagrams are often used in object oriented analysis and design to show the various identified objects , their types (classes) , their data and operations and how the relate , or communicate with other objects or classes. Here are some of the standard UML conventions and a sample class diagram to get you started: 

Identify the classes in the problem domain:

 This is the first and most important step for creating the class diagram. What classes should you include and how to identify them given a problem statement or a scenario? The solution is simple and some time should be spent with the client / system engineers /your teacher in case you are making an academic project or any concerned authority having the required business knowledge.The first step however is creating a problem statement or establishing a set of requirements that the software should fulfill. E.g. you need to create a small library management system. What are some of the requirements for the system? Let’s try to make a problem statement or the scenario for your design. For the sake of simplicity considers the following simple problem Statement. “The library management system would be used by the librarian to keep track of books, library members and the borrowing activity. Not all books can be borrowed by the members. Some books may only be available to review in the library; all such books are termed as Reference books. There are 2 types of library members students and college faculty members. Faculty members can also check out research papers and magazines where as students can only checkout books. The system need to send alerts whenever a book that has to be returned within a specific date is not returned. An email is sent to the librarian and the borrower. The system maintains a catalogue having a description of each book that is available in the library” 

Ways to identify Classes:

 Do the Noun Analysis: Go through the problem statement again and again and try to figure out all the nouns that you come across. In our case some strong contenders for the classes of the library management system would be: Librarian,Book,Member,Catalogue,Student_Member,Faculty_Member,Reference_Book,Issueable_Book,Alert 

Perhaps there might be some nouns that I skipped but why??  I did that intentionally because of either of the two reasons. Either there is no data associated with them. They have no role to play in the system i.e. they don’t have any functions or actions associated with them. So by this we mean that “In order for a noun to be an object or a class it should have some attributes or member data and some actions or member functions.

 Resolving the relationships between classes:

Object oriented analysis and design is all about relationships between objects. Look for a certain type of relationships. These include generalization/inheritance/specialization, composition / containership, aggregation/ collections and associations. All of these are explained briefly below and discussed in terms of our scenario. There are some key questions associated with object oriented design over here.  How data is passed between the classes? What classes should have the objects of another class?What classes create the objects of other classes?What are some of the utility classes that the application requires? All these questions play an important role in the design. Think in terms of hierarchy for generalizations/inheritence:First of all check for hierarchy that may exist between the classes or the objects.This would model the inheritance or generaliztion or the superclass/subclass relationship.In natural language this might resolve to “type of” or “can be”. If you find such words in a problem statement there might be a case of generalization. E.g. In our scenario take the three classes BOOK , REFERENCE_BOOK and ISSUEABLE_BOOK . So a book can be a reference book or an issue able book or you can say that reference books and issue able books are the type of books. They all should ideally share many characteristics which are common to all the three classes.What I mean to say is, whether it is any book (reference or issue able) they all have ISBN number, author a language, a topic e.t.c so what is the difference. The difference is implied by the business rule that reference books cannot be issued but only reviewed. So for reference books we might add a Boolean data member called m_bReference and set it to true or something. Same is the case with Member, Student_Member and Faculty_Member. Inheritance is indicated in the class diagram with a filled black triangle pointing towards the base class and connecters connecting it to all the derived classes. In our scenario the inheritance could be shown as the figure below:

 Think of the Part-Whole Relationships:

Ok so now you know what might be the possible hierarchies in your system and what might be the common data members and the common functions. What are the differences and how the qualify to be another class. Another important type of relationship in terms of Object Oriented Analysis and Design is the “Part of” or “Part Whole” relationship. In Natural language, you might come across “has a” words to quickly identify these kind of relationships. In the list of candidate classes observe which of the objects the part of other objects is. This can also be taken as collection.To give you some examples for common scenarios. A Windows form is a collection of many controls.An automobile is composed of many parts.A shopping cart has many itemsA university is comprised of many campuses Here you want to ask a simple question to resolve the type of relationship and to know whether it is an aggregation or a composition. “Is the whole destroyed when the part is destroyed” or “It doesn’t make a difference to the Whole if the part is destroyed”. Now going through this example list. A form would still exist if any of the control is destroyed; the form serves it purpose properly. This implies an aggregation .An automobile wont function properly if any of its parts are destroyed e.g. it cannot function if the tires, steering, battery is taken out so this implies composition. A university will still exist if a campus is destroyed. So it depends upon the scenario and the business rules.

Returning to our depicted scenario the only part whole relationship noticeable is perhaps the catalogue. A catalogue has list of books available in the system with a short description of each. The catalogue is not destroyed if a book is destroyed so I would use aggregation in the design. In UML aggregation is shown with an empty diamond where as composition is shown with a solid black diamond.

 The Uses relationship – Association:

 Many objects use the methods/functions of other classes for utility. The objects are somehow related might be statically or dynamically but there is not a hierarchy or a part whole relationship. Such relationships are called association and can be mostly identified with “makes use of” or “uses” in the problem statement. E.g. There is a class called “Pen” which exposes a method called “Draw ()”. There is also a “Shape” class having a method called“drawShape ( )” . In the implementation of “drawShape( )” it internally calls / invokes the “Draw ()” method exposed by Pen. In our scenario  A librarian uses the book and student information to issue a book.The catalogue needs a reference of the book to add or update itselfAnd probably some more: 

Here is the sample design which I created with Visio just for the sake of discussion and show how relationships can be expressed in UML in terms of object oriented design.The business rules that I assumed for this discussion were really simple just to make the understanding better.If it helped you in any way or you require some discussion in any area do supply your feedback by leaving comments for this post. Thanks.

Sample Class Diagram

       

53 Comments

Filed under Software Design