Precise Use Cases

David Gelperin, LiveSpecs Software

Abstract

This paper describes a precise form of use case that promotes the specification of inter-actor options and alternative course conditions. Precise cases use a description language with a Structured English grammar to specify interactions. The design goals for the notation are to maximize understandability by application experts, not familiar with formal object-oriented concepts, and to supply sufficient information and structure to support both manual and automated test design. In addition to a detailed example, a development process, and guidelines for modeling and test coverage are provided. The reader is assumed to have a basic understanding of use cases. [Editor: look at our Spring 2000 issue for an article written by Sinan Si Alhir introducing use case modeling]

1. Introduction

Use Cases can be described by diagrams [16] and text [6]. Diagrams emphasize relationships between inter-actors and cases and between cases. Text describes inter-actor/system interaction at different levels of detail ranging from short summaries to longer precise specifications. Diagrams and summaries are useful during early elicitation, while more precise text is useful during detailed analysis and functional specification.

While use cases, in general, and their current detailed formulations, in particular, provide useful information to manual test design, no current use case formulation is adequate for automated test design that includes result checking. This paper describes a test-adequate text-based formulation, Precise Use Cases. Because this formulation makes more details explicit, it lowers the risk of misunderstandings and provides a firmer foundation for system development and manual testing as well.

Constantine [4, 5] has proposed approaches to some of the same issues. Although our work focuses on testing rather than usage-centered design, Precise Use Cases conform to Constantine's definition of essential cases and therefore are likely to be effective at supporting user interface design.

In addition, using precise cases should provide a firm foundation for usage-based reading [25], for building operational profiles [23], for generating user documentation [17], and for increasing the accuracy of test and development effort estimation [24].

The remainder of the paper is organized as follows: Sections 2 and 3 describe the information needs of testing and an approach to satisfying those needs. Section 4 describes the structure of a Precise Use Case, Section 5 provides a substantial example, Section 6 comments on aspects of the example, and Section 7 specifies the Structured English constructs used to precisely describe courses of action. Section 8 discusses alternative formats for course descriptions, Section 9 provides a few modeling guidelines, and Section 10 describes a development process for suites of cases. Finally, Section 11 provides test coverage criteria and Section 12 discusses related work.

2. A testing need

Effective testing must include usage scenarios. Use cases can be a valuable source of usage information and usage testing ideas.

The following information associated with a single usage scenario (i.e., complete path through a use case) is necessary (but not sufficient) to design a usage-based test:

• Sequence of user actions and system actions in the scenario
• Scenario pre, invariant, and post conditions
• Alternative initial states of the domain entities (e.g. order) associated with the scenario
• Alternative scenario trigger events
• Alternative inputs to the scenario
• Alternative Boolean values of the predicates determining the flow of the scenario

If use cases are specified informally or semi-formally [3, 6, 16, 19, 23], then high quality, usage-based test design remains a manual process and some of the information identified above will always be missing, unclear, or incorrect. Formality and precision are prerequisites for automating test design and for automatically verifying use cases as well.

Cockburn [7] reports that people do not like to write formal cases. He argues that, formal or not, use cases can not automatically produce system designs, UI designs, or feature lists. Formal cases seem to be pain, without gain. However, formal cases can support automated design of (manual or automated) test scripts. In addition, attempts at precision can bring to light critical issues hidden in informal descriptions. Sometimes formality is warranted due to the nature and extent of product risk.

Note that software development always gets to formality and precision if code is produced. So the question is not if formality and precision, but when and by whom it is introduced and who can review it. Since ambiguity often masks the seeds of failure, introducing formality and precision earlier in the development process can reduce the risk of critical information being missed or guessed at by the developers.

3. Satisfying the testing need

Precise Use Cases lie at the heart of a larger-scale description of application usage called a Precise Usage Model. In addition to use cases, these models contain:

• Application name & abstract
• Population description - including population diagram and inter-actor profiles
• Application domain description - including essential class descriptions, states, transition rules, class relationships, domain invariants, and function limits
• Definitions of derived attributes and conditions - optional
• Dependencies between conditions - optional
• Non-functional requirements - optional
• Work breakdown structure - optional
• Action contracts - optional [12]

This additional information provides context for the precise cases including background on the inter-actors involved as well as descriptions of the application entities, their relationships, their state changes, and their constraints. This additional information provides semantics for the conditions and actions in the use cases. Precise Usage Models are consistent with the specifications described by Larman [21]. A sample Precise Usage Model for a Library Management System can be found in [9].

The twin goals that drove the design of Precise Use Cases were to maximize the understandability of the cases by application experts, not familiar with formal object-oriented concepts, and to supply sufficient information and structure to support both manual and automated test design.

4. Structure of a Precise Use Case (PUC)

The formulation of Precise Use Cases was greatly influenced by Cockburn's book on Use Cases [6], but violates several of his guidelines. It also draws on DeMarco's Structured English [8].

A Precise Use Case contains the following core information:

1. Case Id, Name and optional Abstract/Context Diagram

2. Risk Factors

Frequency of occurrence: [frequency range per time interval or event]

Impact of failure, likely & worst case [high, medium, low]

3. Case Conditions

Invariants and Pre-conditions

4. Courses of Action

Basic course

Performed course(s)

Alternative course(s)

Exception handler (EH)

Case-exiting utilities (CE)

Required selections (RS)

Optional actions (OA)

User-invoked interrupts (UI)

A Precise Use Case contains one basic course and zero or more performed and/or alternative courses. Additional information such as version, modeler, sources, duration, trigger events (e.g., specific times), undoing cases, or likely successors may also be included in the case. Additional candidates for inclusion can be found in [4] and [6].

A basic course description contains the following core information: (1) name, (2) course conditions i.e., invariant, pre, and post conditions, (3) inter-actors, and (4) interaction steps. Each usage scenario (i.e., complete path through a use case) begins at the first step of the basic course and must satisfy the case invariants and pre-conditions. Success scenarios, including those taking alternative courses, successfully exit the last step of the basic course.

A performed course is invoked with a "does <performed course name>" action and contains the following core information: (1) name, (2) course conditions, (3) inter-actors, and (4) interaction steps. Performed courses are used to simplify the basic course description as well as to encapsulate common course segments.

There are four types of alternative courses. All alternative course descriptions contain the following core information: (1) name, (2) insertion site location or range, (3) alternative course conditions, (4) inter-actors, and (5) interaction steps. The types of alternative courses include:

1. Exception handlers deal with abnormal conditions that block the successful completion of a system process. An exception condition is checked and if TRUE, the corresponding handler is invoked. The handler may compensate for the abnormal condition or take other steps to deal with the situation.
2. Required selections are elements of a set of two or more mutually exclusive alternative courses, one of which must be followed e.g., payment alternatives.
3. Optional actions are guarded by a set of guard conditions i.e., invariants and pre-conditions. If all the guards conditions are TRUE, then the option is included in the flow e.g., using discount coupons during checkout.
4. User-invoked interrupts are included goal-level use cases from the same application or a different application or utilities (e.g., help, save, print).

Go to page 2

Back to the archive list