Precise Use Cases - Part 3

David Gelperin, LiveSpecs Software

7. Structured English in PUC courses

Structured English was originally developed to describe the actions of individual analysis entities [8]. The version used in PUCs is intended to describe interactions between multiple entities.

7.1. Courses of action

The types of courses that can appear in a PUC are listed below:

• Basic course -- each PUC has exactly one of these and every scenario begins at its first step.
• Performed Course -- refers to action sequences used to specify common or simplifying course segments.
• Alternative Course -- performed under specific conditions.
• Exception Handling Macros -- analogous to macros in programming and classes in object-oriented analysis. Macros are used to group exception handlers that have predictable differences. They use a common set of steps and handler specific information to generate a specific exception handler. Macros make the common structure of multiple handlers explicit.

7.2. Actions

<action> [, unless <exception conditions [N%]>]

An action has the structure <verb> <direct object [modifiers]> [<indirect object>]. See the many examples in this paper.

does <performed course name>

[using <parameter1>, <parameter2>, ...]

[, unless <exception conditions [N%]>]

selects/wants

a. <valid input alternative [N%]>

b. <valid input alternative [N%]>

In this paper, specific action names signal inputs, outputs, and state changes.

Inputs are signaled by: requests, provides, enters, selects, and wants

Outputs are signaled by: advises, approves, confirms, displays, prints, offers, requests, and provides

State changes are signaled by: accepts, deposits, places, records, returns, stores, and updates

The N% annotation of input alternatives and exception conditions is the (integer) probability that the alternative will be selected or the condition will be TRUE. The sum of probabilities of all alternatives must be 100%. The sum of probabilities of all exception condition must be less than 50%.

Examples:

• places passenger on standby
• approves drop request, unless course not added 1%
• does "adds a book" using "Writing Effective Use Cases",
• unless book is already present
• wants aisle seat
• selects

a. credit or debt card 38%

b. sufficient cash or equivalent 62%

7.3. Handling intermediate failure

We try, we fail, we compensate or try something different, and we succeed. Intermediate failure is a normal component of successful goal-directed behavior. There are three basic approaches to handling such failures: (1) report, (2) compensate, and (3) retry using a different approach.

<action>, unless <exception conditions [N%]>

Exception handlers can effectively model reporting and compensating behavior. Exception conditions in an unless clause are Booleans that all must evaluate to FALSE in order for an action or performed course to be performed. Each exception condition has a corresponding handler that is invoked if its condition is the first to evaluate to TRUE. The exception handler may attempt to compensate for the condition and may succeed or fail in this attempt. If compensation is not attempted or the attempt fails, then following the termination style [15], the handler will record/report the condition, possibly do other things, but will always cause a FAILURE EXIT from the course containing its invoking action-unless statement i.e., the course raising the exception. If correction succeeds, then (following the resumption style [15],) control returns to the point it would have reached initially had the exception condition been FALSE. This permits the evaluation of conditions to continue.

does alternative strategies

<strategy1 course>

[using <parameter1>, <parameter2>, ...]

<strategy2 course>

[using <parameter1>, <parameter2>, ...]

[<failure preparation course>

[using <parameter1>, ...]]

FAILURE EXIT

End

A different construct (i.e., does alternative strategies) is needed to model the use of heuristic alternatives that are expected to fail occasionally. This construct contains an ordered sequence of performed courses for different strategies that are performed until one strategy succeeds or the final FAILURE EXIT clause is executed. Each strategy course, except failure preparation, must contain a SUCCESS EXIT and may contain one or more FAILURE EXITs. The failure preparation course must not contain a SUCCESS EXIT.

7.4. Selection

If (<selection conditions [N%]>)

<action> or does < ...>

[Else

<action> or does <... >]

[Endif]

Examples:

If ((customer offers credit or debit card)

and (payment amount is approved) 33%)

accepts card payment

Endif

If (customer rejects all card payments) does "handles cash payment",

unless cash or equivalent amount is insufficient

Endif

If (check in time and no assignable seat 2%),

places passenger on standby

Else

advises when assignment will be possible

Endif

 

Avoid directly embedding if statements within if statements. The embedded if should be placed in a performed course.

7.5. Repetition

Until or While <conditions> or For each <item name>,

repeat <step range>

or repeat <performed course name>

The step range must be immediately above or below the repetition statement.

Repetition must always encompass both inter-actor and system actions.

 

3. provides a (corrected) reservation locator alternative	4. searches for reservation
Until(reservation located or all reservation locator strategies tried), repeat 3 to 4

Figure 2. Example of using a repetition construct

7.6. Scenario flow

Each usage scenario starts with the ENTER in the basic course and ends with an EXIT. The EXITs may be SUCCESS or FAILURE.

CONTINUE means a return to the invoking course. If all conditions in the set of conditions (e.g., exception conditions) that triggered the CONTINUEing course have not been evaluated, then evaluate the unevaluated conditions, otherwise execute the next step.

ITERATE only appears in steps that are being performed within a repeat loop. It means that the flow should continue at the repeat statement and proceed normally depending on the evaluation of the repetition conditions.

7.7. Ambiguity of order in a step

For the following action:

inter-actor provides

a. name

b. address

c. phone number

the order in which inputs are provided is not specified.

For the step actions: "requests checkout and provides items", the order of actions is not specified. If order is important, write multiple steps.

For the following action:

system approves add request, unless

a. course is full

b. prerequisites are not satisfied

c. conflict in schedule

d. course load is unacceptable

the order in which exception conditions are evaluated is not specified. Therefore, if multiple conditions are TRUE, any of the corresponding exception handlers might be invoked.

8. Alternative formats for courses

The activity within courses can be in one-column, two-column, or three-column format. In a one-column format, the actions of all inter-actors and the system, appear in a single stream. Therefore, to avoid confusion, each action description must explicitly name its associated inter-actor or system.

The example above shows a two-column format. This is useful for describing dialogs between one or more inter-actors and a fully automated system. System actions appear in the second column and the actions of all inter-actors appear in the first. All inter-actors are named in the heading of the first column. If there are multiple inter-actors, each action in the first column should explicitly name its inter-actor.

A three-column format is useful for describing trialogs i.e., when inter-actors interact with a combination of technology and people. For example, at an airport or supermarket, we find ticket agents and cashiers as well as technology. The people and the technology are inside the system from the perspective of the inter-actor. As with the two-column format, if there are multiple inter-actors or multiple people or both, they should all be named in the headings and explicitly named with the actions. This format should not be used for multiple inter-actors and a fully automated system.

Go to part 2    Go to part 4    Back to the archive list