BISM 7255 -- Business Information Systems Analysis and Design Page 0

Tutorial Material

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.
à A join cannot be used as a merge.
5. A decision node MUST be labeled with meaningful text.
6. There are two types of fork and join. They can be used for showing…
o parallel concurrent paths;
o looping (with description next to the fork and join elements).
For example, Fork – for each item; join – end for each item.
7. Conditions are mandatory for decision node. The conditions should be placed on each
outgoing flow that comes out of the decision node and they should be written between
brackets.
8. Use activities rather than actions.

3) Sequence Diagram
1. The input data MUST come from the attributes of the corresponding class in the class
diagram.
2. Alt fragment MUST have minimum two compartments, each of which has one guard
condition.
3. Loop and Opt fragments MUST have one condition only.
4. Return messages must be depicted as dashed lines.
5. A synchronous input message MUST have at least one return message.
6. The name of an input message should follow the verb-noun format.
7. camelBack notation rule MUST be used as the naming convention for labelling input
messages, input data (i.e., parameters), and return messages.
8. The name of a return message should be noun/noun phrases (e.g., patientInformation,
patientInformationDisplayed)
9. For each input message, input data MUST be sent with the input message.
10. The sequence diagram can have more than one actor.

4) Class Diagram
BISM 7255 -- Business Information Systems Analysis and Design Page 1
1. The naming of an attribute follows camelBack notation rule, which begins with a lowercase
letter, and the first letter of any words after the first word must be uppercase (e.g.,
firstName, emailAddress).
2. Each word of a class name Must be capitalized and with NO space between words (e.g.,
JuniorDoctor).
3. Attributes and Operations should be present in all classes.
4. Multiplicities MUST be present for each association.
5. The attributes of an association class must NOT be included in either of the endpoint
classes.
6. The name of an abstract class MUST be written in italics (e.g., Doctor).

5) State Machine Diagram
1. A major state can be a composite state, but is not a substate of the composite state.
2. A trigger should be present in each transition. It may be omitted on the transition from the
initial state to the first substate of a composite state.
3. Trigger names and guard conditions must follow the camelBack notation rule. For example,
when a trigger is…
o an event: ticketCreated
o a change in some conditions: createTicket
o the passage of time: fiveMinutesPassed
4. Guard and Effect are optional. However, guard conditions MUST be present for modelling
OR condition/ choice pseudo-state.
5. Guards must be written between brackets […].
6. The name of a state should NOT be a noun (which indicates an object); it should be the
term that describes the object (e.g., Active, On Hold, In Progress, Closed).

You must clearly capture the relationships between different types of UML models. This
means:

• The Activity Diagram must model the business process that is captured in one or more use
cases of the Use Case Diagram.
• Activity Diagram and Sequence Diagram must depict the same business process.
• The information contained in the Sequence Diagram should match the information
captured in the Class Diagram.
• State Machine Diagram must depict the states of a single object (over its lifespan); this
object is captured as a class in the Class Diagram.
Hint: you will need to select the object that is evidently the focus of the case scenario.



Good luck with the assignment!