7 DesigningWithUseCases-Ch60

8/2/2019 7 DesigningWithUseCases-Ch60

1/71

Page 1

ENGR2720U

ENGR2720 Software Design II

Slides modified from: Introduction to Software Engineering Design(C. Fox)

Designing With Use Cases


2/71

Page 2

ENGR2720U

Use Cases and Use Case Diagrams


3/71

Page 3

ENGR2720U

Objectives

To explain what use cases are

To present UML use case diagram notation

To suggest processes for creating use case

diagrams

To present rules and heuristics for making usecase diagrams.

To list use case diagram quality checksTo explain when to use use case diagrams


4/71

Page 4

ENGR2720U

Topics

Why use case diagrams work

Use cases, actors, and scenarios

UML use case diagram notations

How to make use case diagrams

Rules of formation

Heuristics

Quality checksWhen to use use case diagrams


5/71

Page 5

ENGR2720U

Why Use Case Modeling Works

User-level requirements are generatedfrom stakeholder needs.

Operational-level requirements are hard to

generate in isolation.Considering the interactions between aprogram and its environment

Organizes operational level requirements

Provides context for refinement

Help avoid inconsistencies, omissions,redundancies, etc.


6/71

Page 6

ENGR2720U

Use Cases and Actors

The collection of use cases characterizes allexternally observable behavior.

A use case is an entire, coherent interaction.

Actors are roles not individuals.

The product is neveran actor.

Ause case is a type of complete interactionbetween and product and its environment.

An actor is a type of agent thatinteracts with a product.


7/71Page 7

ENGR2720U

Use Case Diagrams

Static model

Catalog of all use casesUML diagram

Ause case diagram represents aproducts use cases and the actors

involved in each use case.


8/71Page 8

ENGR2720U

Use Case Diagram Symbols

Actor Name

Use Case Name

Association Line Use Case SymbolActor Symbol


9/71Page 9

ENGR2720U

What constitutes a Good actor

An actor will use the system differently than anotheractor

For example a student might be a different actor than a returningstudent if they use the system differently.

An actor is basically a role that a user will take on in thesystem and not the user themselves.

Create an actor for every role.

This may be an overkill but it is a good rule of thumb.

An example of an overkill is a TA as an actor. If the TA does boththe same thing as a professor and a student then theirinteraction with the system is the same as a professor and/or astudent so that the TA actor is not required.


10/71Page 10

ENGR2720U

How to decide on Use cases

What are the tasks of each actor?

Will any actor create, store, change, remove, or readinformation in the system? What use case will create, store, change, remove, or read this

information?Will any actor need to inform the system about suddenexternal changes?

Does any actor need to be informed about certainoccurrences in the system?

What use case will support and maintain the system?

Can all functional requirements be performed be the usecases?


11/71Page 11

ENGR2720U

What constitutes a good use case?

A use case typically represents a major piece offunctionality that is complete from beginning to end.

A use case must deliver something of value to an actor.

If you are not careful, you may fall into the world offunctional decomposition.

One way to avoid this is to treat your use cases in the followingways:

Determine if the uses cases represent something that shows start to

finish functionality. Avoid small use cases (one piece of functionality).

Avoid many use cases. At most 50.

Avoid use cases whose name implies one of functionality.


12/71Page 12

ENGR2720U

Use Case Diagram Example

Use Case Diagram for an AutomatedCarwash

Customer

Soap Sensor

Buy WashStall Sensors

Wash Car

Produce LogManager

Activate/Deactivate


13/71Page 13

ENGR2720U

Exercises

Consider a software system that sells productsover the Web, Classify the following activities asprobably too big (B), too small (S), or the rightsize (R), to be use cases of this system. Enter credit card number

Set Printing parameters

Buy an item

Manage Web Site

Select mailing address

Modify Shopping cart

Search for an item


14/71Page 14

ENGR2720U

Scenarios

Instance of a use case

Help envision how a product can be used

Abstracted into use cases

Ascenario is an interaction betweena product and particular individuals.


15/71Page 15

ENGR2720U

Scenarios

A collection of user scenarios that describe the thread of usage of asystemEach scenario is described from the point-of-view of an actoraperson or device that interacts with the software in some wayEach scenario answers the following questions:

Who is the primary actor, the secondary actor (s)? What are the actors goals?

What preconditions should exist before the story begins? What main tasks or functions are performed by the actor?

What exceptions might be considered as the story is described?

What variations in the actors interaction are possible?

What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external

environment? What information does the actor desire from the system?

Does the actor wish to be informed about unexpected changes?


16/71Page 16

ENGR2720U

A Scenario Example

Scenario for Buying a Car Wash

Michael drives to the kiosk outside the carwash and attempts

to insert five dollars. The kiosk accepts the money and

displays the message You have paid enough for a complete

wash. Insert another dollar for a deluxe wash. Michaelpresses the button for an express wash. The kiosk refunds

one dollar. The carwash queries its stall sensors. The stall

sensors report that no car is detected, so the kiosk displays

the message Please drive forward into the wash stall.


17/71Page 17

ENGR2720U

Making Use Case Diagrams 1

Write

Scenarios

Check Each Actors

Needs for Use Cases

Draw a Use Case Diagrammission : Project Mission Statement

goals : Stakeholders-Goals List

needs : Needs Listdiagram : Use Case Diagram

Abstract Scenario

Individuals as Actors

Check Development

Documents for Actors

Abstract Scenariosas Use Cases

goals

mission

needs

diagram


18/71Page 18

ENGR2720U

Making Use Case Diagrams 2

An event list a list of all internal and externalevents to which the product must respond.

Invent use cases to handle each event in the

list; add it to the diagram

Consider each use case and determine itsactors; add them to the diagram

See the AguaLush example of an event listbottom of page 163.


19/71

Page 19

ENGR2720U

Use Case Briefs

Supplements the use case diagram

Usually only one or two sentences or

phrasesSee the AguaLush example in Figure 6-1-6 and its associated briefs.

Ause case or actor briefis a shortdescription of a use case or actor.


20/71

Page 20

ENGR2720U

Formation Rules

Every use case diagram must have

At least one use case

At least one actor

At least one actor associated with each use case

At least one use case associated with each actor

No association line between actors

No association line between use cases

Name every actor and use case

Not label any association line


21/71

Page 21

ENGR2720U

Use Case Diagram Heuristics 1

Never make the product an actor.

Name actors with noun phrases.

Name use cases with verb phrases.

Achieve a stakeholders goal in a use case.

Make use cases that can be finished in asingle session.


22/71

Page 22

ENGR2720U

Use Case Diagram Heuristics 2

Make use cases of uniform size andcomplexity.

Draw use case diagrams on one page.

Organize use cases by actor, problemdomain categories, or solution categories.


23/71

Page 23

ENGR2720U

Checking Use Case Diagrams 1

Review the stakeholders-goals list to makesure no actors are missing.

Review the needs list to make sure no uses

cases are missing.Review constraints and limitations to makesure none are violated.


24/71

Page 24

ENGR2720U

Checking Use Case Diagrams 2

Generate an event list and check that allevents are handled.

Check that the collection of use cases

covers all externally visible behavior.Check the diagram against the use caseheuristics above.


25/71

Page 25

ENGR2720U

When to Use Use Case Diagrams

User-level product design alternatives (moreon this later)

Summarizing design alternatives

Catalog use cases elaborated in use casedescriptions (more on this later)

A component of a use case model (more on

this later)

ENGR U


26/71

Page 26

ENGR2720U

Summary

Use cases are types of episodes of interactionbetween a product and its environment.

Working with use cases help organize, analyze,generate, evaluate, and select functionalrequirements.

UML use case diagrams are static models of allthe use cases in a product.

There are several processes for creating use casediagrams.

Rules govern use case diagram formation, andheuristics and checks help achieve and ensuretheir quality.

ENGR2720U


27/71

Page 27

ENGR2720U

Exercise

Name five things wrong with the use casediagram in Figure 6-E-1 in the textbook.

ENGR2720U


28/71

Page 28

ENGR2720U

Use Cases Descriptions and Use Case

Models

ENGR2720U


29/71

Page 29

ENGR2720U

Objectives

To explain what use case descriptions areTo specify the contents of use case descriptions

To present a use case description writingprocess

To present heuristics for use case descriptions

To explain the relationship between use casesand requirements

To explain what use case models are

To explain how to design with use case models

To outline how to use use cases in iterativedevelopment

ENGR2720U


30/71

Page 30

ENGR2720U

Topics

Use case descriptions, their formats, andtheir contents

Writing use case descriptions

Use case description heuristicsUse case descriptions and requirements

Use case models

Designing with use case modelsUse-case-driven iterative development

ENGR2720U


31/71

Page 31

ENGR2720U

Use Case Descriptions

What each party does

The order in which each party actsAll possible courses of interaction:complex activity flows

Ause case description is aspecification of the interaction betweena product and the actors in a use case.

ENGR2720U


32/71

Page 32

ENGR2720U

Use Case Description Contents 1

Use case name and number

Actors

Stakeholders and their needs

PreconditionsA precondition is an assertion that mustbe true when an activity or operation begins.

Not checked by the use case

PostconditionsA postcondition is an assertion of what

must be true when an activity or operation ends. Must satisfy stakeholder needs

ENGR2720U


33/71

Page 33

ENGR2720U

Use Case Description Contents 2

TriggerA trigger is an event that causes a usecase to begin.

May be the first step in the use case

Basic flow

An action flow: a list of steps

Documents a standard, successful interaction

Begins at the trigger, continues until the use case ends

Extensions

Alternative action flows

May begin and end anywhere

Extensions may have extensions

ENGR2720U


34/71

Page 34

ENGR2720U

Car Wash Example Part 1

Use Case 2: Activate/DeactivateActors: Soap sensorStakeholders and needs:

CustomersNeed their cars washed with soap, and

want a complete washOperationsWant the carwash to operate withoutconstant attention

Preconditions: NonePostconditions:

The carwash is active if and only if the soap sensorindicates that there is soap.No wash currently in progress is interrupted.

ENGR2720U


35/71

Page 35

ENGR2720U


Trigger: One minute has passed since the last time thesoap sensor was checked.

Basic Flow:1. The carwash queries the soap sensor.

2. The soap sensor indicates that there is soap.3. If the carwash is active, it continues its operation and

the use case ends.Extensions:1a: The carwash is unable to query the soap sensor:

1a1. The controller logs the problem and the use caseends.

ENGR2720U


36/71

Page 36

ENGR2720U


Extensions (continued):2a: The soap sensor indicates that there is no more soap:

2a1. If the carwash is inactive, the use case ends.2a2. If the carwash is active, the controller displays an out-of-order message and becomes inactive; the use case ends.

2b: The soap sensor does not respond:2b1. The controller logs the problem.2b2. If the carwash is inactive, the use case ends.2b3. If the carwash is active, the controller displays an out-of-order message and becomes inactive; the use case ends.

2a2, 2b3: A wash is in progress:

2a21. The carwash completes the current wash, then displaysan out-of-order message; the use case ends.

3a: The carwash is inactive:3a1. The carwash becomes active and displays a ready message.

ENGR2720U


37/71

Page 37

ENGR2720U

Use Case Description Formats

Many alternatives

Fully-dressed format by Alistair Cockburn

Underlined text refers to another use case.

Extensions use a special numbering scheme: Numbers are for action step sequencing;

Letters are for extension triggers;

Extension identifiers have interleaved numbers and letters;

An asterisk refers to all action steps;

A dash is used for ranges of action steps;

A comma separates action steps in a list.

ENGR2720U


38/71

Page 38

ENGR2720U

Use Case Description Template

Use Casenumber:nameActors:actorListStakeholders and Needs:

stakeholderneedsList.stakeholderneedsList.

Preconditions: what is assumed at the start.Postconditions: what is guaranteed at the end.Trigger: the event that starts the use case.Basic Flow:

#stepDescription

Extensions:extensionIdentifier condition:

extensionIdentifier # stepDescription

ENGR2720U


39/71

Page 39

ENGR2720U

Requisite Pro Use Case Template

1. Use Case Name

2. Flow of Events

1. Basic Flow

2. Alternate Flows3. Special Requirements

4. Preconditions

5. Post Conditions6. Extension Points

ENGR2720U


40/71

Page 40

ENGR2720U

Description Writing Process

Fill in the

Initial Fields

Write Extensions

Write a Use Case Descriptiondiagram : Use Case Diagramgoals : Stakeholders-Goals Listneeds : Needs Listscenarios : Collection of Scenariosdescription : Use Case Description

Write Basic

Flow

Brainstorm Branch

Points and Conditions

Rationalize BranchPoints and Conditions

goals

diagram

needs

description

scenarios

ENGR2720U


41/71

Page 41

ENGR2720U

Filling in the Initial Fields

Stakeholders are human use case actors oranyone with an interest to protect.

Only state things that really matter as use

case preconditions.Postconditions must be true when the usecase ends whether it is successful or not.

The trigger is often the first step in the usecase (but not always).

ENGR2720U


42/71

Page 42

ENGR2720U

Writing the Basic Flow 1

Choose a common, simple activity flow.

Trace it from the trigger through use casecompletion.

Scenarios are often good resources.

ENGR2720U


43/71

Page 43

ENGR2720U

Writing the Basic Flow 2

Steps may assume the preconditions andshould achieve the postconditions.

Each step should state an action of a

single agent (the product or an actor).Supplemental directions aboutconditions, iteration, or currency areallowed.

See Figure 6-2-3 in the text book as anexample of a Flow for the fingerprintreader.

ENGR2720U


44/71

Page 44

ENGR2720U

Extensions and Brainstorming Branch Points

A branch point is a place where the action flowmay diverge.

Brainstorm a list of branch points and failure

conditions. Look at scenarios for failed or alternative interactions.

Consider errors, faults, and alternatives at every step.

Dont forget an actors failure to act.

ENGR2720U


45/71

Page 45

ENGR2720U

Rationalizing Branch Points

Remove from further considerations anyconditions that the product

Cannot detect

Cannot do anything about

Rewrite poorly stated conditions

ENGR2720U


46/71

Page 46

ENGR2720U

Writing Extensions

Treat an extension as if it were a separate use case:

The condition is the trigger;

Extension steps are the basic flow;

Completing the use case or returning to the branch point are

the goals.Scenarios are a good resource.

Repeat the extension writing process for the extension(extensions may have extensions).

See Figure 6-2-4 and 6-2-5 in the text book as anexample of candidate branch points and conditions forthe fingerprint reader.

ENGR2720U


47/71

Page 47

ENGR2720U

Final Use Case Example

Figure 6-2-6 shows the final Enter SecureFacility use case example for the Fingerprint

Reader.

Review and comment.

ENGR2720U


48/71

Page 48

ENGR2720U

Use Case Description Heuristics 1

Fill in the use case template from top to bottom.

Obtain use case and actor names from the usecase diagram.

Make human actors stakeholders whose needsinclude completion of the task done by the usecase.

Write simple declarative sentences in the activevoice.

ENGR2720U


49/71

Page 49

ENGR2720U

Use Case Description Heuristics 2

Make actors or the the product the subject ofeach step description.

Write a basic flow with three to nine steps.

Avoid sequences of steps by actors or theproduct.

Dont specify physical details.

Impose minimal order on activities.Proofread the description.

ENGR2720U


50/71

Page 50

ENGR2720U

Use Case Models

The diagram is a static model catalogingproduct interactions.

The descriptions are dynamic modelsdetailing the interactions.

Ause case model is a use case diagramtogether with use case descriptions for

each use case in the diagram.

ENGR2720U


51/71

Page 51

ENGR2720U

Exercise

Write a use case for the Fingerprint AccessSystem described in the text book on page 186.

ENGR2720U


52/71

Page 52

G 0U

Designing with Use Cases

ENGR2720U


53/71

Page 53

Designing with Use Case Diagrams

Models a design alternative for the interactionsthat a product will support

Generate several design alternatives

Alternative can be evaluated in terms of Unmet needs

Extraneous features or capabilities

Development costs

Time and risk Conformance to constraints

Feasibility, simplicity, beauty

ENGR2720U


54/71

Page 54

AquaLush Example

Consider the two alternative Use Case diagramsA and B Figures 6-3-1 and 6-3-2.

Figures 6-3-1 is a full-featured product design

Figures 6-3-2 is a minimal product design

Comment on how these use case diagramsmeet the stakeholder needs.

ENGR2720U


55/71

Page 55

Designing with Use Case Descriptions

Use case descriptions refine the user-levelspecification in a use case diagram intooperational-level specifications.

Design alternatives are specified in differentdescriptions.

Alternatives can be evaluated as alreadydescribed.

The same 2 detailed examples are presented inthe use case diagrams is presented as usecases in Figures 6-3-3 and 6-3-4.

ENGR2720U


56/71

Page 56

Requirements and Use Case Models

Use case models do not provide atomizedrequirements statements. They are not traceable;

Some product functions may not appear;

Data and non-functional requirements are not explicit.

The exercise of extracting requirements statementsprovides yet another check of the design.

It is better to spend extra time and effort during

product design to make engineering design easier.Use case models sometime serve as surrogatesfor requirements.

ENGR2720U


57/71

Page 57

Extracting Requirements

Extracting requirements from use case models

Helps designers understand their designs better;

Helps find errors and improve designs;

Produces a useful artifact for engineering design.

Additional requirements are also needed.

Data and non-functional requirements

Physical-level requirements

ENGR2720U


58/71

Page 58

Use-Case-Driven Iterative Development

In an iterative development project

Choose several use cases for implementation in aniteration;

Furnish product design details;

Do engineering design, code, test, and (perhaps)deploy;

Evaluate the result for the next iteration;

Repeat these steps.

ENGR2720U


59/71

Page 59

Process Guidelines

Start with a complete use case diagram.

Choose use cases for each iteration accordingthe the following criteria:

Important to stakeholders

Requires a core system function

Requires the essentials of the system architecture

The implementation is technically challenging

ENGR2720U


60/71

Page 60

Detailing Use Cases

By operational example Use scenarios captured via sequence diagrams

Each scenario capture a specific path through the use case

Partially constructive

Infinite set, so you must select which are interestinglydifferent

Non-technical users can understand scenarios

By specification Use an informal (e.g. English) and/or formal (e.g.

statechart) to represent all possible paths

Fully constructive

Non-technical readers might not understand formal specs

Real-Time UML 60

ENGR2720U


61/71

Page 61

Use Case Description

Use Case Description Structure Name

Purpose May be written informally (The purpose of the capability is to)

Description May be written semi-formally (The system shall)

May be a hyperlink to a textual document

Preconditions What is true prior to the execution of the capability?

Postconditions

What does the system guarantee to be true after the execution of theuse case?

Constraints Additional QoS requirements or other rules for the use case

Real-Time UML 61

ENGR2720U


62/71

Page 62

Description Example

Real-Time UML

6

ENGR2720U


63/71

Page 63Real-Time UML 63

Information Flow Requirements

As part of analysis, it is common to want tounderstand information flow and processingrequired.

Information Flow diagrams (UML 2) show info flowsbetween elements, but no sequence is shown

Similar to de Marco-style DFDs

Can be done for entire system or per use case

Activity diagrams show sequence of informationprocessing within a system

Usually done per use case

ENGR2720U


64/71


Information Flow Requirements

ENGR2720U


65/71

Page 65

Relating to Textual Requirements

Use cases and related notations are analternative to text-based requirements

Restating text-based requirements

When the text requirements are vague

When they need to be validated with the customer

When the risk or cost of incorrect, inaccurate, orinconsistent requirements is high

When there is a high need to perform validation testsagainst the requirements

When the requirements are complex

Real-Time UML 65

ENGR2720U


66/71

Page 66

Traceability To Textual Requirements

Real-Time UML 66

ENGR2720U


67/71

Page 67

Detailing Use Cases: Scenarios

A typical system has one dozen to a few dozen usecase

Each use case typically has a few to several dozenscenarios of interest

Scenarios capture a specific actor-systeminteraction protocols of interaction

permitted sequences of

message flow collaboration of structural elements

show typical or exceptional paths through the use case

Real-Time UML 67

ENGR2720U


68/71

Page 68

Sequence Diagrams in UML

Real-Time UML 68

Constraint

Note

Lifeline

MessageInteractionfragmentInteraction

operator

ENGR2720U


69/71


Detailing Use Cases with Statecharts

ENGR2720U


70/71


Detailing Use Cases: Statecharts

ENGR2720U


71/71

Summary

A use cases description is structured text thatspecifies the details of a use case.

Templates, processes, and heuristics guide usecase description writers.

Use case descriptions, though not requirements,can be a source for them.

Use case diagrams and descriptions togetherform use case models.

These models are a powerful product design tool.Use cases can drive iterative development.

7 DesigningWithUseCases-Ch60

Documents

Transcript of 7 DesigningWithUseCases-Ch60