CSE681
Software Modeling
and
Analysis
Chapter 3
Use Cases, CRC Cards
Jim Fawcett
Copyright (C) 1997-2002
Chapter 1 - Use Cases, CRC Cards
1
Use Cases

Who are the users?
–
–
–
–

What roles do they play?
What do they need?
Why are they using our system?
What does the system need from them?
What information do users get from system?
– How do they build information from data generated by the system?
– What data formats are appropriate to convey the
desired information?
– Do we need to save data between invocations?

What information does the system need from
users?
– What data formats are appropriate to convey the
desired information?
– Do we need to save inputs between invocations?
Chapter 1 - Use Cases, CRC Cards
2
Use Case is a Scenario
input
information
output
information
user
input
data
Processing
output
data
persistent data
Chapter 1 - Use Cases, CRC Cards
3
Questions about Use Cases

What user input events are significant to the
system?
– Do we need to process asynchronous requests?
– Will the user need to interrupt processing?
– Will the user respond to system outputs before
processing terminates?

What program events are significant to users?
– Does the user need progress reports?
– Should intermediate data be shown to the user?
– Does the user need to create new inputs in
response to outputs before termination?

What outputs are significant to the user?
–
–
–
–
Progress messages?
Error messages?
Requests for decisions?
Are there multiple output messages and formats?
Chapter 1 - Use Cases, CRC Cards
4
How do We Identify Use
Cases?

List hypothetical users and their roles
– define typical user
– are there atypical users?
– are there unusual events or tasks

List useful products
– what tasks are required to produce each
product?
– are some tasks common to all the products?

Find new applications for required tasks
– have we unnecessarily limited system operation?
– have we been too ambitious in goal setting?

Interview customers
– identify their goals
– what tasks and products are required to achieve
their goals?
– what objects are appropriate for each task?
– How do users interact with objects?
Chapter 1 - Use Cases, CRC Cards
5
Interviews

Is the interviewee describing:
– surface symptoms?
– Internal details?
– Internal structure?
internal structure
surface details
internal details
Chapter 1 - Use Cases, CRC Cards
6
Users

Users may be people:
–
–
–
–
–

developers:
managers
quality inspectors
marketing
customers
need all the details
need summaries
need all final results
need statistics
need help with tasks
Users may be other software components:
– input collectors
• need a sink for all their outputs and need to detect input
errors
– data displayers
• need error-free data source
• need to know formats
• need to know initiation and termination events
– executives
• don’t want to know any details
• don’t want to participate in formatting
– data transformers
• need error free data
• don’t want to deal with formatting
Chapter 1 - Use Cases, CRC Cards
7
User Role Types

Commander:
– issues open loop command to system, expects
absolute compliance
– looks only for error messages or completed product

Constructor:
– progressively builds a product

Declarer:
– states facts and relationships
– asks questions about implications of facts and
relationships

Functional Transformer:
– asks for transformations of inputs or persistent data
– examines outputs
– may lead to further inputs

Observer:
– watches continuos output
– observations are expected to trigger some action by
observer

Controller:
– supplies inputs based on monitored system state
Chapter 1 - Use Cases, CRC Cards
8
CRC Cards

Component:
– identifier of user, module, object, or class

[Role
]
[ – component’s role or role type ]

Responsibilities:
– what tasks and products is this component
responsible for?

Collaborators:
– what other components does this component
interact with?
– What messages are received?
– What messages are sent?
Chapter 1 - Use Cases, CRC Cards
9
Component:
Responsibilities:
Collaborators:
Chapter 1 - Use Cases, CRC Cards
10
Component: PAGE User
Role:

commands pagination
Responsibilities:



invoke PAGE program
supply list of file names
supply page parameters, e.g.,
margin, line width, number lines, ...
Collaborators:

PAGEexecutive object
– pass file patterns, commands
Chapter 1 - Use Cases, CRC Cards
11
Component: PAGEexecutive
Role:


Integrates server activities to carry out pagination
makes lower level components independent of
application specifics for later reuse
Responsibilities:


reduce file patterns to, possibly empty, sequences
of names matching files in default directory
pass expanded command line to processCL object
Collaborators:

getUniqueName object
– send filename pattern
– get sequence of matching names

processCL object
– pass filenames, commands
Chapter 1 - Use Cases, CRC Cards
12
Component: getUniqueName
Responsibilities:
 finds the next available file name in the default
directory matching a name pattern.
 returns null name if no more matches exist
Collaborators:
 PAGEexecutive
– receives file pattern
– returns next unique matching file name
Chapter 1 - Use Cases, CRC Cards
13
Component: processCL object
Responsibilities:



read command line tokens
parse into filenames and parameter setting
commands
set page parameter values based on commands
Collaborators:

PAGEexecutive
– accept file names, parameters

Params object
– set parameter values

headerLine object
– send unique filename

builderPage object
– send current parameter object, header object
Chapter 1 - Use Cases, CRC Cards
14
Component: Params Object
Responsibilities:
 build default set of parameter values
 receive set value command and modify
appropriate parameter value
Collaborators:
 PAGEexecutive Object
– receive default parameter values

processCL Object
– receive set value command

buildPage object
– give top margin, number of lines, first and last
pages

textLine, headerLine objects
– give margin, width, tab stop width,
isContinuousCount
Chapter 1 - Use Cases, CRC Cards
15
Component: buildPage object
Responsibilities:
 build header line, using header object
 build lines of text, using line object
 look for orphans?
 send page to output stream
Collaborators:
 processCL
– receive file name, params

headerLine
– send file name
– receive file pointer, line pointer

textLine
– send file pointer
– receive line pointer
Chapter 1 - Use Cases, CRC Cards
16
Component: headerLine
Responsibilities:
 open file
 send error message if open fails
 put filename on left
 date and time in middle
 page number on right
 send line to output
Collaborators:
 buildPage
– receive file name, params
– return file handle, line pointer

output stream
– send line of chars to output
Chapter 1 - Use Cases, CRC Cards
17
Component: textLine
Responsibilities:
 if not blank extract line of chars from file
 if blank insert newline in first char position
 send line to output
Collaborators:
 buildPage
– receive file handle
– return line of chars

output stream
– send line of chars to output
Chapter 1 - Use Cases, CRC Cards
18
PAGE DFD1
Params
PAGEexecutive
file
co pa
m tte
m rn
an s,
ds
current parameter values
new parameter value
me
rs,
fie rs
i
t
n e
ide met
r
a
e
t
r
me pa
ra ault
a
p ef
d
na
file
file pattern
getUniqueName
fil
co ena
m m me
an s,
ds
or
err
e
te
g
ssa
me
d
ge
pa
cu cur
rre ren
nt t f
pa ilen
ra am
m e
et
er
s
processCL
xt
buildPage
ag
e
es
s
m
e
ro
rm
na
er
file handle
le
nd r
ha inte
file e po
lin
line poin
ter
file
headerLine
e
fil
file
tim
e
&d
t
ate
x
te
textLine
Chapter 1 - Use Cases, CRC Cards
19
PAGE DFD1 Notes

We added PAGEexecutive to help make processCL
more reusable in later applications.

getUniqueName processing can be done in Visual
C/C++ environment with library processing invoked
by initialization code. We just link with setargs.obj.

At this point we have a very clear idea about how to
proceed with an implementation.
– We were able to reason effectively about the structure
and operations required of each component.
– If we need to prepare a formal requirements document
that is now a fairly simple process of elaborating what
we already have.
– We know what events are important and what objects
are needed and how they must interact.
Chapter 1 - Use Cases, CRC Cards
20