classes and for the verification of the domain class model against the use case ... or computer-computer interfaces, and the derivation of test cases for statistical ...
Validation and Verification of Use Cases and Class Models Georg Kösters1, Hans-Werner Six2, and Mario Winter2 2
1 ISOWARE GmbH, Feithstr. 142, TGZ, D-58097 Hagen, Germany University of Hagen, Dept. of CS, Feithstr. 140, INF.Z, D-58084 Hagen, Germany {hw.six | mario.winter}@fernuni-hagen.de
Abstract. The description of the functional, behavioral, and structural system essentials form central components of any serious requirements specification. In the UML, for example, functional requirements are expressed by use cases, their behavior modeled by e.g. activity graphs, and structural requirements are captured by class models. Unfortunately, any software development method dealing with different models faces difficulties ensuring consistency of the specifications and completeness with respect to each other. To overcome these deficiencies, we refine activity graphs to meet the needs of a suitable modeling element for use case behavior. The refinement in particular supports the proper coupling of activity graphs and the class model. Granularity and semantics of the approach allow for a seamless, traceable transition of use cases to domain classes and for the verification of the domain class model against the use case model. The validation of the use case model and parts of the domain class model is supported as well.
1 INTRODUCTION The specification of software systems mainly addresses the functional, behavioral, and structural system essentials. In the UML [11], for example, functional requirements are expressed by use cases while structural requirements are captured by class models. For modeling behavioral aspects of use cases, interaction diagrams are mainly used. Unfortunately, an interaction diagram does not capture an entire use case but represents only one specific sequence of actions (a scenario) compatible with the use case. The attempt to specify an entire use case by a set of interaction diagrams also fails, as pointed out in e.g. [13][15]. Regnell et al. define the semantics of use cases with message sequence charts, which can be hierarchically composed to higher structures [14][15]. Because of the level of detail the approach seems to be more suitable for the specification of human-computer or computer-computer interfaces, and the derivation of test cases for statistical usage testing. Glinz proposes an integrated formal model of scenarios based on hierarchical composed state charts [3]. The approach aims at executable specifications and the generation of prototypes, thus focusing on system-internal information on a relatively low level of abstraction. More recently, activity graphs have been considered as a better choice for modeling use case behavior. An activity graph is “a variation of a state machine in which the states represent the performance of actions or subactivities and the transitions are triggered by the completion of the actions or subactivities“[11]. Unfortunately, up to now the semantics definition and the metamodel of activity graphs are in progress and desirable properties are still missing. Following Pohl and Haumer, a use case model should cover three types of information: the system internal information focusing on the system itself, interaction information concentrating on the direct interaction of the
system with its environment, and contextual information representing the system's environment [12]. An activity graph describing the behavior of a use case should therefore capture all three types of information. Since an activity graph focuses on a single modeling element, e.g. an operation, a class, or an entire system, it cannot model the behavior of more than one interacting modeling elements, and in particular cannot cope with interaction information. Concerning the specification of structural system requirements, the UML provides the class model. The class model plays an important role in the system development process because it serves as a central basis for the main development activities [5][10][11]. Summarizing our discussion, in order to capture functional system aspects, their behavior, and structural essentials, a requirements specification deals with use cases, activity graphs, and class models. These different models, however, are based on different modeling techniques and aim at different levels of abstraction, such that serious consistency and completeness problems are induced. In this paper, we propose a refinement of activity graphs to meet the needs of a suitable modeling element for use case behavior. The refinement in particular supports a proper coupling of activity graphs and class models. Granularity and semantics of the approach allow for a seamless, traceable transition of use cases (actually their related activity graphs) to domain classes thus providing the basis not only for consistency and completeness checks but also for the verification of the domain class model against the use case model (comprising use cases and activity graphs). The validation of the use case model and parts of the domain class modelis supported as well. 2 COUPLING USE CASES AND CLASS MODELS 2.1 Actors and Use Cases According to the UML, actors represent the global business context the proposed system will fit in. Actors characterize roles played by external objects which interact with the system as part of a coherent work unit (a use case). An actor is specified by a unique global name and an informal description characterizing its particular role in the problem domain. A use case describes a coherent work unit or task to be carried by one or more actors with the help of the system. A use case is characterized by a unique global name, a set of actors being involved in the work unit, a description of actions being performed, and a pre- and a post-condition specifying the assumptions and the outcome of the use case. Pre- and post-conditions are used similar to contracts in object-oriented programming [10]. They can be formulated using consistent prose and later refined and formalized using e.g. the Object Constraint Language (OCL) [11]. Running example: Throughout the paper we explain our approach using the automatic teller machine (ATM) case study [2][5]. We identify three actors Customer, Bank Host and Operator, and five use cases: Identification, Withdraw Money, Deposit Money, Transfer Funds, and Supply Money. Fig. 1 shows the use case diagram of the ATM. Fig. 2 provides a textual description of the Identification use case. 2.2 Activity Graphs and Actions We exploit activity graphs to model the behavior of use cases. We start characterizing an action by a name that is unique among all actions of the entire use case, an informal description of the action, its type ∈ {contextual action, interaction, macro action}, a
ATM
Supply Money
Withdraw Money «include»
Customer «include»
Operator
Identification «include»
Bank Host
Transfer Funds Deposit Money
Fig. 1. ATM use case diagram
pre- and a post-condition specifying the assumptions and the result of the action, and a set of actors involved in the action. An activity graph is characterized by a non-empty set S of vertices (i.e. actions), a set of directed edges E ⊆ S × S (transitions). Each edge e = (s, s') is annotated by a guard c(e); the control flow follows an edge e only if guard c(e) holds after the execution of action s, a start vertex s0 ∈ S from which paths to all other vertices of the activity graph exist, a non-empty set of final vertices SF ⊆ S. In order to use activity graphs for a proper modeling of use case behavior, we refine them in compliance with the UML extension mechanism [11]. To model the executions of the three different types of actions in activity graphs, we define suitable stereotypes for subclasses of the metaclasses State and ObjectFlowState. The stereotypes «contextual action», «interaction», and «actor in action» reflect contextual and interaction information. The system internal information will be covered by so-called class scopes and interaction sequences (see Sect. 2.3 and 4). The «macro action» stereotype serves as an aid for carrying the «include» and «extend» associations between use cases over to activity graphs. Finally, an actor is individually connected to an action via an ObjectFlowState instance stereotyped «actor in action». (For more details regarding our extensions see [6] and [8]). These four stereotypes are graphically depicted by the symbols shown in Fig. 3. In the common use case terminology, a use case describes a set of “scenarios“ [2] that Use Case Identification in Model ATM Description: When the card has been inserted, the ATM card reader reads the code and checks PIN and card (if the ATM is online, by the bank host, otherwise by its own algorithm). If the PIN is entered 3 times wrongly, the ATM marks the card as locked and ejects it, else the ATM panel shows a menu and the ATM waits for the customer's selection. Actors: Customer, Bank Host Pre-Condition: CardReader ready, Panel shows logo Post-Condition: Card in CardReader, CardReader locked, Card ok, PIN ok, Customer identified, Panel shows menu or Card unreadable, Card retracted, CardReader ready, Panel shows logo or PIN 3 times wrong, Card locked, Card ejected, CardReader ready, Panel shows logo End Identification
Fig. 2. Textual description of the use case Identification
Contextual Action
Macro Action
Interaction
ActorInAction
Fig. 3. Graphical symbols for the proposed stereotypes
represent concrete executions of the corresponding work unit. A scenario corresponds to a path through the activity graph of the use case which starts at the start vertex, is guided by action post-conditions and edge guards, and ends up in a final vertex. Such a scenario can be visualized as an UML sequence diagram. Example: The activity diagram within the package Withdraw Money Description depicted in the left part of Fig. 4 refines use case Withdraw Money. For simplicity reasons, edge guards are omitted. Start vertex and final vertices of the activity graph are illustrated by transitions from the start state, resp. to final states, of the activity diagram. Note that the start vertex is a «macro action» which calls (the activity graph of) the use case Identification. The start vertex is simultaneously a final vertex, because a scenario of the use case Withdraw Money might end up with an unsuccessful identification process, e.g. if the card is unreadable or a wrong PIN is entered. The right part of Fig. 4 illustrates a sequence diagram for the scenario Successful Withdrawal of the use case Withdraw Money. Textual descriptions of the action Check Amount and two of it‘s outgoing edges are provided by Fig. 5. 2.3 Class Scopes According to the UML, use cases represent functional requirements of the system while the domain class model focuses on structural or “data“ aspects. These aspects
Customer
Bank Host Withdraw Money WithdrawMoney Scenarios
WithdrawMoney Description
«refine» Customer
Identification
:ATM Bank Host Identification
Get Selection
Get Amount
Get Selection Get Amount Bank Host
Check Amount
Customer Check Amount
Write Card Eject Card
Write Card
Take Card Take Card
Dispense Money
Eject Card Take Money
Retract Card
Dispense Money Take Money
«instanceOf»
Fig. 4. Use case Withdraw Money with activity diagram and scenario Successful Withdrawal
Interaction Check Amount in Activity Graph Withdraw Money Description: The amount is checked; if the ATM is online, by the state and balance of the account, else by the offline-rules. Actors: Bank Host Pre-Condition: Card in CardReader, CardReader locked, Card ok, PIN ok, Customer identified, (Amount read or Transaction canceled) Post-Condition: Card in CardReader, CardReader locked, Card ok, PIN ok, Customer identified, Amount ok or Transaction canceled or (not Amount ok, not Transaction canceled) End Check Amount Transition Check Amount - Write Card in Activity Graph Withdraw Money Guard Amount ok or Transaction canceled End Check Amount - Write Card Transition Check Amount - Get Amount in Activity Graph Withdraw Money Guard not (Amount ok OR Transaction canceled) End Check Amount - Get Amount
Fig. 5. Textual description of the «interaction» Check Amount and two outgoing transitions
are derived from key domain concepts when analysts work out a first, “entityrelationship-like“ skeleton of the domain class model (e.g. [4][10]). For a proper coupling of activity graphs and the domain class model we further extend activity graphs by introducing the concept of a class scope. For each use case, we determine the set of domain classes with instances involved in the execution of the work unit (i.e. which are created, retrieved, modified, or deleted). The set of classes is called the class scope of the use case. The class scope is basically derived from the use case description and its pre- and post-condition and complies with the domain class model. It can be visualized by a UML collaboration diagram. Analogously, we derive the class scope for each action of the according activity graph. Furthermore, we balance the activity graphs and the class model such that for each «interaction» (of an activity graph) an operation o exists that accomplishes the «interaction» in the class model. Operation o belongs to a class C which is element of the class scope of the «interaction». We call C the root class and o the root operation of the «interaction». Example: In Fig. 6 on the next page the ATM domain class diagram is sketched. Classes Account, Cash and Card represent the core business objects, class Transaction with it‘s subclasses Withdrawal, Deposit and TransferFunds the ATM transaction rules. The other classes reflect the hardware components. Fig. 7 illustrates the class scope of the use case Identification. 3 VALIDATION Concerning the validation of requirements specifications, we focus on inspections and walkthroughs proved as effective means for document based validation [1][2][13]. We propose a phased [17] (actually a two level) inspection process which comprises different techniques and assembles teams in a problem oriented manner. Stakeholders participating in validation activities are analysts, testers, domain experts, and users. • The first level is mainly devoted to the preparation of the second level activities. Analysts and testers pre-inspect the use case model and the domain class model to detect violations of the UML syntax and our modeling rules. Since we share the opinion that business scenarios are an appropriate validation means [13][16], we construct business scenarios for each use case by deriving them from its pre-condi-
1
Card
Transaction
Number IdentCode BankCode DateLastUse NbrOfTrials AmountAtDate CreditLimit
Begin End Amount Ident Schedule State
0,N
checkPIN
Number Balance State Type CreditLimit BankCode
0,N theAccount
1
open close deposit withdraw lock
begin end commit 0,N rollback doSchedule offline 0,N checkPIN
CardReader State ? readCard writeCard awaitCard ejectCard retractCard
Account
0,N
0,N
BankInterface Deposit
Withdrawal
State ? getAccount checkPIN
Panel checkAmount getKey showMenu showLogo readPIN readAccountNbr readAmount
1
0,N
Printer
1
1,N 1
0,N
Dispenser
TransferFunds
Cash
CashSlot
Cash ? printLine
0,N
0,N
canDispense dispense 0,N 0,N
Fig. 6. ATM domain class diagram
Use Case Model
Class Model «trace»
Identification
Identification
participant
participant
participant
participant CardReader
Card
Transaction
BankInterface
Fig. 7. Class scope of the use case Identification
•
tion and activity graph. For each scenario, an initial domain object constellation is assembled from the class scope of the start action of the activity graph. For a better comprehension, analysts build up user-centered views of the scenarios and domain object constellations. To this end, they incorporate, for example, domain specific pictograms (see e.g. Fig. 8) or so-called “real world scenes“ captured by multimedia sequences [9]. On the second level, a series of walks through business scenarios is jointly conducted by all parties involved [7]. First, domain experts and users check the initial domain object constellation and the (textual) precondition of the scenario to ensure that all necessary information is at hand. In the course of the walkthroughs, domain experts and users focus on the textual descriptions of the actions, check their correctness and the related domain object constellations. When validating the domain object constellations, the domain class model is partly validated as well.
Example: Consider the activity diagram describing the use case Withdraw Money (Fig.
Domain Objects
Actors Actions
Identification
Withdraw Deposit Transfer Cancel
Domain Objects: Get Selection
Card Card Reader Withdraw Deposit Transfer Cancel 1 4 7 *
1 4 7 *
2 5 8 0
3 6 9 #
2 5 8 0
Panel (Selection)
3 6 9 #
Get Amount
Panel (Numeric) Withdrawal Bank Interface Account
Check Amount
Actors: Customer
Write Card
Bank Host Eject Card
Actions: Failed Action
Take Card
Macro Action
Fig. 8. User centered view of a scenario for use case Withdraw Money
4). Fig. 8 depicts a user centered view of the scenario Withdrawal Failed - Illegal Amount, which can be validated by users and domain experts. 4 VERIFICATION Based on the refined use case model and the class scopes, we are now going to verify the class model against the use cases and activity graphs. Validation and verification of requirements specifications bear certain similarities, but the latter works on a more formal level. Users and domain experts in general are not able to contribute to verification activities, such that analysts and testers remain the only parties involved. Similar to the validation, the verification activities are performed in a two level process. • On the first level, the verification starts with detailed inspections of the formal parts of the use case model (e.g. pre- and post-conditions and edge-guards of the activity graphs). Then the (refined) class model is checked to detect incomplete, inconsistent, and/or ambiguous specifications and/or missing items. Finally, each «interaction» specification of the activity graphs is examined concerning compliance with its class scope and the specification of the root operation. When these detailed inspections have been completed, the use case model is verified (and also validated, see Sect. 3). The class model is now consistent and unambiguous. It remains to check that the class model is correct and complete with
respect to the use case model. On the second verification level, it must therefore be confirmed that the class model is able to cope with each «interaction» of the activity graphs. To this end, analysts and testers walk through the scenarios (re-used from the validation) and investigate the thread of executions of operations in the class model triggered by the «interaction» vertices. Obviously, the operation which is invoked first in a thread of executions is a root operation. It serves as an entry point to the (operations of the) class model. Note that for every «interaction» initial and final object constellations can be re-used from the validation process. The simulation of a thread of executions in the class model which is prompted by an «interaction» is called an interaction sequence. Interaction sequences can be visualized by UML sequence diagrams (see e.g. Fig. 9 (b)). An interaction sequence depends on it‘s context, i.e. on the triggering «interaction» and the initial object constellation. Since this object constellation has already been validated, it satisfies the pre-condition of the root operation such that the interaction sequence can start. In the course of an interaction sequence, the current object constellation is changing. An error in the class model is detected, if the current object constellation does not meet the pre-condition of the operation to be performed next. The interaction sequence completes successfully, if no such error has been encountered and the final object constellation satisfies the post-condition of the action (and the root operation). Elements of the class model, which have not been involved in some interaction sequence, indicate that the class model is overspecified, or — less likely — the use case model is still incomplete. In the latter case, the validation of the use case model has not sufficiently been accomplished. The business scenarios which are re-used during the verification and enriched by interaction sequences are called test scenarios. A test scenario can be regarded as a test case which tests the class model against an activity graph. Furthermore, test scenarios can be exploited for system and acceptance test cases [18]. •
Requirements
Analysis
Verification Model Test Model
Validation Model Test Model Scenarios Identification Test Cases
Read Card Test Cases
:ATM
:CardReader
Customer Insert Card
Read Card
«trace»
readCard
:Card new
Get PIN PIN
Check PIN Test Cases :Transaction
Check PIN
«trace»
:Card
:BankInterface
checkPIN checkPIN offline
Show Menu checkPIN Menu manipulate
(a)
(b)
Fig. 9. Test scenario Successful Off-Line Identification (a) and two interaction sequences (b)
Example: Consider the test scenario Successful Off-Line Identification in Fig. 9 (a) which assumes that the BankHost is unavailable, and the interaction sequence triggered by action Check PIN (Fig. 9 (b)). In this interaction sequence the ATM switches its state to off-line and performs the operation checkPIN defined in class Card. 5 TOOL SUPPORT AND EXPERIENCES We have developed a tool comprising modeling, validation, and verification facilities, which support the application of our approach to real world problems. In the GIS (Geographical Information Systems) area, we have developed a retrieval system for naive users and domain experts and a tool for less skilled persons which supports collecting geometric information and feeding it into a GIS. For a software house, we have implemented an internet-based system for planning, collecting, computing, and evaluating project related efforts and costs. Experiences from these projects have turned out that analysts do not encounter problems when modeling activity graphs and coupling them with class models. We share the common experiences that users (assisted by analysts) are able to understand and validate user-centered views of scenarios [2][9][16]. In all projects, skilled testers and analysts have succeeded in performing the verification activities. On the other hand, all analysts and testers were more or less sceptical when the projects started, because they did not believe that the validation effort would really pay off. However, when they got aware of the high re-use of validation elements during verification as well as system and acceptance testing, they judged our approach to be worthwhile. They found it especially useful when they observed that the software developed according to our method was significantly less error prone than the software they have developed so far. 6 FUTURE WORK Our tool is currently re-implemented in Rational Rose, a commercial CASE tool supporting the UML notation. The modeling elements are integrated into Rational Rose via the UML extension mechanism, while scripts implement the validation and verification components. One difficult problem of both validation and program testing is “knowing when to stop“. Due to the structural similarity of activity graphs and control flow graphs of programs, we will adapt coverage criteria for program testing to yield quantitative measures for the planning and control of the validation (and verification) activities. Our approach also provides a basis for the derivation of test cases for system and acceptance testing. At the moment, we are working on a component generating suitable test cases from the specifications. Furthermore, we are developing a tool that — based on the knowledge gained from the verification of the class model against the use case model and in particular from the interaction sequences gathered for this purpose — supports the derivation of revealing “grey-box“ system test cases which can be traced back to domain objects [18]. 7 REFERENCES 1. B. Boehm: Verifying and Validating Software Requirements and Design Specifications. IEEE Software, January (1984) 75-88
2. J. M. Carroll (Ed.): Scenario-Based Design — Envisioning Work and Technology in System Development. John Wiley & Sons, Inc., New York (1995) 3. M. Glinz: An Integrated Formal Model of Scenarios Based on Statecharts. Proc. ESEC‘95, 5th European Software Engineering Conf., Sitges, Spain, LNCS 989, Springer (1995) 254-271 4. Jacobson, M. Christerson, P. Jonsson, G. Övergaard: Object-Oriented Software Engineering. Addison-Wesley/acm Press, Reading, Massachusetts (1992) 5. I. Jacobson, G. Booch, J. Rumbaugh: The Unified Software Development Process. Addison-Wesley/acm Press, Reading, Massachusetts (1999) 6. G. Kösters, B.-U. Pagel, M. Winter: Coupling Use Cases and Class Models. Proc. BCS FACS/EROS Workshop on Making Object-Oriented Methods More Rigorous, 24. June, London, GB (1997) 27-30 7. G. Kösters, B.-U. Pagel, T. de Ridder, M. Winter: Animated Requirements Walkthroughs Based on Business Scenarios. Proc. euroSTAR‘, 5th European Conf. on Software Testing, Analysis & Review, 24.-28. Nov., Edinburgh, GB (1997) 8. G. Kösters, H.-W. Six, M. Winter: Enhancing Activity Graphs to Bridge the Gap between Use Cases and Class Models. Technical Report, Dept. of CS, University of Hagen, August (1999) http://www.informatik.fernuni-hagen.de/import/pi3/publikationen/abstracts/UML_TR.html
9. N. Maiden, M. Cisse, H. Perez, D. Manuel: CREWS Validation Frames: Patterns for Validating System Requirements. CREWS Report 98-29 (1998) 10. B. Meyer: Object-Oriented Software Construction, 2nd Ed., Prentice Hall, Upper Saddle River, New Jersey (1997) 11. OMG Unified Modeling Language Specification. Version 1.1, September (1997) 12. K. Pohl, P. Haumer: Modelling Contextual Information about Scenarios. Proc. REFSQ‘97, 3rd Int. Workshop on RE: Foundation for SW Quality, Barcelona, Spain (1997) 13. C. Potts, K. Takahashi, A. I. Anton: Inquiry-based requirements analysis. IEEE Software, March (1994) 21-32 14. B. Regnell, K. Kimbler, A. Wesslén: Improving the Use Case Driven Approach to Requirements Engineering. Proc. RE‘95, 2nd IEEE Int. Symp. on Requirements Engineering, York, UK (1995) 40-47 15. B. Regnell, M. Andersson, J. Bergstrand: A Hierarchical Use Case Model with Graphical Representation. Proc. ECBS‘96, IEEE Int. Workshop on Engineering of Computer-Based Systems, IEEE Press (1996) 16. K. Weidenhaupt, K. Pohl, M. Jarke, P. Haumer: Scenarios in System Development: Current Practice. IEEE Software, March/April (1998) 34-45 17. David A. Wheeler, Bill Brykczinski, Reginals N. Meeson, Jr.: Software Inspection - An Industrial Best Practice. IEEE Press, Los Alamitos (1996) 18. M. Winter: Quality Assurance for Object-Oriented Software — Requirements Engineering and Testing w.r.t. Requirements Specification. Ph.D. Dissertation (in German), University of Hagen, Sept. 1999
