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

The Vision SSM Models Use Cases Activity Models Dynamic Models Object Models Programs Databases Business Computing

Beginnings of a Method Soft Systems Model

Use Case Models Consist of –Use Cases –Actors –Relationships between Actors and Use Cases

What is a Use Case? “A Use Case is a sequence of transactions performed by a system that yields a measurable result of values for an actor” Formal definition “A Use Case is a sequence of transactions performed by a system that yields a measurable result of values for an actor” A Use Case: is a meaningful piece of system functionality models a dialogue between a user and the system Note - The user can be another system is more than a simple transaction (e.g. enter customer address)

We draw a use case as:

Examples of Use Cases Print Invoice Correct Invoice Chase Payment Register Bad Debt

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: An Actor

Actors 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 use cases An Actor A Use Case

Arrows indicate who initiates interaction An Actor A Use Case Sometimes the use case initiates interaction

Use 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

Stereotypes 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 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 PaymentIssue Warning Letter >

Include 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 Validat e user >

SSM Conceptual Model Any use cases here?

Initial thoughts on a development method

Problem 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 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 System 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-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 Model Identify suitable peer tutors Document Skills of peer tutors Train peer tutors Advertise Receive tutee Document tutee needs Book times and rooms

Attendance Monitoring

Related Use Cases Let’s consider this one

Create Class List

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

Class Diagram showing relationships between these objects

We can do two things with this class diagram 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 can be implemented in an OOPL

And how class diagrams can drive database design When the computer is switched off…. –…the data used by the class diagram must be stored in a database

My Next Example Program

Another Student

The Underlying Database

The Program that uses the Database

The Class Diagram

Get Group Student Numbers Get Student Number

Get Student Marks Get Module Results

Three Tiers

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 Architecture

Back to Use Cases

Finding Use Cases (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 (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? 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 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 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 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 (2)

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

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