Object Diagrams in UML
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:
- Open your Poseidon project file (the .zargo file) in which you created your class diagram earlier.
- 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 on Create diagram -> Deployment/Object/Component diagram (or Ctrl+D) in the menu bar above.
- 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.
- 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."
- 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.
- 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.6—the creation of an object diagram in Poseidon
Figure 5.7—the object diagram in Poseidon for the case study Courseware management system
Dos and Don'ts
- Use the object diagram as a means of debugging the functionality of your system.
- 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.
- 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.
- 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.
- Because object diagrams represent the state of objects, forward engineering of object diagrams does not make sense.
Page 2 of 3