Basics of the Use Cases Editor (UCEd)

Stéphane S. SoméSITE, University of Ottawa

Use Case Editor (UCEd) A toolset for Use Cases capture and validation

Use Cases edition

Domain model edition

Scenario edition

Use Case & Domain model validation

Use Cases combination in state models

Simulation of executable model derived from Use Cases

Scenario generation

Elements of UCEd

UCED(Use Case Editor)

Simulator

Use CasesEditing

State ModelSynthesis

Domain Editing

ScenarioEditing

Use Case Edition

Use Case model

Use Casedescription

Use Case Model• Consists of

– Use Cases• normal use cases

• extension use cases

– Relationships• include

• extend– extend condition

– Actors

Use Cases Template (1) Normal Use Case

Use Cases Template (2) Title: a label that uniquely identifies the use case within the

use case model. Description: a free form text that summarizes the use case. System Under Design: specifies what is the system in the

use case. The system is the entity that react to stimuli from external actors.

Primary Actor: the actor that initiates the use case. Participants: other actors participating in the use case. Goal: a statement of the primary actor expectation at the

successful completion of the use case.

Use Cases Template (3) Follows Use Cases: a list of normal use cases that the use

case directly follows. Invariant: a condition that must hold through the use case. Precondition: a condition that must hold before an instance

of the use case can be executed. Success Postcondition: a condition that must be true at the

end of a successful execution of an instance of the use case. STEPS: a sequence of repeat blocks and steps. ALTERNATIVES: alternatives to steps. Alternative Postcondition: a condition that must be true at

the end of an alternative.

Use Case Description - Conditions Two types of conditions Simple conditions

Entity bound conditions: based on domain entities

Non-Entity bound conditions: declared verbatim in the domain model

Compound conditions negation, conjunction, disjunction of simple

conditions

Use Case Description Syntax Entity bound Condition

[determinant] entity verb value

Optional determinant: a, an, or the

Entity: sequence of words naming an entity in the domain model (see later)

Verb can be one of: is, isn't, is not, are, aren't, are not, has, hasn't, has not,

have, haven't, have not

Value: sequence of words defined as entity state characterization comparison

Use Case Description - Conditions Examples of Entity bound Conditions

The User Card is not valid

User number of attempts is > 3

The System Display is blinking

System registered users are less than 10

....

Use Case Description - Conditions Compound Conditions

Negation

NO condition

NOT condition

e.g. “Not User identification is valid”.

Conjunction

condition AND condition

Disjunction

condition OR condition

Use Case Description - Steps Operation execution

Sentence describing an action by an actor or the system under design

Must be a simple sentence in the present tense

Examples: The User inserts a card ATM ejects the user's card The system displays a pin enter prompt

Branching – refers to a step in the main scenario GOTO 5.

Use Case Description - Steps Steps may be constrained by guard condition and/or a

delay

Guard conditions are specified with IFIF ... THENTHEN

e.g. IF User identification is invalid THEN ATM ejects card

Delays are specified with AFTERAFTER

e.g. AFTER 10 sec, ATM ejects card

Use Case Description – Step alternatives

Alternative behavior that may follow the step Include

alternative condition condition under which the extension takes place

steps Alternative steps can not have further alternatives

alternative postconditionpostcondition when the alternative is taken

Use Case Description – Step alternatives Alternative condition – may be

a delay

condition, or

combination of delays and condition statement

Examples after 30 sec

before 2 min AND after 20 sec

The User identification is not valid

after 60 sec, IF Bank hasn't responded

Example of use case description (1)Title: User loginSystem Under Design:PMSystemDescription: This use case describes a login process in the PMSystem.

The use case is executed by a User (Doctor or Nurse).Primary Actor: UserParticipants: Goal: A User want to identify herself in order to use a PM system. Precondition: System is ON AND NO user is logged inFollows Use Cases: turn system onturn system onSteps: 1: The User inserts a Card in the card slot 2: The PMSystem asks for PIN 3: The User types a PIN 4: The PMSystem validates the USER identification 5: IF the USER identification is valid THEN The PMSystem displays a welcome message to the USER 6: After 60 sec The PMSystem ejects the CardSuccess Postcondition: User is logged in

Alternatives:

1a: User Card is inserted1a1: User presses cancel button1a2: PMSystem ejects CardAlternative Postcondition: User is not logged in

1b: The Card is not regular1b1: The PMSystem emits an alarm1b2: After 20 sec The System ejects the CardAlternative Postcondition: User is not logged in

2a: after 60 seconds 2a1: PMSystem emits alarm2a2: After 20 sec PMSystem ejects CardAlternative Postcondition: User is not logged in

4a: The user identification is invalid AND number of attempts is less than 44a1: Goto Step 2

4b: User identification is invalid AND number of attempts is equal to 44b1: The PMSystem emits an alarm4b2: After 20 sec PMSystem ejects the CardAlternative Postcondition: User is not logged in

Example of use case description (2)

Sources Download UCEd Get user guide Get papers on UCEd

http://www.site.uottawa.ca/~ssome/Use_Case_Editor_UCEd.html