ENGR2720U

ENGR2720 Software Design II

Designing With Use Cases

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

Page 1

ENGR2720U

Use Cases and Use Case Diagrams

Page 2

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 use case diagrams. To list use case diagram quality checks To explain when to use use case diagrams

Page 3

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 checks When to use use case diagrams

Page 4

ENGR2720U

Why Use Case Modeling Works User-level requirements are generated from stakeholder needs. Operational-level requirements are hard to generate in isolation. Considering the interactions between a program and its environment Organizes operational level requirements Provides context for refinement Help avoid inconsistencies, omissions,
redundancies, etc.
Page 5

ENGR2720U

Use Cases and Actors

A use case is a type of complete interaction between and product and its environment.
An actor is a type of agent that interacts with a product. The collection of use cases characterizes all externally observable behavior. A use case is an entire, coherent interaction. Actors are roles not individuals. The product is never an actor.
Page 6

ENGR2720U

Use Case Diagrams

A use case diagram represents a products use cases and the actors involved in each use case.

Static model Catalog of all use cases UML diagram

Page 7

ENGR2720U Use Case Diagram Symbols

Use Case Name Actor Name Actor Symbol Association Line Use Case Symbol

Page 8

ENGR2720U

What constitutes a Good actor

An actor will use the system differently than another actor For example a student might be a different actor than a returning
student if they use the system differently.

An actor is basically a role that a user will take on in the system 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 both
the same thing as a professor and a student then their interaction with the system is the same as a professor and/or a student so that the TA actor is not required.

Page 9

ENGR2720U

How to decide on Use cases

What are the tasks of each actor? Will any actor create, store, change, remove, or read information in the system? What use case will create, store, change, remove, or read this
information?

Will any actor need to inform the system about sudden external changes? Does any actor need to be informed about certain occurrences in the system? What use case will support and maintain the system? Can all functional requirements be performed be the use cases?
Page 10

ENGR2720U

What constitutes a good use case?

A use case typically represents a major piece of functionality 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 of functional decomposition. One way to avoid this is to treat your use cases in the following
ways:

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.

Page 11

ENGR2720U Use Case Diagram Example

Buy Wash Customer Stall Sensors

Soap Sensor

Activate/ Deactivate

Wash Car

Produce Log

Manager

Use Case Diagram for an Automated Carwash

Page 12

ENGR2720U

Exercises

Consider a software system that sells products over the Web, Classify the following activities as probably too big (B), too small (S), or the right size (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
Page 13

ENGR2720U

Scenarios

A scenario is an interaction between a product and particular individuals.

Instance of a use case Help envision how a product can be used Abstracted into use cases

Page 14

ENGR2720U

Scenarios
A collection of user scenarios that describe the thread of usage of a system Each scenario is described from the point-of-view of an actora person or device that interacts with the software in some way Each 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?

Page 15

ENGR2720U

A Scenario Example

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. Michael presses 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.

Scenario for Buying a Car Wash

Page 16

ENGR2720U

Making Use Case Diagrams 1

Draw a Use Case Diagram
mission : Project Mission Statement goals : Stakeholders-Goals List needs : Needs List diagram : Use Case Diagram

Write Scenarios Abstract Scenario Individuals as Actors Check Development Documents for Actors Abstract Scenarios as Use Cases Check Each Actors Needs for Use Cases

mission goals needs

diagram

Page 17

ENGR2720U

Making Use Case Diagrams 2 An event list a list of all internal and external events 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 its actors; add them to the diagram See the AguaLush example of an event list bottom of page 163.

Page 18

ENGR2720U

Use Case Briefs

A use case or actor brief is a short description of a use case or actor.

Supplements the use case diagram Usually only one or two sentences or phrases See the AguaLush example in Figure 6-16 and its associated briefs.
Page 19

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

Page 20

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 a single session.

Page 21

ENGR2720U

Use Case Diagram Heuristics 2

Make use cases of uniform size and complexity. Draw use case diagrams on one page. Organize use cases by actor, problem domain categories, or solution categories.

Page 22

ENGR2720U

Checking Use Case Diagrams 1

Review the stakeholders-goals list to make sure no actors are missing. Review the needs list to make sure no uses cases are missing. Review constraints and limitations to make sure none are violated.

Page 23

ENGR2720U

Checking Use Case Diagrams 2

Generate an event list and check that all events are handled. Check that the collection of use cases covers all externally visible behavior. Check the diagram against the use case heuristics above.

Page 24

ENGR2720U When to Use Use Case Diagrams

User-level product design alternatives (more on this later) Summarizing design alternatives Catalog use cases elaborated in use case descriptions (more on this later) A component of a use case model (more on this later)

Page 25

ENGR2720U

Summary
Use cases are types of episodes of interaction between a product and its environment. Working with use cases help organize, analyze, generate, evaluate, and select functional requirements. UML use case diagrams are static models of all the use cases in a product. There are several processes for creating use case diagrams. Rules govern use case diagram formation, and heuristics and checks help achieve and ensure their quality.

Page 26

ENGR2720U

Exercise

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

Page 27

ENGR2720U

Use Cases Descriptions and Use Case Models

Page 28

ENGR2720U

Objectives
To explain what use case descriptions are To specify the contents of use case descriptions To present a use case description writing process To present heuristics for use case descriptions To explain the relationship between use cases and 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 iterative development
Page 29

ENGR2720U

Topics Use case descriptions, their formats, and their contents Writing use case descriptions Use case description heuristics Use case descriptions and requirements Use case models Designing with use case models Use-case-driven iterative development

Page 30

ENGR2720U

Use Case Descriptions

A use case description is a specification of the interaction between a product and the actors in a use case.

What each party does The order in which each party acts All possible courses of interaction: complex activity flows
Page 31

ENGR2720U Use Case Description Contents 1

Use case name and number

Actors Stakeholders and their needs

PreconditionsA precondition is an assertion that must be 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

Page 32

ENGR2720U Use Case Description Contents 2 TriggerA trigger is an event that causes a use case 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
Page 33

ENGR2720U

Car Wash Example Part 1

Use Case 2: Activate/Deactivate Actors: Soap sensor Stakeholders and needs: CustomersNeed their cars washed with soap, and want a complete wash OperationsWant the carwash to operate without constant attention Preconditions: None Postconditions: The carwash is active if and only if the soap sensor indicates that there is soap. No wash currently in progress is interrupted.

Page 34

ENGR2720U

Car Wash Example Part 2

Trigger: One minute has passed since the last time the soap 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 case ends.

Page 35

ENGR2720U

Car Wash Example Part 3

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-oforder 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-oforder message and becomes inactive; the use case ends. 2a2, 2b3: A wash is in progress: 2a21. The carwash completes the current wash, then displays an out-of-order message; the use case ends. 3a: The carwash is inactive: 3a1. The carwash becomes active and displays a ready message.

Page 36

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.

Page 37

ENGR2720U

Use Case Description Template

Use Case number: name Actors: actorList Stakeholders 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: extensionIdentier condition: extensionIdentier # stepDescription
Page 38

ENGR2720U

Requisite Pro Use Case Template

1. Use Case Name 2. Flow of Events 1. Basic Flow 2. Alternate Flows 3. Special Requirements 4. Preconditions 5. Post Conditions 6. Extension Points

Page 39

ENGR2720U

Description Writing Process

Write a Use Case Description
diagram : Use Case Diagram goals : Stakeholders-Goals List needs : Needs List scenarios : Collection of Scenarios description : Use Case Description diagram goals needs

Fill in the Initial Fields Write Basic Flow Brainstorm Branch Points and Conditions Rationalize Branch Points and Conditions

scenarios

Write Extensions

description

Page 40

ENGR2720U

Filling in the Initial Fields

Stakeholders are human use case actors or anyone with an interest to protect. Only state things that really matter as use case preconditions. Postconditions must be true when the use case ends whether it is successful or not. The trigger is often the first step in the use case (but not always).

Page 41

ENGR2720U

Writing the Basic Flow 1

Choose a common, simple activity flow. Trace it from the trigger through use case completion. Scenarios are often good resources.

Page 42

ENGR2720U

Writing the Basic Flow 2

Steps may assume the preconditions and should achieve the postconditions. Each step should state an action of a single agent (the product or an actor). Supplemental directions about conditions, iteration, or currency are allowed. See Figure 6-2-3 in the text book as an example of a Flow for the fingerprint reader.
Page 43

ENGR2720U

Extensions and Brainstorming Branch Points

A branch point is a place where the action flow may 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.

Page 44

ENGR2720U

Rationalizing Branch Points

Remove from further considerations any conditions that the product Cannot detect Cannot do anything about Rewrite poorly stated conditions

Page 45

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 an example of candidate branch points and conditions for the fingerprint reader.

Page 46

ENGR2720U

Final Use Case Example

Figure 6-2-6 shows the final Enter Secure Facility use case example for the Fingerprint Reader. Review and comment.

Page 47

ENGR2720U Use Case Description Heuristics 1

Fill in the use case template from top to bottom. Obtain use case and actor names from the use case diagram. Make human actors stakeholders whose needs include completion of the task done by the use case. Write simple declarative sentences in the active voice.

Page 48

ENGR2720U Use Case Description Heuristics 2

Make actors or the the product the subject of each step description. Write a basic flow with three to nine steps. Avoid sequences of steps by actors or the product. Dont specify physical details. Impose minimal order on activities. Proofread the description.

Page 49

ENGR2720U

Use Case Models

A use case model is a use case diagram together with use case descriptions for each use case in the diagram.

The diagram is a static model cataloging product interactions. The descriptions are dynamic models detailing the interactions.

Page 50

ENGR2720U

Exercise

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

Page 51

ENGR2720U

Designing with Use Cases

Page 52

ENGR2720U

Designing with Use Case Diagrams

Models a design alternative for the interactions that 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
Page 53

ENGR2720U

AquaLush Example

Consider the two alternative Use Case diagrams A 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 diagrams meet the stakeholder needs.

Page 54

ENGR2720U

Designing with Use Case Descriptions

Use case descriptions refine the user-level specification in a use case diagram into operational-level specifications. Design alternatives are specified in different descriptions. Alternatives can be evaluated as already described. The same 2 detailed examples are presented in the use case diagrams is presented as use cases in Figures 6-3-3 and 6-3-4.
Page 55

ENGR2720U

Requirements and Use Case Models

Use case models do not provide atomized requirements statements. They are not traceable; Some product functions may not appear; Data and non-functional requirements are not explicit. The exercise of extracting requirements statements

provides 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 surrogates for requirements.

Page 56

ENGR2720U

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

Page 57

ENGR2720U

Use-Case-Driven Iterative Development

In an iterative development project Choose several use cases for implementation in an

iteration; Furnish product design details; Do engineering design, code, test, and (perhaps) deploy; Evaluate the result for the next iteration; Repeat these steps.

Page 58

ENGR2720U

Process Guidelines

Start with a complete use case diagram. Choose use cases for each iteration according the the following criteria: Important to stakeholders Requires a core system function Requires the essentials of the system architecture The implementation is technically challenging

Page 59

ENGR2720U

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 interestingly different Non-technical users can understand scenarios

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

Real-Time UML

statechart) to represent all possible paths Fully constructive Non-technical readers might not understand formal specs

60
Page 60

ENGR2720U

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 the
use case?

Constraints

Additional QoS requirements or other rules for the use case

Real-Time UML

61
Page 61

ENGR2720U

Description Example

Real-Time UML

6
Page 62

ENGR2720U

Information Flow Requirements

As part of analysis, it is common to want to understand information flow and processing required. Information Flow diagrams (UML 2) show info flows
between 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 information processing within a system Usually done per use case

Real-Time UML

63
Page 63

ENGR2720U

Information Flow Requirements

Real-Time UML

64
Page 64

ENGR2720U

Relating to Textual Requirements

Use cases and related notations are an alternative 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, or
inconsistent requirements is high When there is a high need to perform validation tests against the requirements When the requirements are complex
Real-Time UML

65
Page 65

ENGR2720U

Traceability To Textual Requirements

Real-Time UML

66
Page 66

ENGR2720U

Detailing Use Cases: Scenarios

A typical system has one dozen to a few dozen use case Each use case typically has a few to several dozen scenarios of interest Scenarios capture a specific actor-system interaction 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
Page 67

ENGR2720U
Lifeline

Sequence Diagrams in UML

Message Interaction operator Interaction fragment

Note

Constraint

Real-Time UML

68
Page 68

ENGR2720U

Detailing Use Cases with Statecharts

Real-Time UML

69
Page 69

ENGR2720U

Detailing Use Cases: Statecharts

Real-Time UML

70
Page 70

ENGR2720U

Summary
A use cases description is structured text that specifies the details of a use case. Templates, processes, and heuristics guide use case description writers. Use case descriptions, though not requirements, can be a source for them. Use case diagrams and descriptions together form use case models. These models are a powerful product design tool. Use cases can drive iterative development.

Page 71