Coupling Use Cases and Class Models as a Means for ... - CiteSeerX

Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications Georg Köstersa, Hans-Werner Sixb, and Mario Winterb aISOWARE GmbH, Hagen, Germany; bUniversity of Hagen, Dept. of CS, Hagen, Germany

In many applications, especially from the business domain, the requirements specification mainly deals with use cases and class models. Unfortunately, these models are based on different modeling techniques and aim at different levels of abstraction, such that serious consistency and completeness problems are induced. To overcome these deficiencies, we refine activity graphs to meet the needs for a suitable modeling element for use case behavior. The refinement in particular supports the proper coupling of use cases via activity graphs and the class model. The granularity and semantics of our approach allow for a seamless, traceable transition of use cases to the class model and for the verification of the class model against the use case model. The validation of the use case model and parts of the class model is supported as well. Experiences from several applications have turned out that the investment in specification, validation, and verification not only pays off during system and acceptance testing but also significantly improves the quality of the final product. Keywords: Use cases; Activity graphs; Class models; Requirements engineering; UML; Validation; Verification

1. Introduction The description of the functional, structural, and behavioral system essentials form central components of any serious requirements specification. In the UML, for example, the functionality of the system to be built is mostly expressed in terms of use cases while its structural aspects are captured by the class model. For modeling the system’s behavior, state machines are widely used. In many applications, especially from the business domain, the requirements specification concentrates on the system’s functionality and its structural (data) essentials, while Correspondence and offprint requests to: Mario Winter, FernUniversität Hagen, Prakt. Inf. III / IZ, Feithstr. 142, D-58084 Hagen, Germany. Email: [email protected]

behavioral aspects modeled by state machines are often of secondary importance. The elicitation of the system’s functionality and its specification with the help of use cases usually form the starting point of the development process. Furthermore, the validation of the entire requirements specification heavily relies on the specification of the system’s functionality [3][20][25][30]. The class model, on the other hand, plays an important role in the further development process because it serves as the central basis for the main development activities [12][21][23][32]. Hence, in order to capture the system’s functionality and its structural aspects, a requirements specification deals with use cases and class models. Actually, we consider domain class models in the sense of Jacobson et al. [12]. A domain class model comprises the most important types of objects which represent "things" that exist or events that occur in the context in which the system works. Throughout the paper which deals with requirements engineering, we prefer the shorter term class model over domain class model. Use cases and class 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 method for a proper coupling of UML use cases and class models. Since the class model provides a finer granularity and more rigorous semantics compared to the use case model, we start with a refinement of use cases to achieve more precise specifications. To this end, we tailor activity graphs for a suitable modeling of use case behavior. Granularity and semantics of the refinement allow to establish a seamless, traceable transition of use cases via activity graphs to the class model. The approach supports not only consistency and completeness checks but also the verification of the class model against the use case model. The verification ensures that the class model is able to cope with the use cases, or more precise, that the instances of classes in the class model are able to execute the use cases. Furthermore, the activity graph based

2

Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications

specification of use cases can be enriched by user-centered views of scenarios and domain object constellations yielding a basis for the validation of the use case model. As a consequence, the class model is actually verified against the validated use case model. The approach also comprises the definition of quantitative measures controlling the validation and verification efforts. The paper is organized as follows. Section 2 discusses the related work. Section 3 deals with the refinement of activity graphs for a suitable modeling of use cases and introduces class scopes to couple use cases, i.e. refined activity graphs, with class models. In section 4, we explain how these concepts are exploited to domain modeling and the validation of the use case model. Section 5 is devoted to analysis and the verification of the class model against the use case model. Section 6 sketches the tool support and section 7 reports on experiences about the applications of the approach. Section 8 concludes the paper.

2. Related Work A prerequisite for coupling use cases and class models is a refinement of use cases in order to match the granularity and preciseness of class models. Following Pohl and Haumer [24], 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. There exist several approaches for a more precise specification of use cases known from the literature. Interaction diagrams are widely used for the specification of the "control flow oriented" behavior of use cases. An interaction diagram captures the interplay of concrete objects in the course of a specific sequence of actions (a scenario cf. [3]). To overcome the limitation of representing only one specific sequence of actions, there have been a few attempts to specify an entire use case by a set of interaction diagrams. Unfortunately, these approaches have not been successful as pointed out in e.g. [19][25][27]. Regnell et al. define a use case as a hierarchy of so-called episode structures [27]. At the lowest level, an episode is described by an interaction diagram. For a suitable modeling of use case behavior, episodes are hierarchically composed to higher episode structures and supplied with control-flow constructs like sequence, choice, and repetition. All use cases related to a single actor are combined into a synthesized usage model. The model is an "abstraction mechanism that conceals the detailed protocol of interactions" [26] and therefore deals with interaction information only. Because of the single actor view, the approach seems to be more suitable for the specification of

human-computer or computer-computer interfaces. In [28] Regnell and Runeson apply the model to the derivation of test cases for statistical usage testing. More recently, activity graphs have been considered as a better choice for modeling control flow oriented behavior of use cases [12][23]. 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" [23]. Unfortunately, up to now the semantics definition and the metamodel of activity graphs are in progress and desirable properties are still missing. 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 element, and in particular cannot cope with interaction information. Furthermore, an activity graph is not able to capture associations to actors, and «include» or «extend» relationships between use cases. Glinz proposes a hierarchical composition of use cases (he actually uses the term scenario instead of use case) yielding an integrated model of the external system behavior [7]. A single use case is specified as a state chart with exactly one initial and one terminal state. The state chart basically models the control flow oriented behavior of the use case and bears certain similarities to activity graphs. The use case specification based on state charts exhibits deficiencies similar to those of activity graphs, namely it cannot cope with actors, and «include» and «extend» relationships. Concerning the coupling of functional and structural (UML) specifications, interaction diagrams play a prominent role. However, since only one concrete instance of a use case and concrete instances of classes are covered, an interaction diagram fails as a universal and comprehensive means to couple functional and structural specifications like use cases and class models. Another attempt of coupling functional and structural aspects are object flow states [4] (a subclass of the UML metaclass State) in activity graphs. Object flow states represent the participation of objects in the flow of control. However, a specification of use case behavior should be linked to classes and not to concrete objects, as already pointed out in [4]. Summarizing, up to our knowledge there does not exist a compelling approach of coupling functional and structural aspects specified by use cases and class models. A comprehensive specification of the control flow oriented behavior of use cases that complies with the abstraction level of class models seems also to be missing. Because of their control flow oriented nature, we take activity graphs as starting point, refine them to match the needs of an appropriate use case specification and then attack the coupling problem.

G. Kösters, H.-W. Six, M. Winter

3

3. Coupling Use Cases and Class Models

ATM

We first refine activity graphs to model use case behavior and then introduce class scopes which couple the refined activity graphs and the class model.

Withdraw Money Supply Money

3.1. Actors, Use Cases, and Activity Graphs

In this subsection, we briefly sketch the relevant UML modeling elements. Actors: 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. Use cases: A use case describes a coherent work unit or task to be carried out 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. To support modularity and avoid redundant modeling, use cases may be related to each other by generalization or «include» and «extend» associations. "An include relationship from use case A to use case B indicates that an instance of the use case A will also contain the behavior as specified by B. The behavior is included at the location which [is] defined in A [...] An extend relationship from use case A to use case B indicates that an instance of use case B may be augmented (subject to specific conditions specified in the extension) by the behavior specified by A. The behavior is inserted at the location defined by the extension point in B which is referenced by the extend relationship" [23]. Actions and Activity graphs: Actions form the basic components of activity graphs. An action is characterized by • a name unique within the activity graph, • an informal description of its functionality, and • a pre- and a post-condition specifying the assumptions and the result of the action. An activity graph is characterized by • a non-empty set S of vertices (e.g. 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 action s0 ∈ S from which paths to all other vertices of the activity graph exist, and • a non-empty set of final actions SF ⊆ S.

Operator

«include»

Transfer Funds

Customer

BankHost Deposit Money «include»

«include»

Identification

Fig. 1. ATM use case diagram

According to the UML, the start action is indicated by a transition from the initial state, while a final action is indicated by a transition to a final state. Pre- and postconditions of use cases and actions are used similar to contracts in object-oriented programming [21]: if the precondition is satisfied, the system guarantees to realize the postcondition. They are formulated using consistent prose and could be refined and formalized using e.g. the Object Constraint Language (OCL) [23]. In the common use case terminology, a use case describes a set of UML "scenarios" [4] or "use case instances" [10], which delineate concrete executions of the corresponding work unit. We define a scenario as a sequence of actions, i.e. a path through the activity graph which starts at the start action, is guided by post-conditions of actions and edge guards of transitions, and ends up in a final action. Such a scenario can be visualized by a UML sequence diagram. Running example: Throughout the paper we explain our approach using the automatic teller machine (ATM) case study [6][12]. We identify three actors Customer, BankHost 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. The right part of Fig. 3 illustrates a scenario of the use case Withdraw Money. 3.2. Modeling Use Case Behavior by Activity Graphs

In order to use activity graphs for modeling use case behavior, we refine them in compliance with the UML extension mechanism [23]. Information types: We extend activity graphs to capture the three information types proposed by Pohl and Haumer [24]. To cover contextual and interaction information, we introduce the stereotypes «contextual action» and «interaction» as explained in the first and second row of Tab. 1. Note that a «contextual action» allows for capturing

4

Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications

even those parts of a business process which will not be supported by the system. The system internal information is covered by so-called class scopes and interaction sequences which we will discuss in subsections 3.3 and 5.2. Actors: We now carry the associations between actors and use cases over to activity graphs. Since the UML does not provide associations between actors and actions [23], we use the stereotype «actor in action» as explained in the third row of Tab. 1. An ObjectFlowState stereotyped «actor in action» refers to an (anonymous) instance of an actor which can be connected to actions. These connections show either which actor executes which contextual action or which actor triggers or is involved in which interaction. Note that there exist situations where the set of actions cannot be partitioned with respect to the actors and hence the swimlane mechanism proposed in the UML [23] is not applicable. For example, action Identification in Fig. 3 is associated with both, the Customer actor and the BankHost actor. Include and Extend: The «macro action» stereotype (last row of Tab. 1) reflects the «include» and «extend» relationships between use cases within activity graphs. Let A, B be use cases, and AG, BG their corresponding activity graphs. The «include» relationship between use cases denotes that a use case is part of or "called by" several main use cases. Hence we get: If A «include» B then AG contains a «macro action» state calling BG. The «extend» relationship is applied if "a use case may be augmented with some additional behavior defined in another use case" [23]. If A «extend» B, then A provides parts of behavior for all extension points in B which are listed in the «extend» association. To make this notion more precise, we require that A has no behavior of its own but only «include» relationships to use cases which can be dedicated to extension points in B. Finally, if B is extendible, each extension point in B is reflected by a 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, this is done by the bank host, otherwise by an ATM algorithm). If the PIN is wrongly entered 3 times, 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

«macro action» state in BG. Altogether we get: If A «extend» B via a set EP of n > 0 extension points, then (i) AG contains at least n vertices, (ii) each vertex in AG is a «macro action», and (iii) for each «macro action» in BG which reflects an extension point in EP there exists an activity graph which is called by a «macro action» in AG. Generalization: Transferring the generalization relationship for use cases to activity graphs is not an easy task (see e.g. [29]). In any case, the semantics definition of the generalization between activity graphs should be in compliance with the state machine subtyping policy which "is based on the rationale that the subtype preserves the pre-/post- condition relationships of applying events/ operations on the type [...]. Preserving pre-/postconditions guarantees the substitutability principle" [23]. Note that the «extend» relationship is less powerful than generalization, because it allows variation only at predefined points (the extension points, i.e. macro actions). Stereotype

Description

«contextual action»

An ActionState stereotyped «contextual action» represents the execution of an action which is performed by an actor without the help of the system.

«interaction»

A CallState stereotyped «interaction» represents an action that is supported or carried out by the system.

«actor in action»

An ObjectFlowState stereotyped «actor in action» depicts an actor which can be connected to actions.

«macro action»

A SubactivityState stereotyped «macro action» "calls" a subgraph (it reflects an «include» or an «extend» association).

Visualization

Contextual Action

Interaction

: ActorName

Macro Action

Table 1. Proposed stereotypes for activity graphs

Summarizing, in our approach each action in an activity graph is marked with a stereotype s ∈ {contextual action, interaction, macro action}. The «macro action» stereotype reflects the «include» and «extend» relationships within activity graphs, the stereotype «actor in action» allows to connect actors to actions. The right column of Tab. 1 shows the graphical symbols for the stereotypes involved. Example: The activity diagram within the package Withdraw Money Description depicted in the left part of Fig.

G. Kösters, H.-W. Six, M. Winter

5

Customer

BankHost Withdraw Money

«refine»

Identification Paul : Customer

:ATM HagenCity : BankHost Identification

Get Selection

Get Selection Get Amount

: BankHost

: Customer

Get Amount

«instanceOf»

Check Amount

Check Amount

Write Card

Write Card

Eject Card Take Card

Dispense Money

Eject Card

Take Card

Retract Card

Take Money

Dispense Money Take Money

Fig. 3. Use case Withdraw Money with activity diagram and scenario Successful Withdrawal

3 refines use case Withdraw Money. For simplicity reasons, edge guards are omitted. Initial state and final states are visualized by a bullet, resp. framed bullets. Note that the start action is a «macro action» which calls or "executes" (the activity graph of) the use case Identification. The start action is simultaneously a final action, 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. 3 illustrates a sequence diagram for the scenario Successful Withdrawal of the use case Withdraw Money. Textual descriptions of the action Check Amount and two outgoing edges are provided by Fig. 4. 3.3. Class Scopes

In the previous subsection, we have refined activity graphs for modeling use case behavior. We now present the concept of a class scope which couples the refined activity graphs and class models. For each use case, we determine the set of classes involved in its execution, i.e. classes with instances being created, retrieved, activated, updated, 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 preand post-condition, and obviously should comply with the class model. The concept of a class scope is somewhat similar to the visibility scope induced by signatures of operations [21] and can be visualized by a UML collaboration.

Analogously, we derive the class scope for each action of the according activity graph, i.e. the set of classes with instances involved in an execution of the action. Actually, a class in the class scope can appear in different classifier roles [23] according to different actions in activity graphs. To improve the readability of the paper, we abstain from distinguishing between classes and classifier roles. 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 Interaction Check Amount in Activity Graph Withdraw Money Description: The amount is checked; if the ATM is online, this is done according to the state and balance of the account, otherwise by the offline-rules. Actors: Bank Host Pre-Condition: Amount read or Transaction canceled Post-Condition: 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. 4. Textual descriptions of the «interaction» Check Amount

6

Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications

Card number identCode bankCode dateLastUsed nbrOfTrials amountAtDate creditLimit ... checkPIN() ... 0..1

1

*

Transaction begin end amount identCode schedule state ... begin() end() 0..1 commit() rollback() 0..1 doSchedule() 0..1 offline() checkPIN() ...

0..1 CardReader state ...

*

Account number balance type creditLimit 1 bankCode state ... open() close() deposit() withdraw() lock() ... *

theAccount

0..1

1

* BankInterface

readCard() writeCard() awaitCard() ejectCard() retractCard() ...

1 state

Deposit

Withdrawal ...

...

checkAmount() ... 0..1

...

... getAccount() checkPIN() ...

*

Panel 1

...

1

getKey() ShowMenu() ShowLogo() readPIN() readAccountNbr() readAmount() ...

1 Printer ... printLine() ...

1

Dispenser Cash ... canDispense() dispense() ... 0..1

CashSlot TransferFunds ...

0..1 * Cash

... unlock() lock() ...

checkAmount() ...

... ... *

Fig. 5. ATM class diagram

«trace»

(a) Identification

Identification

participant

participant

participant

participant CardReader

(b)

Check PIN

«trace»

Card

Transaction

BankInterface

Check PIN

participant Transaction

participant participant Card

BankInterface

checkPIN()

Fig. 6. Class scope of the use case Identification (a) and the «interaction» Check PIN (b)

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: Fig. 5 sketches the ATM class diagram. Classes Account, Cash and Card represent the core business objects, while class Transaction and its subclasses Withdrawal, Deposit and TransferFunds reflect the ATM

transactions. The other classes stand for the hardware components. Fig. 6 (a) illustrates the class scope of the use case Identification. As an example for the visualization of the class scope of an action, Fig. 6 (b) depicts the «interaction» Check PIN together with its class scope. The root class Transaction is partially expanded to expose the root operation checkPIN().

G. Kösters, H.-W. Six, M. Winter

7

4. Domain Modeling and Validation As Jacobson states, "the purpose of domain modeling is to understand and describe the most important classes within the context of the domain. [...] The domain classes and the glossary of terms are used when developing use case and analysis class models" [12]. The method we propose for domain modeling and validation (as well as for analysis and verification, c.f. section 5), called SCORES, is based on the refined use case model, the class model, and class scopes connecting both models. SCORES also incorporates the definition of quantitative measures to control the validation (and verification, c.f. section 5) process. Tab. 2 exhibits the relations between the main aspects (external and internal observable behavior and structure) and the main activities (elicitation & specification and validation). In this section, we focus on validation while requirements elicitation and specification activities are only sketched. Aspect \ Activity

Elicitation & Specification

Validation

External observable Behavior

Use Cases, Activity Graphs

Business Scenarios

Structure

Domain Classes, Attributes, Associations

Object Constellations

Internal observable Behavior

Class Scopes, Operations

Responsibilities

Table 2. Domain modeling: aspects related to activities 4.1. Elicitation and Specification

Following Jacobson [10][12], analysts and domain experts investigate and draft relevant business scenarios and identify actors. This information contributes to the description of use cases. In SCORES, the use cases are refined by specifying actions. Actions together with basic control flow information derived from narrative descriptions of business tasks are composed into an activity diagram. A task which is part of several main tasks is modeled as a use case of its own and captured by a «macro action» in the activity diagrams of its main tasks. Due to lessons learned from our projects (see section 7), we recommend an incremental, iterative process for the specification of use cases which relies on four basic steps. During the first step, we describe the regular course of actions using e.g. sequence diagrams. Next, alternative courses of actions are identified. In the third step, we derive the activity graph from the actions determined in the previous steps. The fourth step checks node and edge coverage achieved by the courses of actions at hand. As long as the coverage criteria are not fulfilled we go back to step one, resp. step two, and proceed searching for further courses of actions.

According to the mainstream OO-literature, data requirements are derived from key domain concepts (e.g. [10][21][32]). Analysts work out a first, "entityrelationship-like" skeleton of the class model. Whenever an instance of a class is mentioned in the description of an action, the class is added to its class scope, its responsibilities [32] are determined, and an initial set of corresponding operations, attributes, and associations are defined. For each «interaction», root class and root operation are selected from its class scope. 4.2. Validation

Requirements specifications usually cannot be validated against a concise "source" document, but have to meet the users’ rather vague mental images. Hence, besides analysts and testers, domain experts and users are the stakeholders participating in validation process. The joint venture of these stakeholders is a prerequisite for a successful validation process and assures that finally all specifications are formulated in a language understandable by all parties involved. Validation techniques applicable to requirements specifications are inspections, walkthroughs, and prototyping [3][6][8][25]. We focus on inspections and walkthroughs which are proved as an effective means for document based validation. Since the early Seventies, several combinations, variations, and refinements of the original inspection techniques have been proposed. Among them are Fagan inspections, active design reviews, and phased inspections (for a collection of seminal papers see [31]). Inspections are often used to check for certain properties, like adherence to standards or typical errors that have been prevalent in the past. SCORES applies a two level inspection process which comprises different techniques and assembles teams in a problem oriented manner (Fig. 7). • On the first level, analysts and testers pre-inspect the use case model and the (domain) class model to detect violations of the UML syntax and SCORES modeling rules. Since we share the opinion that business scenarios are an appropriate validation means [25][30], we construct business scenarios for each use case according to its pre-condition and activity graph. For each scenario, an initial object constellation is assembled from the class scope of the start action. For a better comprehension, analysts build up user-centered views of the scenarios and object constellations. To this end, they incorporate, for example, domain specific pictograms (see e.g. Fig. 9) or so-called "real world scenes" captured by multimedia sequences [20]. • On the second level, a series of walks through business scenarios is jointly conducted by all parties involved [16]. First, domain experts and users check the initial (domain) object constellation and the (textual) pre-condition of the scenario to ensure that all necessary information is at hand. In the course of the walkthroughs,

8

Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications

Stakeholder

Activities

Artifacts

Level 1

Pre-Inspections Class Model Tester, Analyst Use Case Model

Level 2

Preparation

User Domain Expert

Walkthroughs of Business Scenarios

Object Constellations Business Scenarios Test Protocols

Tester, Analyst

Fig. 7. SCORES two-level validation process

domain experts and users focus on the textual descriptions of the actions, check their correctness and the related object constellations. When validating the object constellations, the class model is partly validated as well. The walkthroughs driven by business scenarios reveal ill-formed object constellations, wrong or missing actions and transitions, and assure the proper meaning of action descriptions. Analysts and testers protocol the detected errors in order to correct and eventually re-validate the specifications. If users or domain experts exhibit missing scenarios, these will be incorporated into the use case model and then validated as well. Some sample items from a validation checklist are shown in Fig. 8. Such checklists are domain dependent and should be tailored to each specific development organization and project. Validation (and verification) and program testing face a lot of similar problems. One difficult problem they have in common is "knowing when to stop" [22]. Many so-called coverage criteria for program testing have been proposed as an aid to determine the right point in time (e.g. [2][22]). If the validation (and verification) of requirements specifications could rely on similar quantitative measures, the activities could much better be planned and controlled. Because of the structural similarity of activity graphs and control flow graphs of programs, coverage criteria for program testing can be carried over to the validation of use case models. For example, vertex and edge coverage [2][22] can canonically be applied to activity graphs. We suggest that any validation of an activity graph should not stop before 100% vertex coverage has been achieved, i.e. each vertex has been encountered during some

walkthrough at least once. For use cases representing critical tasks, 100% edge coverage should be achieved, i.e. all edges of the activity graph should have been traversed at least once. Special attention should be paid to each «macro action» which calls a rather complex activity graph. In such a situation, different scenarios for the called activity graph should also be considered during the walkthroughs. Example: Consider the activity diagram describing the use case Withdraw Money (cf. Fig. 3). Fig. 9 depicts user centered views of three scenarios to be validated by users and domain experts. Walking through scenario Successful Withdrawal (Fig. 9 (a)) covers the classes {Card, CardReader, Panel, BankInterface, Account, Withdrawal, Dispenser, Cash} and their associations. The scenario achieves 69% vertex coverage and 63% edge coverage of the activity diagram. In Fig. 10 (a), the covered vertices and Completeness - Are all business scenarios captured by use cases? - Are gaps in the activity graph, i.e. missing action states / transitions? - Is a pre- and post-condition defined for each use case and each action? - Are all affected classes contained in the class scope of an action? Correctness - Does the pre- and post-condition of each use case capture a legal business situation? - Does the specification of each use case comply with the corresponding business rule(s)? - Is the expected outcome of a scenario reflected correctly by the post-condition(s) of the final action(s)? Consistency - Do different scenarios exist for the same initial object constellation? - Does the post-condition of each action imply the disjunction of the guards of its outgoing edges?

Fig. 8. Sample items from the validation checklist

G. Kösters, H.-W. Six, M. Winter

9

Domain Actors Actions Objects

Domain Actors Actions Objects Identification

Withdraw Deposit Transfer Cancel

Identification

Withdraw Deposit Transfer Cancel

Get Selection

Domain Actors Actions Objects Identification

Get Selection

Domain Objects: Card Card Reader Withdraw

1 4 7 *

2 5 8 0

Get Amount

3 6 9 #

1 4 7 *

2 5 8 0

Deposit Transfer

Get Amount

3 6 9 #

Panel (Selection)

Cancel 1 4 7 *

2 5 8 0

3 6 9 #

Panel (Numeric) Withdrawal Bank Interface

Check Amount

Check Amount

Write Card

Write Card

Eject Card

Eject Card

Account Dispenser Cash Actors: Customer

Take Card

Take Card

Bank Host Actions:

Dispense Money

Failed Action Macro Action

Take Money

(a)

(b)

(c)

Fig. 9. User centered views of scenarios for use case Withdraw Money

edges are indicated by bold lines. Scenario Withdrawal Failed - Amount to High (Fig. 9 (b)) achieves 56% vertex coverage and 50% edge coverage (Fig. 10 (b)). A walk through scenario Withdrawal Failed Identification Failed (Fig. 9 (c)) stops in the final action which is also a start action (Fig. 10 (c)). This walkthrough achieves 19% vertex coverage because only 3 of the 16

(a)

(b)

(c)

Fig. 10. Coverage of activity diagram Withdraw Money achieved by three different scenarios

vertices are visited. Since 2 of the 16 control flow edges are traversed, 12.5% edge coverage is achieved. The three scenarios jointly achieve 87,5% vertex coverage and also 87,5% edge coverage of the activity diagram.

5. Analysis Domain modeling and validation are performed with the users’ assistance. To this end, the requirements specifications must be described in a way such that users can understand them. From the developers’ point of view, however, these specifications are not detailed and precise enough. During analysis, SCORES supports refinement of the use case model and the class model as well as verification activities. Tab. 3 exhibits the relations between the main aspects (external and internal observable behavior and structure) and the main activities (refinement and verification).

10

Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications

Activities

Level 1

Stakeholder

Detailed Inspections

Level 2

Tester, Analyst

Artifacts

Business Scenarios

Use Case Model

Class Model

Object Constellations

Walkthroughs of Operation Specifications

Interaction Sequences

Tester, Analyst Test Protocols

Fig. 11. SCORES two-level verification process 5.2. Verification Aspect \ Activity

Refinement

Verification

External observable Behavior

Use Cases, Activity Graphs

Verification Scenarios

Structure

Classes, Attributes, Associations

Object Constellations

Internal observable Behavior

Class Scopes, Operations

Episodes

Table 3. Analysis: aspects related to activities 5.1. Refinement

The class model delivered by domain modeling comprises the most important classes of the domain with their responsibilities, root operations, some initial attributes, and relationships. In an incremental, iterative process, analysts now explore the activity graphs in more detail in order to extract all modeling elements involved in the execution of the corresponding use cases. To this end, for each «interaction» of a use case, the responsibilities [32] of classes in its class scope and the root operation are examined. Mapping the responsibilities of a class on corresponding operations and specifying the behavior of the root operation more precisely (e.g. by sequence diagrams) usually uncovers further operations, missing attributes, associations, dependencies and objects states. In addition, the classes are revisited to determine control, entity, and boundary classes [10][12], to extract common behavior into generalization classes, and to find aggregations which decompose complex classes into appropriate "whole" and "part" classes. Packages are reexamined in order to find an appropriate decomposition of the model. The resulting (analysis) class model can be viewed as "a first cut at a design model (although it is a model of its own)" [12].

When the refinement process has reached a sufficiently stable state, it is followed up by the verification of the (analysis) class model against the use case model. Validation and verification of requirements specifications bear certain similarities, but the latter works on a substantially more detailed and formal level. Users and domain experts in general are not able to contribute to verification activities, such that analysts and testers remain the only stakeholders involved. Similar to the validation, the verification activities are performed in a two-level process (Fig. 11). • 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 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 its 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 section 4.2). The class model is now consistent and unambiguous. It remains to check that it is correct and complete with respect to the use case model. • On the second verification level, it must 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 each «interaction». Obviously, the operation which is invoked first in such a thread of executions is a root operation. It serves as an entry point to the (operations of the) class model. Note that an initial and final object constellation is at hand for every «interaction» and can be re-used, if

G. Kösters, H.-W. Six, M. Winter

node coverage has been achieved for all activity graphs during the validation. 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. 13 (b)). An interaction sequence depends on the context, i.e. on the triggering «interaction» and the corresponding initial object constellation. Since the object constellation has already been validated, it satisfies the precondition 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 interaction (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. Sample items from the verification checklist are depicted in Fig. 12. The business scenarios which are re-used during the verification and enriched by interaction sequences are called verification scenarios. A verification scenario can be regarded as a test case which tests the class model against an activity graph. Furthermore, test scenarios for system and acceptance testing can be derived from the verification scenarios [33].

Completeness - Is every class contained in at least one class scope? - Is every interaction mapped to a root operation? - Are all classes in the signature of a root operation contained in the class scope of the corresponding interaction(s)? Correctness - Does the pre-condition of the interaction imply the pre-condition of the root operation? - Does the post-condition of the root operation imply the post-condition of the interaction? - If an edge e of an activity graph is traversed by a scenario, does its guard c(e) hold for the actual object constellation? - Is the class scope of the macro action a subset of the class scope of the referenced activity graph? Consistency - Are the interaction specifications compatible with the class scopes and the specifications of the root operations? - Does an interaction and a concrete object constellation allow different interaction sequences? - Is an operation a root operation for different interactions? - Does the post-condition of each non-final interaction imply the disjunction of its outgoing edge guards? - Does an object constellation violate an association multiplicity? - Are there usage anomalies in interaction sequences (create-delete, write-write, delete-read, ...)?

Fig. 12. Sample items from the verification checklist

11

Coverage criteria similar to those driving the validation process can be used to guide the verification efforts. The verification task can be controlled by e.g. class or operation coverage (each class or each operation is touched by an interaction sequence). For use cases representing critical tasks, predicate coverage for all conditions should be achieved. Predicate coverage implies that every compounded pre- and post-condition of actions must be evaluated with respect to every possible combination of its constituent clauses [2]. This can be done by varying the inputs and states of the objects for the corresponding scenarios. Example: Consider the verification scenario Successful Off-Line Identification (Fig. 13 (a)) which assumes that the BankHost is unavailable. Fig. 13 (b) exhibits two interaction sequences. In the lower one which is triggered by action Check PIN, the ATM switches its state to offline, activates the operation checkPIN defined in class Card and manipulates some attributes of the Card instance. The use case Identification (for a textual description see Fig. 2) is included by any other use case in the ATM use case diagram (Fig. 1). For predicate coverage, each of the three clauses of its post-condition must be evaluated to true at least once by some suitable scenario. Since the precondition is atomic, no further evaluation is needed.

6. Tool Support We have developed SCORESTOOL to apply SCORES to real world problems. It is implemented on top of a tool for GEOOOA, a domain specific RE-method for applications based on geographical information systems (GIS) [13][14]. SCORESTOOL comprises modeling, validation, and verification facilities. Modeling Facilities: Editors offer functionality to create, modify, and lay out use cases and class models (Fig. 14). Graphical editors support the visualization of model instances on different levels of abstractions. Textual specifications are maintained with specification editors. Browsers support editing and tracing of (nested) textual specifications. Advanced browsing and cross-referencing facilities collect all information that relate to a selected instance. For example, all operations of a selected class in a class scope are displayed in a list according to inheritance structures (inherited operations are marked and ordered by generalization classes). To support the pre-inspections, checkers control the syntax of the model and its compliance with SCORES modeling rules and the UML semantics (for more details see [18]). Validation Facilities: A validation session deals with a socalled validation unit, i.e. a group of related use cases. The tool compiles the elements of the class model involved in the use cases of the unit. During a validation session, the analyst uses a scenario recorder to display object

12

Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications

Read Card Test Cases

Identification Scenarios

Paul : Customer

:CardReader

:ATM HagenCity : BankHost

readCard() Insert Card

Card

Read Card

PIN

new()

«refine»

:Card

Get PIN Check PIN Test Cases

Check PIN

«refine»

: Transaction checkPIN()

:Card

:BankInterface

checkPIN() offline()

Menu

Show Menu

checkPIN() manipulate()

(a)

(b)

Fig. 13. Verification scenario Successful Off-Line Identification (a) and two interaction sequences (b)

constellations and record business scenarios and revealed defects. Fig. 15 depicts a screen shot of the recorder displaying a defective use case action. In replay mode, the recorder animates scenario walk-throughs [16]. The tool also computes coverage metrics for an immediate feedback from the validation progress.

SCORESTOOL is currently being re-implemented in Rational Rose, a commercial CASE tool supporting the UML notation. SCORES modeling elements are integrated into Rational Rose via the UML extension mechanism, while scripts implement the validation and verification components.

Verification Facilities: Tool support for verification is similar to that for validation but has different objectives and works on a finer granularity. For example, coverage metrics can be computed and impacts of changes are automatically traced back to all elements of the model which have to be re-verified.

Fig. 14. SCORESTOOL class model editor screen shot

Fig. 15. SCORESTOOL scenario recorder screen shot

G. Kösters, H.-W. Six, M. Winter

7. Experiences We have used SCORES and SCORESTOOL in a series of applications in different domains. In the GIS domain, for example, we have developed a retrieval system supporting naive users and domain experts, and a data capturing tool for less skilled persons which supports collecting geometric informations and feeding them into a GIS. For a software house, we have implemented a Web-based system for planning, collecting, computing, and evaluating project related efforts and costs. We have re-modeled and reengineered WEBASSIGN, a Web-based assignment system that is used by different departments from several german universities [5]. At the moment, we are implementing a billing software for telecommunication services and a cable management system for telecommunication infrastructures. Experiences from these projects have turned out that analysts do not encounter problems when modeling activity graphs and coupling them with class models. Like others [1], we have observed that the resulting activity graphs tend to have a simple topology, i.e. mainly consist of linear chains of vertices with only a few branches. Testers and designers appreciated the (relatively) simple but precise specifications. The communication effort between them and the analysts was considerably reduced. We also have made experiences similar to those reported in [6][9][20][30], namely that users (assisted by analysts) are able to understand and validate user-centered views of scenarios. Coverage metrics have been proven useful for controlling the validation and verification process. In most cases only a few scenarios were needed to achieve 100% node and edge coverage of the activity diagrams. As main benefit of the three information types, all parties involved got a clear picture of which tasks should be performed by the projected system and which tasks belong to its environment. We also observed that macro actions often define the interfaces between business processes and help identifying different user roles. In all projects, skilled testers and analysts succeeded in performing the verification activities. Regarding the class model, 100%-coverage of classes and associations could always be achieved. Due to the coupling of use cases and the class model those elements of the class model which had not been covered during the validation activities could be traced to corresponding use cases and their activity graphs. From the descriptions of these use cases, resp. activity graphs, scenarios could be derived to verify the uncovered elements. On the other hand, all analysts and testers were more or less sceptical during the early phase of the projects, 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 SCORES

13

to be helpful. They even admit that in their opinion the software developed with SCORES had less errors and better matched the user needs than the software they had developed so far. We sometimes faced the situation that the extensive specification, validation, and verification activities made the customer worrying about the project progress and users being annoyed about their perpetual involvement. We coped with such a situation by integrating at least one user or domain expert into the requirements engineering team. Such an "on-site user" became pretty familiar with the project and was permanently available for clarifying open questions. This significantly reduced time and effort needed for domain modeling. The customer has been less worrying because he got ongoing information about the project progress from a person he trusted. We also have encountered customers who regarded the development of software systems mainly as a coding task. In such a situation we additionally provided GUI-mockups for central actions during the validation sessions and, if affordable, for entire use cases. This add-on not only showed pieces of the final system to the customer at an early stage but also improved the validation process.

8. Summary and Future work We have presented SCORES, a requirements engineering method based on the coupling of use cases via refined activity graphs and class models. The up front investment due to a higher effort for specification, validation, and verification pays off during system and acceptance testing because of the high re-use of validation and verification elements. It also improves the quality of all development artifacts during the entire development process including the final product. Among the most promising benefits of SCORES are: • A precise modeling of use case behavior in terms of refined activity graphs covering internal, interaction, and contextual information. • A seamless, traceable transition of use cases via activity graphs to the class model which allows for the validation of the use case model and the verification of the class model against the use case model. • Quantitative measures controlling the validation and verification process of requirements specifications. The detailed descriptions represented by activity graphs, class scopes, and root operations provide 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 SCORES specifications. Additionally, the knowledge gained from the verification of the class model and in particular from the interaction sequences gathered for this purpose, can be exploited for the derivation of revealing "grey-box" system test cases

14

Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications

which can be traced to objects [33]. Finally, we are going to extend SCORES to integrate GUImodeling like task analysis, navigation structure, and layout description. The approach will rely on our previous work on the combined analysis of user interface and domain requirements [17]. Acknowledgments The authors like to acknowledge the comments of the anonymous referees which led to a considerable improvement of the paper.

9. References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

Antón A, Potts C. A Representational Framework for Scenarios of System Use. Requirements Eng 1998;3(4):219-241 Beizer B. Software Testing Techniques. 2nd Ed., Van Nostrand Reinhold, NY, 1990 Boehm B. Verifying and Validating Software Requirements and Design Specifications. IEEE Software, Jan. 1984, pp 75-88 Booch G, Rumbaugh J, Jacobson I. The Unified Modeling Language Users Guide. Addison-Wesley/acm Press, Reading, MA, 1999 Brunsmann J, Homrighausen A, Six HW, Voss J. Assignments in a Virtual University — The WebAssign System. Proc. 19th World Conf. on Open Learning and Distance Education, Vienna, Austria, 1999 Carroll JM (Ed.). Scenario-Based Design — Envisioning Work and Technology in System Development. John Wiley & Sons, Inc., NY, 1995 Glinz M. An Integrated Formal Model of Scenarios Based on Statecharts. Proc. ESEC‘95, 5th European Software Engineering Conf., Sitges, Spain, LNCS 989, Springer, 1995, pp 254-271 Hsia P, Samuel J, Gao J, Kung D, Toyoshima Y, Chen C. Formal approach to scenario analysis, IEEE Software1994;11(2):33-41. Jarke M, Bui TX, Carroll JM. Scenario management: an interdisciplinary approach. Requirements Eng 1998;3(4):155-173 Jacobson I, Christerson M, Jonsson P, Övergaard G. Object-Oriented Software Engineering. Addison-Wesley/acm Press, Reading, MA, 1992 Jacobson I. The Use Case Construct in Object-Oriented Software Engineering. In: [6], pp 309-336 Jacobson I, Booch G, Rumbaugh J. The Unified Software Development Process. Addison-Wesley/acm Press, Reading, MA, 1999 Kösters G, Pagel BU, Six HW. GeoOOA — Object-Oriented Analysis for Geographic Information Systems. Proc. 2nd Int. Conf. on Requirements Engineering, Colorado Springs, 1996, pp 245-253 Kösters G, Pagel BU. The GEOOOA-Tool and Its Interface to Open GIS-Software Development Environments. Proc. 4th ACM Workshop on Advances in Geographic Information Systems, Rockville, USA, 1996, pp 165-173

15. Kösters G, Pagel BU, Winter M. Coupling Use Cases and Class Models. Proc. BCS FACS/EROS Workshop on Making Object-Oriented Methods More Rigorous, 24. June, London, GB, 1997, pp 27-30 16. Kösters G, Pagel BU, de Ridder T, Winter M.Animated Requirements Walkthroughs Based on Business Scenarios. Proc. euroSTAR, 5th European Conf. on Software Testing, Analysis & Review, 24.-28. Nov., Edinburgh, GB, 1997 17. Kösters G, Six HW, Voss J. Combined Analysis of User Interface and Domain Requirements. Proc. 2nd Int. Conf. on Requirements Engineering, Colorado Springs, 1996, pp 307-336 18. Kösters G, Six HW, Winter M. Enhancing Activity Graphs to Bridge the Gap between Use Cases and Class Models. Technical Report, Dept. of CS, University of Hagen, August1999 http://www.informatik.fernuni-hagen.de/import/pi3/publikationen/abstracts/UML_TR.html 19. van Lamsweerde A, Willemet L. Inferring Declarative Requirements Specifications from Operational Scenarios. IEEE Transactions on Software Engineering (Special Issue on Scenario Management) 1998;24(12):1089-1114 20. Maiden N, Cisse M, Perez H, Manuel D. CREWS Validation Frames: Patterns for Validating System Requirements. CREWS Report 98-29, 1998 21. Meyer B. Object-Oriented Software Construction, 2nd Ed., Prentice Hall, Upper Saddle River, NJ, 1997 22. Myers GJ. The Art of Software Testing. Wiley, NY, 1979 23. OMG Unified Modeling Language Specification. Version 1.3, June 1999 24. Pohl K, Haumer P. Modelling Contextual Information about Scenarios. Proc. REFSQ‘97, 3rd Int. Workshop on RE: Foundation for SW Quality, Barcelona, Spain, 1997 25. Potts C, Takahashi K, Anton AI. Inquiry-based requirements analysis. IEEE Software, March 1994, pp 21-32 26. Regnell B, Kimbler K, Wesslén A. Improving the Use Case Driven Approach to Requirements Engineering. Proc. RE‘95, 2nd IEEE Int. Symp. on Requirements Engineering, York, UK, 1995, pp 40-47 27. Regnell B, Andersson M, Bergstrand J. A Hierarchical Use Case Model with Graphical Representation. Proc. ECBS‘96, IEEE Int. Workshop on Engineering of Computer-Based Systems, IEEE Press, 1996 28. Regnell B, Runeson P. Derivation of an Integrated Operational Profile and Use Case Model. Proc. 9th International Symposium on Software Reliability Engineering (ISSRE’98), Paderborn, Germany, 1998 29. Rumpe B. Formale Methodik des Entwurfs verteilter objektorientierter Systeme. Herbert Utz Verlag Wissenschaft (in German). Also: Dissertation, Technical University of Munic, Germany, 1996 30. Weidenhaupt K, Pohl K, Jarke M, Haumer P. Scenarios in System Development: Current Practice. IEEE Software, March/April 1998, pp 34-45 31. Wheeler DA, Brykczinski B, Meeson, RN Jr. Software Inspection An Industrial Best Practice. IEEE Press, Los Alamitos, 1996 32. Wirfs-Brock R. Designing Objects and Their Interactions: A Brief Look at Responsibility-Driven Design. In: [6], pp 337-360 33. Winter M. 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