1765217752 Methods: Deciding What to Design Use Case Modeling I

1
17-652/17-752Methods Deciding What to Design
Use Case Modeling I

• Jim Herbsleb
• Carnegie Mellon University

2
Are there any answers?
3
Today

• Use case basics
• Dangers and balancing
• Business decisions, money, and risk
• Random advice about use cases

4
Two Roles of Use Case Models

• Development team
• Architecture
• Deisgn
• Functional testing
• User interface design
• Stakeholders
• Basis for agreement with customer
• Communication with stakeholders
• Need to keep both audiences in mind!

Jim Heumann, Requirements Evangelist, IBM
Rational
5
Right Granularity Is Important

• What would you think if you saw a use case named,
  e.g., modify data? Or get mortgage
• Three levels (Alistair Cockburn)
• Sea level (user goal)
• Should get most attention
• Kite level (bigger goal)
• Useful to write a few of them
• No more than 4-5 even for biggest systems
• Underwater, clams eye view
• Too detailed
• Dont do it in most circumstances
• Give examples for studio projects . . .

Jim Heumann, Requirements Evangelist, IBM
Rational
6
User Goals

• Yields an observable result of value
• Needs to stand alone, especially in the early
  design
• No sequencing, explicit interaction of use cases
• Extend, include, generalization are the
  exceptions

7
Today

• Use case basics
• Dangers and balancing
• Business decisions, money, and risk
• Random advice about use cases

8
Dangers of Use Cases

• Use cases are not object oriented, but rather,
  functional
• A use case is often implemented using multiple
  objects and classes
• Classes implement many use cases
• If work is assigned based on sets of use cases,
  there is potential for duplication, multiple
  variants, or scattering of objects
• Made worse with extensive use of extend, include,
  generalization
• Made worse when use cases are basis for
  incremental development, project tracking such as
  earned value

Use Cases the Pros and Cons By Donald G.
Firesmith
9
And Yet More Dangers

• Semantic gap between functional use cases and
  network structure of object model, with
  collaborating objects and classes traceability
  is difficult and confusing
• Hard to know when to stop
• Not ideal for representing logic, loops,
  concurrency
• May lead to naïve decompositions, e.g., single
  control object for each use case, several dumb
  entity objects
• Not ideal for cases where there is much
  functionality that is not triggered by external
  actor (e.g., some control functions)

Use Cases the Pros and Cons By Donald G.
Firesmith
10
Mitigating These Dangers Balancing

• Domain analysis
• Interface specification
• User interfaces how about UED?
• Systems interfaces
• Architecture definition
• Each forces you to think explicitly about the
  structural characteristics of the system

11
Today

• Use case basics
• Dangers and balancing
• Business decisions, money, and risk
• Random advice about use cases

12
Business Decisions


Next work Product
Idea
Work Product
Time
Adapted, with apologies, from Boehms spiral
model.
13
Decision Points
Risk
Money
Make Product Proposal
Product Definition
Feasibility
Vision
Implement
Time
14
Decision Points
Risk
Money

• Where you are influences
• What technique to apply
• How to apply it
• How would you apply use cases analysis
• Feasibility?
• Vision?
• Product definition?
• Implementation?

Time
15
Today

• Use case basics
• Dangers and balancing
• Business decisions, money, and risk
• Random advice about use cases

16
Random Advice - 1

• Preconditions and postconditions
• Dont reach for them
• student must be alive
• system must be running
• State of the world (as opposed to system) not
  helpful
• Alternate flows can be
• Regular variants
• Odd variants
• Exceptional (error) flow
• Pick main flow that best captures the main goal

17
Random Advice - 2

• Pick a style to structure text
• Not specified in UML
• Drives people crazy if each person has different
  style, and each UC guru has a different one
• In general
• No GUI
• No architecture
• Steps may affect the architecture
• No internal processing unrelated to a stakeholder
  requirement
• Dont be afraid of detail be judicious
• Enough to satisfy all stakeholders that their
  interests will be satisfied in the delivered
  system (Heumann)
• Appropriate constraint for developers

18
Random Advice - 3

• Creativity?
• Something not brought up by stakeholder?
• Writing the flow can affect the user experience
• E.g., system will pre-populate the application
  form with all information possible from the bank
  records
• What about collecting actors and use cases in a
  brainstorming session or stakeholder workshop?
• Risks?
• Advantages?
• How about use cases for real-time systems?
• Useful?