Chapter 4: Use Cases and Actors

diagrams will show you sets of use cases and actors. You may also want to create a single diagram with all of the use cases and all of the actors. How many Use Case diagrams you create and what you name them is entirely up to you. Be sure that the diagrams have enough information to be useful, but are not so crowded as to be confusing.

Tip Rational Rose can automatically create diagrams with all modeling elements in a package. In the rose.ini, set the AutoConstructMainDiagrams=Yes flag to enable this feature and a main diagram will be automatically created for each package with all modeling elements of the package.

Use Case diagrams fulfill a specific purpose: to document the actors (everything outside the system scope), the use cases (everything inside the system scope), and their relationships. Some things to keep in mind as you are creating Use Case diagrams include:

∙

Do not model actor−to−actor associations (although generalizations are OK). By definition, the actors are outside the scope of the current project. The communication between the actors, therefore, is also outside the scope of what you're building. You can use a workflow diagram to examine the actor associations.

∙

Do not draw an association directly between two use cases (although includes or extends relationships are OK). The diagrams show what use cases are available, but don't show in which order the use cases will be executed, so there shouldn't be an association between use cases.

∙

Every use case must be initiated by an actor. That is, there should be an arrow starting with an actor and ending with the use case. Again, the exception here is an includes or extends relationship.

∙

Think of the database as a layer underneath the entire Use Case diagram. You can enter information in the database using one use case, and then access that information from the database in another use case. You don't have to draw associations from one use case to another to show information flow.

Activity Diagrams

An activity diagram is another way to model the flow of events. Using text, as we did in the example above, is useful, but it can be difficult to read and understand if the logic is complex, if there are a lot of alternate flows, or if your customers simply prefer diagrams over text.

An activity diagram shows you the same information as a textual flow of events would. We use activity diagrams in business modeling to depict the workflow through a business process. Here, we will use them to depict the flow through a piece of the system.

Figure 4.7 is the activity diagram that corresponds to the flow of events for purchasing an airline ticket from earlier in this chapter.

119

Chapter 4: Use Cases and Actors

Figure 4.7: Activity diagram

As you can see, the activity diagram can be an easier way to communicate the steps in the flow. Let's look at the different pieces of notation in this diagram.

Activity

As the name implies, an activity is one of the essential pieces of an activity diagram. An activity is simply a step in the process. The steps we outlined in the text above become our activities here. An activity is modeled using the following symbol:

We can add more detailed steps to the activity by using actions. Actions are smaller steps that take place within an activity. They may occur at one of four times:

∙

Upon entering the activity. An entry action occurs as soon as the activity begins, and is marked with the word "entry."

∙

When exiting the activity. An exit action occurs as you are leaving the activity, and is marked with the word "exit."

∙

While performing the activity. These actions occur while in the activity and continue until you leave the activity. They are marked with the word "do."

∙

120

Chapter 4: Use Cases and Actors

Upon a specific event. These actions happen if and only if a specific event occurs. They are marked by the word "event," followed by the event name.

Actions are optional, but they can give us detailed information that will help us complete the system design later. If actions are included, they are displayed inside the activity, regardless of which of the above four categories they fall into. Here is an example of an activity with actions:

In this example, the actions show the steps within the "display available flights" activity. When the activity first begins, the system will find all flights for the selected cities and dates, and then determine which of these flights has available seats. While inside the activity, the system displays a list of flights and highlights the one with the lowest fare. Finally, upon the event that the user wishes to see fare information, the system will display the fare information.

Start and End States

The start and end states let you know where the flow begins and ends. Each activity diagram must have a start state, which is drawn as a solid dot, to signify where the flow begins.

End states are optional on the diagram. They show you where the flow ends, and are represented by a bull's−eye. You can have more than one end state on the diagram, but only a single start state.

Objects and Object Flows

An object is an entity that is affected by the flow. It may be used or changed by an activity in the flow. On an activity diagram, you can display the object and its state so that you can understand where and how the object's state changes.

Objects are linked to activities through object flows. An object flow is a dashed arrow drawn from an activity to the object it changes, or from the object to the activity that needs to use it.

121

Chapter 4: Use Cases and Actors

In this example, once the user enters their credit information, a ticket is created with a status of "unconfirmed." Once the credit processing is complete and the credit is approved, the "reserve seat" activity occurs, which sets the state of the ticket to "purchased." These are both examples of how an activity can change an object.

An object can also serve as input into an activity. In this example, in order to generate a confirmation number, the system must have a purchased ticket. The ticket is therefore input into the "generate confirmation number" activity. In either case, the relationships between the activities and the objects are drawn as dashed arrows and are known as an object flow.

Transitions

A transition shows how the flow of control moves from one activity to another. In the simplest situation, a transition is simply an arrow from one activity to another:

In this simple situation, we can assume that as soon as one activity ends, the next begins.

We can, however, set limitations on the transition to control when the transition occurs. This can be done either by using an event or a guard condition. If an event is specified for a transition, the event must happen in order for the transition to occur. The transition arrow is labeled with the event name, along with any arguments in parenthesis.

Here we can see that if the user changes their mind and performs a cancel event, the purchase price will be refunded and the ticket will be canceled.

While an event triggers a transition, a guard condition controls whether or not the transition can occur. If a guard condition is present, it must be true in order for the transition to occur. The guard condition is listed along the transition arrow, following any event, and is enclosed in square brackets:

In this example, a new confirmation number is needed only if there is a new reservation made. If we are changing an existing reservation, the old confirmation number will remain. Because we need to generate a confirmation number only if this is a new reservation, "New reservation" becomes our guard condition.

Synchronization

A synchronization is a way to show that two or more branches of a flow occur in parallel. In our example, if we want to show that the system would—at the same time—reserve a seat, generate a confirmation number, generate a receipt, and e−mail a receipt before displaying the confirmation number, the diagram would look

122