Object diagram - Unified Modeling Language (UML) Tutorial

- [Instructor] Object diagrams are drawn to model example configurations of instances in a system. While class diagrams help us see the relationships among entities throughout the life of the system while running, object diagrams help visualize what the system's state will look like at a particular snapshot in time. Instead of modeling classifiers, such as classes, interfaces, or abstract classes, object diagrams represent their instances, and hence, they're also known as instance diagrams. Object diagrams are very similar to class diagrams, with some minor differences. There are three key elements in them. First, objects that are instances of a particular classifier, second, the attributes, or instance variables, with their values, also called slots, and third, relationships among various objects alive at that snapshot in time. Let us look at each of these three elements in a little more detail. The object diagram shown here is actually derived from a class diagram where Book is the parent class and EBook is its child class. You can see the similarity between the two diagrams and notations. Objects are also shown as a rectangle, with a difference that they carry instance name with an optional class name separated by a colon. Note that the name is underlined to emphasize that it is an object. You many also give only class name, and if you do that, make sure you still underline it and put a colon before the name to show that it is a class name and not an object name. In such a case, you are modeling an anonymous object, which can be helpful in modeling instances of inner classes. In slots, you give the values of instance variables, however, you need not show the values of all attributes that the object may have. Just show the ones relevant to what you are trying to model. Relationships shown in object diagrams are similar to what you have in class diagrams. They have the same notations and mean the same as they do in class diagrams. Let me take a little more elaborate example to demonstrate their use. This is an oversimplified class diagram of a library management system. The Library class has two child classes: OnlineLibrary and CityLibrary. Library has a collection of books, represented by the class Book, which also has a child class called EBook. CityLibrary carries books, while the OnlineLibrary carries eBooks. Next, Library class has patrons, represented by the Patron class. Each patron can check out anywhere from zero to five books. Note that because eBook is also a book, a patron can check out a book as well as an eBook. Now if you want to see what the instances of these classes will look like when the system is running, we can draw an object diagram. Note that all these objects only have their attribute values and not their methods, as objects represent only the structural aspect of the system and not the behavioral aspect. In this diagram, the instance of Library has name lib, and one of its slots has a name attribute whose value is Public Library. The instances of child classes have names cityLib and onlineLib, with their address values in their slots. The cityLib has an aggregation of books, one of which is paper book, which is an instance of Book with values for ISBN, title, and author, as shown in the slots. The onlineLib has an eBook version of the same book, and you can see that there are two EBook instances shown, one reflecting the child and one reflecting the parent part. There is a Patron instance whose patronid has value 555. This patron has checked out the eBook instance of the book. As you can see, such a diagram shows the state of the system at some point in time. Some designers do not draw the arrow notations to differentiate associations and generalizations. In such a case, the diagram will look like this. If it is not important for you to model how these objects are related to each other as long as all relationships are represented, then simply drawing solid lines without arrows also suffices.