UoL CS Notes
Menu

Case Study Example & Noun Identification Technique

COMP201 Lectures

The Problem

You have been contacted to develop a computer system for a university medical clinic.

The clinic needs the following types of service:

  • Staff management
  • Booking appointments
  • Keeping records

You are asked to build an interactive system which handles all of these aspects online.

Developing Requirements

We need to identify all the actors:

  • Doctors
  • Patients
  • Admin Staff

and the data we want to keep track of:

  • Appointments
  • Treatments

We can as the actors about their requirements that can then be made into use-cases.

Use Case Model

We should take the requirements, identify the actors and the use cases (tasks) that the actors must undertake.

left to right direction
:Doctor: as D
:Receptionist: as R
:Patient: as Pa
:Pharmacist: as Ph

package "Clinic System" {
(View Appointments) as va
(Schedule Appointment) as sa
(Cancel Appointment) as ca
(View Notes) as vn
(Add Notes) as an
(Issue Prescription) as ip
(Request Repeat Prescription) as rrp
(Re-book Appointment) as ra
(Supply Prescription) as sp
(Check Stock) as cs
}
D -l-|> R
R --- va
R --- sa
R --- ca
D --- vn
D --- an
D --- ip
Pa -up- rrp
Pa -up- ra
Ph -up- sp
Ph -up- cs

We shouldn’t make addition use-cases without first confirming with the client.

We should make this use-case diagram with an iterative approach.

Identifying Classes

This is where the noun identification technique is used.

Consider that we have the following requirements document:

Clinic, appointments and treatment system.

Before seeing a doctor or nurse the patient needs to make an appointment. The appointment will be made by the receptionist, before making the appointment the patient needs to ask the patient which doctor they wish to see and if the appointment is a standard appointment or urgent appointment. The receptionist will use this information, check the appointment schedule and find a free slot and make the booking. When the patient sees the Dr, the Dr will sometimes issue a prescription. The patient may at some time request a repeat issue of their prescription. Receptionists can also cancel appointments. Each doctor has a maximum of 2000 patients registered to them.

We can then underline all nouns like:

  • Clinic
  • System
  • Doctor
  • Appointment
  • Prescription
  • Time
  • …

We can the use these as a list of candidate classes.

We should remove nouns that are:

  • Outside the scope of the system.
  • Redundant
  • Measures, such as “time”.
  • Vague (need clarification)
  • Meta-language, such as “system”.

Relations Between Classes

We can use the classes we have found to create an initial class model using only the multiplicity relations:

classDiagram
direction LR
Doctor "1" -- "1..*" Patient:Cares For
Doctor "1" -- "1..*" Prescription:Writes/Issues/Confirms
Doctor "1" -- "1..*" Appointment
Receptionist "1" -- "1..*" Appointment:Books/Cancels/Re-Books
Patient "1" -- "1..*" Appointment:Attends
Nurse "1" -- "1..*" Patient:Treats
Nurse "1" -- "1..*" Appointment

Inheritance Class Model

We can see if there are any shared roles between the actors. This can inform the inheritance.

classDiagram
direction TB
HealthcareStaff <|-- Doctor
HealthcareStaff <|-- Nurse
Staff <|-- Receptionist
Staff <|-- HealthcareStaff
Person <|-- Staff
Person <|-- Patient

We can then involve hierarchy this in our initial diagram:

classDiagram
HealthcareStaff <|-- Doctor
HealthcareStaff <|-- Nurse
Staff <|-- Receptionist
Staff <|-- HealthcareStaff
Nurse "1" -- "1..*" Patient:Treats
Nurse "1" -- "1..*" Appointment
Doctor "1" -- "1..*" Patient:Cares For
Person <|-- Patient
Person <|-- Staff
Doctor "1" -- "1..*" Prescription:Writes/Issues/Confirms
Doctor "1" -- "1..*" Appointment
Receptionist "1" -- "1..*" Appointment:Books/Cancels/Re-Books
Patient "1" -- "1..*" Appointment:Attends

Interaction Diagrams (Sequence Diagram)

Consider what happens in the appointment booking scenario when a user wishes to make an appointment:

  1. The receptionist must check that the person is a valid patient.
  2. Then the doctor object must be checked to see if there are any available appointments.
  3. If there are any suitable slots available, a new appointment should be created and assigned to the doctor.

This can be shown in the following sequence diagram:

sequenceDiagram
actor Receptionist
actor Patient
actor Doctor

Receptionist -->> Patient:create(name)
activate Receptionist
Receptionist ->> Patient:valid?
activate Patient
Patient -->> Receptionist: 
deactivate Patient

Receptionist ->> Doctor:available(date/time)
activate Doctor 
Doctor ->> Appointment:dateMatch(date/time)
Appointment -->> Doctor:match?
Doctor -->> Receptionist:available?
deactivate Doctor
Receptionist -->> Appointment:create(date,time)
Appointment -->> Receptionist: 
Receptionist ->> Doctor:setAppointment(Appointment)
activate Doctor
Doctor -->> Receptionist: 
deactivate Doctor
Receptionist ->> Patient:setAppointment(Appointment)
activate Patient
Patient -->> Receptionist: 
deactivate Patient
deactivate Receptionist

State Diagrams

Objects in the system have a state. State diagrams show how methods can change an object’s state:

stateDiagram
state Doctor {
direction LR
FullyBooked --> Available:cancelAppointment()
Available --> FullyBooked:bookAppointment()[lastAppointment]
Available --> Available:bookAppointment()[notLastAppointment]
Available --> Available:cancelAppointment()
}