54
Use Case Analysis Use Case Analysis From soft systems methodology to understanding the system functionality

Use Case Analysis From soft systems methodology to understanding the system functionality

Embed Size (px)

Citation preview

Page 1: Use Case Analysis From soft systems methodology to understanding the system functionality

Use Case AnalysisUse Case Analysis

From soft systems methodology to understanding the system functionality

Page 2: Use Case Analysis From soft systems methodology to understanding the system functionality

The VisionThe Vision

SSM Models

Use Cases

Activity Models

Dynamic Models

ObjectModels

Programs

Databases

BusinessComputing

Page 3: Use Case Analysis From soft systems methodology to understanding the system functionality

Beginnings of a MethodBeginnings of a Method

Soft Systems

Model

Page 4: Use Case Analysis From soft systems methodology to understanding the system functionality

Use Case ModelsUse Case Models

• Consist of

– Use Cases

– Actors

– Relationships between Actors and Use Cases

Page 5: Use Case Analysis From soft systems methodology to understanding the system functionality

What is a Use Case?What is a Use Case?

Formal definition

“A Use Case is a sequence of transactions performed “A Use Case is a sequence of transactions performed

by a system that yields a measurable result of values by a system that yields a measurable result of values

for an actor”for an actor”

A Use Case:

• is a meaningful piece of system functionality

• models a dialogue between a user and the systemNote - The user can be another system

• is more than a simple transaction (e.g. enter customer

address)

Page 6: Use Case Analysis From soft systems methodology to understanding the system functionality

We draw a use case as:We draw a use case as:

A Use Case

Page 7: Use Case Analysis From soft systems methodology to understanding the system functionality

Examples of Use CasesExamples of Use Cases

• Print Invoice

• Correct Invoice

• Chase Payment

• Register Bad Debt

Page 8: Use Case Analysis From soft systems methodology to understanding the system functionality

What is an Actor?What is an Actor?

• Anyone or any thing that uses or interfaces with the

system, such as:

– customer

– credit controller

– EPOS system

– Bank system

Page 9: Use Case Analysis From soft systems methodology to understanding the system functionality

We draw actors as:We draw actors as:

An Actor

Page 10: Use Case Analysis From soft systems methodology to understanding the system functionality

Actors and Use CasesActors and Use Cases

• An Actor may use many Use Cases

• A Use Case may interface with many Actors

• We draw a simple line to indicate interaction

Page 11: Use Case Analysis From soft systems methodology to understanding the system functionality

Relationships between actors and Relationships between actors and use casesuse cases

An ActorA Use Case

Page 12: Use Case Analysis From soft systems methodology to understanding the system functionality

Arrows indicate who initiates Arrows indicate who initiates interactioninteraction

An ActorA Use Case

Sometimes the use case initiates interaction

Page 13: Use Case Analysis From soft systems methodology to understanding the system functionality

Use Cases can be relatedUse Cases can be related

• One Use Case may use another Use Case

• Sometimes that use is an exception or

alternative, and we say that one Use Case

extends another Use Case

Page 14: Use Case Analysis From soft systems methodology to understanding the system functionality

StereotypesStereotypes

UML has a concept called a stereotype which is used to describe the type of relation ship that is being used.

Stereotypes are written between guillemets << >> (pronounced “ gweemays”) which are placed on the relationship lines.

Example

<<extend>>

Page 15: Use Case Analysis From soft systems methodology to understanding the system functionality

ExtendExtend relationship relationship

Used where an alternative or an exception is being shown.

In this case as part of a money collecting function, it is required that a warning letter is sent out.

Note the direction of the arrow. It always goes from the extension to the base case.

Chase Payment Issue Warning Letter

<<extend>>

Page 16: Use Case Analysis From soft systems methodology to understanding the system functionality

IncludeInclude relationship relationship

When use cases share the same piece of functionality,

we use the include relationship whereby the common

use case is linked to the use cases that use its

functionality.

In this case, the Validate User

use case needs

to be used for taking

an order and for

displaying user

information

Note direction is from base to extension case

Take order

Confirm details

Validate user

<<include>>

<<include>>

Page 17: Use Case Analysis From soft systems methodology to understanding the system functionality

SSM Conceptual ModelSSM Conceptual Model

enrol studentsdesign

educationprogrammes

appreciatenational

standards

educatestudents

allotresources

designand carry outassessment

awarddegrees + diplomasto students reaching

acceptable levels

Any use cases here?

Page 18: Use Case Analysis From soft systems methodology to understanding the system functionality

Initial thoughts on a development Initial thoughts on a development methodmethod

Page 19: Use Case Analysis From soft systems methodology to understanding the system functionality

Problem SituationProblem Situation

• Student Retention

• Too many students enrol on a course then withdraw in their first year

• Need a software system to help solve the problem– An improved

school intranet

Page 20: Use Case Analysis From soft systems methodology to understanding the system functionality

Identify Relevant SystemsIdentify Relevant Systems

1. Admissions 

2. Pastoral Care

3. Timetabling 

4. Module Delivery

5. Peer Tutoring

6. Assessment

7. Attendance Monitoring

8. Research 

Page 21: Use Case Analysis From soft systems methodology to understanding the system functionality

Definition of a Pastoral Services Definition of a Pastoral Services SystemSystem

• A system under the control of an in-school counselling team – giving appropriate referrals to external agencies to students presenting personal problems to members of the counselling team.

Page 22: Use Case Analysis From soft systems methodology to understanding the system functionality

Root Definition for Peer-TutoringRoot Definition for Peer-Tutoring

• A system owned by the school that provides study skills support to students using volunteers from the student body with the quality of their support activities monitored by academic staff

Page 23: Use Case Analysis From soft systems methodology to understanding the system functionality

Conceptual ModelConceptual Model

Identify suitable peer tutors

Document Skills of peer tutors

Train peer tutors

Advertise

Receive tutee

Document tutee needs

Book times and rooms

Page 24: Use Case Analysis From soft systems methodology to understanding the system functionality

Attendance MonitoringAttendance Monitoring

Record absentees during a tutorial session

Know tutorial group members

Inform pathway leader of persistent absentees

Know student's pathway leader

Inform student of contact with pathway leader

Page 25: Use Case Analysis From soft systems methodology to understanding the system functionality

Related Use CasesRelated Use Cases

Print Class List

Enter Attendance Data for Class Tutorial

Print Attendance Record for Specific Class

Print Attendance Record for Specific Student

Module Leaderemail pathway leader and student

Let’s consider this one

Page 26: Use Case Analysis From soft systems methodology to understanding the system functionality

Create Class ListCreate Class List

Page 27: Use Case Analysis From soft systems methodology to understanding the system functionality

The information displayed here might be brought The information displayed here might be brought together through collaboration between objectstogether through collaboration between objects

: Pathway : Module : StudentCreate Class List Form

CreateClassList( )getStudentDetails( )

getPathwayTitle( )

Page 28: Use Case Analysis From soft systems methodology to understanding the system functionality

Class Diagram showing relationships between Class Diagram showing relationships between these objectsthese objects

Module

NameModule Code

Create Class List()

Student

Name

get student details()n nn n

enrolled on

Pathway

TitleDescription

get pathway title()1

nn

1

registered on

Page 29: Use Case Analysis From soft systems methodology to understanding the system functionality

We can do two things with this class We can do two things with this class diagramdiagram

• Implement it in an OOPL

• Translate it into an entity model then implement the entity model as a relational database

Page 30: Use Case Analysis From soft systems methodology to understanding the system functionality

We’ve considered how class diagrams We’ve considered how class diagrams can be implemented in an OOPLcan be implemented in an OOPL

Pathway

Title

Student

Name

1

n

1

n

Module

CodeTitle

nn

n

n

n

n

Page 31: Use Case Analysis From soft systems methodology to understanding the system functionality

And how class diagrams can drive And how class diagrams can drive database designdatabase design

• When the computer is switched off…. – …the data used by the class diagram must be stored in a

database

Page 32: Use Case Analysis From soft systems methodology to understanding the system functionality
Page 33: Use Case Analysis From soft systems methodology to understanding the system functionality

My Next Example ProgramMy Next Example Program

Page 34: Use Case Analysis From soft systems methodology to understanding the system functionality

Another StudentAnother Student

Page 35: Use Case Analysis From soft systems methodology to understanding the system functionality

The Underlying DatabaseThe Underlying Database

Page 36: Use Case Analysis From soft systems methodology to understanding the system functionality

The Program that uses the The Program that uses the DatabaseDatabase

Page 37: Use Case Analysis From soft systems methodology to understanding the system functionality

The Class DiagramThe Class Diagram

Group

Student

n

Module Work Recordn1

n

n1

Page 38: Use Case Analysis From soft systems methodology to understanding the system functionality
Page 39: Use Case Analysis From soft systems methodology to understanding the system functionality

System Boundary

Group Student

Get Group Student Numbers

Get Student Number

Page 40: Use Case Analysis From soft systems methodology to understanding the system functionality

System Boundary

Group Student Module Results

Get Student Marks

Get Module Results

Page 41: Use Case Analysis From soft systems methodology to understanding the system functionality

Three TiersThree Tiers

Group

Student

n

Module Work Recordn1

n

n1

Page 42: Use Case Analysis From soft systems methodology to understanding the system functionality

An interface developed in Visual Basic or HTML?

An implementation of the class diagram using VB class modules or Java?

An implementation of the entity model in MS Access, ORACLE, MySQL?

Classic Three Tier ArchitectureClassic Three Tier Architecture

Page 43: Use Case Analysis From soft systems methodology to understanding the system functionality

Back to Use CasesBack to Use Cases

Page 44: Use Case Analysis From soft systems methodology to understanding the system functionality

Finding Use Cases Finding Use Cases (cont’d)(cont’d)

• Examine all the activities in the conceptual model and determine where the system is used

• Big use cases sometimes naturally break down via includes and extends

• Elaborating the use case often finds other use cases

Page 45: Use Case Analysis From soft systems methodology to understanding the system functionality

Finding Use Cases Finding Use Cases (cont’d)(cont’d)

To fulfil a defined role:

• What do users need to be able to do?

• What are users trying to accomplish

• What are the main tasks of users in this role?

• What information do users in this role need to examine, create, or change?

• What do users in this role need to be informed of by the system?

• What do users in this role need to inform the system about?

Page 46: Use Case Analysis From soft systems methodology to understanding the system functionality

What do Students do?What do Students do?

• Enroll in, attend, drop, fail, and pass modules.

• Need a list of available modules.

• Need to determine basic information about a module, such as its description and its prerequisites.

• Obtain a copy of their transcript, their course schedules, and the fees due.

• Pay fees, pay late charges, receive reimbursements for dropped and cancelled modules, receive grants, and receive student loans.

• Graduate from a school or drop out of it.

• Need to be informed of changes in modules, including room changes, time changes, etc.

 

Page 47: Use Case Analysis From soft systems methodology to understanding the system functionality

Prototyping and Use CasesPrototyping and Use Cases

• Interface prototypes are good for:

– Agreeing user interaction (HCI factors)

– Clarifying with users

– Determining data requirements

– Working out how to group use cases in interfaces

Page 48: Use Case Analysis From soft systems methodology to understanding the system functionality

Use Case ProformaUse Case Proforma

• Number and Name

• Primary Path

• Pre- and post-conditions

• Alternatives and Exceptions

• Related Use Cases

• Prototype Interfaces

• Activity Diagrams

• Supported Business Processes / Activities

• Notes

Page 49: Use Case Analysis From soft systems methodology to understanding the system functionality

A Use Case CatalogueA Use Case Catalogue

• Is a Substantial Document

• Overviewed by set of Use Case Diagrams

• Has Individual Use Cases

• Linked into CASE tool

• This is your requirements definition!

Page 50: Use Case Analysis From soft systems methodology to understanding the system functionality

Invoicing use case (1)Invoicing use case (1)

Use Case Number: 99

Use Case Name: Invoice Customer

Brief Description: This is run daily to send invoices to customers. Itemsthat have been delivered are billed all on the same invoice. Customersare only billed once a month.Actors: Daily batch run, customer (indirectly, through post)Frequency of Execution: DailyScalability: Only one instance of this runs at any one time.Criticality: Essential. Every days delay to printing invoices affects thebank balance considerably. Not running this for 7 days could trigger aserious cash flow problem.Primary Path:The following sequence is carried out for every customer on the salesledger who has not been billed in the last month:

1. Get sales items from the sales ledger.2. Get customer details from the customer file, covering billing addressdetails.3. Get any credits that the customer has.4. Get discount details for customer.5. Print the invoice header6. Print the line items on the invoice7. Calculate any discounts8. Apply any credits9. Calculate and print the invoice total10. Calculate and print the VAT11. Mark items on sales ledger as invoiced

Page 51: Use Case Analysis From soft systems methodology to understanding the system functionality

Invoicing use case (2)Invoicing use case (2)

Use Cases Related to Primary Path: Alternatives:2.1 No customer details on customer file, so print an error message on areport. Do not mark the items on the sales ledger as invoiced. Themessage needs to detail the sales items that have been entered.Use Cases Related to Alternatives:Invoicing error reportExceptions: Use Cases Related to Exceptions: Notes:

Page 52: Use Case Analysis From soft systems methodology to understanding the system functionality

Why Use Case Modelling?Why Use Case Modelling?

• Agree system functionality and scope

• Relate it to how business processes are supported

• High level soft model, can be understood by all parties

• Prioritise implementation - particularly important for

iterative development

Page 53: Use Case Analysis From soft systems methodology to understanding the system functionality

What about Objects?What about Objects?

• You don’t need to be developing an OO system to use

Use Case analysis

• Once you have Use Cases, then OO analysis and

design can begin in earnest

Page 54: Use Case Analysis From soft systems methodology to understanding the system functionality

SummarySummary

• Use Cases are meaningful chunks of system

functionality

• They support business processes

• They are important for defining and agreeing scope of a

system

• They can be prototyped

• They are important for driving implementation

schedules

• Modern development methods are “use case centric”