1 of 29

1
How are Use Cases at System Levels Related to
Each Other?

• Biography - Malcolm Currie
• UCLA Control Systems Engineering Ph.D.
• Engineering Consultant - Aerospace and
  Commercial Lear Seigler, Rockwell, Hughes,
  Boeing, Rocketdyne, Schindler Elevator,
• Missile/Aircraft guidance, navigation, and
  control systems Military Systems requirements
  Elevator and Security Systems control software,
• Member of IEEE, GNSS, INCOSE
• Over 14 years of experience in UML

2
Why Learn Experientially?

• Why use examples in learning? Every abstract
  idea can be learned in a concrete way.
  --- Maria Montessori.
• Why use experiential learning? All learning
  is state dependent. --- NLP
• More easily remembered if the learning is tied to
  a reproducible state, e.g., the Learning state
  (Huna Hakalau).
• "Wisdom is not what comes from reading great
  books. When it comes to understanding life,
  experiential learning is the only worthwhile
  kind - everything else is hearsay"
  ---Joan Erikson

3
A Use Case describes an essential function of a
system

• A UC (Use Case) for a system is a description of
  something that the system does for an entity
  outside of the system (referred to as an actor
  because the entity plays a role in its
  interaction with the system).
• A UCD (Use Case Diagram) shows the UCs of the
  system and their communication paths with the
  actors.
• A UCD is a context diagram of a system (for those
  who are familiar with that term).
• An important part of a UCD is the system
  boundary. Why?

4
A Use Case describes an essential function of a
system

• Show generic UCD.

5
Why would you want Use Cases?

• Many organizations have adopted Use Cases for
  defining the intent of a system. This is a good
  start.
• Do they also build executable models of the Use
  Cases?
• Some management is also aware of the power of Use
  Cases as a way to partition a project and to
  track the progress of deliverable capabilities.
• Use Cases are synergistic with the use of the
  principle of incremental development
• Use Cases also complement Risk Management
• Use Cases also provide management a means to
  specify and monitor testing. of project cost?

6
A Use Case maps to tests

• High level Use Cases map to final acceptance
  tests of a system
• allowing the question to be asked during the
  concept phase of a system If you have this
  system, how will it be used?
• Use Cases provide a means to plan tests of the
  system early in development (very early).
• Use Cases at lower levels map to component tests
• allowing the question to be asked during each
  level of decomposition of a system If you have
  this component, how will it be used?
• Use Cases provide a means to plan tests of each
  component of the system early in its development
  (very early)
• to the interfaces, including message protocols,
  expected by the supported system. What is this?
  Groups of messages. How are they determined and
  specified? SDs and ports.

7
Use Cases shorten the development time

• Use Cases, when used properly, will shorten the
  development time especially integration testing
  while improving quality and reducing
  maintenance costs and turnaround time for
  enhancements.

8
Review of Requirements development

• Elevator example
• What might be Use Cases for an elevator?
• Lets get a list of some of the possible Use
  Cases of an elevator as an example, assuming that
  the elevator is installed
• Startup Describes how to apply power safely
• Transport Passenger Describes the Passenger
  experience from calling a car on one floor to
  exiting the car on a destination floor.
• Respond to Emergency Fire persons need special
  access to elevators that override normal
  Passenger services.
• Can you think of any more? Discuss.
• We will revisit this a little later.

9
Use Case Diagram Exercise

• Divide yourselves up into groups of 4 or 5 in
  each group, with some people who attended the
  first part in each group.
• Hands up.
• Select one person in the group to be the
  customer.
• Develop a Use Case Diagram for an elevator and a
  brief description of each Use Case.
• Assume the elevator is installed.
• Use Flip Charts
• Remember
• Magic number 7 /- 2
• What is the actor (role of users) for each Use
  Case?
• What is the value provided to an actor for each
  Use Case?.
• Avoid functional decomposition or sequential Use
  Cases think value to actors.
• How you do anything is how you do everything.

10
What is a Use Case? In More Detail

• A UC (Use Case) for a system is a description of
  something that the system does for an entity
  outside of the system (referred to as an actor
  because the entity plays a role in its
  interaction with the system).
• As such, A UC if a functional requirement not a
  requirement statement, which is often referred
  to as a requirement.
• A UCD (Use Case Diagram) shows the UCs of the
  system and their communication paths with the
  actors.
• An important part of a UCD is the system
  boundary.
• A Use Case is much more than an oval on a UCD and
  a brief textual description.

11
What is a Use Case Description?

• The focus of the UC description is on the
  functional requirement part of system
  requirements.
• A UC Description may include performance and
  constraints relative to the UC itself
• The overall system performance and constraints
  are described outside of the UC description,
  because they apply to all UCs.
• A Use Case is much more than an oval on a UCD and
  a brief textual description.
• The UC description includes
• what the system does,
• why it does it, and
• the value the system provides to the (primary)
  actor.
• A Use Case has a description sufficient to build
  an executable model of the system at whatever
  level of detail is needed during phases of system
  development. Increments and Iterations
• A Use Case describes how the system (or
  component) will be used
• It describes a test of a planned system (or
  component).
• It allows management, customers, and developers
  to understand what they will be building.
• An executable model of a system (or a component)
  and of its environment can evolve into a test
  harness of the system (or a component).

12
What Use Cases were elicited for an elevator?

• Did you get Use Cases such as the following list
  of possible Use Cases assuming the elevator is
  installed? Show and tell is coming
• Startup Describes how to apply power safely
• Transport Passenger Describes the Passenger
  experience from calling a car on one floor to
  exiting the car on a destination floor.
• Respond to an Emergency Service Emergency
  service, such as in a hospital, need to have
  priority service for such things as going to an
  emergency ward.
• Respond to Fire Event Fire persons need special
  access to elevators that override normal
  Passenger services. And hospital staff?
• Provide Software Maintenance Services Allow for
  installation and test of software upgrades.
• Provide Hardware Maintenance Services Allow for
  installation and test of hardware upgrades.

13
How do I describe a Use Case? Elevator Example

• A Use Case is a functional description of the
  system from a users viewpoint apply the
  basics.
• How would a Passenger use and elevator?
• The Transport Passenger Use Case would follow a
  scenario such as the following user story One
  way to describe informally.
• Request a car
• Monitor indications of car status until it
  arrives and the doors open
• Enter the car and perhaps interact with the car
  from inside
• Monitor the car doors closing
• Monitor indication of the car progress to the
  destination floor
• Monitor the car doors opening
• Exit the car.
• Car doors close

14
Is that all there is? Elevator Example Show

• The listed scenario of this type is sufficient
  for a simple, well understood, system.
• For a more complex system
• can describe the scenario in a tabular form or
• use other UML diagram (Message Sequence Diagram,
  Statechart, or Activity Diagram).
• Also need other attributes of a UC, such as pre-
  post-conditions.
• How did you elicit Use Cases?
• To elicit the set of Use Cases for a system, ask
  the customer what he will do with the system.
• Imagine the system exists and after he has it up
  and running (one of the Use Cases is to do this),
  what do you want to do?
• Each group leader show their UCD and brief
  description of a representative Use Case for an
  elevator. Customer?
• What are the actors?
• What is the primary actor for your representative
  Use Case?

15
Description of the Transport Passenger Use Case

• The description must also include the
  preconditions
• e.g., the elevator must be operating in the
  Passenger Service Mode (which is carefully
  defined).
• The description should also include some
  post-conditions for the Use Case
• e.g., the elevator doors are closed and system is
  waiting for another passenger request (in the
  Passenger Service Mode).
• This Use Case description is for the Primary
  Scenario of the Transport Passenger Use Case
• What if the power fails at any of these steps?
• What if a fire alarm overrides the passenger
  request?
• These are analyzed with Secondary Scenarios
  (flows) for the off-nominal and error variations
  to a primary sequence
• Developed as the use case description evolves

16
Now what? Draw generic SD 2 levels

• Now what - after you have the Use Case described
  in text?
• Other UML diagrams describe behavior
• A SD (Sequence Diagram or more explicitly,
  a Message Sequence Diagram).
• A SD describes interactions (messages) between
  objects (e.g., system and actors) in time along
  vertical lifelines2, one lifeline for each
  object.
• An Activity Diagram also describes a activities
• It is possible to use both of these diagrams.
• The SD uses interactions between Objects in
  this case a passenger and the elevator is the
  primary concern.
• The passenger is external to the system (and in
  UML terminology is referred to as an Actor the
  passenger plays a role in the scenarios of a Use
  Case).
• The system, at the top level, is the elevator.
• Later, the system can be divided into objects
  that are functional (for conceptual analysis) or
  physical (when a design is known)
• Draw primary SD examples at two levels for a
  generic Use Case.

17
How would I use a SD (Message Sequence
Diagram)?

• Each UC will usually have only one primary SD and
  several secondary SDs
• Each SD may have several depths
• nested into the base diagram, as described below.
• A top level SD for a UC shows the interaction of
  the system with its actors for a specific UC.
• The interactions in a SD (or message sequence
  diagram) are via messages passing between the
  actor and the system.
• The messages are arranged chronologically
  (without a time scale) down a vertical lifeline.
• The system in each top level SD for each UC can
  be expanded to show the components that support
  that UC
• A top level SD for one UC should not show all
  levels of the components.
• The interaction of the components of the system
  at the next lower level can be described on that
  supporting SD.
• A SD can also show the states of the components
  along the lifeline
• Subsequences (subflows) can be shown on a SD
• much like subroutines in a sequential computer
  program.
• One other point about a SD is the
  desire/necessity for feedback to the primary
  actor
• the initiator of an action gets confirmation of
  the result or an error indication.
• Can you think of a system design where this was
  missed? Now? Take away. Draw 2 levels -gt

18
A Use Case exercise Draw 2 levels break

• Get into your groups again
• 1. Draw a primary SD for the Transport Passenger
  UC of an elevator at the system level.
• What are the pre-conditions /post-conditions?
• What constraints might be important from the
  customer?
• (Never mind performance for now focus on
  functional behavior.) Are you making design
  decisions? If so, list them.
• 2. Draw a primary SD for the Transport Passenger
  UC of an elevator at the first level components
  level. Are you making design decisions? If
  so, list them.
• 3. If you have time, draw a secondary SD at the
  system level.

19
How do we get Use Cases for Lower Levels? Post
break and show tell 1100 2-slides 20
minutes

• Look at the first level SD.
• What does each component provide of value?
• What receives that value?
• Is it another component?
• Is it something external to Use Case?
• What supports the component to provide its value?
  
• Is it another component?
• Is it something external to Use Case?
• Can you see that each component at each level can
  have its own UCs and UCD?

20
How do we get Use Cases for Lower Levels? (2 of 2)

• Can you see that the development of each
  component can be done independently if
  interfaces, including message protocols, are
  defined at the next level up including an
  executable model?
• Can you see that the management of a complex
  project can be managed as several small projects?
• Now the components can be given to subject matter
  experts at that level, along with clearly defined
  interfaces, including message protocols.
• How might that affect the component tests?
• How might that affect the integration tests?
• How might that affect the communication between
  component providers, system integrators, and the
  customer?

21
Use Cases add other value to project development
lt1120 2-slides - what else

• Use Cases support Incremental Development of
  system functionality
• The functionality of the system can be developed
  incrementally
• Risks can be attacked early
• Design decisions between levels are made more
  apparent.
• Caution should be used not to generate more
  levels than necessary. Two is typical. Three is
  rare.
• Use Cases support iterative Development of tasks
  at each level
• The functionality at each level of the system of
  the system can be developed iteratively
• Repeat the process at succeeding level of
  decomposition and each increment of
  functionality/fidelity.
• Formal expression of the functionality of some or
  all components at each level is not always needed
• first model whatever is needed to support the
  interfaces, including the message protocols.
• Then the fidelity of the functionality can be
  elaborated without affecting the interfaces.

22
What if

• What if you had Use Cases and Primary Sequence
  Diagrams for your project?
• Up front Communication customer, management,
  developers, testers.
• And continuing communication during development
  as people com and people leave.
• Visibility of the project
• Define when we are done, before beginning
  building anything (Hw or Sw)
• Executable models
• How might that affect the integration tests?
• Provides test harness of prototypes.
• Test Management
• Test Planning
• begin with the end in mind by UC/Functionality
• Pretest Simulation - reference results
• Test harness plug and play
• Test Progress monitoring visibility and known
  goal calibrate and reschedule
• Prioritize development of the important
  functionality
• Incremental development by UC/Functionality
• Manage schedule calibrate and reschedule
• Faster learning of new people on program
• A known goal

23
So you have Use Cases, Now What?

• Retrospective questions

24
What will you remember from this experience?

• What did you notice about this period of time?
• Was there anything that was challenging to you?
  
• Was there anything that was fun for you?
• What's the first thing you want to say about
  this exercise?
• What's the first thought you would like to
  share about this experience?

25
How might this experience be used for you in your
work/life?

• What makes that a problem for you?
• Then what happens?
• What did you see and hear?
• What is it like to answer these questions?
• Did this exercise go on too long, too short, or
  just right?
• Has this ever happened to you at work?
• What do you do at work when it happens?
• Would you like to learn how to be different?
• Would you like to learn a different way to do
  this?

26
What else did you learn about yourself?

• What do you want to know about yourself?
• Did the exercise suggest any ways you could do
  that?
• How are you now interpreting the word
  requirement?
• Did drawing allow you to process your
  experience fully?
• Do you want to talk about it as well?
• What did you learn by observing that?

27
Use Cases positively impact project development
success End

• Use Cases positively impact project development
  success at all levels
• Why would you want to elicit and develop
  functional requirements without using Use Cases?
• Do you recognize the value of executable models?
• Can you visualize the enormous savings in time,
  energy, frustration, and miscommunication that
  can be realized in Integration Testing alone (a
  major cost in most projects) with the proper
  application of Use Cases?
• Do you appreciate the value in managing a project
  with Use Cases at multiple levels?

28
Final thought

• Expect change - and plan for it.

29
Special Thanks!

• Malcolm Currie
• SEC_Services_at_Earthlink.net 310 821-3081
• Special Thanks to SPIN Leaders, especially
• Yolanda De Oro
• Warren Schein
• And to NGC and CSULB for Sponsoring the SoCal
  SPIN