use case diagram

1. USE CASE DIAGRAMS
1
USE CASE DESCRIPTIONS

2. USE CASE DIAGRAMS…
2
Withdraw Money
Transfer Money
Simply actors and use cases
Can, of course, be much more detailed. Often the
relationships are ‘tagged.’

3. EXTENDING THE UML WITH
STEREOTYPING
 Know we have ‘Change’ in everything.
 But very few graphics in UML.
 Need to communicate special cases:
 special classes
 special kinds of use cases…
 Extend UML for new ‘types’
 New types of model elements?
 We often need customization of models for some projects.
 Extend UML? No! Ability to stereotype is built in.
3

4. EXTENDING THE UML WITH
STEREOTYPING
 Enter: Stereotyping.
 Allow us to ‘refine’ / ‘reclassify’ ‘re-specify’ all model elements
into a more specialized form rather than create additional
symbols!
 We might specify a Use Case as a <<mission critical>> or class
name with the stereotype: <<boundary>> or <<control>> etc.
 Indicate that the symbol is still a Use Case – but a ‘special one’
perhaps in a ‘special context.’
 Most common UML stereotyped element is the class.
 Stereotyping makes these different model elements!!!
 (Incidentally, additional icons can be added, if wanted…)
4

5. EXAMPLES
5
Choices
<boundary>
(attributes)
(methods)
Authenticate User
<included>
A ‘special’ kind of class with special behaviors – a boundary class.
A ‘special’ kind of Association – indicates a use case that supports a
more fundamental use case – one that is more significant.

6. STEREOTYPES IN MODELING:
BUILT-INS AND USER-DEFINED
 Stereotypes can be used to ‘increase relevance’ of model
elements, such as use cases in requirements gathering.
 (Much controversy on ‘extend use cases’ and ‘include use cases’
Much more later: stereotypes: <<includes>> and <<extends>>
 Use Cases are quite commonly stereotyped
 A <mission critical> use case ‘may’ be specified in a separate
document addressing all stereotypes
 “Stereotyped element” implies that there are ‘special’ criteria.
 e.g. A use case that is “mission critical” => must be processed
within five seconds.
 Classes may also very often stereotyped:
 <boundary>, <control>, <entity> (as found in Analysis Modeling)
 A boundary class is a special kind of class that interacts directly with
an actor…
 Any UML modeling element may be stereotyped….
6

7. USE CASE TEMPLATE
(BE AWARE THERE ARE MANY MANY FORMATS. FORMAT IS NOT
CRITICAL. CONTENT IS.)
7
One of many different
kind of formats…
Will discuss others in
next lecture.

8. USE CASES
 Use Cases – a great tool that helps us to express
interactions between system (application) and
actors.
 We can see the behaviors of the system.
 Meaningful to customer who is concerned with the
‘whats’ of the system to see how system and actor
interact with each other.
 Successful development of Use Cases requires an
understanding of the goals of each of the use cases,
which, in turn, is developed from identified, required
functionality – namely Features.
8

9. GOALS OF USE CASES
 Interactions must present a value to actor.
 actor may be an accounting system; general ledger
system; person; customer; a relay; or thermostat…
 person, device, external system/database/file.
 Actors are external to the system.
 Use Cases are black box representations
 Do not show implementation-specific language
 Do not want to imply how use case will be realized.
 Do not include language such as: people, interface
widgets (buttons, menus…), IFTHENELSE statements,
pseudo-code, more…
 Are written in language of the application domain.
 Are ‘abstractions’ of detailed interactions.
 Capture stories addressing functional
requirements…
9

10. GOALS: USE CASES CAPTURE ‘WHATS’
 “Context-free” use (that is, no design constraints)
 Excellent for requirements gathering / modeling;
analyzing and capturing desired user interactions
  Numbers of Use Cases?
 70-80 for very large system?
 Medium sized – 20 to 50;
 Small systems – fewer. Often 6 to 8 may be sufficient.
  Smaller number forces abstraction. Desirable.
 There is no ‘one size / number’ fits all. But there are
guidelines in their development! (Coming)
10

11. ACTORS
 Actors trigger the start of a use case.
 people, computer systems, date/time, relay, device...
 Actors must receive value from the system
 Systems that are actors generally supplying data or services to
your system and vice versa.
 May be a legacy RDBMS or a legacy VSAM file…
 Pressure and temperature may be actors (triggers), as well as a
device, such as a conveyer belt, given a signal to start…
 Secondary actors (surrogate actors) (next slide)
 actor/role providing system inputs/outputs from another
actor/role.
 First (outside) actor/role is ‘secondary actor’ and should be
shown if its actions affect system reaction.
11

12. SECONDARY ACTORS
12
Register Guest
Desk Clerk
Customer
<communicates>
(inheritance arrow)

13. ASSOCIATIONS: GENERALIZATION IN ACTORS
 Generalization: Abstract the commonalities.
 two sub-actors generalized into a super-actor
 Have both behavior and attributes in common
– described under the super-actor.
 Super-actor should interact with use cases
when ALL of its sub-actors interact the same
way;
 Sub-actors should interact with use cases
when their individual interactions differ from
that of the super-actor.
13

14. 14
Some use case
Different use case

15. ACTORS AND CLASSES
 Actors may influence how classes are built
because they will be using the services of the
objects of those classes.
 Actors may themselves be classes –
 Customer
 often an Actor – external to the system.
 often a Class (this is NOT an actor)
 Probably: Customer exists in the domain model and
is likely a business ‘entity.’
 Makes sense to take care in creating the right
actor to interact with the use cases.”
15

16. ACTORS AND ASSOCIATIONS
 Not customary to label association lines between actor & use
case.
 Default is <<communicates>>
 But there are others…
 Role names. Actors have ‘role names’ – useful if ‘association’
needs information beyond the fact that they simply interact.
 Actor: Professor. role: student;
 Actor: Professor. role: assessing another’s teaching; …
 Associations exist in many forms and among many model
elements…
 between classes
 between use cases
 between design entities (subsystems, packages, etc.)
 between analysis classes, etc .
16

17. USE CASE ASSOCIATIONS
EXTEND/INCLUDE STEREOTYPES
 Stereotyped associations indicate a special kind of
association. (good pix – Chap 2, Use Cases, Fig 2.12)
 Extending (blunt side) is a special use case that extends the
original use case (sharp)
 “Extending use case” would not exist without the use case it is
extending (the extended use case);
 Used for special cases; exceptional behaviors. Inserted behaviors
 Arrow points toward the base use case that is being extended…
 Include stereotype allows use case designers to avoid
duplicating steps across multiple use cases (a reuse strategy).
 Arrow extends away from the owning parent use case.
 e.g. Authenticate User
 Note: controversial;
 Many Use Case authors do not like these and include the steps
within the use case itself or use some other kind of sub-flow
(later).
17

18. 18
extending Use Case
(inserted behaviors)
(extended) Use Case
Included Use Case
(Particularly good for reuse!)
Use Case
(Primary use case)
(Primary use case)

19. 19
extending Use Case
(inserted behaviors)
Primary Use Case
Included Use Case
(Particularly good for reuse!)
Use Case
Compute Pay
Compute Pay
Compute Pro Pay
Authenticate User

20. THE USE CASE SPECIFICATION
 A page or two of text; corresponds to a rounded oval in the
Use Case diagram. Relate horror stories!!
 Definitely need some kind of a standard template.
 Most organizations using Use Cases develop their own
template format. Consistency is critical.
 In all, the Use Case Specification should contain most of
the following attributes:
 Name, iteration name/number; author, description, basic course
of events; alternative paths, exception paths, triggers,
assumptions; preconditions; post-conditions; references to
related business rules; risks lists, and more.
 All seem important.
20

21. THE USE CASE SPECIFICATION -2
 We have also indicated the need for an Index of Use
Cases. Designate each use case as UC1, …, UCn.
 Have already discussed the UC name: verb -> object
 Iteration = the ‘maturity’ of the use case – and hence
the maturity of our understanding of the functional
requirements. (façade, filled, focused … many name variations…)
 Descriptions –sentences describing the interaction.
21

22. THE USE CASE SPECIFICATION -3
 Basic Course of Events – (NOT in Façade)
 actor always takes first step (trigger)
 always have a ‘happy path’
 Simple path; Most likely path)
 Can include a picture, if helpful. (screen shot, etc.)
 Alternative Paths
 Other paths (may be less common)
 Each alternative and exception (below) should indicate
WHERE in the basic course of events the alternative /
exception emanates from. Starting point.
 Techniques:
  cite the step number;
  labels in the basic course of events (preferred). Discuss.
22

23. THE USE CASE SPECIFICATION -4
 Exception Paths
 Like alternatives but typically shown for errors.
 Extension Points
 The <<extends>> relationship exists between use cases when
one use case provides an optional sequence of events that is
inserted in the other use case. (See pg. 42, Use Case text)
 “Extension point” in the flow of events shows step name (in
braces) or step number from which the extending use case
extends. (more later)
 Note: the extending use case points to the extended use case.
 Again, this implies ‘inserted’ behaviors.
 Extending use case has ‘no life’ without the extended use case
23

24. THE USE CASE SPECIFICATION -5
 Triggers - entry points for a use case
 Assumptions –
 document things assumed to be true (but might not be true) (Critical section.)
 Preconditions –
 Things that must be in place before an interaction may occur. (part of contract
between use case and outside world)
 Post Condition –
 part of contract between use case and outside world; specify outcomes;
independent of alternative path. e.g. transaction successfully posted.
 Related Business Rules
 - Reference to business rules Related Risks addressed by this Use Case.
 Include a reference to the Risk List document
 Author and Date
 at bottom; original date for each version: façade, filled, focused etc.
24