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

The VisionThe Vision

SSM Models

Use Cases

Activity Models

Dynamic Models

ObjectModels

Programs

Databases

BusinessComputing

Beginnings of a MethodBeginnings of a Method

Soft Systems

Model

Use Case ModelsUse Case Models

• Consist of

– Use Cases

– Actors

– Relationships between Actors and Use Cases

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)

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

A Use Case

Examples of Use CasesExamples of Use Cases

• Print Invoice

• Correct Invoice

• Chase Payment

• Register Bad Debt

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

We draw actors as:We draw actors as:

An Actor

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

Relationships between actors and Relationships between actors and use casesuse cases

An ActorA Use Case

Arrows indicate who initiates Arrows indicate who initiates interactioninteraction

An ActorA Use Case

Sometimes the use case initiates interaction

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

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>>

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>>

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>>

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?

Initial thoughts on a development Initial thoughts on a development methodmethod

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

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 

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.

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

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

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

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

Create Class ListCreate Class List

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( )

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

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

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

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

My Next Example ProgramMy Next Example Program

Another StudentAnother Student

The Underlying DatabaseThe Underlying Database

The Program that uses the The Program that uses the DatabaseDatabase

The Class DiagramThe Class Diagram

Group

Student

n

Module Work Recordn1

n

n1

System Boundary

Group Student

Get Group Student Numbers

Get Student Number

System Boundary

Group Student Module Results

Get Student Marks

Get Module Results

Three TiersThree Tiers

Group

Student

n

Module Work Recordn1

n

n1

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

Back to Use CasesBack to Use Cases

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

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?

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.

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

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

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!

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

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:

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

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

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”