Transcript Document 7412663

Use Case Diagrams
Use Case Descriptions
Use Case Book
and
Visual Modeling Book
18
1
Use Case Diagrams…
Withdraw Money
Transfer Money
2
Extending the UML with Stereotyping
Know we have ‘Change’ in everything.
 Extend UML? Built in feature!

– extend UML for new ‘types’ ; New types of model elements!
– allows customization of models for project
Stereotypes allow ‘refine’ / ‘reclassify’ ‘re-specify’ all
model elements into a more specialized form rather
than create additional symbols!
 Example: might specify a Use Case as a <<mission
critical>> or class name with the stereotype:
<<boundary>> or <<control>> etc.
 Most common UML stereotyped element is the class.
 Stereotyping makes these different model elements!!!

3
Stereotypes in Modeling:
Built-ins and User-Defined

Associations in Use Case Diagrams may be
stereotyped as includes or extends. (built-ins)
– Now, special kinds of associations between Use Cases (later)
– Can be used to ‘increase relevance’ of model elements, such as
use cases in requirements gathering.
– (Much controversy on ‘extends’ and ‘includes’ and use cases
invoking use cases...(Later) <includes> and <extends> …

Use Cases may also be stereotyped
– “Stereotyped element”  has ‘special’ criteria.
– e.g. A use case that is “mission critical” => must be processed
within five seconds.
– A <mission critical> use case ‘may’ be specified in a separate
document addressing all stereotypes

Classes may also be stereotyped: <boundary>, others…
– A boundary class is one that interacts directly with an actor…

Any UML modeling element may be stereotyped….
4
Use Cases
5
Use Cases
Use Cases – a great tool that helps us
to express interactions between
system (application) and actor.
 Meaningful to customer who is
concerned with the ‘whats’ of the
system.
 Successful development of Use Cases
requires an understanding of the goals
of each of the use cases.

6
Goals of Use Cases

Meant to show interactions between system and
external entities (actors) with system .
– Interactions must present a value to actor.
– actor may be an accounting system; general ledger
system; person; customer; a relay; or thermostat…

Use Cases are black box representations; they
– 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…
7
Goals: Use Cases capture ‘whats’
“Context-free” use
 Excellent for requirements gathering / modeling;
analyzing the user environment…
 Numbers of Use Cases?

– 70-80 for very large system?
– Medium sized – 20 to 50;
– Small systems - fewer.

Smaller number forces abstraction. Desirable.
8
Use Case Diagrams and Relationships
9
Actors

Actors trigger the start of a use case.
– people, computer systems, date/time, relay, device...

Secondary actors
– 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.

Actors may be:
– Systems feeding your system and vice versa.
• May be a legacy RDBMS or a legacy VSAM file…
– Pressure and temperature may be actors (triggers)


Actors may influence how the classes are constructed;
may themselves become classes – e.g. Customer
Makes sense to take care in creating the right actor to
interact with the use cases.”
10
Actors and Use Case Diagrams

Not customary to label association lines
between actor & use case.
– Default is <<communicates>>
• But there are others…
Actors have ‘role names’ – useful if
‘association’ needs information beyond the
fact that they simply interact.
 Associations exist in many ways and
among many model elements…
 Exist between actors, use cases, and actor
11
and use cases

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.
12
some use case
Different use case
13
Use Case Associations
Extend/Include Adornments

Stereotyped associations indicate a special kind of
association. (good pix – Fig 2.13)
– Extend (blunt side) is a special use case that extends the
original use case (sharp)
• extended use case would not exist without the use case it is
extending; special case; exceptional behaviors.
• Arrow points toward the base use case that is 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.
• (Similar steps put into the owner Use Case.
• e.g. Authenticate User

Called ‘adornments’ when certain special cases would
clutter original use case.
14
The Use Case Template





A page or two of text; corresponds to a
rounded oval in the Use Case diagram.
Definitely need a standard template.
May create your own – but be consistent.
Use Case 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.
15
All seem important.
Use Case Template - more



Create an “index of use cases” to index
the use cases…
Name – unique and in English; verb  object
Iteration – stage; identify each use case.
– (façade, filled, focused, finished… many name variations…)


Description – a couple of sentences describing the
interaction.
Basic Course of Events
– actor always takes first step (trigger)
– always the happy path (simple path)
• can include a picture, if helpful. (Attached)
• Happy path: the most common interaction.
16
Use Case Template - more

Alternative Paths
– less common path
• May not be ‘too less common’
– Each alternative and exception (below) should
indicate WHERE in the basic course of events the
alternative / exception emanates from.
– Where is its starting point…

Exception Paths
• Like alternatives but typically shown for errors.
17
Use Case Template - more

Extension Points
– The extend relationship exists between use cases
when one use case provides an optional sequence of
events that is included in the other use case.
– Extension point shows step (or a name – place
holder) in a use case from which the extending use
case extends. (more later)

Triggers: entry points for a use case - conditions
 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
18
contract between use case and outside world)
Use Case Template - more

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
– written / unwritten rules on how a company
conducts its business.
– Refer to business rules – may be separated

Author and Date
– at bottom; original date for each version: façade,
filled, focused, and finished.
19
Paths and Scenarios

Use Cases – abstract; not too many
– Really need detailed interactions – scenarios.
Will use Scenario Definition #2 – the “Instance,”
where the scenario is a realization of a use
case (one possible path) with included data.
 Scenarios can be used during requirements
capture for feedback to users and analysts that
the use cases accurately reflect user needs,
and in testing to test whether the system
reflects the requirements.
 Scenarios, then, are instances, of use cases
(complete with production data) that effectively
test one path through a use case.
20

Exception and Alternative Paths


Last look:
Exceptions are errors that occur.
– Interactions thus contain steps to be executed.

Alternatives are close to basic course of events – just
not the most likely course of events.
– No errors- but some authors treat these to document error
conditions.
– Alternatives may be just as important as the basic course…
– Some authors treat alternatives and MUCH less likely to occur. I
don’t.

Be aware that there are some very heated
disagreements over implementation of use case
diagrams and their extensions:
– The use of <<includes>> and <<extends>> !!
21
Read last three pages of chapter – Use
Cases for Inquiry-only systems, Use
Cases for Requests For Proposals, etc.
 DO READ THESE.

22
Summary Tidbits on Use Cases
Use Case Driven Modeling by Rosenberg



Essence of use case model is to capture user requirements of a
new system or based on an existing system.
Detail all scenarios users will be performing
Use Case Model is at conceptual center of the process.
– Developed in cooperation with domain model
– Precedes Analysis model


UC – sequence of actions that an actor, usually a person, but
perhaps an external entity, such as another system, performs
within a system to achieve a particular goal.
A complete and unambiguous use case describes one aspect of
usage of the system without presuming any specific design or
implementation.
– Result of UC Modeling: all required system functionality is
described in the use cases!! (Recall, however, that these evolve…)
– We show use cases and actors on a use case diagram.
23

Some authors describe use cases as:
– Analysis-level use cases – never instantiated
– (sometimes called business process use cases)
– Design-level use case – instantiated; concrete…
contains real data….

Some authors call design-level use cases
scenarios.
– Should take a solid paragraph or two to capture
the essence of a design use case.

Rapid prototyping can be used to
demonstrate ‘proof of concept.’
 Can write a rough Users Manual from the
prototype and use case descriptions.
– (as if the prototype were a fully functioning
system….)
24




From prototyping, you normally get the Basic Courses of events,
because rapid prototyping normally (may often) ignores alternatives
and exceptions…
Prototype can contain simple windows containing radio buttons or
generic icons – only to show functionality..
Should have a window navigation diagram w/i prototype.
Whether you build a prototype, draw mockups, or use some other
technique to address the visual aspects of your system, it is very
useful to link your screen designs to your use cases.
– (Can do this manually or via a visual modeling tool.)

Use Case text should be relatively free of presentation details.
– Field names often match up directly with attribute names in
domain classes.
– Many nouns / actors are classes in domain model
– Interactions will be ‘control’ later…

 Important to do prototyping, mockups, etc. before you start
writing use cases…Otherwise, you may spend lots of extra time
trying to pin down your user expectations….

 Remember, a static model isn’t really ‘static’ until the system
works!
25

‘Basic course of action’ is the main start to
finish path the user will follow.
– Alternate course of actions represent an
(infrequently) used path through the scenario, an
exception, or an error condition.
Goal is NOT to build an elegant use case –
goal is to ACCOUNT for everything user
might do!
 The more well-defined the system behavior
is (modeled from the interactions in use case
and other design drawings later), the easier it
will be to build the system.

26
Factoring out Commonality in Usage


Generalization - …
Includes – involves making one use case take full use of
another use case.
– Goes to ‘reuse’ = a prime objective of use case modeling.


Association is defined as a stereotype. Put ‘includes’ on arrow.
Extends – allows a modeler to insert one use case into another
use case thus ‘extending’ the second use case.
– Can show ‘optional system behavior’ or behavior that is executed
only under certain circumstances.
– Defined as a stereotype Put ‘extends’ on association arrow.




UML defines a use case as one form of a class….But we
normally do not Generalize use cases, because generalization
is most useful for building elaborate structures dominated by
abstract use cases….(But some people do…)
Don’t spend lots of time worrying to use includes, extends …..
Don’t spend lots of time with long, involved use case templates.
(I like extends and includes to assist in factoring use cases…)
27
Use Case Packages



A package is a grouping of related model elements
such as classes, use cases...
Very desirable to group into packages primarily
because these packages can be used to form logical
boundaries for dividing work among sub-teams.
A good rule of thumb – each package should
correspond with a chapter or at least a major section
in the user manual.
– A division of functionality, responsibilities, etc……

Package Diagrams may contain use cases that are
related….
28
More – very important tidbits here.

The relationship between requirements and use cases is subject
of much discussion.
–
–
–
–

A use case describes a unit of behavior
A requirement describes a law that governs behavior
A use case can satisfy one or more functional requirements
A functional requirement may be satisfied by one or more use
cases…
Note that a system will have other requirements besides
‘functional,’ such as performance, maintainability, scalability,
reliability… that don’t map easily to use cases….
– These tend to ‘thread themselves through Use Cases.’ More later.

At end of use case modeling, you are ready to embark upon the
creation of an analysis model (or preliminary design) … (some
authors call it a robust analysis…)
– This will involve very careful and highly iterative analysis of use
cases and all their scenarios.
– This can only take place after the full Use Case Model is
completed.
29
Summary

Where are we in our projects?
– ‘Done’ with real-world domain objects and business modeling….
– Hopefully have done rapid prototyping of proposed system to gain
substantive information…
– Identify your use cases using use case diagrams
– Organize use cases into packages…
– To do: allocate functional requirements to the use cases and
domain objects at this stage….(early Use Case iteration…)

To do: we will have a full Requirements Review after next
bullet:
– Will develop full descriptions of each use cases – basic courses of
action that represent mainstream interactions and alternate courses
for less-frequently traveled paths and error conditions.
– Will then develop: analysis model….
• For each use case, identify first cut objects to accomplish the stated
scenario. Use stereotypes…
• Update domain model class diagram with new objects and attributes as
you discover them.
• Ensure initial vision still holds;

To do: have a preliminary design review……
30
Common Mistakes










10. Write functional requirements instead of usage scenario text
9. Describe attributes and methods rather than usage
8.  Write the use cases too tersely
7.  Divorce yourself completely from the user interface
6. Avoid explicit names for your boundary objects.
5.  Write using a perspective other than the user’s, in passive
voice.
4. Describe only user interactions; ignore system responses.
3.  Omit text for alternative courses of action
2. Focus on something other than what’s ‘inside’ a use case,
such as how you get there (precondition) or what happens
afterward (post-condition).
1. Spend a month deciding whether to use includes or extends.
31