Use Case Modeling - Practices

The main goal of use case modeling is to understand user needs and to enable you to view a system from the customer’s point of view. Use cases describe how actors interact with the system in order to achieve some business purpose. They are procedural descriptions of the process of functional decomposition.

Even though use cases aren’t object-oriented in nature, this doesn’t mean that use cases have no value in OOAD, on the contrary, they are good vehicles for the understanding of user requirements and for the planning of deliverable milestones in a system.

That said, it’s important to use caution when modeling with use cases because they could lead to the definition of procedures without a proper understanding of the problem domain. This can lead to the creation of many “artificial” classes to support a specific use case that taints and distorts the essence of the domain being modeled. As long as you understand this you should have no problem with use cases.

In our experience use cases are of great value to the implementation of test cases and they promote a test-driven (test-first approach) process. In this sense the completion of a use case becomes a tangible deliverable that can provide instant feedback to the system’s stakeholders. With the current emphasis on service-driven architectures, use cases are a good vehicle to define the goals of services and are useful in the definition of service-oriented components (like session facades, as you’ll see in Chapter 5).

Use Cases and the Domain-Neutral Component

Applying the DNC makes for a great preamble to modeling use cases because it helps prevent one of the cardinal sins of use case modeling: uses cases dictating an object-model’s structure. When use cases drive a model’s shape the model effectively becomes a slave of the current functionality being addressed and no longer is a true representation of the business. This means that although a use case might give you a clear understanding of a single interaction between an actor(s) and the system, it doesn’t give you an understanding of the problem domain (as the domain model does), which can lead to “design tunnel vision.”

To an extent, you can equate the Moment-Interval classes with either a use case, part of a use case, or an encapsulation of one or more use cases. Use cases are typically documented as short but concise textual descriptions or scenarios— a concept similar to XP’s User Stories, which represents a “story” about how a system solves a particular problem.

Use Cases Overview

Use cases are primarily delivered as documents. There are many “templates” floating around in the industry that do a good job of explaining use cases, from flowing textual descriptions to enumerated bullet point step-by-step descriptions. These descriptions are usually structured around a normal flow of events, which are often referred to as a success scenario. These scenarios differ from the normal flow of events, which are documented as extensions or variations. For a sample template see Alistair Cockburn’s website (http:// www. usecases.org/).

In use case modeling the concept of an actor plays a central role. An actor is a role that some entity plays while the system is being analyzed or designed. Typically, actors are classified as primary and secondary actors. Primary actors are those that are deriving business value from an interaction with the system, while secondary actors are those that the system interacts with in order to fulfill the needs of a primary actor. In the case of the TCMS system, your defined stakeholders map directly to primary actors in your use cases.

At a higher level, a use case diagram can show the associations among use cases and the primary and secondary actors involved. In the case of the TCMS system you started with a high-level use case diagram to get a birds-eye view of the functionality that the system must satisfy. Like class diagrams, use case diagrams provide display associations between the use cases in the system. A use case diagram helps you organize the functionality of a system. A use case diagram is the primary artifact used in defining the services and the components that fulfill them.

Use case diagrams consist of actors (usually represented by a stick figure), use cases (represented as an ellipse), and optionally, a rectangle enclosing the use cases, which denotes a system boundary or simply groups the use case model. There are three relations between use cases: extend, include, and generalization.

• Extend: Represents an extension on behavior and not in structure. It signifies that the extending use case contains added behavior, not alternatives or exceptions. The new use case doesn’t alter the behavior produced by the base use case. Extension points are used to determine when the extended case applies inside the base case.
  
• Include: Represents containment of behavior. Think of it as a use case that “invokes” the behavior of another use case at a specific point in a use case.

   

• Generalization: Implies an “is like” relationship between use cases. Generalization is used whenever a use case is conceptually similar to another use case.

   

Creating a Use Case Diagram in ArgoUML

To create a use case diagram in ArgoUML you follow steps similar to those used to create a class diagram:

1. Select the use case diagram. In the Explorer, under the tcms model, expand the domain package under the model and select Usecase Diagram. The toolbar should now change to the use case diagram controls.

    

2. Add actors. Using the toolbar controls, you can add different elements to the diagram including actors. Add four actors: attendee, presenter, administrator, and sponsor. This is similar to working with classes. If you select an actor on the diagram its properties (such as the name) can be changed in the Details pane on the Property tab.

    

3. Add use cases. Using the toolbar controls, you select the use case (white ellipse) and click anywhere on the diagram. Next, rename the use case to Browse Schedule. Repeat this step for a use case named Add Schedule Reminder.

    

4. Add associations. Using the Association drop-down list on the toolbar, select the directed association (on first row, right-most element in the drop-down list, which is an arrow pointing to the right). Connect the attendee actor to the Browse Schedule use case. Next, using the extend association in the toolbar (the upward-pointing segmented arrow with an “E” on the left) connect the Add Schedule Reminder use case to the Browse Schedule use case.

    

The use case diagram should now resemble Figure 2-13.

Figure 2-13. Partial use case diagram

Chapter 2 Table 2-7. TCMS Preliminary List of Use Cases (Continued)

The resulting use case diagram—the TCMS use case model—is shown in Figure 2-14.

Figure 2-14. The TCMS use case diagram