MSc-IT Study Material
January 2011 Edition

Computer Science Department, University of Cape Town
| MIT Notes Home | Edition Home |

Dynamic behaviour

The object model which we have just been discussing is a static model of classes and their relationships. It does not show how the classes call on one another to perform the functions required in the software system.

These dynamic aspects of the object model are usually represented in other diagram types of the UML. We will be briefly discuss interaction diagrams.

Interaction diagrams

Interaction diagrams show how objects interact with one another. Specifically, they show which objects are currently executing, and what methods they are calling on other objects.

There are various kinds of interaction diagrams that can be employed in the UML. We will examine one specific type, the sequence diagram. Sequence diagrams show how objects interact with each other over time. In other words, sequence diagrams show the sequence of interactions between objects.

Figure 5.9. Sequence diagram notation in the UML

Sequence diagram notation in the UML

The figure above shows a sequence diagram of how books are checked out of a library. Notice how the objects are arranged horizontally along the top of the diagram, and are represented as rectangle boxes, just as classes are. It is important to notice the colon before the class name in these boxes — this colon tells us that the box represents not a class, but an instance of the class. If the instance should be given a specific name, then the name appears before the colon. For example, artOfWar : Book represents an object called artOfWar, of class Book. This is exactly the same as when specifying attributes in classes (see the section called “Attributes” above).

It is important to realise that it is because sequence diagrams represent the interactions a software system undergoes over time that it is interested in objects rather than classes. A running software system consists of instances of classes, and not of the classes themselves.

Time is represented vertically, with earlier events happening closer to the top. This means that sequence diagrams should be read from top to bottom. Each object also has a vertical life-line that shows us the object's period of existence. Interactions are represented by solid and dotted lines, each of which has an arrow and a label. Solid lines show method calls, and point from the life-line of the object making the call towards the object which will execute the method. The rectangles along the life-line represent the time over which an object is executing a function. Dotted lines represent a return of control from the object executing a method to and object which had originally called it.

Note that the method names should be operations belonging to the object to which the arrow is pointing. Borrower calls requestBook, an operation belonging to an instance of class Book.

A useful way of using sequence diagrams is to outline difficult use cases as a sequence diagram: this will highlight what objects are required in developing the use case, as well as what actions each object will perform in order to complete the use case. Further, a sequence diagram can then be thought of as showing how the system reacts to events, the events being the input from the actor in the use case.

The UML also prompts us to use sequence diagrams in this way: remember that actors in use cases are themselves classes. We can easily use instance of these classes (of these actors) as valid objects in sequence diagrams.

Summary

Class modelling is the key modelling technique for object-oriented designers. If you are in a position to say that you understand class modelling, then you can reasonably claim that you understand object-oriented design. Of course, an understanding of other object-oriented techniques (e.g., use case modelling) will also be helpful.

Class modelling centres on a small number of philosophical points, which must be understood extremely well. There is not a great deal of factual material to remember, but these key points are crucial. These are the most important issues:

  • The distinction between objects and classes

  • The nature of attributes and operations

  • The use and specification of associations, especially generalisation

In constructing a class model, the first step must be to obtain a working list of candidate classes. As design progresses, these classes will be refined and some will be deleted. At an even later stage, new classes will be introduced to support more detailed, implementation-related concepts.

A class model is refined by finding and specifying associations. Doing this helps to determine whether the initial choice of classes is a sound one, and how to improve it.

Ultimately the class model will be transformed into a computer program.