Building a Domain Model

Software Engineering 2015-2016

November 27, 2016
This is a first exercise in software modelling. The purpose of this exercise is
the construction of a domain model for the MiniDrone Domain.
A domain model is a useful first step in creating models to support software engineering processes. A domain model is sometimes referred-to as an
analysis model, and serves the requirements analysis process (i.e. the process
of considering requirements in deep detail).

What is a Domain Model?

In software engineering a domain model is a conceptual model of the domain,

i.e. a structured collection of concepts that are used in a specific domain. A common
view is that it incorporates both behaviour and data, but this is essentially irrelevant. What matters are i) what are the concepts and ii) what are the relations
between them.
In precise terms, a domain model is a system of abstractions that describes
selected aspects of a sphere of knowledge, influence, or activity (i.e. a domain
[Evans 2006]). Examples of domains are: banking, medical insurance, drone
control, potato farming, etc.
The model can then be used to solve problems related to that domain. In
software terms, the domain model is a software representation of meaningful
real-world concepts pertinent to the domain that need to be modelled in software to be used in software engineering processes. The most simple manifestation of these concepts are the data involved in the implementation of datatypes
for programs.
A domain model generally uses the vocabulary of the domain so that a
representation of the model can be used to communicate with non-technical
stakeholders. Here the maxim follow the names! applies.
In terms of software engineering, the domain model is generally implemented as an object model. In the Unified Modeling Language (UML), a class
diagram is the central element used to represent the domain model. Figure 1
shows an example of a class diagram used for the capture of a domain model
in the domain of health insurance plans.

Domain models can be captured in any other language english, math,

C++, etc. and not necessarily in UML. Glossaries in monographs are a good
example of domain models.

Figure 1: Sample domain model for a health insurance plans domain.

Figure 1 is an example of a domain model for the health insurance plans
domain. We can think of health insurance plans as an area of knowledge,
activity or software applications, i.e. a domain. If we work in this domain we
will be always speaking about health plans, subscribers, hospitals, benefits,
etc. Some of these domain concepts and some of their relations are captured
using the syntax of the UML class diagram. This diagram is composed of boxes
concepts and lines relations and can be read as a text in any other
language. This diagram says things like this: An insured is enrolled in one or
more health plans.
In the following section, a more elaborated domain model of another domain the Hospital is presented. This model is captured in three diagrams: Organization, Wards and Treatments. These can be considered three
subdomains of the hospital domain.

A Hospital Domain Model

This is an example of a hospital domain model diagrams. The domain model

for the Hospital Management System is represented by several class dia-

grams. The purpose of the diagram is to show and explain hospital structure,
staff, relationships with patients, and patient treatment terminology.
On the diagram below a Person could be associated with different Hospitals,
and a Hospital could employ or serve multiple Persons. Person class has derived attributes name and homeAddress. Name represents full name and could
be combined from title, given (or first) name, middle name, and family (or last)
name. Patient class has derived attribute age which could be calculated based
on her or his birth date and current date or hospital admission date.
The Patient class inherits attributes from the Person class. Several inherited
attributes name, gender, and birthDate are shown with prepended caret
symbol (new notation introduced in UML 2.5).

Figure 2: Hospital organization domain model - Patient, Hospital, Staff - Operations, Administrative, Technical.
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. Diagram below shows it using {id} modifier for wards name.
Wards are differentiated by gender of its patients, i.e. male wards and female
3

wards. A ward can only have patients of the gender admitted to it. Gender is
shown as enumeration. Ward and patient have constraint on Gender.
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 organised into teams (also called firms). Each
team has a unique name or code (e.g. Orthopaedics or Pediatrics) and is headed
by a consultant doctor (in the UK, Republic of Ireland, and parts of the Commonwealth) or attending physician (also known as staff physician) (in the United
States). Consultant doctor or attending physician 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 could be a member of no more than one team.

Figure 3: Hospital wards, teams of doctors, and patients.

Each patient is on a single ward and is under the care of a single team of
doctors. A patient may be treated by any number of doctors but they must
all be in the team that cares for the patient. A doctor can treat any number
of patients. The team leader accepts ultimate responsibility, legally and otherwise, for the care of all the patients referred to him/her, even with many of the
minute-to-minute decisions being made by subordinates.

Figure 4: Domain model - Patient, Doctors and Treatments.

The Task

As was said at the beginning, the purpose of this exercise is the construction
of a domain model for the MiniDrone Domain (i.e. the domain of drones
controlled by software using the MiniDrone framework). This is a domain of
relevance for our Software Engineering project.
Steps to follow:
1. Read -if not done before- the article on MiniDrone by Sanchez-Lopez
[Sanchez-Lopez 2015].
2. Learn about UML class diagrams.
3. Create a class diagram to capture the MiniDrone Domain using Papyrus
UML.
4. Prepare a single PDF with the diagram(s) and any explanation that you
consider relevant to understand them.
5. Upload to Moodle.
The objective of the task is to explore the process of domain modelling of
the drone/MiniDrone domain using UML class diagrams. It is not an objective
to achieve a complete model. However, if properly done, this model can be a
basis for future team/project modelling efforts.
Consider that this model can be later be used in the generation of a design
model of the system-of-interest, i.e. the MiniDrone Demo Application.

References

Evans, Eric Domain-Driven Design: Definitions and Pattern Summaries. Domain

Language Inc. 2006.
OMG. OMG Unified Modeling LanguageTM (OMG UMLTM ) Specification 2.5. 2015.
Sanchez-Lopez, Jose Luis, Pestana, Jesus, de la Puente, Paloma and Campoy,
Pascual. A Reliable Open-Source System Architecture for the Fast Designing and
Prototyping of Autonomous Multi-UAV Systems: Simulation and Experimentation.
2015.

UML Class Diagram Summary

Figure 5 contains a summary of the main class diagram elements that are commonly used in capturing a domain model using an UML class diagram.

Figure 5: A domain model using a class diagram: classes, interfaces, associations, usage, realization, multiplicity . . .

A Glimpse on Papyrus UML

Figure 6 contains a screen capture of Papyrus while editing an UML class diagram.

Figure 6: Papyrus screen shot.