Object Diagrams

Object diagrams and class diagrams look very similar, because an object is an instantiation (i.e. a specific instance) of a class. Both class diagrams and object diagrams represent a static, structural view of a system. Object diagrams are not frequently used, but they can sometimes be useful for demonstrating the way in which objects interact in a system "at run time" (i.e. while the system is actually running). The can be used, for example, to show how a small part of the system works when this is not immediately obvious from looking at a class diagram. Put another way, they provide concrete examples that can be used to explain abstract concepts. Whereas a class icon represents all of the instances of a particular class that exist, have existed, or ever will exist in a system, an object icon represents exactly one instance of a class at one particular moment in time. The illustration below shows the difference between how a class icon, and its instantiation as an object, are represented in the UML.

Many UML modeling tools do not provide facilities for the creation of an object diagram as such, but because of the similarities between object diagrams and class diagrams, most UML tools allow objects to be placed on class diagrams in order to facilitate the production of an object diagram. Notice that the icon for an object looks quite similar (it is still represented by a rectangular icon), but there are some differences. The name of the object is underlined to show that it is an object. It is also the convention to add the name of the class of which the object is an instance, following the name of the object and separated from it by a colon. In our example we have "HartleyJR : BankAccount", which indicates an object of type BankAccount with the name "HarleyJR" (note that the names of objects normally start with a lower case character).

The name of the object may be omitted where it is considered to be unimportant, provided the meaning of the diagram is still clear. If it is omitted, the object is said to be an anonymous instance of a class. If no object name is supplied, the name of the class must be present, and must have the colon in front of it to indicate that this is an object (i.e. an instance of a class), and not a class. The attributes defined for the class may also be shown, but the data type is omitted. Instead of the default value, an actual value for the attribute is shown. The format for displaying an attribute is to show the attribute name, followed by an equals sign ("="), followed by the value assigned to the attribute. In our diagram, for example, we have "balance = €576.23".

If the attributes of individual objects are unimportant for the purposes of the object diagram, you can illustrate multiple objects using a single icon, as shown below. The icon shows the details of the first object, with additional objects being implied by the addition of a second rectangle drawn in such a fashion that it appears to be behind the first.

The connection between two objects on an object diagram is called a link. A link is represented by a solid line between two object icons. A label showing the purpose of the link may be added if required. Just as you can think of an object as a single instance of a class, you can think of a link as a single instance of an association between two classes (note that a link can only be shown where the class diagram has a corresponding association). The difference between a link and an association is that a link connects two objects, rather than two classes. The object diagram below tells us that an object named "HartleyJR" of type Customer is linked with both an object named "HartleyJR" of type SavingsAccount and an object named "HartleyJR" of type CurrentAccount.

In order to illustrate a situation in which an object diagram might be used to clarify a situation that a class diagram alone may not adequately explain, consider the class diagram below, which describes a college information system. It might be useful to first examine just what this diagram does tell us about the system, and then consider what it might not tell us.

This diagram tells us the following things:

• The college is an aggregation of one or more faculties, and a faculty can only belong to one college.
• Each faculty is an aggregation of one or more departments, and a department may only belong to one faculty.
• Each department is an aggregation of a number of lecturers, and a lecturer may only belong to one department.
• Each faculty administers one or more courses, and a course may only be administered by one faculty.
• Each department administers one or more modules, and a module may only be administered by one department.
• Each course is an aggregation of one or more modules, and a module may belong to one or more courses.
• Each course may have zero or more students enrolled on it, but a student must be enrolled on one (and only one) course.

The class diagram does in fact tell us quite a lot, but there may be questions that haven't been answered. One obvious question here revolves around modules, because it would seem that a module could be a part of a number of courses. Faculties are split into departments, and it is the departments that have responsibility for administering the modules, whereas the courses are administered by the faculties. Does this mean that a module that is administered by a department of one faculty might be included on a course run by another faculty? The implication is that this is indeed possible, but some concrete examples would be nice. Let's look at an object diagram that provides such an example.

The object diagram shown above is designed to highlight the fact that a single course (in this case "Computing and Informatics") is administered by the Faculty of Technology, and includes a number of modules administered by the Computing department (as you might expect, given the title of the course). It also tells us that the course includes modules administered by both the Management department and the Finance department, both of which are in turn administered by the Faculty of Business Studies.

Object diagrams can be used to highlight all kinds of situations that can arise at some moment in the life of an information system, at an arbitrary level of detail (the level of detail shown on an object diagram should only be as much as is necessary to make the point we are trying to make). They are useful for helping stakeholders to understand a class diagram, or for showing a client how part of the system is supposed to work in a given scenario. They are not as a rule used by system designers or programmers to design an application or write program code (class diagrams are far better suited for that purpose).

An object diagram can sometimes be used to test the accuracy of a corresponding class diagram, or to show how an instantiated object relates to its class definition. Although it is not common for classes and objects to appear on the same diagram, sometimes part of a larger class diagram may be abstracted onto a separate diagram, together with an object diagram that provides a concrete example of the relationship between the classes involved.