Basics of the Use Cases Editor (UCEd) ‏

1. Stéphane S. Somé SITE, University of Ottawa Basics of the Use Cases Editor (UCEd)‏

2. 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

3. Elements of UCEd Domain Editing State Model Synthesis Use Cases Editing UCED (Use Case Editor)‏ Simulator Scenario Editing

4. Use Case Edition Use Case model Use Case description

5. Use Case Model Consists of Use Cases normal use cases extension use cases Relationships include extend extend condition Actors

6. Use Cases Template (1)‏ Normal Use Case

7. 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.

8. 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.

9. 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

10. 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

11. 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 ....

12. 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

13. 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.

14. Use Case Description - Steps Steps may be constrained by guard condition and/or a delay Guard conditions are specified with IF ... THEN e.g. IF User identification is invalid THEN ATM ejects card Delays are specified with AFTER e.g. AFTER 10 sec, ATM ejects card

15. 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 postcondition postcondition when the alternative is taken

16. 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

17. Example of use case description (1)‏ Title: User login System Under Design: PMSystem Description: This use case describes a login process in the PMSystem. The use case is executed by a User (Doctor or Nurse). Primary Actor: User Participants: Goal: A User want to identify herself in order to use a PM system. Precondition: System is ON AND NO user is logged in Follows Use Cases: turn system on Steps: 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 Card Success Postcondition: User is logged in

18. Example of use case description (2)‏ Alternatives: 1a: User Card is inserted 1a1: User presses cancel button 1a2: PMSystem ejects Card Alternative Postcondition: User is not logged in 1b: The Card is not regular 1b1: The PMSystem emits an alarm 1b2: After 20 sec The System ejects the Card Alternative Postcondition: User is not logged in 2a: after 60 seconds 2a1: PMSystem emits alarm 2a2: After 20 sec PMSystem ejects Card Alternative Postcondition: User is not logged in 4a: The user identification is invalid AND number of attempts is less than 4 4a1: Goto Step 2 4b: User identification is invalid AND number of attempts is equal to 4 4b1: The PMSystem emits an alarm 4b2: After 20 sec PMSystem ejects the Card Alternative Postcondition: User is not logged in

19. Sources Download UCEd Get user guide Get papers on UCEd http://www.site.uottawa.ca/~ssome/Use_Case_Editor_UCEd.html