sa04 ch6b usecase diagrams

© 2010 Bennett, McRobb and Farmer 1

Use Case DiagramsUse Case Diagrams

Based on Chapter 6: Section 6.6-6.8Bennett, McRobb and Farmer

Object Oriented Systems Analysis and Design Using UML

4th Edition, McGraw Hill, 2010

2

Last Lecture• What is a model?

– A simplified representation that helps us understand something more complicated, e.g., a tube map

• Different types of models used to provide different views of same system, e.g., a person is modelled by a photo, an x-ray, a model of preferences

• Models range in level of detail: As IS development proceeds, models become more detailed

• Diagrams are standardized visual representations used to communicate models.

• Many diagrams can serve to convey a single model, e.g. a model of a solar system may be conveyed with many diagrams.

3

Size of Real IT Systems

Why model Information Systems?

• Student programs typically less than 500 lines (first year)

• up to 5000 lines of Java in following years.

• Commercial systems may be written by large teams of programmers and may contain 100,000- millions, of lines of code.

4

Many types of models in UML• Activity diagrams• Use Case Diagrams• Class Diagrams• Collaboration Diagrams• …There are ~14 types of diagrams in UML

All types of diagrams vary in detail as project processes, e.g., Use Case Diagram ranges from simple to more complex.

UML is for Object-oriented systems development (vs. structured systems approach)

5

Two general types of UML diagramsDiagrams that support :

• Structural (static) view: represent things that must be present in the system, e.g., static structure such as objects, attributes, operations and relationships.

• Behavioural (dynamic) view: represents dynamic behaviour of the system, e.g., showing collaborations among objects and changes to the internal states of objects.

6

The different types of UML diagrams

7

In this module we will cover:

8

In this module we will cover:

A model usually consists of many diagrams of different types

9

A model consists of many diagrams of different types

Analysis Model

Use CasesInterface

Prototypes

RequirementsList

Class diagram (initial draft)

Glossary

Use Case Model

Assign staff to work on

a campaign

Campaign Manager

Add a new advert to

a campaign

Check campaign budget

Find campaign

Accountant

summary Print campaign

invoice

«include»

«extend» «extend»

Print campaign

«include»

«include»

Campaign Management

Use Case DiagramsOne View of the Use Case Model

Assign staff to work on

a campaign

Campaign Manager

Add a new advert to

a campaign

Check campaign budget

Find campaign

Accountant

summary Print campaign

invoice

«include»


Print campaign

«include»

«include»

Campaign Management

11

In this lecture you will learn

• Using scenarios to capture functional requirements

• Use case diagram• The notation of use case diagrams• How to draw use case diagrams• How to write use case descriptions

• Requirements lists• How prototyping can be used with use case

modelling

12

Drawing Use Case Diagrams

• Purpose– document the functionality of the system from

the users’ perspective– document the scope of the system– document the interaction between the users

and the system using supporting use case descriptions (behaviour specifications)

13

Notation of Use Case Diagrams

Staff Contact

Change a client

contact

System or subsystem boundary(Subject)

Actor

Use case Communication association


Requirements as Scenarios

15

What is a Scenario?• Possible interaction between a system and

its users• Specific scenario

– specific data values at each step in the interaction

– test case

• Generalised scenario– cover many specific scenarios

• Word ‘scenario’ most often means specific scenario

16

Specific Scenario• Mrs H wants to register a new student for

Computer Science• Mrs H enters the student details

– A. Patel lives at 29 Devon Lane, Surbiton

• Mrs H enters the registration details– home student, G500, first year, – adviser Prof Robinson

• The system – allocates A. Patel student id 123456789– records A. Patel’s registration details– prints A. Patel’s course registration form, with the

first year G500 recommended programme

17

Generalised Scenario• Administrator wants to enter a student

registration• Administrator enters the student details

– name, address

• Administrator enters the course details– fees level, UCAS code, year of study, adviser

• The system – generates a student id number– records details of the student– prints the course registration form, with the

recommended programme, if any

18

Essential v. Real ScenariosUse cases range in level of detail specified, can

range from ‘essential’ to ‘real’

• Essential scenario (minimal detail) – abstract, ignore user interface, ignores precise

number of steps, free of technology and design assumptions and user interface details

– Only contains essential information

• Real scenario (maximum detail).– how is the interaction achieved?– details of the user interface– specifies concrete steps that assume technology

and design commitments

19

Essential v. Real Scenarios

• Administrator enters the course details– UCAS code

• Administrator chooses the UCAS course code form a drop-down box, with an ‘others’ option which allows the course code and the description

Real

Essential

20

Use Cases• Generalised and essential scenarios

• Number of use cases– up to 80 for complex systems– 20 to 50 for most systems

• Diagram– very simple and abstract– standardised in UML

• Description– ‘structured text’, not standardised

21

Use Case Diagram

CampaignManager

Accountant

Assign staff contact

Add new staffmember

actor

communicationassociation

use case

22


• An actor is– user of the system– initiates the interaction– Drawn with a stick figure

• Not all actors are people– can be a connected system

(e.g. Facebook)

Campaign Manager

Invoicing system


Case Study: Agate

(from Object-Oriented Systems Analysis and

Design; Bennett, McRobb and Farmer)

24

Agate Organisation

A d m in is tration

C redit Co n tro ller

A ccou nts Cle rks

P u rch as in g Ass istant

A cco u ntant

A ccou n ts

G raph ics D es ign ers

C o py W rite rs

E d ito rs

P h otog rap hers

R eso u rce L ib rar ian

A ccou n t M anag ers x 4

C reative C o m p uting

B o ard of D irecto rs

A g ate L td

25

Existing and Proposed Systems

• Existing system:– client management

• record names• assign client contact• campaign

– staff management• names, grades, bonuses

• Redevelop existing system in Java, more functions

26

Organisation’s roles may inform choice of actors

A d m in is tration

C redit Co n tro ller

A ccou nts Cle rks

P u rch as in g Ass istant

A cco u ntant

A ccou n ts

G raph ics D es ign ers

C o py W rite rs

E d ito rs

P h otog rap hers

R eso u rce L ib rar ian

A ccou n t M anag ers x 4

C reative C o m p uting

B o ard of D irecto rs

A g ate L td

The roles in organization give you an idea for possible actors in your use case scenario. Whom you choose to be an actor may be a specific job title, ‘Accountant’, or can be general ‘Creative staff’.

27

Notation of Use Case Diagrams• Use cases

– drawn as ellipses with a name in or below each ellipse

– describe a sequence of actions that the system performs to achieve an observable result of value to an actor

– the name is usually an active verb and a noun phrase

Add a new client

Assign staff to work on campaign

Add a new campaign

28


• Communication associations

– line drawn between an actor and a use case– represent communication link between an instance of

the use case and an instance of the actor

Campaign Manager

Add a new client


Add a new campaign

29

Notation of Use Case Diagrams• Subsystems (also called subjects)

– drawn as a rectangle around a group of use cases that belong to the same subject

– in a CASE tool, use cases for different subjects are usually placed in separate use case diagrams

Campaign Manager

Add a new client


Add a new campaign


Examples

31

Campaign Manager

Add a new client


Record completion of a campaign

Change a client contact

Record completion of an advert

Assign a staff contact

Add a new advert to a campaign

Add a new campaign

Staff Contact

Use case diagrams for Agate

32

Additional descriptions/notations

• Each use case (ellipse) and actor (stick figure) is usually accompanied by a textual actor and use case description. This can be brief description, or can be a step-by-step breakdown of the interaction between the actor and system

• These descriptions are added using the program you are using to draw UML diagrams

33

Campaign Manager

Detailed description…………………

Use Case Diagrams will often be accompanied by more detailed descriptions of actor and use case

CampaignManager

Add new advert to campaign


Detailed description…………………

So for above Use Case, additional screens in CASE tool will show the following descriptions:

34

Campaign Manager

A Campaign manager is either a Director or an Account Manager. They are responsible for estimating the campaign cost and agreeing it with the client. They are responsible for assigning staff to the team and supervising their work, managing the progress of the campaign, conducting any further budget negotiations, and authorizing the final invoice.

Actor DescriptionCampaignManager


35

Add a new advert to a campaign

A campaign can consist of many adverts. Details of each advert are entered into the system, including advert cost

Record completion of a campaign

When a campaign is completed, the actual completion date and cost are entered. A record of completion form is printed out for the Accountant as the basis for invoicing the client

Clients have a member of staff assigned to them as their particular contact person.

Assign a staff contact

Change a client contact

Records when the client’ s contact person with Agate is changed.

Agate Use Cases and Descriptions

36

When Agate gets the business for a new campaign, details of the campaign are entered, including the intended finish date and the estimated cost. The manager for that campaign is the person who enters it.

When a new campaign starts, members of staff are assigned to work on it.

Add a new campaign

Assign staff to work on a campaign

When Agate obtains a new client, the full details of the client are entered. Typically this will be because of a new campaign, and therefore the new campaign will be added straight away.

Add a new client

When an advert is completed, the actual date is entered.

Record completion of an advert

Agate Use Cases

37

Accountant

Record client payment

Change the rate for a staff grade

Add a new member of staff

Add a new staff grade

Change the grade for a member of staff

38

Add a new member of staffWhen a new member of staff joins Agate, his or her details are recorded. He or she is assigned a staff number, and the start date is entered. Start date defaults to today’ s date. The starting grade is entered.

Accountant Use Case descriptions

39

Add a new staff grade

Change the rate for a staff grade

Change the grade for member of staff

Record client payment


40

Add a new staff gradeOccasionally a new grade for a member of staff must be added. The name of the grade is entered. At the same time, the rate for that grade and the rate start date are entered; the date defaults to today’ s date.

Change the rate for a staff gradeAnnually the rates for grades are changed. The new rate for each grade is entered, and the rate start date set (no default). The old grade is retrieved and the rate finish date for that grade rate set to the day before the start of the new rate.


41

Record client payment. When a client pays for a campaign, the payment amount is checked against the actual cost and the date paid is entered.

Change the grade for a member of staff When a member of staff is promoted, the new grade and the date on which they start on that grade are entered. The old staff grade is retrieved and the finish date set to the day before the start of the new one.

Accountant Use Cases

42

Good Use Cases• Identifying use cases

– do not distinguish too many, especially at first

• Title– verb and noun combination

• Language– ‘user’ language, not computer-speak

– avoid ‘click’, ‘input’, ‘menu box’


Detailed Description of a Use Case

• add more detail• … structured description• … following a template

44

Normal Flow• Normal flow (or path)

– steps of the interaction

– distinguish between the user’s request and the system’s response

actor system

request

response

45

Use case description: Add a New Advert to a Campaign

System Response

2. Displays campaign budget, total cost of adverts paid for and total estimated cost of adverts not paid for.

4. Creates new advert and adds to list of adverts for that campaign.

Actor Action

1. Campaign manager checks campaign budget.

3. Campaign manager enters details of advert including estimated cost.

Alternative Courses

Step 4. The advert will exceed the budget and a budget extension request is generated.

Another version of Use Case description

CampaignManager


46

Use case description: Add a New Advert to a Campaign

In comparison: A more general Use Case description. Use cases get more detailed as analysis progresses

CampaignManager


A campaign can consist of many adverts. Details of each advert are entered into the system, including advert cost

47

Additional descriptions for use cases: Alternative Flow

• Variation to some steps of the normal flow

• Alternative flow allows several related scenarios to be combined

• Admin. enters the student details

• Admin updates the student details

Single use case: admin enters/updates student details

48

Additional descriptions for use cases: Exceptions

• Errors, and what happens when they occurs

• Exceptions v. Alternatives– exception is abnormal – alternative is just different to the normal interaction– an alternative path could be a separate Use Case

• Caution– some versions of Use Cases don’t have

exceptions– don’t have too many exceptions

49

Additional descriptions for use cases: Pre- and Postconditions

• Precondition– must be true, – … otherwise the interaction is not possible

• Postcondition– how the system is changed by the

interaction– applies to all alternatives– e.g. ‘customer order is recorded’

50

Suggested Detailed Use Case Description Template

• Use case name• Description• Precondition: required starting state of system

(optional)• Normal flow of events (actions and system

responses)• Alternative flows (optional)• Postcondition: ending state of system (optional)• Exceptions (optional)

51

Suggested Detailed Use Case Description Template

• Use case name• Description• Precondition: required starting state of system

(optional)• Normal flow of events (actions and system

responses)• Alternative flows (optional)• Postcondition: ending state of system (optional)• Exceptions (optional)

Difference between exceptions and alternative flows is subtle, you will not be required to distinguish these in exams

53

Good Use Cases• Distinguish

– user actions– system response

• Use user language– avoid ‘click’, ‘input’, ‘menu box’, ‘database’

For analysis:– abstract as possible– avoid user interface details


Additional Use Case notations:

include and extend

55


• Dependencies– Extend and Include relationships between use

cases– shown as stereotyped dependencies– stereotypes are written as text strings in

guillemets: «extend» and «include»

56

«include»

• Common steps can be included in other use cases

• Common steps documented as a normal use case

• Referenced by name in ‘using’ use case

A

Common Sequence

«include»

«include»

B

57

CampaignManager

Assign staff to Work on a Campaign

Add a New Advertto a Campaign

Find Campaign

«includes»

«includes»

«include»

58

Detailing «include»

• Possible template for included use case

Use case: Update widget details

Description: Update the details about the widgetNormal flow: 1. Widget details are displayed with ‘Find Widget Details’ 2. User enters new widget price 3. …..

Use case: Find Widget Details

Description: Display the basic details about the widgetNormal flow: 1. User requests list of widgets 2. System displays the available widgets 3. User chooses the widget identifier 4. System displays widget details

• Informal approach – not too much ‘apparatus’

59

«extend»

• One use can extend the functionality of another

• Extension may be available to another actor

Basic Use Case

Extension BExtension A

Extension Point


60

Detailing «extend»

• Possible template for extended use case

Use case: Display details

Description: Display the basic details

Normal flow: 1. User enters widget name 2. System displays the details

Extension points: When the system displays details (step 2): Print details Confidential display

Use case: Confidential display

Description: Display the basic details

Normal flow: Extends ‘Display details’ 1. User enters authorisation code 2. System displays confidential data

• Informal approach – not too much ‘apparatus’

61

«extends»

CampaignManager

Accountant

Check Campaign Budget

Print CampaignInvoice

Print CampaignSummary

System Displays Balance

«extends» «extends»

62

Actor Generalisation• Some actors

represent roles which generalise another role

• Use cases available to the ‘Staff Member’ are also available to the ‘Campaign Manager’

Staff Member

Staff ContactCampaign Manager


Developing Use Cases

64

Use Case Iterations• Use cases can be developed in stages• Step 1: Scope

– identify actors and use cases, short descriptions – objective is to scope system

• Step 2: Details– detailed descriptions– break out some detailed use cases

• Step 3: Structure– structure use cases using ‘extend’ and ‘include’– select the use cases that are to be implemented,

discard non-essential functionality

65

Other Uses of Scenarios• Scenario as a test case

– test cases derived from use cases

• Development increments– implement, test & deliver sets of use cases

• Scenarios can be used to analyse other models– we will see the how scenarios analyse an

object model, using sequence diagrams

66

Use Case Descriptions

• Many projects use templates– name of use case– pre-conditions– post-conditions– purpose– description– alternative courses– errors

67

Drawing Use Case Diagrams

• Identify the actors and the use cases• Prioritize the use cases• Develop each use case, starting with the

priority ones, writing a description for each• Add structure to the use case model:

generalization, include and extend relationships and subsystems

68

Prototyping

• Use case modelling can be supported with prototyping

• Prototypes can be used to help elicit requirements

• Prototypes can be used to test out system architectures based on the use cases in order to meet the non-functional requirements

69

Prototyping

• For user interface prototypes, storyboarding can be used with hand-drawn designs

70

Prototyping

• User interface prototypes can be implemented using languages other than the one that the system will be developed in

OKOK QuitQuit

Campaign:

Campaign Selection

Holborn MotorsLynch PropertiesYellow Partridge Zeta Systems

Client:

Spring Jewellery Campaign 2003Spring Jewellery Campaign 2004Spring Jewellery Campaign 2005Summer Collection 2004

Campaign:

Campaign Selection


Client:

Yellow Partridge

Spring Jewellery Campaign 2003Spring Jewellery Campaign 2004Spring Jewellery Campaign 2005Summer Collection 2004

Campaign:

Campaign Selection


Client:

Yellow Partridge

Spring Jewellery Campaign 2002

Dialogue initialized. User selects Client. Campaigns listed.

User selects Campaign.

OKOK QuitQuit OKOK QuitQuit

71

Summary

In this lecture you have learned about:

• The purpose of use case diagrams

• The notation of use case diagrams

• How to draw use case diagrams

• How to write use case descriptions

• How prototyping can be used with use case modelling

sa04 ch6b usecase diagrams

Documents