The Sequence Diagram
The sequence diagram is the most used of the dynamic models. It has a long and rich history tracing back to, among others, James Rumbaugh's OMT (Object Modeling Technique) methodology. The diagram begins with instances of classes—objects—organized in “swim lanes” across the top. Below each object is a “lifeline,” as Figure 7-3 shows.
Objects are drawn as boxes, with the class name preceded by a colon and then the entire name underlined. This notation can be verbalized as, for example, “any old Customer object.” If a specifically named object is desired, then the colon is preceded with the name of the object—for example, Rene Becnel:Customer, which, verbalized, means “the Rene Becnel object of class Customer.” Figure 7-3 shows an example of objects interacting in a sequence diagram.
The sequence diagram often uses the focus-of-control rectangle. It appears as a rectangular box imposed on top of the swim lane. This optional adornment indicates that this object is orchestrating the messaging activity and has control of that particular messaging sequence. Indicating this control on the diagram, especially in multithreaded applications, can be helpful.
In this book we use the sequence diagram for a very specific purpose in the project's Elaboration phase. However, it may also be used for enterprise-level modeling—for example, in business process reengineering efforts or even during a project's scoping phase. Figure 7-3 is an example of a sequence diagram depicting the overall enterprise-level interactions of departments within Remulak Productions. Note that this is a much higher-level use of the sequence diagram than we require here and doesn't specifically model a concrete use-case pathway, at least not to the level at which we have defined our use-cases.
Additional adornments can be added to the sequence diagram, the most important of which are the following:
Script: Script comments are aligned to the left of each message flow. Often a script gives a detailed description of a task taken directly from the pathway detail of the use-case.
Latency and timing: Latency and timing allow us to designate time constraints on message send-and-receive semantics.
Guard condition: The guard condition is a means to show condition checking. It allows us to introduce branching considerations.
Iteration: Iteration allows us to note repetitive message sequences until a given guard condition is met.
Synchronization semantics: Synchronization semantics allows us to identify messages that are nonblocking and that follow the “fire-and-forget” paradigm (asynchronous message—probably the most used). Other messages that fall into this category are classified as simple (the default), synchronous, timeout, and balking.
Sequence Diagram of the Happy Path
We begin our modeling by creating a sequence diagram of the use-case happy path. Recall that the happy path is the most commonly occurring pathway through the use-case (for the Process Orders use-case, the happy path is Customer calls and orders a guitar and supplies, and pays with a credit card). If this pathway is modeled first, the other sequence diagrams should simply be variations of the happy pathway's diagram. In this way we reduce the amount of work required, while adding the most artifacts (e.g., operations, attributes) to the class diagram in the shortest amount of time.
The class diagram benefits a lot from the dynamic modeling process because every message sent to an object results in an operation's being assigned to the target class. Figure 7-4 is the use-case diagram we defined during project scoping in Chapter 4. In particular, we deal in this chapter with dynamic models for the use-cases that are part of Increment 1 of Remulak Productions' deliverable, as specified in the figure.
Figure 7-4. Remulak use-case diagram
Recall from Figure 4-4 the Architecture Infrastructure shadow technical use-case. The first increment outlined with the package diagram is shown in Figure 7-5. This shadow use-case is not shown on the business view of the Remulak use-case diagram in Figure 7-4 because the use-case focuses on the infrastructure needed for communication to occur among the user interface, the Business Rule Services layer, and the Database Services layer of the application.
Figure 7-5. Increment 1 package diagram
What follows is the completed use-case template (without pathway detail) for the Process Orders use-case. This is the same template that was introduced in Chapter 4.
Use-Case Template
Use-Case Description Information
1.1 Name
Process Orders.
1.2 Goal
This use-case satisfies all of the goals of setting up a new order. This applies for both new and existing customers. All aspects of the order entry process are covered, from initial entry to ultimate pricing.
1.3 Use-Case Team Leader/Members
Rene Becnel (team lead), Stan Young, Todd Klock, Jose Aponte.
1.4 Precondition
Order clerk has logged onto the system.
1.5 Postcondition
Order is placed, inventory is reduced.
1.6 Constraints/Issues/Risks
The new system might not be ready in time for the summer product promotions.
1.7 Trigger Event(s)
All events dealing with new and existing customers calling and placing an order.
1.8 Primary Actor
Order clerk.
1.9 Secondary Actor(s)
Customer.
Use-Case Pathway Names
2.1 Primary Pathway (Happy Path)
Customer calls and orders a guitar and supplies, and pays with a credit card.
2.2 Alternate Pathway(s)
Customer calls and orders a guitar and supplies, and uses a purchase order.
Customer calls and orders a guitar and supplies, and uses the Remulak easy finance plan.
Customer calls and orders an organ, and pays with a credit card.
Customer calls and orders an organ, and pays with a purchase order.
2.3 Exception Pathway(s)
Customer calls to place an order using a credit card, and the card is invalid.
Customer calls with a purchase order but has not been approved to use the purchase order method.
Customer calls to place an order, and the items desired are not in stock.
Use-Case Detail
A Section 3 will exist for all use-case pathways that are detailed enough to warrant their own unique set of steps. In this case only the happy path and the payment variation are shown.
3.1 Pathway Name
Customer calls and orders a guitar and supplies, and pays with a credit card.
3.2 Trigger Event(s)
All events dealing with new and existing customers calling and placing an order.
3.3 Main Sequence of Steps
Step Description 1 Customer supplies customer number. 2 Customer is acknowledged as current. 3 For each product that the customer desires: 3.1 - Product ID or description is requested.
3.2 - Product description is resolved with ID if necessary.
3.3 - Quantity is requested.
3.4 - Item price is calculated.
4 Extended order total is calculated. 5 Tax is applied. 6 Shipping charges are applied. 7 Extended price is quoted to customer. 8 Customer supplies credit card number. 9 Customer's credit card is validated. 10 Inventory is reduced. 11 Sale is finalized. 3.4 Variations
Step Description 8.1 Customer may pay with purchase order or easy finance plan. 3.5 Extensions (optional)
None.
3.6 Business Rules (optional)
Customers may not order more than ten products at one time.
Any sale over $50,000 requires supervisor approval.
Any sale over $20,000 receives a five-percent discount.
3.7 Constraints/Issues/Risks (optional)
Timeliness of the product is key to the next sales promotion.
Use-Case Tactical Information
4.1 Priority
Highest (#1).
4.2 Performance Target(s)
None indicated.
4.3 Frequency
Customer calls and orders a guitar and supplies, and pays with a credit card (800/day).
Customer calls and orders a guitar and supplies, and uses a purchase order (120/day).
Customer calls and orders a guitar and supplies, and uses the Remulak easy finance plan (25/day).
Customer calls and orders an organ, and pays with a credit card (40/day).
Customer calls and orders an organ, and pays with a purchase order (15/day).
4.4 User Interface
This portion of the application will not use the Web as a form of entry because of the need for clerk assistance.
4.5 Location of Source
Newport Hills, Washington.
Portland, Maine (in the future).
We must determine the classes needed to build the first draft of the sequence diagram. We choose from the class diagram in Figure 7-6.
Figure 7-6. Remulak class diagram: First draft
The following objects are selected:
Customer
Invoice
Order
OrderLine
Payment
Product
Figure 7-7 shows a first attempt at the sequence diagram for Remulak Productions and the happy path of the Process Orders use-case. In this view of the sequence diagram, sequence numbers are included to allow easier reference to specific messages. However, sequence numbers on a sequence diagram are optional because time flows from top to bottom in such diagrams.
Figure 7-7. Remulak sequence diagram: First attempt
The sequence diagram forces us to ask some serious questions about the other UML artifacts, especially the classes and associations between classes. A message cannot be sent between two objects unless an association is defined between the classes that represent the objects. If a use-case pathway requires communication between two objects whose classes have no such association, the class diagram is incorrect. In addition, early iterationz`s of a sequence diagram might require that additional classes be created to satisfy the requirements specified in the pathways. These new classes may be any of the three types discussed in Chapter 5: entity, boundary, and control.
The sequence diagram also forces us to focus on good object-oriented design concepts. As messaging patterns begin to emerge, we will need to address some sound object-oriented design practices. One of these is the notion that classes in the solution set should be loosely coupled and highly cohesive.
Class Coupling and Cohesion
Classes are considered loosely coupled if generally the associations between them are minimal. This doesn't mean that we should skimp on associations. If an association is needed, then by all means we should add it to the model. However, if a new class, usually a control or boundary class, can be introduced to funnel messages, and thus reduce the overall number of associations, then going this route will make the design more resilient in the long run.
The reason is that every class association has eventual code ramifications in the form of references to other classes; these references are needed to allow messages to pass between the classes. Imagine the impact of a change to the domain and the resulting possible rippling to all of the associations. The amount of code that must be changed might be minimal, but if that code is in the interface, enormous amounts of regression testing might be necessary.
A good place to reduce class coupling is aggregation/composition associations. By nature these associations insulate their components from future changes. As an example, consider in the case of Remulak Productions the composition association between Order and OrderLine. Order is the “boss”; all messages should flow through the boss if at all possible. Nothing prevents our adding several associations to all of Order's components. However, if the structure of an Order later changes, the impact of the change could be substantial.
In the sequence diagram in Figure 7-7, notice that any messages dealing with a component of Order are initially sent to the Order object. Message 4 (create()) could have originated from the order clerk actor, but it actually originates from Order. The same is true for message 5 (addProduct()). Although Order will have several “pass-through” shell operations that delegate work to its component parts, the solution is much more flexible.
You can also place classes that reduce coupling in the interfaces between packages (this will be required for Remulak Productions' security, audit, and archiving subsystems). These packages also happen to be use-cases. Recall from Chapter 5 that a control class was created for every use-case in Increment 1.
A class is considered highly cohesive if it adheres to the adage that “a class should do only one thing and do it well.” Consider a class that does too many things. In our case, what if Order directly handled all of the responsibilities of its composite? Instead of two classes, we'd have just one. But Order would have taken on responsibilities that far exceed its original charter. The same issues that surfaced regarding coupling also show up with classes that are not highly cohesive. The design is improved by having each of the two classes continue to do one thing well. We can make this possible only by defining them as separate classes.
We learn as we go. In the case of Remulak Productions, some of the messaging didn't work, thereby requiring some changes. The issue here concerns tax calculation and shipping charges. The sequence diagram shows messages 10 and 11 (calcTax() and calcShipping()) being sent, privately, to the Order class. However, this raises the question about where to maintain the specific tax and shipping information. Order isn't a good solution. So we need to create a new class that manages not only the rates to charge but also the necessary algorithms for calculating the extended charges. For now, let's call this new class Charge. After further design of the class, we might find that Charge is an ancestor class to more specialized classes in the form of Shipping and Tax.
We also need to modify message 14 (validateCard()). The Order class isn't very smart regarding credit card validation—and it shouldn't be (remember: do one thing and one thing well). Thus the Order object should not receive the validateCard() message. Recall from Chapter 5 that we identified the boundary class CreditCardInterface. This is the object that should receive the validateCard() message.
One last observation about the sequence diagram: It does not reflect the iterative nature of buying multiple products. At present, the diagram applies to just one product. To make it more flexible, we add the ability to note iteration, simply by adding a note and then referencing the exact sequences that can repeat (see Figure 7-8).
Figure 7-8. Remulak sequence diagram with iteration
Sequence Diagram for an Alternate Pathway
Now that we've modeled the happy pathway with a sequence diagram, creating a sequence diagram for an alternate pathway is easy. Let's look at one of the alternate pathways for the Process Orders use-case (Customer calls and orders a guitar and supplies, and pays with a purchase order). The sequence diagrams for the happy and alternate pathways differ only in message 14, as shown in Figure 7-9. We need a message sent back to the order clerk that validates the authorization and good-through-date components of the Payment class. Figure 7-9 shows the sequence diagram for this alternate pathway of the Process Orders use-case.
Figure 7-9. Remulak sequence diagram for an alternate pathway
Although our biggest job generally will be diagramming the happy path, this could change depending on the complexity of the alternate pathways. Also, depending on the granularity of the project's use-cases, the alternate pathways might be very distinct.
Transferring Knowledge to the Class Diagram
The power and benefits that result from using a visual modeling tool really become evident during the creation of sequence diagrams. Leading modeling products allow operations to be added dynamically to the classes represented by the objects on the diagram. This is fine, but the impact of this dynamic addition of operations enforces two key elements of good project management and software design:
As operations are added to the classes, subsequent messages to the same class instance will display the newly added operations, thereby allowing them to be selected from the list. This feature forces us to focus on reusing existing operations instead of working in a vacuum and duplicating work.
Most class operations will be defined just by diagramming of the happy pathway for each use-case. The speed with which we diagram can increase a lot as the first few sequence diagrams take shape.
Figure 7-10 shows the use of Rational Rose to add or select operations during the sequence diagramming process. We can add a new operation by clicking the <new operation> option, which opens the operation creation dialog box. Also under the <new operation> option is a list of operations already present in the Order class from which we can select.
Figure 7-10. Rational Rose visual modeling tool
Notice, too, the diagram's tree view pane in the upper left-hand corner of the window. The Process Orders use-case shows in the tree view; beneath it is a list of the associated sequence diagrams. The organization of the tree reinforces the steps taken in the Unified Process. What start out as events become pathways through a use-case. Those pathways eventually are rendered as sequence diagrams that show the dynamic interaction of objects necessary to realize the goal of the use-case.
Walking through the Sequence Diagram
We still need to create a sequence diagram that shows how the user interface will communicate with the essential use-case pathway of placing an order. We turn our attention now to using the sequence diagram to walk through the application to ensure its integrity. The sequence diagram is the primary vehicle for walk-throughs. Code walk-throughs become less of an issue when UML is used.
Although sound coding standards are still necessary (How will variables be defined? How are classes defined?), the integrity of the system is depicted through the perspective of the sequence diagram. Once the project team gets used to the idea, the creation of the sequence diagram will become an invaluable task on the project plan.