Introduction to UML Class Diagrams
This post is going to give a brief introduction to UML Class Diagrams, their purpose and important concepts.
It is important to understand that when a product is to be built, whatever it is, it can be a system, a mobile application, web application or a game, we have to go through certain phases before the actual implementation of the product using various or the required programming languages begins. These phases are important and crucial so as to have a conceptual understanding of the product that is being built.
These phases involve — gathering of the functional and the non-functional requirements regarding the product where the functional requirements determine what the product must do and the non-functional requirements determine what the product must be, creating the Use Cases and the User Stories and building upon a conceptual model using CRC cards or Class Responsibility Collaboration cards.
All of this previous work was done to identify our first set of classes. Therefore after these processes, we have to visually represent the classes through class diagrams. Moreover this is the place where object oriented design principles come into play like Inheritance and Polymorphism. The most common feature to use is the UML class diagram. This can be a quite advanced topic but for this post I am going to stick with the basic concepts.
Purpose:
Class diagrams are the only diagrams that can be mapped with the object oriented languages and thus are widely used at the time of development of an application. The purpose of class diagrams:
- To have a clear picture like a blueprint of the application, system or simply the product that is to be built.
- To identify and describe the responsibilities of the system.
- To determine the relationships that exist between the various components of the end product.
- It is quite helpful for the developers and other team members in providing them the required knowledge regarding the application or system that is to be built or developed.
UML Class Diagram
The UML Class diagram is a graphical notation that is used to construct and visualise object oriented systems. A class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system’s:
- classes,
- their attributes,
- operations (or methods),
- and the relationships among objects
Now let us first discuss about Class:
A class is a blueprint for an object. Hence the objects and classes go hand in hand. The entire concept of object oriented design is further not about objects, it is actually about classes. This is because we use classes to create the objects. The class acts as a blueprint which describes the object and the objects on the other side are the usable instance of a class. Hence an object is an identifiable entity that has its own set of characteristics(also known as attributes) and behaviour.
Consider the example below:
Here as we can see that the class is just a blueprint, the object is an instance of the class.
UML Class Diagrams — Notations and other concepts
A class represents a concept that encapsulates state that are known as attributes and behaviour that are known as operations. Each attribute of a class has a data type and each operation has its own signature.
A class diagram consists of three partitions:
- Class Name: The name of the class appears in the first partition.
- Class Attributes: They are shown in the second partition. Their type is defined after a colon.
- Class Operations: They are shown in the third partition. Their return type is also shown after a colon that comes after the method signature.
In class diagrams, each class should have a name written in the singular form, it should not be plural and the standard is to use first letter in uppercase. For example words like Person, Address, Student, etc. As far as the attributes are concerned, you won’t be knowing all of them because so far in the previous stages one would be focusing on identifying the relationship between the object, class responsibilities and behaviours, but try writing the obvious or the basic ones. Use the naming convention that is typical for the programming language that is to be used during the implementation phase. I will be using the camel case format to represent the attributes. In the camel case format the first letter of the first word is in lowercase and then uses uppercase first letter for all the additional words.
While it’s common to write the attribute names, it is also preferred to also write the data type of the attributes. This can be done by using a colon after the attribute name followed by the data type. Consider a class Person which has attributes like name, email, address, phoneNumber and age. We can define their data types as String, Integer, etc as shown below.
If it is required we can also give a default value to the attribute where required by using an equal to sign after the data type, followed by the default value. We don’t have to use it for all attributes but for only those where it is required and is relevant. Since we are focusing on initially creating the class diagrams, try not to give all your attention in knowing the exact data types that are to be used. Don’t spend time in this phase to identify whether some attribute has to be a 32-bit integer or a 64-bit. Knowing that it has to be an integer is enough. There might be some attributes that can be implemented in several different ways. It can be implemented by splitting it into two separate attributes or we can use a complex data type or we can create our own class for a particular type. However these are the details that we have to work on in the latter phases.
Before we go any further let us discuss about Class Visibility
In UML diagram, to represent the visibility of the attributes and methods, plus, minus and hash symbols are used before them.
- + denotes public attributes or operations
- - denotes private attributes or operations
- # denotes protected attributes or operations
Now the question arises that what are the operations of an object that the other objects need to know about? This is in line with the principle of encapsulation. That is to hide as much of the implementation details as possible and only share that which is absolutely necessary to expose to other classes. In UML class diagrams therefore plus and minus signs are added before the attributes and methods. The former indicates those attributes and methods which are public and can be accessed directly by the other methods while the latter indicates that the member is private and cannot be accessed directly by the other objects. For example, if we don’t want the email, address and phoneNumber attributes of a Person class to have a public visibility then the below class diagram shows how they can be represented.
Remember that if you are defining classes that are strangely devoid of behaviour, you might want to revisit those responsibilities that have been established for the classes. Go again through the requirements that have been gathered, written descriptions and the conceptual object model or the CRC cards. The focus should be on what the object has to do rather than viewing the objects as mere data structures. For example, consider a Student class that extends the Person class. We should not first focus on what attributes it will have like roll number, personal registration number, college name, branch name, the list of courses, etc, rather we should first identify what the object has to do. One of those operations is to attend classes.
In short we should first identify the purpose of the object as to what it is supposed to do, what operations it has to perform, its responsibilities rather than focusing on what data it’ll be storing as in attributes.
Class Diagram — Perspective
Let us discuss the various perspectives of a class diagram. The class diagram can be interpreted from various perspectives.
- Conceptual represents the concepts in the domain
- Specification refers to the focus on the interfaces of ADTs in the product.
- Implementation defines how the classes will implement the interfaces defined.
Perspective therefore impacts the amount of detail that is to be given and the level of relationships that have to be defined between the entities.
As we have discussed before that during the phase of domain modelling, we determine the objects, relationship between the classes and class responsibilities. Let us the see the types of relationships that might exist between the classes.
Relationships
A relationship can be of the following types:
Generalisation
It is a relationship that exists between a more general entity and a more specific entity. Therefore each instance of the more specific entity is also an indirect instance of the more general entity. Hence it will acquire the properties and behaviour of the more general entity.
Generalisation represents an “is-a” relationship. It is a bottom-up approach whereas specialisation on the other side is an opposite approach that is top-down.
Let us see and example, in the image below, Student class and Professor Class are the sub-classes of the Person class. This shows the inheritance hierarchy.
Association
Association is a structural relationship that exists between different objects that are linked within a system. It is used to show the binary relationship that exists between the classes. Hence in short it depicts the relationship between them such as one teacher may be associated with many students. Association is a broad term that encompasses just about any relationship that exists between the classes. Association is of different types.
Directed Association: It refers to the directional relationship that exists between the classes that is represented using a solid line connecting the classes with an arrowhead. The arrowhead depicts the container and contained directional flow between the classes.
Bidirectional Association: When the arrow is on both ends then it is known as a bidirectional association.
Reflexive Association: This occurs when a class has multiple functions or responsibilities. For example a staff member of a shop may be the manager, a receptionist, etc.
Cardinality
Cardinality is expressed in terms of:
- one to one
- one to many
- many to many
Aggregation
It refers to the formation of a particular class that is the result of aggregation or collection of other classes. It is also a type of an association. Consider the example of a Library class that consists of a number of Books and then all other materials. The contained classes of an aggregated class do not strongly depend on the container which means that if the container is dissolved, that is if the library is dissolved then the books will still exist.
We can show aggregation between a child class and a parent class by joining a line from the child class to the parent class with a diamond at the end of the line joining the parent class. An example is shown below to have a better understanding.
Composition
Composition is quite similar to aggregation, but here the main difference is the dependence of the contained classes on the life cycle of the container class. This basically means that here unlike aggregation if the container class is dissolved then the contained classes also get dissolved or obliterated.
If the same example as mentioned in aggregation has to be represented as a composition. It’ll be as follows:
Notice in the above diagram the diamond is filled unlike in the case of aggregation.
Dependency
It is when an object of one class might require an object of another class in one of its method so as to perform an operation. Such a relationship is known as a dependency relationship.
For example a Person class where there is a method to read a book. For that it requires some data from a Book class to fetch details so as to check if the Person has read the book or not. This can be represented as below:
Realization
It denotes the implementation of the functionality defined in one class by another class. Consider the example below, the printing preferences that are set using the printer setup interface are being implemented by the printer.
Converting Class diagrams into Code
After all the design work is done, finally it will be time to convert the design into code using an appropriate programming language. This is because every programming language has its own unique way of implementing things. However the object oriented design concepts work across many programming languages, even though the implementation details, like the syntax will be different.
I hope this was helpful and provided the basic yet important information about UML class diagrams. Thank you.
Have a look at my other posts. Share if you like them. :)
