Example of normal use case

The use case Log in describes a login procedure that must be used by the users of the PM System.

Figure 4.2: Use case describing a login procedure in a Patient Monitoring System.

Title:

Log in

Primary Actor:

User

Participants:

Goal:

A User wants to identify herself in order to be able to use the PM system to perform a task such as admitting a patient or changing silencing an alarm.

Precondition:

PM System is ON

Postcondition:

User is logged in

Steps:

1:

User inserts a Card in the card slot

2:

PMSystem asks for PIN

3:

User types her PIN

4:

PMSystem validates the USER identification

5:

IF the USER identification is valid THEN PMSystem displays a welcome message to User

6:

AFTER 45 sec PMSystem ejects the USER Card

Extensions

:

*1

:

*1a:

USER presses cancel button

*1b:

PMSystem ejects Card

1a:

USER Card is not regular

1a1:

PMSystem emits alarm

1a2:

After 20 sec PMSystem ejects Card

2a:

after 60 seconds

2a1:

PMSystem emits alarm

2a2:

After 20 sec PMSystem ejects Card

4a:

User identification is invalid AND User number of attempts is less than 4

4a1

Go to Step 2

4b:

User identification is invalid AND User number of attempts is equal to 4

4b1:

PMSystem emits alarm

4b2:

After 20 sec PMSystem ejects Card

EXTENSION POINTS

:

STEP 1. card inserted

STEP 3. pin entered

Use case Log in precondition is condition ``PMSystem is ON'', and postcondition is condition ``User is logged in''.

Log in includes six steps listed in the section titled Steps. Each step refers to a use case step operation.

For instance step 1 references the User's operation 'insert card' and step 2 the PMSystem operation 'ask pin'. Step 5 includes a step condition 'User identification is valid'. The execution of step 5 (and that of the following step) is possible only under that condition. Step 6 operation is constrained by an after delay 'After 45 sec'. Means 45 seconds need to pass after the completion of step 5 before this step is possible.

Steps 1, 2 and 4 have step extensions described in the section titled Extensions. Each extension label starts with the corresponding step label. Extension 1a corresponds to step 1, 2a corresponds to step 2. Extensions 4a and 4b correspond to step 4.

Extensions 1a, 4a and 4b include conditions. For instance, after step 1 is completed the operation 1a1 followed by 1a2 are executed if the condition 'User Card is not regular' evaluates to true. Extension 2a includes an after delay, such that 60 seconds need to pass after step 2 operation completion for the extension to be possible.

All the extension actions in use case Log in are operation instances. The exception is extension 4a that includes a branching statement branching back to step 2.

Use case Log in includes one any extension. Any extension labels start with '*'. Log in any extension doesn't include a condition or a delay. Consequently, the extension is possible anytime during the execution of an instance of the use case.

Use case Log in includes the extension points labelled card inserted after step 1, and pin entered after step 3. An extension use case such as Log in secure can refer to these extension points.

A use case includes a primary scenario (or main course of events) and 0 or more secondary scenarios that are alternative courses of events to the primary scenario [6]. The primary scenario is described in the section titled Steps while the secondary scenarios consist of interactions in the primary scenario followed by behaviors defined in the section titled Extensions. As an example, use case Log in primary scenario is defined by step 1 to 6 operation (sequence 1-2-3-4-5-6). Examples of secondary scenarios are defined by sequences 1-1a1-1a2 and 1-2-3-4-4b1-4b2.