Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: zz-x2580
BISM7255
Business Information Systems Analysis
and Design
Tutorial 6 – Summary Tutorial and
Comprehensive UML Case
BISM 7255 -- Business Information Systems Analysis and Design Page 1
UML Case Scenario
1 Summary Task
In this tutorial, you will create UML diagrams (i.e., use case diagram, activity diagram,
sequence diagram, class diagram, state machine diagram) that represent business information
systems for the Blackberry Hill Hospital.
This tutorial provides you with a comprehensive example to apply all diagrams. It allows you
to understand and model the dependencies between the different diagrams and as such the data
and processes that are related.
The case summarizes all the knowledge that was covered in the UML tutorials; there is no new
knowledge introduced. We encourage you to go back to the knowledge sheet of each tutorial
should any aspects of UML diagrams are not clear to you. Tutors are available for help and
happy to answer any questions you might have when working through the case.
2 Detailed Information about the Business Case
Blackberry Hill Hospital has implemented a new system called Hospital Management System
for improving the quality of its health services. The system consists of two subsystems –
Electronic Prescribing Subsystem (EPS) and IT Helpdesk Subsystem.
Medicine Prescribing and Dispensing Process
The following text provides you with details you need to create the use case diagram, activity
diagram, and sequence diagram.
The use case shall present the electronic prescribing subsystem (EPS). Both activity diagram
and sequence diagram shall present the prescribing and dispensing processes. However, the
activity diagram needs to capture the process, whereas the sequence diagram captures the
interactions between the actors [doctor & pharmacist] and the system (each).
The EPS enables the prescribing, dispensing and claiming of medicines, without the need for a
paper prescription. It aims to provide convenience and choice to patients whilst improving
overall efficiency, compliance and drug safety. The prescribing and dispensing processes are
detailed as follows.
To generate an electronic prescription, the doctor accesses the EPS by providing login details.
Once authenticated, the EPS requests for the patient and medicine details, it is compulsory to
at least include the patient’s national identification number and the medicine name. After
receiving this information, the EPS generates the electronic prescription and, meanwhile, a
BISM 7255 -- Business Information Systems Analysis and Design Page 2
confirmation message is sent to the doctor. Then, the doctor notifies the patient that its
prescription is done and ready to be used.
The patient needs to collect his/her medicine from a pharmacy with access to the EPS. When
the patient arrives at the pharmacy, a pharmacist asks for the patient’s information, especially
the national identification number. The pharmacist accesses the EPS in the same way as the
doctor. Once authenticated, the pharmacist enters the patient’s NIN into EPS and retrieves
his/her electronic prescription via the system.
For each medicine, EPS checks its records to see whether the medicine is currently available.
If the medicine that the patient was prescribed is in stock, the pharmacist dispenses the medicine
to the patient and marks the medicine as ‘dispensed’. If medicine is shown in the system as ‘out
of stock’ or ‘on backorder’ at the time of dispensing, the patient will be told to wait until further
notice. For the medicines that are currently available, the patient pays for those medicines. Once
the pharmacist receives the payment, he/she records them in the database and provides receipts
if required. The pharmacist is encouraged to report the medicine shortages through the system
on a daily basis to minimize the impact on patient care as much as possible.
Data Requirements of the Hospital Management System
The following text provides you with details you need to create a domain class diagram of the
Hospital Management System.
The Hospital Management System contains all the records for the hospital wards, teams of
doctors, and patients.
Ward is a division of a hospital or a suite of rooms shared by patients who need a similar kind
of care. In a hospital, there are a number of wards, each of which may be empty or have on it
one or more patients. Each ward has a unique name represented by ID. Wards are differentiated
by gender of its patients, i.e. male wards and female wards. A ward can only have patients of
the gender admitted to it. Gender is shown as enumeration. Every ward has a fixed capacity,
which is the maximum number of patients that can be on it at one time (i.e. the capacity is the
number of beds in the ward). Different wards may have different capacities.
The doctors in the hospital are organized into teams. Each team has a unique name (e.g.,
Orthopedics or Pediatrics) and is headed by a consultant doctor. Consultant doctor is the senior
doctor who has completed all of his or her specialist training, residency and practices medicine
in a clinic or hospital, in the specialty learned during residency. She or he can supervise fellows,
residents, and medical students. The rest of the team are all junior doctors. Each doctor is a
member of no more than one team.
Each doctor can treat many patients. Likewise, a patient can book appointment(s) with one or
more doctors with different expertise.
The hospital also provides targeted IT support for doctors. If a doctor encounters an IT-related
problem, such as requesting for additional software installed, access to a system, password
reset, or technical problems with computer equipment, they can request support from the IT
Helpdesk by opening a support ticket. A doctor can create many tickets, each of which for a
specific issue encountered.
BISM 7255 -- Business Information Systems Analysis and Design Page 3
The Lifecycle of a Support Ticket
The following text provides you with details you need to create the state machine diagram that
represents states of a support ticket and the transitions between them.
A doctor requests support from the IT Helpdesk subsystem by opening a support ticket. Once
a support ticket is created, it’s in an active state. New tickets are placed into a queue. IT support
staff checks the queue and action tickets based on their priority. New tickets initially have
normal priority. If they remain un-actioned after three days, they are raised to high priority
status.
When they start working on the ticket, they indicate that work is in progress. Sometimes IT
support staff are unable to immediately resolve the problem as they must, for example, contact
the vendor for additional support. In that case, a support ticket is placed on hold. When the
response for the vendor or other relevant party is received, the ticket is back in progress. When
the IT problem is resolved, the ticket can be closed. A closed state for the ticket indicates that
the problem has been resolved.
3 Now it is your turn
Start modeling with UML 2.0 the respective diagrams. Create the diagrams in the following
order:
1) Use Case Diagram
2) Activity Diagram
3) Sequence Diagram
4) Class Diagram
5) State Machine Diagram
4 Overview of Modelling Conventions
When you create UML diagrams, the way you create them needs to follow the modeling
convention of UML 2.5.
1) Use Case Diagram: All actors, use cases, and relationships between different use cases
should come from the section ‘Medicine Prescribing and Dispensing Process’.
2) Activity Diagram: All activities, partitions, decision activities, parallel concurrent paths,
and looping should come from the section ‘Medicine Prescribing and Dispensing Process’.
3) Sequence Diagram: All actors, input messages, output messages, input data, self-
messages, and three types of fragments should come from the section ‘Medicine
Prescribing and Dispensing Process’.
4) Class Diagram: All classes should come from the section ‘Data Requirements of the
Hospital Management System’.
5) State Machine Diagram: All states, transitions, triggers, and guard conditions should
come from the section ‘The Lifecycle of a Support Ticket’.
Next there is an example given between an incorrect and a correct modeling convention.
BISM 7255 -- Business Information Systems Analysis and Design Page 0
Example class diagram with incorrect modelling convention: Example class diagram with correct modelling convention:
Mistakes: Correction:
1. Incorrect modelling of the whole-part relationship between Team and
Doctor
1. In the whole-part relationship (Composition) between Team and Doctor,
Team class is the ‘Whole’ while Doctor class is its ‘Part’.
2. Incorrect format for attributes and operations of Doctor class 2. The naming of attributes must follow camelBack notation rule. The attributes
and operations for Doctor class should be written as:
• Attributes: doctorID, firstName, lastName, specialty
• Operations: checkReport, prescribeMedicine
3. Incorrect relationships among Doctor, ConsultantDoctor, and
JuniorDoctor
3. The relationship between Doctor and ConsultanDoctor is a generalization/
specialization relationship.
Likewise, the relationship between Doctor and JuniorDoctor is a
generalization/ specialization relationship.
4. Incorrect format for class name – Consultant Doctor, and Junior Doctor 4. The class name should be written as ConsultantDoctor and JuniorDoctor.
There is no space between words.
5. doctorID should not be present in the specialized classes, namely,
ConsultantDoctor and JuniorDoctor
5. Delete doctorID from ConsultantDoctor class and JuniorDoctor class
6. Incorrect naming convention of the Doctor class 6. The Doctor class name should be written in italics because it is an abstract
class.
BISM 7255 -- Business Information Systems Analysis and D Page 0
5 Modelling conventions
1) Use Case Diagram
1. A top-level use case is a use case that is not used by a using use case and that is not
extending a base use case.
2. NO order of appearance of described activities/services is shown.
3. A use case captures a functional requirement of the system. For example, “Enter Patient
Information” indicates that the pharmacist uses the EPS to enter patients’ information. Note
that “Arrives at Pharmacy” is NOT a use case because it is not a function of the system.
4. Articles (e.g., a, an, the) must NOT be used in naming a use case.
5. The use case must be named in ‘Verb–Noun’ form. For the name of any actors and use
cases, the first letter of each word should be capitalized, e.g., Enter Patient Information.
6. A use case can be used by more than one actor.
7. The actor represents roles (e.g., doctor), this means that it cannot be a person’s name (e.g.,
Emily).
8. The automation boundary is compulsory as well as its name. For the system name, the first
letter of each word must be capitalized (e.g., Electronic Prescribing Subsystem).
9. In an “Extend” relationship, the condition MUST be specified in a Note symbol attached
to the arrow.
2) Activity Diagram
1. The name of activities must follow “Verb–Noun” format.
2. Articles (e.g., a, an, the) must NOT be used in naming an activity.
3. The diagram must have ONE initial node and ONE final node (activity final node).
4. Synchronization bars, as well as decision activities, must be opened and closed.
à fork and join MUST be used in pairs!
à A merge node MUST be used to bring together multiple incoming alternate flows to
accept a single outgoing flow.
