The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Common Modeling Techniques

Modeling Flows of Control by Time Ordering

Consider the objects that live in the context of a system, subsystem, operation or class. Consider also the objects and roles that participate in a use case or collaboration. To model a flow of control that winds through these objects and roles, you use an interaction diagram; to emphasize the passing of messages as they unfold over time, you use a sequence diagram, a kind of interaction diagram.

To model a flow of control by time ordering,

• Set the context for the interaction, whether it is a system, subsystem, operation, or class, or one scenario of a use case or collaboration.

• Set the stage for the interaction by identifying which objects play a role in the interaction. Lay them out on the sequence diagram from left to right, placing the more important objects to the left and their neighboring objects to the right.

• Set the lifeline for each object. In most cases, objects will persist through the entire interaction. For those objects that are created and destroyed during the interaction, set their lifelines, as appropriate, and explicitly indicate their birth and death with appropriately stereotyped messages.

• Starting with the message that initiates this interaction, lay out each subsequent message from top to bottom between the lifelines, showing each message's properties (such as its parameters), as necessary to explain the semantics of the interaction.

• If you need to visualize the nesting of messages or the points in time when actual computation is taking place, adorn each object's lifeline with its focus of control.

• If you need to specify time or space constraints, adorn each message with a timing mark and attach suitable time or space constraints.

• If you need to specify this flow of control more formally, attach pre- and postconditions to each message.

A single sequence diagram can show only one thread of control (although you can show structured concurrency by using the structured control constructs). Typically, you'll have a number of interaction diagrams, some of which are primary and others that show alternative paths or exceptional conditions. You can use packages to organize these collections of sequence diagrams, giving each diagram a suitable name to distinguish it from its siblings.

For example, Figure 19-6 shows a sequence diagram that specifies the flow of control involved in initiating a simple, two-party phone call. At this level of abstraction, there are four roles involved: two Callers (s and r); an unnamed telephone Switch; and c, the reification of the Conversation between the two parties. Note that the diagram models the four roles; each instance of the diagram has particular objects bound to each of the roles. The same pattern of interaction applies to every instance of the diagram.

The sequence begins with one Caller (s) dispatching a signal (liftReceiver) to the Switch object. In turn, the Switch sends setDialTone to the Caller, and the Caller iterates on the message dialDigit. Note that this sequence must be less than 30 seconds, as specified by the constraint. This diagram does not indicate what happens if this time constraint is violated. To show that, you could include a branch or a completely separate sequence diagram. The Switch object then calls itself to perform the routeCall operation. It then creates a Conversation object (c), to which it delegates the rest of the work. Although not shown in this interaction, c would have the additional responsibility of being a party in the switch's billing mechanism (which would be expressed in another interaction diagram). The Conversation object (c) rings the Caller (r), who asynchronously sends the message liftReceiver. The Conversation object then tells the Switch to connect the call, then tells both Caller objects to connect, after which they may exchange information, as indicated by the attached note.

An interaction diagram can begin or end at any point of a sequence. A complete trace of the flow of control would be incredibly complex, so it's reasonable to break up parts of a larger flow into separate diagrams.

Modeling Flows of Control by Organization

Consider the objects that live in the context of a system, subsystem, operation, or class. Consider also the objects and roles that participate in a use case or collaboration. To model a flow of control that winds through these objects and roles, you use an interaction diagram; to show the passing of messages in the context of that structure, you use a communication diagram, a kind of interaction diagram.

To model a flow of control by organization,

• Set the context for the interaction, whether it is a system, subsystem, operation, or class, or one scenario of a use case or collaboration.

• Set the stage for the interaction by identifying which objects play a role in the interaction. Lay them out on the communication diagram as vertices in a graph, placing the more important objects in the center of the diagram and their neighboring objects to the outside.

• Specify the links among these objects, along which messages may pass.

  1. Lay out the association links first; these are the most important ones, because they represent structural connections.

  2. Lay out other links next, and adorn them with suitable path annotations (such as global and local) to explicitly specify how these objects are related to one another.

  Dependency relationships are discussed in Chapters 5 and 10; path constraints are discussed in Chapter 16

• Starting with the message that initiates this interaction, attach each subsequent message to the appropriate link, setting its sequence number, as appropriate. Show nesting by using Dewey decimal numbering.

• If you need to specify time or space constraints, adorn each message with a timing mark and attach suitable time or space constraints.

• If you need to specify this flow of control more formally, attach pre- and postconditions to each message.

As with sequence diagrams, a single communication diagram can show only one flow of control (although you can show simple variations by using the UML's notation for interaction and branching). Typically, you'll have a number of such interaction diagrams, some of which are primary and others that show alternative paths or exceptional conditions. You can use packages to organize these collections of communication diagrams, giving each diagram a suitable name to distinguish it from its siblings.

For example, Figure 19-7 shows a communication diagram that specifies the flow of control involved in registering a new student at a school, with an emphasis on the structural relationships among these objects. You see four roles: a RegistrarAgent (r), a Student (s), a Course (c), and an unnamed School role. The flow of control is numbered explicitly. Action begins with the RegistrarAgent creating a Student object, adding the student to the school (the message addStudent), then telling the Student object to register itself. The Student object then invokes getSchedule on itself, obtaining a set of Course objects for which it must register. For each course object in the set, the Student object then adds itself to each Course object.

Forward and Reverse Engineering

Forward engineering (the creation of code from a model) is possible for both sequence and communication diagrams, especially if the context of the diagram is an operation. For example, using the previous communication diagram, a reasonably clever forward engineering tool could generate the following Java code for the operation register, attached to the Student class.

public void register() {
CourseCollection courses = getSchedule();
for (int i = 0; i < courses.size(); i++)
courses.item(i).add(this);
this.registered = true;
}

"Reasonably clever" means the tool would have to realize that getSchedule returns a CourseCollection object, which it could determine by looking at the operation's signature. By walking across the contents of this object using a standard iteration idiom (which the tool could know about implicitly), the code could then generalize to any number of course offerings.

Reverse engineering (the creation of a model from code) is also possible for both sequence and communication diagrams, especially if the context of the code is the body of an operation. Segments of the previous diagram could have been produced by a tool from a prototypical execution of the register operation.

Note

Forward engineering is straightforward; reverse engineering is hard. It's easy to get too much information from simple reverse engineering, so the hard part is being clever about what details to keep.

However, more interesting than the reverse engineering of a model from code is the animation of a model against the execution of a deployed system. For example, given the previous diagram, a tool could animate the messages in the diagram as they were dispatched in a running system. Even better, with this tool under the control of a debugger, you could control the speed of execution, possibly setting breakpoints to stop the action at interesting points to examine the attribute values of individual objects.