Dynamic Modeling

The dynamic models focus on the interactions between objects—instances of the classes identified in prior chapters that work together to implement the detailed pathways through the use-cases. Dynamic models add considerable value to the project, as follows: For the first time we

• Bring together the classes and use-case pathways and demonstrate the ability to model the messaging necessary to implement them

• Transfer knowledge learned from the dynamic model to the class diagrams in the form of operations, attributes, and associations

• Incorporate knowledge learned from the use-case and class diagrams to model the volumetric and loading characteristics of the application through the creation of usage matrices

In our earlier work on the project, we explored the dynamic aspects of the Remulak Productions application. Many of the artifacts already captured add to the dynamic knowledge required to make the Remulak system a reality—for example, the following:

• The events identified during project scoping provide a clear picture of the external and internal stimuli to which the system must be prepared to respond.

• The pathways identified in the use-case templates are dynamic in that they explain the logical steps necessary to satisfy the goal of the use-case.

• The business rules capture the parameters and semantics that certain elements of the application must implement.

The dynamic models reviewed in this chapter provide a more formal approach to what has already been captured in various parts of the project's evolution. Chiefly, they reinforce the object-oriented concepts and principles to be used in the project.

Types of Dynamic Models

UML offers four dynamic models in the form of diagrams that offer different views of the dynamic perspectives of the application. Each diagram's view provides a unique focus and can be used in different instances depending on an application's needs.

• Sequence diagram: Often called one of the interaction diagrams (the other being the collaboration diagram), the sequence diagram, in my experience, is the most often used dynamic model. Applications will always produce sequence diagrams. A sequence diagram is time centered. Its focus is the linear flow of messages between objects. Time flows from the start of the diagram sequentially downward (see, for example, Figure 7-3).

  Figure 7-3. Enterprise-level use of the sequence diagram

  

• Collaboration diagram: Also often called one of the interaction diagrams, the collaboration diagram conveys the same meaning as the sequence diagram, except that it focuses on the individual objects and the messages that they send and receive. Collaboration diagrams are instance centered. Some of the visual modeling tools available (e.g., Rational Rose) will generate collaboration diagrams from sequence diagrams. If a particular design aspect of your application is multithreaded, collaboration diagrams do better than sequence diagrams at representing the application.

  Note

  The two interaction diagrams are the key link between the use-case pathways and the code that will be constructed to implement the pathways.

  
  

  State diagram: A state diagram models the lifecycle of one class. More specifically, it models the various states in which an object can exist and the events and associated actions and activities that are performed when an object makes the transition to a new state or while it is in a particular state. State diagrams add value only when the class exhibits interesting and complex complex dynamic behavior. Many classes in the application (e.g., Customer and Address) are, well, uninteresting concerning state; others (e.g., Order) can be quite interesting, divulging additional requirements knowledge about the application. Most applications will have a low ratio of state diagrams to classes. Applications of a more real-time embedded nature (e.g., machine control, automotive, and telecommunications) typically have a higher ratio of state diagrams to classes.

• Activity diagram: An activity diagram models the steps in a complex operation. It can also be used to model the steps of a use-case pathway. Activity diagrams are as close to traditional flowcharts as one can get.

Figure 7-2 provides a view of the application artifacts as they change focus toward the dynamic elements of the project; the sequence diagram is shown here. The roots of this sequence diagram can be traced to both the use-case pathways and the class diagram.

The outlined steps or tasks necessary to implement a pathway through a use-case eventually must be transformed into messages between objects. The dynamic models, particularly the sequence and collaboration diagrams, always view the live instances of the classes—that is, the objects. The objects are doing the interacting in the dynamic models (Micaela Reed Places an Order). The classes define the rules regarding how each of their instances will change state. The following sections discuss the four diagrams in detail.