Object Diagrams in UML
In the last article, you saw how your application could be represented in a class diagram. A class diagram is a static representation of your system. It shows the types of classes, and how these classes are linked to each other. In this edition of our series we introduce the object diagram.
Although we design and define classes, in a live application classes are not directly used, but instances or objects of these classes are used for executing the business logic. A pictorial representation of the relationships between these instantiated classes at any point of time (called objects) is called an "Object diagram." It looks very similar to a class diagram, and uses the similar notations to denote relationships.
If an object diagram and a class diagram look so similar, what is an object diagram actually used for? Well, if you looked at a class diagram, you would not get the picture of how these classes interact with each other at runtime, and in the actual system, how the objects created at runtime are related to the classes. An object diagram shows this relation between the instantiated classes and the defined class, and the relation between these objects, in the logical view of the system. These are very useful to explain smaller portions of your system, when your system class diagram is very complex, and also sometimes recursive.
Let us now see what the components of an object diagram are. After this, we will build an object diagram for our case study—Courseware Management system.
Elements of an Object Diagram
Because an object diagram shows how specific instances of a class are linked to each other at runtime, at any moment in time it consists of the same elements as a class diagram; in other words, it contains classes and links showing the relationships. However, there is one minor difference. The class diagram shows a class with attributes and methods declared. However, in an object diagram, these attributes and method parameters are allocated values.
As an example, in the last article, a class diagram for a multiplicity relation between college and students was shown, as you cam see in Figure 5.1:
Figure 5.1—an example College-Student class diagram
This class diagram shows that many students can study in a single college. Now, if we were to add attributes to the classes "College" and "Student," we would have a diagram as shown in Figure 5.2:
Figure 5.2—the class diagram with attributes
Now, when an application with the class diagram as shown above is run, instances of College and Student class will be created, with values of the attributes initialized. The object diagram for such a scenario will be represented as shown in Figure 5.3:
Figure 5.3—the object diagram for the College-Student class diagram
As can be seen from Figure 5.3, the object diagram shows how objects are instantiated in the running system represented by the College-Student class diagram. The class diagram shows that a single college has many students, and defines the variables. The object diagram for the same system shows instantiated classes of Student (Student #1 and Student #2) enrolled in College (Graduate School of Business).
The object diagram shows the name of the instantiated object, separated from the class name by a ":", and underlined, to show an instantiation.
Eg. Graduate School of Business: College
In the diagram, values are assigned to variables and represented using the notation variable name=variable value.
This example was the representation of the relation of only two classes with each other. However, in a real application system, there will be multiple classes. An object diagram then shows the relation between the instantiations of these classes. We shall see this in our case study.
A class that defines the flow of the system is called as an active class. This class instance in the object diagram is represented by thick border. In an MVC application architecture, the controller servlet is the action class, and is denoted by a thicker border. Also, multiple instances of the same class, as in a factory pattern, if the attributes of the individual objects are not important, or are not different, these can be represented by a single symbol of overlapping rectangles (see Figure 5.4):
Figure 5.4—the object diagram for a Factory class
A class that performs more than one role, and is self-linked, is represented by a curve starting and ending on itself, as illustrated in Figure 5.5:
Figure 5.5—the object diagram for a self-linked class