so you have use cases, now what?

May 8, 2009 So You Have Use Cases – Now What? 1 of 30

So you have Use Cases, Now What?

• 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 experience in UML


Why Learn Experientially?

• Every abstract idea can be learned in a concrete way.– Maria Montessori.


Develop Requirements

• How many of you are knowledgeable of elicitation and development of

requirements for a system?

• Divide yourselves up into groups of 4 or 5 in each group with some of those experienced people in each group.


What is a Use Case?

• 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

• An important part of a UCD is the system boundary

• A Use Case is much more than a UCD (Use Case Diagram)


Why have Use Cases?

• Many organizations have adopted Use Cases.

• Good start: but do they also build executable models of the Use Cases?

– Executable models clearly define the interfaces between the system and its environment in each one of its intended uses.

– Is this done functionally before allocating the functions to specific parts?


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

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


What is a Use Case Description?

• A Use Case is much more than a UCD (Use Case Diagram). • The UC description includes

– what the system does, – why it does it, and – the value the system provides to the (primary) actor.

• The description may include a UCD– shows the context of the UC with its environment (the actors).

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

• A Use Case describes how the system will be used – before the system exists. As such, it describes a test of a planned system.

• It allows management and customers to understand what they will be building

• It is a means to understand what progress is being made during development.

• If an executable model is built of the system and of its environment, this model can evolve into a test harness of the system.


What might be the 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?

• We will revisit this a little later.


How do I describe the Use Case? – Elevator Example

• The Use Case is a functional description of the system from a user’s viewpoint. – How would a Passenger use and elevator? – The Transport Passenger Use Case would follow a

scenario such as the following:• 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

• The listed scenario is sufficient for a simple, well understood, system.

• For a more complex system, we can describe the scenario in a tabular form or use other UML diagrams – Message Sequence Diagram, – Statechart, or – Activity Diagram).

• In addition, we need other attributes of a Use Case– such as preconditions and post conditions.


How would I get Use Cases for a system?

• How is a Use Case elicited?• 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?

• Get back into your groups and compose a list of UCs for an elevator. – What are the actors? – Draw a UCD for the elevator.


What might we have for Use Cases for an elevator?

• Let’s use an elevator as an example and get a list of possible Use Cases assuming 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.– Provide Software Maintenance Services

• – Allow for installation and test of software upgrades.– Provide Hardware Maintenance Services

• – Allow for installation and test of hardware upgrades.


Description of the Elevator Transport Passenger Use Case

• Include the preconditions for the Use Case – – e.g., the elevator must be operating in the Passenger Service

Mode (which is carefully defined).

• 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– not complete – needs some more formality– 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

• – not discussed here.


How would you use a Use Case?

• Now what – after you have the Use Case described in text?

• Another UML diagram that describes behavior is a SD (Sequence Diagram

– or more explicitly, Message Sequence Diagram

• A SD describes interactions (messages) between objects (e.g., system and actors) in time – – along vertical lifelines,

• one lifeline for each object. – This is one of the other diagrams that are usually used to further

describe the scenarios• - the other one is an Activity Diagram. • It is even possible to use both of these diagrams.

• The SD will be described here because it is executable in many tools – an executable Activity Diagram is only recently becoming available.


How would you use a Use Case for Elevator?

• 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

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

– – this is not addressed here.


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

• Each UC will usually have only one primary SD and several secondary SDs

– to support alternative and exceptional behavior of the system • - not described here.

• Each SD may have several depths which are nested into the base diagram

• 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 of the system that supports that UC

– either conceptual or physical components of the system that support that UC,• A top level SD for one UC should not show all levels of the

components. – Any modern UML tool allows the interaction of the components to be exposed by

clicking on the system object in the system SD• and recursively to each lower level of detail).


How would I use a SD? (2 of 2)

• The interaction of the components of the system at the next lower level can be described on that supporting SD. – This nesting is recursive to whatever level of detail is required to

describe the system behavior. • A SD can also show the states of the components

along the lifeline – from a Statechart (one of the other UML behavior diagrams).

• Subsequences can be shown on a SD, much like subroutines in a sequential computer program.– These two features of a SD are not discussed further herein.

• Get into your groups again – Draw a primary SD for the Elevator Transport Passenger UC.

• Are you making design decisions? – If so, list them.


Why did I choose a SD?

• Many UML tools have executable SDs – I was using them in 1994 to reduce integration test times to hours for a

several month project. This was even before UML 1.0 was released. • The desired SD can be put into a UML tool.

– The system model can be entered with objects • (instances of composite classes) and executed to generate a SD. • Any differences between the executed SD and the desired SD are shown,

not only from comparing the SDs, are shown in an exception report. • The stakeholders are thus assured that the desired behavior is captured in

the model before any implementation begins.• A SD is easy to understand, especially by hardware people

– they have always used objects in their designs, calling them blocks.• Systems engineers often do not distinguish explicitly between

classes and objects. – An alternator for a car is a class, whereas an alternator for the car is an

object – It is only a matter of the grammatical article that is different

• a definite or indefinite article, the or a/an, respectively. • A requirements statement that does not recognize this distinction can be

ambiguous.


Executable SDs communicate between stakeholders

• Executable SDs are essential to communicate requirements between stakeholders– Validation is said to be building the right system. – Verification is building it right.

• How do you know you are building the right system? • How will you show it?

– Executable SDs (Sequence Diagrams) can demonstrate the functionality of Use Cases early in a development program to greatly increase the likelihood that the right system is built.

– If you do not know enough to build an executable model, how can you possibly begin to build the real system?

• Save time. Save money. Make your customer happy. – Adopt Use Cases to scope and control your project from concept to

acceptance test. – Use SDs to execute /document the system functional requirements. – Use classical requirement statements to control the non-functional

requirements.


Why didn’t I use SysML?

• I did not use SysML because I did not need it

– all of the structure and behavior elements of UML are sufficient for building executable models of systems as long as the vocabulary of UML is understood.

• E.g., as mentioned above, what is an object and how does it differ from a class.


What if we had Use Cases and Primary Sequence Diagrams?

• Up front Communication: – customer, management, developers, testers– And continuing Visibility of the project

• Define when we are done– before beginning building anything (HW, Sw, and Test)

• Executable models• 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 (Agile)

• Prioritize development of the important functionality– Incremental development – by Use Case/ Functionality– Manage schedule – calibrate and reschedule

• Faster learning of new people on program– visibility and known goal


So you have Use Cases, Now What?

• Retrospective questions


Have you experienced any changes?

• Does this ever happen at work?• How do you feel about Use Cases now that is

different from how you felt before we started?• How do you think about Use Cases that is different

from how you thought about it before we started?• What have you learned in this session?• How did you do the exercise?

– i.e., what techniques did you use?

• What haven't we talked about yet?• How did you come to be here? • How do you feel about being here?


What will you remember from this experience?

• What did you notice about this period of time?

• What is happening for you? • 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?


What reactions or questions do you have?

• What surprised you? • What would you want to repeat from the exercise? • What would you want to omit from this exercise? • What pleased (puzzled, frightened, displeased,

tickled, angered, any other emotion) you about the experience?

• What question do you prefer we wouldn't ask? • Do you know why you didn't want to be asked that? • What question do you want me to ask?

– Do you know why you want to be asked that?

• What are your future plans for this exercise? – If you had that, what would that do for you?


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?


Summary

• Why would you want to elicit and develop functional requirements with 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 with the proper application of Use Cases?– a major cost in most projects


Final thoughts

• Expect change - and plan for it.

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


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

so you have use cases, now what?

Documents