IS 0514 Lecture Week 3 Use Case Modelling

IS 0514 Lecture Week 3 Use Case Modelling IS 0514 Slide 1

Today's Lecture • • IS 0514 What is a use case? How to draw a use case diagram? Relationships between Actors Use case stereotypes Slide 2

UML Framework IS 0514 Slide 3

System Requirements 1. Functional Requirements 1. What Systems do 2. Inputs, Outputs, Process 2. Non-Functional Requirements 1. Constraints on system 2. Performance, Volume, Security etc 3. Usability Requirements 1. User effectiveness, efficiency, comfort 4. => Use Cases Primarily Model Functional Requirements IS 0514 Slide 4

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 IS 0514 Slide 5

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! IS 0514 Slide 6

Reasons for Use Cases 1. No information system exists in isolation 2. Most systems interact with humans or other automated systems (actors) that use the system for some purpose 3. Actors expect the system to behave in a predictable way 4. Use Cases specify the behavior of the system 5. Helps visualize the system IS 0514 Slide 7

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 IS 0514 Slide 8

Example of a Use Case Diagram Telephone catalogue Check status Salesperson Place order Customer Fill orders Shipping Clerk Establish credit Supervisor IS 0514 Slide 9

Elements of Use Case Models • • IS 0514 Use Case Actor Relationship Use Case Diagram Scenario System Boundary Use case description • More next week Slide 10

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” IS 0514 Slide 11

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 IS 0514 Slide 12

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? IS 0514 Slide 13

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 IS 0514 Slide 14

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 IS 0514 Slide 15

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/inva ders/ IS 0514 Slide 16

Exercise 1 Solution IS 0514 Slide 17

Relationships in use cases • Between actor and use case – Actor uses • Generalisation of actors – Types of users • Use case stereotypes – <> • Optional – <> • Mandatory • Stereotype is a UML extension mechanism to indicate a type of behaviour IS 0514 Slide 18

Generalisation of Actors Blackboard Gradebook Question: Is Login part of this system? IS 0514 Slide 19

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 – <> • 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 • <> – <> IS 0514 Slide 20

Example of Use Case Variants additional functionality Open account Place order <> Extension Point Place back order <> Supply Customer Data Place back order <> Arrange delivery shared functionality IS 0514 Slide 21

Consider Sonic the hedgehog. 1. What can sonic do? 2. What are the use cases? 3. Are there any relationships 4. Draw the use case diagram 1. 2. 3. 4. 5. 6. 7. IS 0514 Move left Move right Jump left Jump right Spin Dash Pause Exercise 2 http: //www. ebaumsworld. com/games/play/1108/ Slide 22

Exercise 2 – Possible Solution Sonic the hedgehog What about: New game Choose character etc IS 0514 Slide 23

This weeks reading ESSENTIAL READING Dennis A, Wixom B, and Tegarden D (2005) System Analysis and Design with UML version 2 second edition, Wiley Pages 178 -186 Further reading Bennett, S. , Mc. Robb, S. and Farmer, R. (2002) Object. Oriented Systems Analysis and Design using UML, 2 nd Edition, Mc. Graw-Hill Pages 134 -146 IS 0514 Slide 24

Summary • • • What is a use case How to draw a use case diagram Use case stereotypes Relationships between Actors Next Week – Use case descriptions IS 0514 Slide 25