Use Case modelling How to go from a diagram to a further definition

Revision To draw a use case diagram: –Pick out tasks –Pick out actors –Check which tasks are directly initiated by actors (Primary tasks) –Check which tasks happen as part of another task (Secondary tasks) –Draw actors outside boundary and primary tasks inside boundary.

Associating primary and secondary tasks Tasks are only associated if they follow the OTOPOP rule: One Time, One Place, One Person To determine how the association works, ask of each secondary task: –Which is its primary task? –Is it always performed, or only sometimes? –Does it communicate with any other actors?

Associating secondary tasks Which is its primary task? –There must be an association to the ‘calling’ task. Is it always performed, or only sometimes? –If always, the primary ‘includes’ the secondary –If sometimes, the secondary ‘extends’ the primary. Does it communicate with any other actors? –If so, have an arrowed communication to the actor.

The actor’s thread The actor’s thread of control only lasts as long as the actor is running the task. The thread begins with a primary task and can only include tasks that –it includes or –Extend it. A thread need not include tasks that are necessary for this thread to work, but do not follow the OTOPOP rule. –E.g. An expert witness lodging a report is NOT in the thread of –Assessor assesses claim.

Primary becoming secondary Primary tasks may also act as secondary tasks –E.g. View a claim, Report incident If a primary task may be performed as part of another task, it can act as secondary in a separate thread.

Communicates Relationships Are denoted as solid associations. Are the only possible relationship between actors and use cases. May have an arrow to indicate the actor’s behaviour within the use case. –If the actor initiates the use case, the communication association has an arrow pointing to the use case. –If the actor utilized the services provided by the use case, the communication association has an arrow pointing to the actor. –A communication association may have arrows in both directions.

Extends Relationships Are used to capture exceptional behaviour. Allow an extending used case to continue the activity sequence of a base use case when the extension point is reached in the base use case and the extension condition is fulfilled. Upon completion of the extension activity sequence, the original use case continues. Are denoted as extends arrows.

Extends Relationships Must use the “extends” keyword. Must have a condition determining when the extending use case will be inserted. May reference an extension point in the base use case determining where the extending use case may be inserted.

Includes Relationships Are used to share common behaviour among use cases. Are denoted as includes arrows. Must use the “includes” keyword.

Details of a Use Case Intent. Description –also known as the happy path. –The most normal branch of each path is taken. Alternate courses. Pre-condition(s). Post condition(s).

Name and Intent The name of a use case is derived from the perspective of the actor with respect to the system. The intent describes the desired objective of this interaction in terms of benefit and value to the actor and is reflected in the use case name.

Description The use case description describes all possible sequence of interactions that may branch into a number of courses or flows. Describes the sequence and flow of dialogue between the actor and the system. Must be two-way (conversational). –Actor requests… system responds… actor requests…etc.

Description Contd. Describe the basic course in natural language (The Happy path). Be written from the user’s perspective. Use actor’s own vocabulary. Clearly define user’s intent. Present terminology that is consistent (i.e. Customer or client). Clearly define start and end points – end point typically yielding value to the actor.

Third Party Claims

Example Please note that the example that follows is from a simulated working computerised system. In a manual system, the current physical description would be given. In most cases, this would consist of the filling in of paper based forms or exchanging information over the phone or through conversation.

Example – Assess a claim According to the Claims Assessor: –When I’m ready to assess claims, I start up the ‘Assess claims’task. This shows me a screen of all claims that haven’t been assessed yet but are ready for assessment. It shows me the date the claim was reported, the date of the incident, the claimant’s name and first 40 characters of the address. If there are more than eight, I can only see the first eight, but there is a scroll-bar that lets me scroll down if there are any more. Thankfully, that doesn’t happen too often! As soon as I highlight and double click on the one that I want to assess, I get a screen full of all the details of that claim.

Contd. – Those include the claim reported date and the nature of the claim (injury or damage). The Claimant’s name, address and phone no are also displayed. There is a button ‘View Accident’ that I can click if I want to see the details of the accident, but usually I don’t need to do that. There is also a button that I can click to look up prior claims made by the claimant – some of them do try it on a bit!. I then click one of the four radio buttons to choose settle, reject, refer to underwriter or choose an expert. If I choose an expert, a button is enabled that allows me to go into another screen and allocate an expert depending on what type of expert I need. If I choose to settle, I must put a valuation on the claim.

Sub- and Alternative flows Sub-flows are reused sub-tasks that are used by this task. Alternative flows are flows that are used when conditions are not as expected in the task.

Pre- and Post-Conditions The pre-conditions are conditions that need to be in place before a task can be carried out. –e.g. Task = make a cup of tea Pre-condition = tea bag / tea leaves, boiling water, cup. The post-condition is the condition that the task leaves behind it –e.g. Task = withdraw cash from ATM. Post-conditions = card retrieved, cash dispensed, account balance adjusted (also known as exit conditions). What are the pre-conditions for ‘Assess a Claim’?

Requirements Elicitation Use scenarios to communicate with users and to validate functionality. First, refine a simplified view (i.e., Many not-very detailed scenarios) to define the scope of the system. Validate with the user. Use mock-ups as a visual support only; User interface design should occur as a separate task once the functionality is sufficiently stable. Present the user with multiple alternatives (as opposed to extracting a single alternative from the user).

Documenting the Use Case Lay out the headings as shown previously in slide 5 above. Put the details of each below. Rational Rose is NOT good for documenting Use Case details at this level, but this documentation can be put in at operation level. E.g. Verify an Incident

Intent The intent of this task is to verify that an incident that has been reported by a third party did in fact occur and that all the details are correct. The driver views the details of the incident as reported by the third party and verifies, amends or rejects them.

Description The driver calls up the screen with the details that the third party has supplied. If the driver agrees to the text, he clicks a button labelled 'verify'. If the driver has some disagreement, he clicks a button labelled 'adjust'. This causes an empty incident form to be displayed, which he fills and clicks 'submit'. If the driver disagrees that the incident happened at all, he clicks 'reject'.

Pre- and Post-conditions Pre –Driver is aware that a report needs to be verified –An unverified incident report has been filed Post –The incident report changes status to verified, verified with amendments or rejected.

Updated claims system

Extras in this diagram Extra Use Cases from screens added Underwriter stereotype displayed as a label with a decoration. –This is more appropriate, because the Underwriter is a firm, not a person.