Object Diagrams in UML

Introduction

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.

Basics

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:

Click here for a larger image.

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

Creating an Object Diagram in Poseidon

In Poseidon, you will find the option to create object diagrams clubbed with the option to create deployment and component diagrams. Presently, Poseidon does not support display of attributes and methods in the object diagram; in other words, you can as of now only define an object of class, its type, and the linked objects. Hence, for our case study, we will use Microsoft Word to create an object diagram.

The steps for creating an object diagram in Poseidon are as follows:

1. Open your Poseidon project file (the .zargo file) in which you created your class diagram earlier.
2. Make sure you are viewing your class diagram in the "Package centric," "Diagram centric," or "Inheritance centric" modes to view the deployment diagram. See Figure 5.6.





Click here for a larger image.

Figure 5.6—the creation of an object diagram in Poseidon

3. Click on Create diagram -> Deployment/Object/Component diagram (or Ctrl+D) in the menu bar above.
4. Click on the object icon (shown in the black circle) in the icon menu bar on the top, to create an object. See Figure 5.7.
5. Fill in the Name of the Object instantiated, in the properties bar below. Select the class of which this object is an instance, in the area titled "Type."
6. After creating all the objects, click on the icon for "link" (shown in the red circle in Figure 5.7) to link the objects. Give the name of the link.
7. In case of our Case study, if we show an object diagram for the CourseAdministrator managing the Courses scenario, we get a diagram as shown in Figure 5.7.





Click here for a larger image.

Figure 5.7—the object diagram in Poseidon for the case study Courseware management system

Dos and Don'ts

Dos

1. Use the object diagram as a means of debugging the functionality of your system.
2. Object diagrams can also be used to check whether the system has been designed as per the requirements, and behaves how the business functionality needs the system to respond.
3. Show associations of any kind between objects as linkages (for example, a single segment joining two objects, without arrows), and not as a dependency or any other specific type of association. An object diagram only shows the linkages, but not the type of association.

Don'ts

1. Avoid representing all the objects of your system in an object diagram. Because an object diagram represents the state of objects, it can become quite complex if you try to represent all the objects. Hence, it is always better to represent the state of objects in certain important/critical flows in your application using an object diagram. This will keep your object diagram readable, yet useful enough to capture the state of objects that are important.
2. Because object diagrams represent the state of objects, forward engineering of object diagrams does not make sense.

Case Study: Courseware Management System

Now, we shall create an object diagram for the courseware system. To do this, we will first build up on our class diagram, and include the possible attributes and define the parameters of to the classes defined earlier.

We will follow the following convention for the variable names:
Names starting with "s_" are of the String data type
Names starting with "i_" are of the int data type
Names starting with "v_" are of the Vector data type

The following table outlines the attributes, methods, and their return types for each of the classes:

To follow a logical sequence now, let us consider that the course administrator, courses, tutors, and topics already exist. Let us now make an object diagram for the case where the administrator with user id "admin" wishes to access the course calendar of a course with course id "Math_Course_001."

Hence, the following will be the attribute values, and method calls:

CourseAdministratorAttributes: s_adminId  = admin            s_courseId = Math_Course_001Methods:    viewCourseCalendar("Math_Course_001")

This method will call the method viewCourseInfo of class Course, which returns a Vector object populated with all the details of the course "MathCourse_001" (see Figure 5.8)

CourseMethods: viewCourseInfo("Math_Course_001")

Click here for a larger image.

Figure 5.8—the object diagram for the courseware management system, for a simple scenario of the course administrator managing a math course.

In Figure 5.8, for the single case where the flow is from Course Administrator to Course, when the CourseAdministrator is requesting the course information for a particular course.

Summary

In the last article, we saw how to make class diagrams, and made a class diagram for the case study—the Courseware Management system. In this article, we saw:

• What an object diagram is
• Notation used in an object diagram
• What the significance and use of an object diagram is
• How to make an object diagram in Poseidon
• The object diagram for a simple scenario in our Courseware Management system

In the next article of this series, we will study the state diagram.

About the Authors

Mandar S. Chitnis, Lakshmi Ananthamurthy, and Pravin S. Tiwari are the co-founders of Novusware, Inc.. They have co-authored the book Teach Yourself BEA WebLogic Server 7.0 in 21 Days (SAMS Publishing October, 2002) based on the recently launched WebLogic Server 7.0 by BEA Systems inc.

For any questions or queries regarding the article's contents, please contact articlewriters@novusware.com.