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.
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:
The use case diagram should now resemble Figure 2-13.
If you feel adventurous you can complete the use case diagram using the list of use cases shown in Table 2-7. A use case diagram consisting of the collection of all actors and all use cases. It’s referred to as the use case model.
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.
blog comments powered by Disqus