is0514slide 1 is0514 lecture week 3 use case modelling

25
IS0514 Slide 1 IS0514 Lecture Week 3 Use Case Modelling

Upload: donald-lawrence

Post on 24-Dec-2015

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 1

IS0514 Lecture Week 3

Use Case Modelling

Page 2: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 2

Today's Lecture

• What is a use case?• How to draw a use case diagram?• Relationships between Actors• Use case stereotypes

Page 3: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 3

UML Framework

RequirementsAnalysis

SystemDesign Implementation

Use Cases

Use Case Diagram

Domain ModelSoftware Architecture* sub-systems* layers & partitioning

Object Design

redrawn/extended classdiagram to reflect designdecisions: addition of interface and control objects; additionof constraints, etc.

Interface Design* Presentation Layer

Data Management* Storage mechanisms

UML Fram ew orkRequirements

Capture

In itia tionFeasibilty StudyScope of Development- domain description- boundaries

static view

dynam icview

Domain Model Design Model

Class DiagramData DictionaryCRCsInteraction Sequence DiagramCollaboration DiagramOperation Specifications

Use CasesUse Case Diagram

Statecharts

Class DiagramData DictionaryCRCsInteraction Sequence DiagramCollaboration DiagramOperation Specifications

Use CasesUse Case Diagram

Statecharts

Page 4: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 4

System Requirements

• Functional Requirements• What Systems do

• Inputs, Outputs, Process

• Non-Functional Requirements• Constraints on system

• Performance, Volume, Security etc

• Usability Requirements• User effectiveness, efficiency, comfort

• => Use Cases Primarily Model Functional Requirements

Page 5: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 5

Traditional Approach to requirements

• Documentation detailing description of system• Document forms “contract” with client• Discussions focus upon document• Result:

• Large legalistic documents

• Easy to misinterpret

• Changes hard to manage

• Easy to miss / omit requirements

• Modern approach – Model using UML• Use cases are used to capture functional requirements

Page 6: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 6

Use Case Modeling

• Models the ‘actors’ outside a system and their interactions with that system

• Every way that an ‘actor’ uses a system is called a Use Case

• Model:• Desired functionality

• Constraints on functionality

• Hence build what client wants!

Page 7: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 7

Reasons for Use Cases

• No information system exists in isolation• Most systems interact with humans or other

automated systems (actors) that use the system for some purpose

• Actors expect the system to behave in a predictable way

• Use Cases specify the behavior of the system• Helps visualize the system

Page 8: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 8

Use Case Modelling

• Use Case diagram– Diagram illustrating

• Actors

• Use cases

In the system

• Use Case Description– Specification of what happens in each use case

• Textural description

• Diagrams

Page 9: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 9

Example of a Use Case DiagramTelephone catalogue

Customer

Salesperson

Shipping Clerk

Supervisor

Check status

Place order

Fill orders

Establish credit

Page 10: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 10

Elements of Use Case Models• Use Case • Actor• Relationship• Use Case Diagram• Scenario• System Boundary• Use case description

• More next week

Page 11: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 11

Use Case• A Use Case is an interaction between the system and a

person or another system to achieve a result• A required “bit” of functionality• It yields an observable result of value to an actor (and

hence a developer)• Typically named with a verb than a noun

• “Do something to something”

View Timetable

Page 12: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 12

Actors• A coherent set of roles that users of Use Cases play when

interacting with Use Cases

• Roles not users or people

• User may have more than one role

Smith Lecturer

Page 13: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 13

Relationships• A semantic connection among elements• Used to show:

• A function required by an actor

• Relationships between actors

• More later

• Relationships between use cases

• More later

• Some people also use external relationships• Relationships between things that do not directly interact with

the system – Out of scope?

Page 14: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 14

Use Case Diagram• A diagram that shows a set of Use Cases and Actors and their

relationships

• Use Case diagrams address a user-centric view of a system

• Show a required “bit” of functionality

Person View Timetable

Page 15: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 15

Scenario / System Boundary• Scenario

• A single path through a Use Case

• Use case is usually a collection of scenarios

• Included as part of use case description

• More next week

• System Boundary

• A high level indication of the domain

• Limit to investigation

• System

• Part of system in focus

Page 16: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 16

Exercise 1 – Use Case Diagram• In groups of 3-4 spend 5 minutes attempting to draw

a use case diagram for the space invader game below:

http://www.neave.com/games/invaders/

Page 17: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 17

Exercise 1 Solution

Move Right

Fire Laser

View High Scores

Play Game

Player

Move Left

Page 18: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 18

Relationships in use cases• Between actor and use case

– Actor uses

• Generalisation of actors– Types of users

• Use case stereotypes– <<extend>>

• Optional – <<include>>

• Mandatory

• Stereotype is a UML extension mechanism to indicate a type of behaviour

Page 19: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 19

Generalisation of Actors

Update Gradebook

View Grade

Student

View Gradebook for all students

Lecturer

BlackboardUser

Login

Blackboard Gradebook

Question:Is Login part of this system?

Page 20: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 20

Use case variants :include and extend

• include relationship occurs when you have a chunk of behavior that is similar across more than one Use Case– use in two or more separate Use Cases to avoid repetition– a significant part of a use case– <<include>>

• extend relationship where you have one Use Case which adds functionality to another Use Case– any Use Case can have more than one extend– use when describing a variation on or in addition to normal behavior– OPTIONAL BEHAVIOUR

• Otherwise part of use case or• <<include>>

– <<extend>>

Page 21: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 21

Example of Use Case Variants

Place orderPlace back order

Supply Customer Data Arrange delivery

<<extend>>

<<include>><<include>>

Open account

<<include>>

shared functionality

additionalfunctionality

Extension PointPlace back order

Page 22: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 22

Exercise 2Consider Sonic the hedgehog.

1. What can sonic do?2. What are the use

cases?3. Are there any

relationships4. Draw the use case

diagram

http://www.ebaumsworld.com/games/play/1108/

1. Move left2. Move right3. Jump4. Jump left5. Jump right6. Spin Dash7. Pause

Page 23: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 23

Exercise 2 – Possible Solution

Sonic the hedgehog

What about:New gameChoose characteretc

Jump Left

Jump Right

Jump <<extend>>

<<extend>>Move Right

Move Left

Spin Dash

Player

Pause Game

Page 24: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 24

This weeks reading

ESSENTIAL READINGDennis A, Wixom B, and Tegarden D (2005) System

Analysis and Design with UML version 2 second edition, Wiley

Pages 178-186Further readingBennett, S., McRobb, S. and Farmer, R. (2002) Object-

Oriented Systems Analysis and Design using UML, 2nd Edition, McGraw-Hill

Pages 134-146

Page 25: IS0514Slide 1 IS0514 Lecture Week 3 Use Case Modelling

IS0514 Slide 25

Summary

• What is a use case• How to draw a use case diagram• Use case stereotypes• Relationships between Actors• Next Week

– Use case descriptions