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

June 5, 2009 SPIN How are Use Cases at System Levels Related 1 of 29

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


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


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?


A Use Case describes an essential function of a system

• Show generic UCD.


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?


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.


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.


Review of Requirements development

• Elevator example– What might be Use Cases for an elevator?

• Let’s 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.


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.


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.


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).


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.


How do I describe a Use Case? – Elevator Example

• A Use Case is a functional description of the system from a user’s 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


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?


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


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 lifelines[2], 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.


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 ->


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.


How do we get Use Cases for Lower Levels? Post break and show & tell; ~11:00; 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?


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?


Use Cases add other value to project development <11:20; 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.


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• Visibility of context of integrated system


So you have Use Cases, Now What?

• Retrospective questions


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?


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?


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?


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?


Final thought

• Expect change - and plan for it.


Special Thanks!

• Malcolm Currie • [email protected]; 310 821-3081

• Special Thanks to SPIN Leaders, especially

• Yolanda De Oro

• Warren Schein

• And to NGC and CSULB for Sponsoring the SoCal SPIN

mailto:[email protected]

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

Documents

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