Explore sequence diagrams with UML, part III

The purpose of a class diagram is to show the structural makeup of an application. An application's structure is dictated by the dynamics of class collaborations. In UML, we commonly represent the dynamic aspects of class collaborations using a sequence diagram. Let's now explore the elements of a sequence diagram.

Behavioral modeling
Behavioral modeling is the process of allocating responsibilities to the classes composing your system. It's debatably the most important activity you perform throughout the life cycle because the behavior dictates your system's structure. Unfortunately, many development efforts tend to move directly from requirements to structural modeling, skipping the modeling of behavior. This approach is flawed because you haven't consciously determined the responsibilities of your classes.

While you eventually may end up with classes and their associated responsibilities, behavioral modeling makes this determination an explicit activity. The result is a much more robust set of classes and associated behaviors, something that will most likely not occur if you don't consciously model behavior.

The resiliency of your application ultimately is based on the degree to which you are able to manage the dependencies between classes.

These flexible dependencies are the heart of a flexible system. However, the identification of these dependencies is extremely difficult when you don't know how your objects talk to each other. If an object talks to another object, the classes must have a structural relationship. So by modeling behavior, not only are you able to determine what a class does, but you're also able to see how it will interact with other objects when instantiated.

While behavioral modeling emphasises allocation of responsibilities, it doesn't imply that you work only with behavioral diagrams. In fact, behavioral and structural modeling are most effective when performed in conjunction with coding activities. The time period separating these activities is measured in hours, if not minutes.

The static view of software probably contributes less than half to the overall specification. Software is all about behavior; therefore, the dynamic view is more valuable than the static view. Unfortunately, few developers recognise this fact, and even fewer actually model the dynamic aspects of a system.

Notation
Let's explore the fundamental elements of sequence and collaboration diagrams, two of the most commonly used behavioral diagrams.

Object
An object is an instance of a class and is represented by a rectangle. An object can be named in three different ways. First, and probably most commonly, you can specify the class that this object is an instance of. Specify the class name, preceded by a semicolon and underline, in the object rectangle. Second, you can specify only the object name, neglecting the class name. You do this by omitting the class name and semicolon and simply typing the object name and underlining it. In this naming scenario, you don't know the class that this object is an instance of. The third way to represent an object is to combine the two previously discussed approaches.

An object also can be thought of as a physical entity, whereas a class is a conceptual entity. An object in UML maps directly to an object in Java. However, when developers create Java applications, they're creating Java classes, not Java objects. Developers never write their code inside a Java object. Thinking about objects a little differently, you might consider objects as existing at runtime and classes as existing at design time. Developers create their code and map UML elements to Java at design time, not runtime. So while a UML object maps directly to a Java object, there is no Java language mapping that represents a UML object.

Message
A message is graphically represented using a solid directed arrow. While this representation is similar to that of an association on a class diagram, messages are used to represent the communication that occurs between objects, not the structural relationship present between classes.

Sequence diagrams
A sequence diagram is a form of behavioral diagram that enables you to specify the interactions that exist between a set of objects. While other behavioral diagrams may prove valuable, sequence diagrams are used most often, primarily because they enable you to see how objects use each other. Based on this information, you can more accurately determine why two objects are related.

Figure A: Sequence diagram

Because sequence diagrams are always read top to bottom, they provide an illustration of the order in which messages are sent between objects.

It's perfectly acceptable to suppress certain messages that may participate in the present flow of events if the message isn't significant in the context of the sequence diagram. While complex diagrams are impressive, they don't do much for communication. Sequence diagrams should be kept as simple as possible, and any message that is insignificant need not be shown. Figure A shows a sample sequence diagram with the following primary components:

• Object: The objects on a sequence diagram are always listed across the top of the diagram, which makes it easy to identify the classes (assuming the class notation is used) that participate in the interaction.
  
• Message: Messages are represented as directed arrows. In the diagram in Figure A, SomeObject sends aMessage to Class. Above the directed arrow is text informing you of the message sent between the objects. Messages can be numbered, indicating the order in which the messages are sent. On sequence diagrams, this numbering is somewhat redundant because the ordering of the messages always is determined by the order, from top to bottom, in which they appear on the diagram.

  In addition, it's possible to show an object sending a message to itself using a reflexive message, which the message marked as 2 in the diagram in Figure A illustrates. There is no restriction on the direction of messages. Messages on sequence diagrams can flow from either left to right or right to left.
  

• Focus of control: This illustrates the period of time during which an object is performing an action. The actual amount of time, measured in some unit such as seconds, isn't relevant. In this context, you're interested only in knowing the period that a particular method has control of the sequence of events. Indicating the focus of control is optional.

  This focus of control can be rendered graphically on sequence diagrams by placing a rectangle on top of the object lifeline.
  

• Object lifeline: This represents the life of an object in the context of the sequence of events. Objects that are created late in the sequence don't necessarily appear at the top of the diagram, but may appear at the point they're created. In addition, the lifeline can end at the point the object is destroyed or a reference to the object is lost. Similarly, object creation can be represented by simply sending a new message to an object.
  
• Reflexive message: This allows you to show a message that is sent from an object to an instance of itself.