IBM
Contents Index Previous Next



Design Use Case Model


The static interface definition alone is not enough to define how the blocks are supposed to cooperate to meet the requirements on the system. In the requirements and system analysis, use cases were used to describe the requirements on the system. This is continued in the system design to define the dynamic interface between the blocks in the system. Essentially the idea is to take each one of the use cases found in the system analysis and formalize this to a sufficient degree of detail that is consistent with the level of detail that is found in the static interface definitions. The degree of detail must be precise enough to make the design use cases act as detailed test specifications.

A benefit with the design use cases is the structured way in which they are constructed. It is easy to verify that all requirements as expressed by the requirements use cases and refined in the analysis use cases are handled by the design use cases and this gives a formal link between the requirements and the structure of the system that implements it.

In a development environment where the different blocks are developed by different teams they also form a necessary common definition of the responsibilities of their respective blocks and how their blocks are to together fulfill the requirements on the system.

From a practical perspective this puts some requirements on the notation used to describe the design use cases:

There are two levels of testing of interest for the design use case model:

Module testing is intended to test one specific part of the system and should check that this particular part of the system fulfills its requirements. The system testing is intended to test the integration of the different parts and check that they together fulfil the requirements on the total system.

The design use case models should form the basis for both kinds of testing.

Another aspect of testing is when in the development project it is performed. One of the benefits of SDL is that it is possible to test already on the design model, essentially testing against a simulation of the SDL system. In addition there is of course also a need to test the implementation in the target environment, but if the logics of the application already has been tested during design then the focus of the target testing can be on target integration issues and the risk for logical errors in the design is reasonably small. The design level testing is further discussed in "Design Testing" on page 3952.

In SOMT two different alternative notations are used:

Usage of MSC

MSCs can be used in a way that is precise and formal enough and can automatically be checked against SDL design models. A benefit is that it is used also in requirements analysis and system analysis and is intuitive and easy to understand also for non-experts. Notice however that there is a difference between the analysis use cases and the design use cases. The fairly abstract messages exchanged between the instances in the analysis use cases must in the design use cases be refined to the level of the static interface definitions, this may include specifying parameter values that where left out and even replacing one message with a sequence of message exchanges. It may also often be necessary to have more than one design use case for each analysis use case, for example to handle a situation where the analysis use case has left out a parameter and there is a need to test more than one combination of parameters.

Consider again the access control system with a decomposition according to Figure 656 where the system is divided into a DoorCtrl, a CentralCtrl and an OperatorCtrl block. If we take the Enter building use case as defined on requirements level by an MSC in Figure 637 on page 3849 and refined to the analysis use case in Figure 644 in chapter 72, System Analysis. When further refining this to a design use case we get an MSC as shown in Figure 663 where some of the messages have been refined.

Note that an MSC describes both the requirements on the separate parts of the system and the requirements on the whole system. This implies that the same MSC can be used to define both module and system tests.

Figure 663 : The Enter building use case distributed over an architecture

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 blocks, but into a hierarchy of blocks. For each new level of decomposition all use cases that involve the decomposed block are taken as input to the validation of the new decomposition. The block that was decomposed is replaced by the new blocks and new versions of the use cases are created.

Usage of TTCN

TTCN is another notation that is suitable for formalizing use cases on the design level. The benefit of TTCN is that it is a special purpose language for test description including:

TTCN is also an established notation for test description so there is good tool support for executing TTCN test cases on target platforms.

The drawback is that it has not a particularly intuitive syntax, making it more difficult for non-experts to maintain, create and review TTCN test suites.

If TTCN is used to define both system and module testing each analysis use case will result in several TTCN test cases, one for each part of the system and then one for the entire system. As an example consider Example 649, that shows a test case testing the requirements from the Enter_Building use case on a DoorCtrl, and Example 650, that shows a test case testing the requirements from the Enter_Building use case on the entire AccessControl system.

Example 649 : A TTCN test case testing a DoorCtrl

1  UsrPCO?Card                                     Card1

2    UsrPCO?Display                                Enter_Code

3      UsrPCO!Digit                                Digit1

4        UsrPCO!Digit                              Digit1

5          UsrPCO!Digit                            Digit1

6            UsrPCO!Digit                          Digit1

7              CentralPCO!Validate                 Validate_1

8                CentralPCO?Accept                 AcceptOK

9                  DoorPCO!Unlock                  Unlock!

10                   UserPCO!Display               Please_Enter

11                     DoorPCO?Open                Open1

12                       DoorPCO?Close             Close1

13                         DoorPCO!Lock            Lock1

14                           UserPCO!Display       Enter_Card P

Example 650 : A TTCN test case testing the AccessControl system

1  UsrPCO?Card                                     Card1

2    UsrPCO?Display                                Enter_Code

3      UsrPCO!Digit                                Digit1

4        UsrPCO!Digit                              Digit1

5          UsrPCO!Digit                            Digit1

6            UsrPCO!Digit                          Digit1

7              DoorPCO!Unlock                      Unlock!

8                UserPCO!Display                   Please_Enter

9                  DoorPCO?Open                    Open1

10                   DoorPCO?Close                 Close1

11                     DoorPCO!Lock                Lock1

12                       UserPCO!Display           Enter_Card P


The choice between MSC and TTCN as design use case notation is very much influenced by application and development organization aspects:


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