Tag Archives: Aggregation

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



Filed under Software Design