I l @ ve RuBoard |
The use case diagram presents an outside view of the system. The functionality of the use case is captured in the flow of events. Scenarios are used to describe how use cases are realized as interactions among societies of objects. A scenario is an instance of a use caseit is one path through the flow of events for the use case. Scenarios are developed to help identify the objects, the classes, and the object interactions needed to carry out a piece of the functionality specified by the use case. Scenarios document decisions about how the responsibilities specified in the use cases are distributed among the objects and classes in the system. They also provide an excellent communication medium to be used in the discussion of the system requirements with customers. "Scenarios speak the language of the end user and the domain expert, and therefore provide a means for them to state their expectations about the desired behavior of a system to its developers." [1]
Each use case is a web of scenariosprimary scenarios (the normal flow for the use case) and secondary scenarios (the what-if logic of the use case). This means that there are numerous scenarios for any given systemall the primary and secondary scenarios for all the use cases. During the early stage of analysis it is safe to say that looking at the primary scenarios for each identified use case is enough. When you find that each new scenario is repeating a lot of steps from previously identified scenarios, then you have reached the finish line. "This phase of analysis should be drawn to a close once the team has elaborated approximately 80 percent of a system's primary scenarios along with a representative selection of the secondary ones. Elaborate upon any more, and your analysis will likely reach diminishing returns; elaborate upon any fewer, and you won't have a sufficient understanding of the desired behavior of the system to properly understand the risks." [2]
In the Rational Unified Process, use case realizations are captured in the Logical View of the model. We will again make use of the concept of a stereotype to show that the use cases that we create in the Logical View of our model are the realizations of the use cases contained in the Use Case View of our model. In other words, the use cases in the Logical View have the same name as the use cases in the Use Case View along with a stereotype of Realization. In the UML, use case realizations are drawn as dashed ovals as shown in Figure 5-1. These Logical View use cases typically are shown on a use case diagram (or set of use case diagrams) contained in the Logical View of your model. CREATING A LOGICAL VIEW USE CASE DIAGRAM IN RATIONAL ROSE
Figure 5-1. UML Notation for a Use Case Realization
A browser view of the Realizations Use Case Diagram is shown in Figure 5-2. CREATING USE CASE REALIZATIONS IN RATIONAL ROSE
Figure 5-2. Use Case Realization Diagram in the Browser
The Realizations Use Case diagram is shown in Figure 5-3. Figure 5-3. Use Case Realization Diagram
Traceability between the use cases in the Logical View and the use cases in the Use Case View is visualized by adding the Use Case View use cases to the Realizations diagram and connecting them to their realizations using a realize relationship. The Realizations Use Case diagram showing traceability is shown in Figure 5-4. Figure 5-4. Use Case Realization Diagram
|
I l @ ve RuBoard |