Developing a Collaboration | UML 2 For Dummies

In the following sections, we outline the design of a GenerateBill use case using some of the communication diagram features. This process starts with the analysis class diagram for the classes that must participate in this use case, which we change by adding some specific design features to help accomplish the use case’s behaviors.

As the class diagram evolves to incorporate the design of the use case and appears to stabilize, you construct a communication diagram that walks through the designed interaction, showing the step-by-step interchange of message over the objects and links participating in our use case.

As you make decisions in the communication diagram, go back to the class diagram to ensure consistency. You need individual communication diagrams to capture different scenarios of the use case. This suite of communication diagrams and the class diagram evolve to capture the design details of the dynamic behavioral view and static class view consistently.

Structuring a design class diagram

When you construct a communication diagram, you need to identify the participating objects and lay them out in a static structure diagram, such as a class diagram. You can find more about the typical features of these diagrams in Chapter 3 and Chapter 5.

Figure 14-1 shows the initial class diagram drawn during analysis for the example use case GenerateBill. In the example diagram, you can see that each Room has an ordered set of Stays (indicated on the diagram by the property {ordered} and the multiplicity * ), and for each Stay and date, there is an associated RoomRate. A RoomRate can be for multiple Rooms, but for each combination of a Stay, a date, and a RoomRate, there is an association class Lodging that has some information about the specifics on that date, such as the number of occupants for that day.

For each Stay and date there is also a set of RoomCharges that can be applied—which might include things like room service or videos. We could have hooked the RoomCharges to the Lodging instead of directly to the Stay, but we felt that the RoomCharges are probably generated by different subsystems than the Lodging charges, so it’s probably better to separate the responsibilities.

Figure 14-1: Initial class diagram for the GenerateBill use case.

Focusing on a central class

A central class or focus class is the class that a use case appears to be most concerned with—usually creating, finding, or manipulating instances of that class or using it to find other information needed by the use case. You can see that the central class for this use case is Stay, as most items of information needed for the use case—in particular, the items on the bill—are available close to the Stay class. Though the needed information is accessible from the other classes, the distance from the Stay is the shorter. Of course, the measure here isn’t the physical distance on the diagram, it’s how many hops it takes to get to the information.

When you can identify the central class for a use case or operation, you have a head start in designing the collaboration. For example, as the interaction among the classes kick off, much of the behavior will need to be focused on how to find the correct instance of the central class. After it is found, this instance will probably be the correct place to assign most of the work. Knowing which class is the central class will allow you to focus your attention on the right place.

Now that we know that the central class is Stay, we need to design our approach to finding the correct instance of Stay as the use case runs. From the logic of the situation, it appears that the actor can be asked for the room number. To help find the correct instance of the central class (Stay), we create a HotelInventory class that acts as a container holding all the available rooms of the hotel. Its main behavior will be to find a particular Room object given a room number. (Refer to Figure 14-3 later in this chapter to see how this design-time container class is positioned.) The HotelInventory container uses the qualifier roomNumber as an index to the Rooms. If you know the roomNumber you can use the HotelInventory to find the Room you want. (The use of qualifiers as indices on associations is discussed in Chapter 4.)

From the correct Room, the use case then needs to find the correct Stay. We assume that the GenerateBill use case is normally started upon guest checkout, so we can use the latest Stay associated with the Room. It’s possible to find the latest Stay from the Room, because the Stays are ordered from the perspective of the Room (back to the {ordered} property on the diagram).

Controlling a use case

Whenever you have a complex use case, you should consider which object controls and organizes the required behavior. Typically, no existing object from the initial class diagram will do. Though each object has its own natural responsibilities that are found by analyzing the use case and the problem domain, the control and organization responsibilities tend to be part of the solution and need to be added. Following good design practice of keeping our classes focused on doing one thing and doing it well, you shouldn’t add these new responsibilities to any of the existing classes. Therefore, you need to design a new class—a use-case controller class that will initiate and coordinate the activities of the classes to meet the needs of the use case. Typically in these circumstances, you would name the use-case controller class with the name of the use case, GenerateBill, as you can see in Figure 14-3.

Tip We recommend that you flag your controller classes with a special stereotype, such as «use-case controller» or «control» to remind the designer of the special features that controllers usually have. (We use «controller».) For example, a use-case controller typically requires its own active thread at run-time and is also ultimately responsible for the interaction with the actor.

As you progress, you’ll often find other common design changes being made to standard modeling approaches. For example, when you see an association class, such as the Lodging class in Figure 14-1, you may need to convert it to a class that lies as an intermediate class between the ends of the original association (an inline class). You can see an example of how to do this in the sample diagram of Figure 14-2. This diagram shows the trick of keeping the promoted multiplicities correct. The outer multiplicities become inner multiplicities—they switch sides on the promoted class—and the outer multiplicities are replaced with 1.

Figure 14-2: Promoting an association class to an inline class

Though there are other possible design/implementation approaches to association classes, the transformation shown in Figure 14-2 is the most common because it’s easy to implement and easy to make the objects live in a database. We promote the association class Lodging in this manner in Figure 14-3.

Figure 14-3: A class diagram incorporating initial design for GenerateBill.

Adding an output class

There is at least one more design class you need to add to the initial diagram shown in Figure 14-1. Because our use-case GenerateBill produces a bill, you must make sure that the Bill class is on the diagram. (Granted, that should be obvious, but the lack of it is a common error found in many diagrams.) For now, hang the Bill class off the use-case controller (as in Figure 14-3).

Preparing the participants

Using the class diagram as a guide to designing the collaboration, you need to select the appropriate participants. We use a UML object diagram (as described in Chapter 7) or a UML composite structure diagram (as described in Chapter 5). In order to make such a diagram, you identify the objects (instances) that need to participate, or you convert the classes to parts. (You can treat the participating instances as internal parts of the collaboration in the same manner as you treat internal parts of a class using the treatment found on composite structure diagrams that we discuss in Chapter 5.) The parts use the same syntax as those of lifeline references as described in Chapter 12.

The basic name of the part/lifeline references for these purposes is as follows:

 referenceName[selectors] : className

The component pieces of this syntax are as follows:

referenceName is the handle you use to refer to the part. It may be the rolename of the participating object’s class, the name passed in a parameter or local variable that contains the participating object. The referenceName is optional, so you often see just the class name when there is only one object for that class in the collaboration.
selectors is an optional field that selects a particular object or objects from a set. It may be a qualifier, an indexing subscript, or some Boolean expression. You don’t need it if the referenceName refers to an object with a multiplicity of one.
className is the class or type of the participating object.

Figure 14-4 shows the participating parts of the communication diagrams for the GenerateBill collaboration. In this diagram, the objects for the controller class GenerateBill (which controls the use case) and the container class HotelInventory (which contains and finds Rooms) don’t need any referenceNames or selectors because they are unambiguous (there’s only one of each of them). However, because there are many possible bills, you need to identify a specific Bill. In this model, the specific Bill being constructed is given the name of newBill.

Figure 14-4: The participants of the GenerateBill collaboration.

There are also many rooms in the HotelInventory. To identify the specific Room, we’ve supplied a value rmNum as the selector. This corresponds to the value of the qualifier roomNumber off of the HotelInventory. (Refer to Figure 14-3.)

In the same manner, from the point of view of the [rmNum]:Room, there are still many possible Stays. When you generate a Bill, it’s always for the most recent Stay, so a selector of [latest] is used. Selectors like 1st, 2nd, last, latest, and nth are only allowed when the underlying association between the respective classes is an ordered or sorted association (as indicated by {ordered} or {sorted} on the diagram). If the association is not ordered or sorted, there’s no way of asking for a positional element in effect, it’s just a set of elements without an order.

From the point of view of the [latest]:Stay, there are many Lodging objects and RoomCharge objects. The [date] qualifier can address either type of object, so you can use a value for date or a dateRange as your selector. As either type of object can have multiple instances, you can also put the * multiplicity in the upper-right corner as a reminder.

Finally, the RoomRate class had a rolename of rate in the original class diagram (see Figure 14-1). Use this rolename as the referenceName for the part for consistency among the diagrams.