![]() |
![]() |
![]() |
![]() |
![]() |
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:
- It must be precise and formal enough to allow an specification of test cases on a detailed level of abstraction.
- It should be possible to automatically check the design use cases against the SDL design model.
- There must be a well-defined way to transform the design use cases to executable test programs that can be executed in the target environment against the application.
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.
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:
- Facilities for describing constraints on complex data values
- Preambles and postambles to show how to compose test cases
- Possibilities to handle alternative outcomes of a test case
- A special "verdict" construct to define the outcome of a test case
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 PExample 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:
- It is more efficient if the same test definitions can be used both for design level testing and target testing, so the plans for how to perform the target level testing may have an implication for the choice of notation. If the target testing should be done using a TTCN environment then at least the system tests should be defined in TTCN also for the design level testing.
- On the other hand, if the target tests are performed using an in-house test script notation implying that the same notation can not be used both in design and target testing, then MSC has the advantage of being a simpler notation and is already known and used in the previous activities.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |