Introduction to Use Cases
Facade Use Cases
Initial Requirements
17
1
First Real Cut at Application
Requirements
Façade Use Cases
Amount to ‘placeholders’ for expanded use cases (to come).
Contain name and short description of the interaction;
contains initiating actors.
Verb…objects.
Typically, we do NOT know all the details.
Want to capture the ‘architecturally significant’ use cases…
(What are these???)
Trying to identify key functions / risks / interactions at a global
level.
2
Introduction: Façade Use Cases
Ensure façade use cases are user-centric and
NOT technology-centric. Why? What does this
mean?
Again, these are the WHATS that the users
want! These are the ‘behaviors’ of the system.
Express in terms the users understand!
Involve various sources early and frequently
Many different stakeholders with diverse ‘takes’ on
the application…
3
Use Case Index
This is a Table of Contents for your Use Cases (that will be
developed). Single Sheet; table in Word
For each Use Case in the index (include a designator (like
UC1, UC2, …), followed by the use case name, short
description (two or three sentences), actors, level (façade,
filled, focused) date last updated (for now).
You may also write a ‘short user story’ describing the use
case objectives. If so, this must be very short!!
“Façade use cases show the basic, essential, high-level
interactions that this application must support (Constantine
1999).”
4
Use Case
Number
Use Case Name
Description
Actors
Level
Date of Update
1
Upload Document
Customer will be able to upload documents for
translation
Customers,
Database
Focused
11/13/2006
2
Translate Document
The System verifies that payment has been
received from the billing company and proceeds
to translate the source document. The language
consultant reads and corrects errors in the virtual
document.
Billing Company,
Language
Consultant,
Database
Focused
11/13/2006
3
Ship Document
System administrator arranges for shipments to
Customer, Shipping
customers. Shipping company ships final product company, System
hard copies and reports the status of shipments to Administrator
the system administrator.
Focused
11/13/2006
4
Maintain Database
Administrator corrects errors and updates all
system databases.
System
Administrator,
Database
Focused
11/13/2006
5
Update Profile
The customer is able to change their personal
information.
Customer, Database
Focused
11/13/2006
6
Change Order
The customer is able to change their order
attributes.
Customer, Database
Focused
11/13/2006
7
Retrieve Document
Customer retrieves target documents.
Customer, Database
Focused
11/13/2006
8
Print Document
System directs customers to Printing
Customer, Printing Focused
company. Printing company provides printing company, System
options to customers and the information is
Administrator
11/13/2006
Façade Use case: Attributes (Rows)
Name of the use case – short name (verb, object); action words;
Actor(s) that trigger the use case…
Level (façade, filled, focused…These refer to levels of granularity.
Short Description – two three sentences: at the most! (story?)
Leave room for the Basic Course of Events…(happy path)
Pre and Post conditions, and more (see ahead…)
Trigger (what initiates the use case…. They just don’t ‘start’)
Business Rules Link (Reference Business Rules in your Use Cases
Risk priority (reference your Risk List preferable by number or
identifier)
Link to text on non-functionals (quality metrics; constraints) here, if
desired
Date / author(s)
We will add attributes like Alternate Paths, Extensions…later)
6
Use Case Number:
03
Use Case Name:
Edit Member Account
Actor (s):
Buyer, Seller
Maturity:
Focused (note: not façade; has basic course of events too)
Summary:
This use case is started by a Buyer or a Seller. It provides the capability for one of these
actors to edit their member profile.
Basic Course of Events:
Actor Action
System Response
1. This use case is started when a Buyer or
Seller elects to edit their member profile.
Perform S1-Login
2. The System displays the
Actor’s member profile and prompts the Actor
3. The Actor updates their member profile. to update it.
4. The System validates the information
entered by the Actor.
{Validate Information}
5. The System prompts the Actor for
6. The Actor confirms that the information confirmation.
is correct.
{Profile Change}
7. The System updates the
Actor’s member profile to the member
8. This use case concludes when the Actor repository and informs the Actor that the
receives visual confirmation of the update. information was updated successfully.
7
Continuing….
Alternate Paths:
A1 Change Member Profile
At {Profile Change} the Member indicates that he/she entered incorrect information.
The System immediately returns to the step 2.
Exception Paths:
E1 Handle Invalid Information
At {Validate Information} if any fields are entered incorrectly.
The System indicates the fields that were entered incorrectly and prompts the Buyer or
Seller to make the necessary corrections.
The flow of events is resumed at Basic Flow Step 2.
Extension Points:
{Change Profile }, {Validate Information}
Triggers:
The Buyer or Seller would like to edit their member profile.
Assumptions:
The Buyer or Seller is aware of the steps required to edit their member profile.
Preconditions:
The System is functioning properly.
Actor already has a Profile stored in the Profile Database???
Post Conditions:
The member profile was successfully updated to the member repository. Actor sent email to
confirm changes.
Reference - Business Rules:
See Business Rules section: 2.3.1 and 2.3.5.
Reference - Risks:
See Risks List sections: 2.1 and 2.4.
Author (s):
Team3
Date:
11-04-04
8
Think About Non-Functional Requirements
(Quality Constraints)
You have seen ‘lists’ of non-functional requirements.
Be aware of a number of examples of non-functional
requirements that may be addressed in your application.
Availability, compatibility, data integrity, extensibility,
interoperability, maintainability, performance, portability, reliability,
robustness, scalability, security, usability / achievability
Know these! (be able to identify them…)
Document these per use case
Non-functional requirements normally not tied to specific use
cases; normally threaded through a number of use cases.
Capture in a Table
These normally are found within a Supplementary
9
Specifications Document…
Verbiage in Use Case
Use Verb-object phrases (stated before…)
Sell Houses, Enroll in Course; Maintain Book…
Should not be instances of classes
Should not be tied to an organization structure, paper
forms or computer implementation
Refer to Prototype to see actions an actor expects to
undertake…(ahead)
Use phraseology from Prototype and Domain Model in text.
Interface items and domain entries will become objects ahead….
Nice technique: Bold items or Italicize items in Use Case
Specifications for which there is a glossary entry or a business entity
in the Domain Model
Have links for key words or entities to domain model / glossary.
10
Candidate Use Case List
Ensure each Use Case is ‘in scope.’
Actors must reflect the roles that people play – not the
actual names of people.
Note: Use Cases will often have multiple actors.
Again: (repeating…)
Actor must provide or receive a value from the system
Do not tie your actors to your organization chart.
11
User Interface Prototype
Use storyboarding to elicit major, high-level enduser requirements.
Document the interactions as seen in the storyboards
as high level text to identify the Façade Use Cases.
The details of the interactions (and likely more
detailed user interface prototypes) will be used to
capture the interactions use cases with more
granularity.
More on prototyping in the next series of slides.
12
Verb Filter and Noun Filter
Use strong verbs (‘generate’ ‘calculate’
‘compute’ )
Use strong, concrete nouns.
Avoid weak nouns such as data, report,
system, form, template, paper…
13
Façade Filter
Façade use cases represent the most important
interactions between the actors and the system.
Don’t worry too much about non-functional
requirements at this time. Will address more later.
Façade use cases should be relatively abstract – so that
they will cover a number of actual proposed
interactions (scenarios). No implementation details!
Façade use cases contain NO basic course of
events….Only trying to identify significant Use Cases
– for their functionality, their actors, pre and post
conditions, triggers, and key attributes…
14
Peer Reviews:
Reviews
Review the use cases carefully.
Have a ‘SME’ available for business domain questions.
Have reviews often and informally
User Reviews:
User review of your Façade use cases is critical.
Every hour you spend in review could save many hours of work later!!!
I RECOMMEND THAT TEAMS REVIEW EACH OTHER’S USE CASES!!
Use Cases capture functional requirements…
15 and
Sometimes called Requirements Analysis…I like to keep ‘Requirements’
Packaging
You need to build packages of Use Cases
group Use Cases of similar ‘value’ or
‘functionality’
16
Use Case Diagrams…
(a graphical model)
Withdraw Money
Transfer Money
Simply actors and use cases
Can, of course, be much more detailed. Often the
relationships are ‘tagged.’
17
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.
18
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…)
19
Examples
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.
Choices
Withdraw Money
<boundary>
(attributes)
<included>
(methods)
Authenticate User
20
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….
21
Use Case Template
(Be aware there are many many formats. Format is not critical. Content is.)
One of many different
kind of formats…
Will discuss others in
next lecture.
22
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.
 We can see the scenarios (instantiation of a use case w/data)


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.
23
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)
24
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…
25