11th slide set of CECS 542 How to develop usage models, using UML use case overview diagrams and use cases according to the Cockburn template

1. Requirements
Engineering:
Usage Models
CECS 542
Dr. Birgit Penzenstadler
1
Photo credit: David Marcu, Unsplash

2. Usage Models
• Defini=on
• Use cases
• Scenarios
• Rela=on
• Cockburn template
• Elabora=on
Dr. Birgit Penzenstadler 2
K Rayker, stock.xchng

3. Usage Model
• Def.: A usage model describes the
system behavior from the point of
view of the user („Black box“) by
modeling interac=on sequences.
• It specifies the use cases
(from the system vision)
• Why? Understanding of intended
uses by means of the system.
• Nota=ons:
– Use case overview diagram
– Structured text (templates)
– UML ac=vity diagrams
– Message Sequence Charts
Dr. Birgit Penzenstadler 3
Context Layer
System Layer
Requirements Layer
Stakeholder Model Objectives
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
Architecture Overview
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
Deployment Requirements
System Constraints
Domain Model
Service ModelUsage Model
Quality Requirements
Risk List
Project Scope
Process Requirements
Glossary
Glossary
Glossary

4. Use cases & Scenarios
• Def.: A use case is a series of system events
triggered by an actor that leads to results for the
actor.
• Def.: A scenario is an ordered set of interac=ons
between partners, usually a system and a group
of actors.
• A Usage Model in AMDiRE has three parts:
– Use Case Overview Diagram („bubble“ diagram)
– Use Case Templates (one per „bubble“)
– Scenario diagrams (one per use case template)
Dr. Birgit Penzenstadler 4

5. Use Case Overview Diagram
Dr. Birgit Penzenstadler 5
[uml-diagrams.org 2010]

6. Another
Use Case
Overview
Diagram
Dr. Birgit Penzenstadler 6
[Scoa W. Ambler 2007]

7. Elabora=on of a Usage Model
• Deducing the Use Cases
– Iden=fica=on of Use Case by
business processes
– Analysis of business processes
• Task distribu=on to actors
• Iden=fica=on of usage func=ons
• Defini=on of the role of the system, e.g.:
– Passive support (data administra=on),
– Ac=ve support (task performance)
– Informal start: What are the system features?
• Stepwise descrip=on and refinement of the scenarios and their interac=on
– Focus on analysis and modeling of
• Informa=on flow (for later data modeling)
• Interac=on and control flow at the system border
7
Usage
Model
Business Processes
... ... ...
User System
External
Systems
Stake
holder

8. Exercise: ATM
• Use case overview
• Use case template
• Scenario
Dr. Birgit Penzenstadler 8
[Scoa W. Ambler 2007]

9. ATM Use Case Overview
Dr. Birgit Penzenstadler 9

10. Rela=on: Use Cases and Scenarios
Dr. Birgit Penzenstadler 10
Use Case
Scenario
(1) (2)
• For each „bubble“ in the overview diagram:
• Use Cases summarize a set of scenarios to a
specific usage of the system.
– Use Case:
Task, objec=ve, causal rela=on (pre- and
post-condi=ons)
– Scenario:
Sequence of Events (steps, events,
interac=on)
Itera&ve Elabora&on
(compare to refinement and abstrac=on of
goals in the earlier lecture)
(1) Cluster scenarios to tasks
(2) Elicit task-specific scenarios,
analyse and walk through them

11. Use cases
& Scenarios:
Cockburn
template
Dr. Birgit Penzenstadler 11
• Use: Use cases and
scenarios complement
each other.
• Techniques: Structured
text and/or sequence/
interac=on diagrams
• Elicita&on: itera=ve;
combine scenarios to
tasks, „play out“ task-
specific scenarios and
analyse

12. Example
UCI winter 2014 Dr. Birgit Penzenstadler 12

13. Exercise: ATM
• Use case overview
• Use case template
• Scenario
Dr. Birgit Penzenstadler 13
[Scoa W. Ambler 2007]

14. • Use Case: <number> <the name should be the goal as a short ac=ve verb phrase>
• CHARACTERISTIC INFORMATION
– Goal in Context: <a longer statement of the goal, if needed>
– Scope: <what system is being considered black-box under design>
– Level: <one of: Summary, Primary task, Subfunc=on>
– Precondi=ons: <what we expect is already the state of the world>
– Success End Condi=on: <the state of the world upon successful comple=on>
– Failed End Condi=on: <the state of the world if goal abandoned>
– Primary Actor: <a role name for the primary actor, or descrip=on>
– Trigger: <the ac=on upon the system that starts the use case, may be =me event>
• MAIN SUCCESS SCENARIO
– <put here the steps of the scenario from trigger to goal delivery, and any cleanup aner>
– <step #> <ac=on descrip=on>
• EXTENSIONS
– <put here there extensions, one at a =me, each refering to the step of the main
scenario>
– <step altered> <condi=on> : <ac=on or sub.use case>
– <step altered> <condi=on> : <ac=on or sub.use case>
• SUB-VARIATIONS
– <put here the sub-varia=ons that will cause eventual bifurca=on in the scenario>
– <step or varia=on # > <list of sub-varia=ons>
– <step or varia=on # > <list of sub-varia=ons> Dr. Birgit Penzenstadler 14
1 of 2

15. • RELATED INFORMATION (op=onal)
– Priority: <how cri=cal to your system / organiza=on>
– Performance Target:
<the amount of =me this use case should take>
– Frequency: <how onen it is expected to happen>
– Superordinate Use Case:
<op=onal, name of use case that includes this one>
– Subordinate Use Cases:
<op=onal, depending on tools, links to sub use cases>
– Channel to primary actor:
<e.g. interac=ve, sta=c files, database>
– Secondary Actors:
<list of other systems needed to accomplish use case>
– Channel to Secondary Actors:
<e.g. interac=ve, sta=c, file, database, =meout>
• OPEN ISSUES (op=onal)
– <list of issues about this use cases awai=ng decisions>
• SCHEDULE
– Due Date: <date or release of deployment>
2 of 2
Dr. Birgit Penzenstadler 15

16. • Use Case: 1 withdraw money
• CHARACTERISTIC INFORMATION
– Goal in Context: user withdraws money from the ATM
– Scope: ATM
– Level: Primary task
– Precondi=ons: user has an ATM card and has access to ATM
– Success End Condi=on: user gets money
– Failed End Condi=on: user doesn’t get money
– Primary Actor: customer (= user)
– Trigger: ATM card entered by user
• MAIN SUCCESS SCENARIO
1. User enters card
2. System prompts for PIN
3. User enters PIN
4. System prompts op=ons for withdrawal / transfer / deposit money
5. User selects withdraw
6. System prompts for amount
7. User enters amount
8. System returns money
• EXTENSIONS
– 5. condi&on selec=on of different account: ac&on Withdraw from different account
– <step altered> <condi=on> : <ac=on or sub.use case>
– <step altered> <condi=on> : <ac=on or sub.use case>
• SUB-VARIATIONS
– 4. condi&on user entered wrong PIN: ac&on system displays error message
– 8. not enough money: system displays error message
– <step or varia=on # > <list of sub-varia=ons>
• RELATED INFORMATION (op=onal)
– Priority: cri=cal
– Performance Target: one minute
– Frequency: very onen (depends on loca=on of ATM)
– Superordinate Use Case: <op=onal, name of use case that includes this one>
– Subordinate Use Cases: <op=onal, depending on tools, links to sub.use cases>
– Channel to primary actor: interac=ve
– Secondary Actors: <list of other systems needed to accomplish use case>
– Channel to Secondary Actors: <e.g. interac=ve, sta=c, file, database, =meout>
• OPEN ISSUES (op=onal)
– <list of issues about this use cases awai=ng decisions>
• SCHEDULE
– Due Date: May 2014
Example
Use Case
ATM
Dr. Birgit Penzenstadler 16

17. Use Cases vs. Scenarios vs. Func=onal
Requirements
17
Use Case
Use Case: Set of all scenarios
Scenario: Concrete interac=on sequence
Func=onal requirement (roughly):
A (system-)reac=on to a s=mulus
Functional
requirement
Scenario

18. Example: Scenario Purchase Item
Dr. Birgit Penzenstadler 18
Def.: A
scenario is an
ordered set of
interac=ons
between
partners,
usually a
system and a
group of
external
actors.

19. How-to: Scenarios in a diagram
• UML Sequence Diagram:
– For user interac=on
– For message sequences
• UML Ac=vity Diagram:
– For process flows
– For system-internal interac=on
à Depends on your system what works beaer.
Dr. Birgit Penzenstadler 19

20. Differen=a=on
• Sequence diagrams describe interac=ons among classes in terms of an
exchange of messages over =me. Sequence diagrams show a detailed flow
for a specific use case or even just part of a specific use case. They are
almost self explanatory; they show the calls between the different objects
in their sequence and can show, at a detailed level, different calls to
different objects.
• Ac&vity diagrams illustrate the dynamic nature of a system by modeling
the flow of control from ac=vity to ac=vity. An ac=vity represents an
opera=on on some class in the system that results in a change in the state
of the system. Typically, ac=vity diagrams are used to model workflow or
business processes and internal opera=on.
• Sequence diagram models the sequen=al logic, ordering of messages with
respect to =me.
• Ac&vity diagram high-level business processes, including data flow, or to
model the logic of complex logic within a system.
Dr. Birgit Penzenstadler 20

21. Sequence Diagram
Dr. Birgit Penzenstadler 21
the getFigureAt() method call’s return is shown labeled with the name of the object
that was returned. A common practice, as we have done in Figure A1.7, is to leave
off the return arrow when a void method has been called, since it clutters up the di-
850 APPENDIX 1 AN INTRODUCTION TO UML
:MouseListener :Drawing :GraphicsaFigure:Figure
.setColor(red)
.highlight(graphics)
.getFigureAt(point)
.mouseClicked(point)
aFigure
.drawRect (x,y,w,h)
.drawString(s)
FIGURE A1.7
A sample
sequence
diagram

22. Sequence Diagram: frame
Dr. Birgit Penzenstadler 22
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
An empty UML 2 frame element

23. Sequence Diagram: in/out messages
Dr. Birgit Penzenstadler 23
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
A sequence diagram that has incoming and
outgoing messages

24. Sequence Diagram: Lifelines
Dr. Birgit Penzenstadler 24
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
An example of the Student class used in a
lifeline whose instance name is freshman

25. Sequence Diagram: Messages
Dr. Birgit Penzenstadler 25
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
An example of messages being sent between
objects, including return messages

26. Sequence Diagram: help method
Dr. Birgit Penzenstadler 26
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
The system object calling its determineAvailableReports method

27. Sequence Diagram: asynch/synch
Dr. Birgit Penzenstadler 27
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
A sequence diagram fragment showing an
asynchronous message being sent to instance2

28. Sequence Diagram: guard
Dr. Birgit Penzenstadler 28
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
A segment of a UML 1.x sequence diagram in
which the addStudent message has a guard

29. Sequence
Diagram:
alterna=ve
Dr. Birgit Penzenstadler 29
hap://www.ibm.com/developerworks
/ra=onal/library/3101.html
A sequence diagram fragment
that contains an alterna=ve
combina=on fragment

30. Sequence Diagram: op=on
Dr. Birgit Penzenstadler 30
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
A sequence
diagram fragment
that includes an
op=on
combina=on
fragment

31. Sequence
Diagram:
loop
Dr. Birgit Penzenstadler 31
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
An example sequence
diagram with a loop
combina=on fragment

32. Sequence
Diagram:
reference
Dr. Birgit Penzenstadler 32
hap://www.ibm.com/developerworks/ra=onal/library/3101.html
A sequence
diagram that
references two
different
sequence
diagrams Problem – it seems like cash is returned either way

33. Sequence Diagram
Dr. Birgit Penzenstadler 33

34. Use case template to MS Diagram
• Use case template extension – depicted as
op=on in message sequence diagram
• Use case template subvaria=on – depicted as
alterna=ve in message sequence diagram
Cephei, 12.12.2012 Dr. Birgit Penzenstadler 34

35. Exercise: ATM
• Use case overview
• Use case template
• Scenario
Dr. Birgit Penzenstadler 35
[Scoa W. Ambler 2007]

36. ATM Scenario in
UML Sequence diagram
Dr. Birgit Penzenstadler 36