IBM
Contents Index Previous Next



Analysis Use Case Model


The purpose of the analysis use case model is to show the dynamic view of how the functionality of the system is decomposed in the same way as the analysis object model describes the static view of the decomposition. This implies that the internal communication between the various parts of the system is the major concern for this activity. Two different types of use cases can be distinguished in the analysis use case model:

Refined Requirements

The analysis use cases that are refined requirements are simply the use cases from the requirements analysis refined to the analysis object model level. Each requirements use case is distributed among the objects from the analysis object model. The purpose of these use cases is mainly to document how the logical architecture as described in the analysis object model is capable of implementing the requirements that are expressed by the use cases. In practice this is done by taking each of the use cases defined in the requirements analysis and reformulate it in terms of the objects that are defined in the analysis object model. It is possible to use both the textual use case notation and the MSC notation to represent the use cases, but since the purpose of the analysis use case model is to show how the functionality is distributed among the objects the MSC notation is especially useful. As in the requirements analysis, HMSCs can be used to simplify the use case model.

Consider again the access control system with a logical architecture according to Figure 645 where the system is divided into a DoorCtrl, a CentralCtrl and an OperatorCtrl components. If we take the Enter building use case as defined by an MSC in Figure 637 and replace the system with the three components we get an MSC as shown in Figure 651.

Figure 651 : The Enter Building use case distributed over a logical architecture

In this MSC we can see that the original system instance is replaced by instances of DoorCtrl, CentralCtrl and OperatorCtrl. This use case deals mainly with the handling of user interaction at the door and since this is the responsibility of the DoorCtrl most of the action is performed by this component. Only the validation of the card and code is performed centrally.

It is easy to see that the strategy outlined above is extendable to allow a decomposition of a system into not only one level of components, but into a hierarchy of components. For each new level of decomposition all use cases that involve the decomposed components are taken as input to the validation of the new decomposition. The component that was decomposed is replaced by the new components and new versions of the use cases are created.

Behavior Patterns

When designing the object structure for a system there is often a need to document behavior patterns that involve one or more objects that participate to fulfill a common objective. Sometimes this can be described in the refined requirements use cases, but there are two advantages of creating special use cases for specific mechanisms and behavior patterns:

As an example consider the keyboard interface of the access control application. The purpose of the keyboard is to allow the user to enter a code consisting of four digits. In a refined requirements use case showing a user entering an office by pushing the digits on a keyboard this can be shown using an MSC reference symbol, as in Figure 652.

Figure 652 : Part of a refined requirements use case

What happens when the user enters a code is thus described in the MSC Enter_Code. We see that it is the user and the DoorControl object that are involved in this interaction.

However, there is of course a specific protocol for Keyboard objects that defines how they interact with the user and the DoorCtrl that is not shown on the abstraction level of the refined requirements use case. This may for example look like in Figure 653, which shows the behavior pattern use case Enter_Code.

Figure 653 : A behavior pattern use case showing the
protocol for Keyboard interface objects

Other examples of behavior patterns that may need special use cases are internal communication between different parts of a system using proxies (i.e. local dummy objects that are used instead of a remote object and hides the communication aspect from the user of the proxy), initialization protocols that describe how various objects are created and exchange information, and in general all other tactical solutions to problems that need a special explanation in the system analysis.


http://www.ibm.com/rational
Contents Index Previous Next