Developing Interaction Diagrams (Design)


Interaction diagrams are about deciding and modeling how your system will achieve what you described in your use case models. Interaction diagrams enable you to visualize, specify, construct, and document the dynamics of how each object in your system interacts (exchanges messages) in order to perform a particular task. The context of a task equates to a single use case scenario.

UML provides two types of interaction diagrams that can be used to model the interactions between objects within the context of a use case scenario: Sequence and Collaboration diagrams. The Sequence and Collaboration diagrams represent two dynamic perspectives to view exactly the same information as they both model the messages that are passed between objects. Also, Sequence and Collaboration diagrams are isomorphic , implying that you can easily derive one from the other. In fact, most modeling tools, such as the Together ControlCenter, will automatically generate one diagram from the other.

Distinctions between the Sequence and Collaboration diagrams exist in how they portray the same information, as follows :

  • Sequence diagrams detail how chronological operations are carried out, what messages are sent, and when. The primary focus of a Sequence diagram is the flow of control by time, which promotes its use for modeling real-time scheduling systems and capturing the chronological sequence of interactions between objects in the context of a use case.

  • Collaboration diagrams convey the same information as Sequence diagrams, but focus on object roles and structural interdependencies. This focus promotes the use of Collaboration diagrams for illustrating the flow of control by organization between objects that interact.

Both Interaction diagrams provide a visual representation of the objects in a system's design and the order they send messages to each other. In UML terminology, sending a message refers to calling one of the operations ( methods ) of an object. Hence, the Class diagrams in conjunction with the Interaction diagrams can provide an initial platform to begin coding a solution.

Because Sequence and Collaboration diagrams are isomorphic, you can learn how to model one of them and catalyze your comprehension of the other through the use of a professional modeling tool, which can perform the conversion between the two model types. The following section will describe the most common features of a Sequence diagram.

The Features of a Sequence Diagram

As illustrated in Figure 3.23, a Sequence diagram has two dimensions:

  • The time dimension (Y-axis) represents the progression of time.

  • The object dimension (X-axis) represents the different objects that interact in a specific use case scenario.

    Figure 3.23. The dimensions of a Sequence diagram.

    graphics/03fig23.gif

Note

The axes can be interchanged, so that time proceeds horizontally to the right and different objects are shown as horizontal lines.


The control of flow by time in a use case scenario is represented in a Sequence diagram through the following:

  • Objects that interact in the context of a use case. The objects that initiate interactions are typically placed on the left of the object dimension, with subordinate objects to their right.

  • An object lifeline represents the existence of an object over a period of time. Objects that exist throughout an interaction should appear at the top of the object dimension with their lifelines drawn parallel to the Time dimension. Objects that are created and destroyed dynamically (transient objects) have object lifelines that begin and end with a receipt of a message.

  • A focus of control , also known as the Activation bar, illustrates the period of time an object is performing an action. Actions can either be performed directly by an object, or through a subordinate object to which it has sent messages.

  • Links provide a semantic connection between objects. They serve as a path along which one object can dispatch a message to another object.

  • Messages specify communication from one object to another, with an expectation that an activity will be performed by the recipient object.

Figure 3.24 illustrates how you can represent objects, object lifelines, focus of control, links, and messages in the context of a Sequence diagram.

Figure 3.24. The representation of objects, object lifelines, focus of control, links, and messages in the context of a Sequence diagram.

graphics/03fig24.gif

In addition to the basic flow of control, as illustrated in Figure 3.24, you can also represent the following control flows in a Sequence diagram:

  • Selection, as illustrated in Figure 3.25.

    Figure 3.25. The representation of a selection flow in a Sequence diagram.

    graphics/03fig25.gif

  • Recursion, as illustrated in Figure 3.26.

    Figure 3.26. The representation of a recursive flow in a Sequence diagram.

    graphics/03fig26.gif

  • Iteration, as illustrated in Figure 3.27.

    Figure 3.27. The representation of an iterative flow in a Sequence diagram.

    graphics/03fig27.gif

The Sequence diagram in Figure 3.28 represents the focus of control, conditional selection, recursion, creation, and destruction aspects of a Sequence diagram.

Figure 3.28. The representation of a focus of control, conditional selection, recursion, creation, and destruction aspects of a Sequence diagram.

graphics/03fig28.gif

The Collaboration diagram for the Sequence diagram represented by Figure 3.28 is illustrated in Figure 3.29, which can easily be generated using a professional modeling tool.

Figure 3.29. The Collaboration diagram representing the Sequence diagram in Figure 3.28.

graphics/03fig29.gif

Note

A Sequence and Collaboration diagram based on a use case scenario is described in the section "UML By Example ”The Book Store," which appears at the end of this chapter.


Tip

Because object-oriented software development is an iterative process, it is often very helpful to write some prototype code to help solidify the design. This becomes evident while developing Sequence diagrams, where you may realize that you need a message that is not yet an operation in the Class diagram. You must therefore update the Class diagram to include the new operation. To maintain traceability, any modifications to your analysis or design must be put back into all affected diagrams. This is not as bad as it sounds if you are using a professional UML modeling tool, such as the Together ControlCenter.




BEA WebLogic Platform 7
BEA WebLogic Platform 7
ISBN: 0789727129
EAN: 2147483647
Year: 2003
Pages: 360

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net