An Introduction to Class Modelling
using UML
(Unified Modelling Language)
Written by: Robin Beaumont e-mail: robin@organplayers.co.uk
Date last updated: Friday, 29 May 2009
Version: 5
Health Informatics
Class modelling with UML
How th is d ocu m en t sh o u ld b e u s ed :
This document has been designed to be suitable for web based and face-to-face teaching. The text has been made to
be as interactive as possible with exercises, Multiple Choice Questions (MCQs) and web based exercises.
If you are using this document as part of a web-based course you are urged to use the online discussion board to
discuss the issues raised in this document and share your solutions with other students.
Wh o m th i s d o cu m en t i s ai m ed at:
This document is aimed at three types of people:

Those who wish to become involved in systems development but are not interested in the nuts
and bolts of programming. Such people are commonly called domain experts and act as bridges
between a professional group (e.g. medics, Solicitors etc) to which they belong and IT experts.

Those just beginning professional computer science courses.

Those who wish to become involved in some form of analysis activity. This might be Process re-engineering
or Data flow analysis etc.
I hope you enjoy working through this document.
Robin Beaumont
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 2 of 53
Health Informatics
Class modelling with UML
Contents
1
BEFORE YOU START ............................................................................................................................................ 5
2
LEARNING OUTCOMES -UML CLASSES/INSTANCES ............................................................................................ 6
4
BACKGROUND .................................................................................................................................................... 7
4.1
WHY LEARN ABOUT CLASS DIAGRAMS?........................................................................................................................ 7
EXERCISE 1. MCQS.............................................................................................................................................................. 8
5
INTRODUCTION................................................................................................................................................... 8
6
OBJECT ORIENTED APPROACHES AND UML ........................................................................................................ 9
7
CLASS INSTANCES ............................................................................................................................................. 10
8
CLASSES ............................................................................................................................................................ 11
8.1
DEFINED BY CONTEXT ............................................................................................................................................. 12
8.2
PRESENTATION IN UML .......................................................................................................................................... 13
EXERCISE 2. MCQS............................................................................................................................................................ 14
EXERCISE 3. CLASSES AND INSTANCES .................................................................................................................................... 16
EXERCISE 4. UML CLASSES AND INSTANCES ............................................................................................................................ 16
EXERCISE 5. MCQS............................................................................................................................................................ 17
8.3
IDENTIFYING CLASSES ............................................................................................................................................. 18
8.3.1
Analyzing a Narrative Description to identify candidate classes .............................................................. 18
EXERCISE 6. MARKING NOUNS............................................................................................................................................. 18
8.3.2
Developing candidate Classes ................................................................................................................... 20
EXERCISE 7. IDENTIFYING CLASSES FROM A NARRATIVE ............................................................................................................. 21
8.3.3
Applying naming standards to Classes ..................................................................................................... 21
EXERCISE 8. APPLYING GUIDELINES TO CLASSES ....................................................................................................................... 21
8.3.4
Workshops ................................................................................................................................................ 22
8.4
DRAWING UML CLASS DIAGRAMS - CASE TOOLS.......................................................................................................... 22
8.5
CLASS DIAGRAMS AND AMOUNT OF DETAIL SHOWN .................................................................................................... 22
8.6
VIEWS ................................................................................................................................................................. 22
EXERCISE 9. MCQS............................................................................................................................................................ 23
EXERCISE 10. DIFFERENT VIEWPOINTS ................................................................................................................................... 23
8.6.1
Warning about the ‘is a Kind of’ Situation ................................................................................................ 23
8.7
CLASS DIAGRAMS AND DATABASES ............................................................................................................................ 24
8.7.1
The Relationship between Classes/Instances to Databases...................................................................... 24
EXERCISE 11. LINKING CLASSES AND INSTANCES TO DATABASES.................................................................................................. 25
8.7.2
Specifying data types ................................................................................................................................ 25
8.8
OPERATIONS ......................................................................................................................................................... 25
8.9
SUMMARY - IDENTIFICATION OF CLASSES .................................................................................................................... 26
EXERCISE 12. MCQS.......................................................................................................................................................... 26
EXERCISE 13. INAPPROPRIATE ATTRIBUTES.............................................................................................................................. 24
9
LINKING CLASSES .............................................................................................................................................. 28
10
LEARNING OUTCOMES .................................................................................................................................. 28
11
UML ASSOCIATIONS ...................................................................................................................................... 29
11.1 MULTIPLICITY........................................................................................................................................................ 30
EXERCISE 14. ASSOCIATIONS................................................................................................................................................ 30

11.2 AGGREGATION AND COMPOSITION
................................................................................................................... 31
EXERCISE 15. AGGREGATION AND COMPOSITION..................................................................................................................... 31
11.3 TERNARY ASSOCIATIONS .......................................................................................................................................... 32
11.3.1 Breaking Ternary associations into Binary ones ....................................................................................... 33
11.4 RECURSIVE ASSOCIATIONS ....................................................................................................................................... 36
11.4.1 Association End Names ............................................................................................................................. 36
EXERCISE 16. MCQS.......................................................................................................................................................... 37
12
12.1
MAPPING ASSOCIATIONS TO DATABASES ..................................................................................................... 38
ONE TO MANY RELATIONSHIP .................................................................................................................................. 38
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 3 of 53
Health Informatics
Class modelling with UML
EXERCISE 17. CONVERTING CLASSES/INSTANCES TO TABLES/RECORDS ......................................................................................... 38
12.2 MANY TO MANY RELATIONSHIP ............................................................................................................................... 39
EXERCISE 18. MCQS.......................................................................................................................................................... 39
EXERCISE 19. IDENTIFYING FOREIGN KEYS AND ASSOCIATIONS..................................................................................................... 40
13
THE MEANING OF RELATIONSHIPS (SEMANTICS) .......................................................................................... 42
14
INHERITANCE ................................................................................................................................................ 42
14.1 GENERALISATION SETS ............................................................................................................................................ 43
14.2 CONSTRAINING SUBCLASSES .................................................................................................................................... 43
14.3 INHERITANCE - HOSPITAL EXAMPLE ........................................................................................................................... 45
EXERCISE 20. GENERALISATION/INHERITANCE ......................................................................................................................... 45
15
ENCAPSULATION ........................................................................................................................................... 46
EXERCISE 21. MCQS.......................................................................................................................................................... 46
16
POLYMORPHISM ........................................................................................................................................... 47
17
LARGER MODELS AND USING CASE TOOLS .................................................................................................... 47
17.1 PACKAGES ............................................................................................................................................................ 47
17.2 STEREOTYPES ........................................................................................................................................................ 48
EXERCISE 22. DEVELOPING PACKAGES.................................................................................................................................... 48
18
EXERCISES ..................................................................................................................................................... 49
EXERCISE 23. DEVELOPING A CLASS DIAGRAM FROM A NARRATIVE .............................................................................................. 49
EXERCISE 24. DEVELOPING A CLASS DIAGRAM FOR A LOGBOOK................................................................................................... 49
EXERCISE 25. DEVELOPING CLASS DIAGRAMS AS A GROUP EXERCISE ............................................................................................ 50
OPTIONAL EXERCISE 26. DEVELOPING CLASS DIAGRAMS FOR PATIENT ADVICE LEAFLETS .................................................................. 50
19
SUMMARY .................................................................................................................................................... 51
20
REFERENCES .................................................................................................................................................. 51
21
WEB LINKS .................................................................................................................................................... 52
You can see Youtube videos of
www.youtube.com/theoldorganplayer
the
concepts
Robin Beaumont robin@organplayers.co.uk
discussed
08/02/2016 Document1
in
Page 4 of 53
this
document
at
Health Informatics
Class modelling with UML
1 Before you start
This document assumes that you have the following knowledge and skills:
Skills/ knowledge:
You should be able to explain and provide examples of the following database concepts:

table,

record,

index,

foreign key,

relation, one to one, one to many, many to many
If you are unsure of what these terms mean and are unable to provide examples, read through:
http://www.robin-beaumont.co.uk/virtualclassroom/chap7/s2/dbcon1.pdf - provides details of what a table, record
and index are.
http://office.microsoft.com/en-us/access-help/database-design-basics-HA001224247.aspx - Microsofts Database
design basics page, goes further than you need but provides a good section on relations and how they work.
Required Resources
You need the following resources to work through this document:

The “Scenarios for practicing modelling techniques” handout available
from http://www.robin-beaumont.co.uk/virtualclassroom/contents.htm and follow the links

A UML case tool - Many of the concepts introduced in this document are difficult to grasp at first and are helped
by experimenting with a Case Tool in addition to carrying out the exercises with pen and paper. Two such tools
are Visual UML and MagicDraw. You can download a community version of MagicDraw at
http://www.magicdraw.com/. In addition if you are reading this document as part of a course you are
undertaking with the Royal college of Surgeons (Edin) or Edinburgh University you are registered as part of the
academic programme for Magicdraw which means you are entitled to use the full personal edition of MagicDraw.
To be able to use the full personal edition you need to contact your course administrator who has the codes to
unlock MagicDraw.
You can see Youtube videos of
www.youtube.com/theoldorganplayer
the
concepts
Robin Beaumont robin@organplayers.co.uk
discussed
08/02/2016 Document1
in
Page 5 of 53
this
document
at
Health Informatics
Class modelling with UML
2
Learning Outcomes -UML Classes/Instances
This section aims to provide you with the following skills and information. After you have completed it you should
come back to these points, ticking off those you feel happy with.
Tick
box
Learning outcome
Be able to describe the main characteristics of object oriented modelling

Be able to provide brief details of the relationship between OMT and UML

Be able to describe briefly the history of UML

Be able to describe what an instance is, as used in object oriented (OO) modelling

Be able to describe the three parts of a UML class

Be able to describe the two parts of a class instance (often called an object)

Be able to explain the difference between a UML class instance and a UML class

Be able to describe misunderstanding between UML classes/instances and the 'is a type of' concept

Be able to discuss the importance of context in identifying UML classes

Be able to produce a list of candidate classes from a narrative description

Be able to use Rumbaughs criteria to help refine an initial list candidate classes

Be able to use Reingruber & Gregorys criteria to standardise class names

Be aware of the use of workshops and informal class diagrams to develop UML class diagrams in a group
setting

Be able to identify and draw classes and instances using the UML notation

Be able to explain the relationship between classes, attributes instances, tables, records and fields

Be able to describe the varying amount of detail that can be displayed in a class diagram

Be able to discuss the concept of “view” as it relates to class diagrams


Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 6 of 53
Health Informatics
Class modelling with UML
4 Background
In the past 30 years the profession of systems analyst (modeller) has come into being and developed rapidly. The first
modelling techniques focused on designing databases, and for an enthralling description of the development of the
first computer system, along with its database, for Lyons teashops in the 1950's See Georgina Ferry's excellent book, A
computer call Leo.
In the 1970's by Peter Chen who is very much still alive and continues to produce important research
(http://www.csc.lsu.edu/~chen/chen.html) developed a diagrammatic description of certain aspects of the data
requirements for a database. The diagram was called an Entity Relationship Diagram (ERD) and is still used today , you
may have come across it when using Microsoft Access. The example below shows an example from a database to
collect research data from those who suffer from diabetes and are also pregnant. It represents the data at a high level
of abstraction meaning that it is not necessary to show details of the various fields or indexes, just the table names
(i.e. entity types) and optionally the field names.
Table name=
entity type
Field names
Relation
For more information about ERDs see: www.robin-beaumont.co.uk/virtualclassroom/chap11/s9/erds_1.pdf
While ERDs are useful they are limited and a more modern approach is to use Class diagrams, this more modern
approach is what we will concentrate on in the rest of this chapter.
4.1
Why learn about Class Diagrams?
This chapter, along with and several subsequent ones, focus on getting you to learn what class diagrams are and how
to produce them. You may ask why, so here are a few reasons I believe it is important for you to do so:

These diagrams form the basis of most database design methods. If you ever are involved in database design
(i.e. data modelling) you will therefore need to understand them because if they are wrong (i.e. the
blueprint), the database that is built from them will also be wrong!

These diagrams can be transformed to the more traditional ERD to create databases.

These diagrams provide a method of analysing a situation that forces you to adopt a stance of a typical
database modeller. By using them you begin to realise how their minds work and also begin to appreciate
why some databases are so problematic.
These are only a few of the reasons that I personally believe this skill is so important.
Even if you do not intend to become a programmer or systems analyst/modeller you may want to become the type of
person who is able to provide a bridge between your professional group – such as doctor, vet or solicitor – and those
who develop or manage information systems. Such people are vitally important in developing usable information
systems and there is a great shortage of them. Such a person is often referred to as a ‘Domain Expert’ or subject
matter expert (SME)
Before you start to learn what class diagrams are and how to create them yourself there are some Multiple Choice
Questions (MCQs) on the next page to see how much you have taken in so far.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 7 of 53
Health Informatics
Class modelling with UML
Exercise 1. MCQs
1. From the list below choose two reasons why it is important for a ‘domain expert’/subject matter expert (SME)such
as you to learn about the Class diagramming method:
a. Provides insight into the mindset of database developers
b. Is the only method available to describe the data requirements
c. Provides credibility to IT personnel
d. Forms the basis of most data modelling techniques
e. Has been proved to be the most cost effective method of specifying data requirements
2. From the list below choose the one option that describes the most desirable ‘domain expert’ from the medical
profession:
a. Someone who has developed several databases but knows little of database modelling or current issues in
medicine
b. Someone who has little interest in how information may help the department
c. Someone who has problems working in a collaborative environment
d. Someone who has previously managed IT projects
e. Someone who has knowledge of data modelling techniques and currently works in the appropriate situation
1. ERDs provide a description of (one correct answer):
a. The processes that occur in the model
b. The various entity types and their relationships in the model
c. The entity types in the model
d. The processes and data requirements of a model
e. The User Interface aspects of the model
2. ERDs provide a (one correct answer):
a. A detailed description of the data within a data model
b. A detailed description of the proposed uses of a database
c. A guide to the training costs
d. A high level description of the data within a data model
e. A graphical picture that is of little use in developing a database
5 Introduction
The process of designing any system, whether it be computer, paper or person based or a mixture of all three, consists
of specifying two important aspects, the what (data - structure) and the how (what it does - behaviour). Considering
the How aspect, a system is worse than useless if it either is difficult to use (e.g. for entering or retrieving information)
or hinders rather than facilitates working practices. For example, if a system is planned to be used in a medical
consultation it should be easier rather than more difficult to prescribe and allow the users to collect data in the way
they would find natural. While this How aspect is as important as the data side of things, we will concentrate on the
'what' side of things in this document.
You may be familiar with ERDs, a graphical technique for specifying the what. However in this document we will be
looking at a more advanced diagramming technique to produce diagrams explaining the What, namely UML Class
diagrams. These diagrams are one aspect of ‘object oriented’ modelling techniques that have developed over the last
few decades. Basically the Object oriented approach allows more complex models to be developed than previously
possible. Before we consider the UML Class diagram in detail we will take a quick look at object oriented modelling
techniques in general and UML.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 8 of 53
Health Informatics
Class modelling with UML
6 Object Oriented Approaches and UML
In the early 1990s Rumbaugh as well as M Blaha et al developed a modelling process called OMT (Object Modelling
Technique) which was documented in a book by them called Object-Oriented Modelling and Design, Prentice Hall
1991. This book has taken on the status of a classic and is still available although they have published what can be
considered to be an update to this in 2005 – Object Oriented Modelling with UML .
So what are Object Oriented Modelling techniques and how do they relate to this thing called UML? Object oriented
modelling relies heavily upon the following five ideas (concepts), which allow us to model aspects of the world in a
logically consistent manner. Notice this is much wider than just database modelling:





Classes and Objects
Association
Inheritance
Encapsulation
Polymorphism
Object Oriented
Techniques
OMT -> UML
In this chapter we will concentrate on the first aspect, although we will have a glance at the others in passing. So how
does UML relate to Object Oriented Modelling? The answer is basically historical.
In 1998, Rumbaugh joined forces with Grady Booch and Ivar Jacobson, who also have their own Object Oriented
Modelling languages, to create a Unified Modelling Language (UML). That year saw a burst of activity with several
books being published describing UML (Fowler & Scott 1998, Blaha & Premerlani 1998), UML not only subsuming
Rumbaugh's OMT but also expanding it with new diagrams. Since this time UML has gone through a number of
revisions with the most recent being version 2.4 (Around May 2011). I have therefore decided not to discuss OMT and
the earlier versions of UML. The specification of the latest version of UML can be found at http://www.omg.org/.
UML is definitely the "in thing" and if you look in any computing/ modelling/system development section of most
large bookshops you will find a row of books about UML. Three that I would recommend are:
Simon Bennett, John Skelton, Ken Lunn, 2005 UML: Schaum’s outlines. ISBN 0-07-710741-1 £10.99 [A much improved second edition – no cd but
what can you expect at this price]
Thomas A Pender: 2002 UML Weekend crash course. ISBN 0-7645-4910-3 [Also contains a CD with a pdf version of the book and a 15 day demo
version of System Architect version 8.5 Costs about £15 – 20]
Class
These diagrams focus on
specifying the structure
(WHAT) of the model
Diagram
Component
Diagram
Composite
Structure
Structure
Diagram
Diagram *
Deployment
Diagram
Object
Diagram
Package
Diagram
Diagram
Activity
These diagrams focus
on specifying the
Behaviour (HOW) of
the model
Diagram
Sequence
Use Case
Diagram
You can get second hand copies of the above books for far less by
looking
on
www.addall.com,
www.Amazon.com
and
www.amazon.co.uk Only the Bennett books talks about uml2 in
detail.
UML provides a standard set of tools (most of us would call these
diagrams – but the UML people get upset if you reduce them to
such things!) for analysing and developing a model using an Object
Oriented Approach. UML is not a method, you are free to use
which tools (diagrams) you feel are appropriate and at the
appropriate points you decide during the process. However this
does not mean there is no relationship between the various
diagrams; one of the most important aspects of a CASE TOOL is
how it manages the relationships that exist between them as
specified in the UML. Few if any modellers use all the diagrams; it
depends upon the specific project and the personal preferences of
the modeller.
Diagram
Communication
Behaviour
Diagram
State Machine
Diagram
Diagram
Interaction
Overview
Interaction
Diagram *
Diagram
Timing
Diagram *
Fowler 2004, p.12 has a nice diagram showing the various
diagrams in UML (version 2) taken from the formal UML
specification document; the greyed out boxes represent the
classification of the diagrams. In UML version 2 there was 13
different diagrams, and now in UML2.4 14 diagrams:
In this and the following chapter we will focus on the Class
diagram, probably the most important diagram in UML. But to help
you understand what classes are we will look briefly at class
instances (Objects) first.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 9 of 53
Health Informatics
Class modelling with UML
If you want a quick overview of UML and the various diagrams see:
http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/intro_rdn.pdf or http://www128.ibm.com/developerworks/rational/library/769.html Please note that both these sites by providing a very
superficial overview make many technical errors - but they do provide a starting point.
7 Class instances
So what is a class instance in the context of 'object oriented modelling'?
A class instance (often called an object in UML but I avoid this term) is best thought of as a definable thing with a
number of facets that results in us perceiving it as something that is distinct.
What are these facets? well in biology people often talk about something having form and function, we can think of
the 'descriptive' side of things as being data (e.g. a person having a name, age, hair colour and address etc) and the
'function' side of things as being activities (e.g. washing hair, giving birth, going shopping etc). Moreover, the data
(structure) and activities (behaviour) are inextricably linked in our conceptualisation of the instance. If the instance
should change either its activities or characteristics it exhibits, we feel distinctly uneasy. In other words, when we
conceptualise an instance in the world, we do not naturally divide it out into these two aspects. To do this requires
skill.
For example, when we see something we like, we tend to think of both actions as well as its characteristics (data),
when one thinks of a banana or a bowl of soup, not only do both have pleasant characteristics such as colour and
smell but they also have pleasant actions associated with them such as the soup being made (created, the default
operation all instances possess) and eaten, and the banana growing and ripening, thinking of something more
complex such as a Person, instances of this would be far more complex..
Class instances - Objects - UML 2.4
Attribute names typically begin
with a lowercase letter. Multiword
names are often formed by
concatenating the words, each
subsequent word starting upper
case
instance name:class name
In uml v1.4 onwards you do not show the
operations compartment in class instance
diagrams
(see Pender 2002 p142)
Attributes=value
No spaces &
underlined
Examples:
mySoup:Soup
id:84739
mary:Person
Class name capitalised
instance name lower case
country of origin=uk
age=20yrs
hair=grey
washing hair=yes
shopping=no
eating=No
flavour=good
john:Person
myBanana:Banana
age=34yrs
hair=Brown
washing hair=No
shopping=No
eating=yes
decomposing=no
age =21 days
variety=Costa rican yellow
flowering=no
growing= no
moving= no
Each of these characteristics
has a value = therefore this is an
instance
each attribute+value is
called a slot
From the above we can say that we have two instances of class, Person and one each of class banana and soup. So we
can have any number of instances for a particular class.
In the context of 'instance modelling' a class instance is therefore something in the investigator's mind that usually
possesses a recognisable number of both characteristics (data consisting of data items) and actions. As in all areas of
computer science, one word is never enough; and UML uses the word 'attribute' instead of data or characteristic.
The diagram above shows how class instances are drawn in UML. Each class instance is divided into two sections:


The top box gives the name of the class instance along with its class name
(more about that below).
The bottom section lists each attribute along with its value, where each line is called a slot.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 10 of 53
Health Informatics
Class modelling with UML
All the above examples of class instances indicate that the attributes have values suggesting that the class instance
exists in some way and because of this it often means class instances are called ‘real world things’ but this can be
misleading.
If you know about ERD diagrams you may be thinking that the concept of a class instance is very similar to that of an
Entity Instance. In fact you would not be far from wrong; however, the class instance concept also has the concept of
Operations within it, they are just not shown in the instance diagram.
In the above section we have discussed instances of Classes now we will investigate the actual Class concept..
8 Classes
The best way to think of a class is to think of the blueprint idea. A class is often called a concept, although
philosophers argue about the differences. Many theorists have provided complex definitions of a class or entity type,
which is a similar idea, but none are complete or infallible. Hopefully by
Banana
the end of this section you will be able to conceptualise what a
A Class
class is in this context even if you still won't be able to provide a
age
definition
for it.
variety
flowering
Chen, one of the early writers (circa 1970), felt that the task of class identification (he
growing
was talking about 'entity types' at the time, as instance modelling had not been
moving
developed) was best left to the individual who was within, and who knew most about,
flower()
grow()
move()
the system to be modelled. This suggests that classes are partially dependent upon
the person who is identifying them, and this will become clear as you work through
this section. The domain expert / subject matter expert (SME) plays a vital function
between the end user and IT/ programmers defining and correctly modelling classes.
What then is a class? A class can be thought of as an abstraction from the instance. Notice that in the examples
concerning instances a single banana was described. The instance 'mybanana' is said to be an instance of class
banana. Similarly John is said to be an instance of class Person and “mysoup” an instance of class soup. Notice that
while the class person could exist without any instances, the reverse is not true. We say that an 'instance' is an
'instantiation' of a class. This may appear rather pedantic but it is very useful in modelling as it provides a method of
classifying groups of things often in very useful ways.
Basically:

Class = Template

Instance = Example of a particular class
All instances of a particular class must have the same structure
as the class
The rest of this section will be concerned with identifying and organising Classes.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 11 of 53
Health Informatics
Class modelling with UML
8.1 Defined by context
Below are some examples of classes and instances for three different contexts:
A typical general practitioner planning on collecting information about patients:
Class
Some possible instance(s):
Doctor
Name=Angus Wallace. Residence= living in the UK
Patient
Name=Joe Bloggs, Town=Newcastle ,
Name=Alan Smith, Town= London
Visit
Time=12/06/2001/4pm location+Prospect House Newcastle
Prescription
Drug=Valium, dosage=5mg. Frequency= eight times a day
Advice leaflet
Title=Chronic back pain leaflet
Title=UTI self management
The university administrator thinking about developing a course database:
Class
Some possible instance(s):
Module Coordinator
Name=Robin Beaumont,
Name=Joe Brand
Student
Name=Paul Whatling
Name=Mary Brown
Name=Anne Smith
Tutor
Name=Ruth Brown
Module
Title=Introduction to Informatics, year=2003
A garage collecting detailed information about car components:
Some possible instance(s):
Class
Spark Plug
Make=Rover, model=49532
Engine
Escription=122 Brake Horsepower
Cooling system
Capacity=17 pints
Gearbox
Second gear ratio= 7.55:1
Propeller shaft
Type=Hardy Spicer
Are the above examples correct?
While the above examples probably list a selection of the important classes for each of the contexts, there is no
absolute way of being able to say they are correct. Rumbaugh et al (1991, p21) makes this important point when
discussing class identification:
“We define a class as a concept, abstraction, or thing with crisp boundaries and meaning for the problem at hand.
Classes serve two purposes: they promote understanding of the real world and provide a practical basis for computer
implementation. Decomposition of a problem into classes depends on judgment and the nature of the problem. There
is no one correct presentation.” [edited slightly]
This is clear from considering the last example concerning car component details. Assume that another garage owner
who was less concerned with collecting detailed information about each component only wanted one item of
information recorded for each component. In this instance we would probably have CAR as the class and each of the
classes listed above relegated to attributes of the CAR class. There is no definitive correct answer; we only know by
talking to the actual garage owner. Classes are largely defined by the context.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 12 of 53
Health Informatics
Class modelling with UML
8.2 Presentation in UML
Computer scientists, whenever possible, use diagrams or symbols rather than words. This is because words are
considered to be the most ambiguous form of communication or more probably because most computer scientists are
notoriously poor at English. The diagram below shows how UML would possibly represent several of the classes
described previously:
In the diagram each box represents a class. The box is divided into three sections. The top section of the box provides
the name of the class, usually a noun. The next section down provides details of the data (attributes or data items) in
the class while the last and final section provides names of the activities (methods) that make up the class. While the
first two examples -- Person and Banana -- are relatively easy to define in this way, the third is more difficult. This is
probably because Soup has a large number of attributes but has very few activities. The only one l could think of,
besides the generic ‘create’ which all classes have, how else would you create instances? is the process of
decomposing when it's left too long, possibly ‘heat up’ might be another. Not all classes have actions (other than the
generic ‘create’ and 'destroy'), but all must have a name and something that uniquely distinguishes them from
another class. Because instances are just instances of a particular class, these rules apply to them as well.
In this chapter we will concentrate on class diagrams rather than instance diagrams; these being more general, they
tend to be more useful. However, instance diagrams are useful if you want to investigate a particular situation.
Classes (UML 2.0)
characteristics
Class name
Class name capitalised
Not underlined
Attributes: (data items)
Operations
behaviour
Examples:
Person
Banana
Soup
age
hair
washingHair
shopping
eating
age
variety
flowering
growing
moving
id
country of origin
flavour
decomposing
washHair()
shop()
eat()
flower()
grow()
move()
decompose()
Attribute names typically begin with a lowercase letter.
Multiword names are often formed by concatenating
the words, each subsequent word starting upper case
UML2.0 infrastructure specification p.121 adapted
If you know about ERD diagrams you may be thinking that classes and Instances (instances) are the same as Entity
Types and Entity Instances however Classes and instances are far more complex because they possess operations as
well as attributes.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 13 of 53
Health Informatics
Class modelling with UML
We will now take a specific example, assume that we have decided to propose that a valid class would be one named
Doctor firstly we need to consider if this is a valid class, again context comes into play if we were creating a model for
a general purpose employment agency we would probably have a more generic class such as client, with thewre
profession as an attribute in the class, however if we were modelling a GP practice or hospital we would have Doctor
as a specific class. Assuming we have the latter situation:
Doctor
Why is this a class?
surname
forename
dob
GMC_no
salary
gender
examine
question
diagnose
request_test
Because it as a name
Because it has a set of unique attributes i.e. surname, forename, date of birth, GMC
number, salary, gender etc.
And a unique set of operations i.e. examine, question, diagnose, request test etc.
Why is this a class rather than an instance?
Because it possesses these attributes and operations but they do not have specific values
'Unique' here means different from any other class in the model
Sarah_smith:Doctor
Why is this an instance of the Doctor Class?
surname=smith
forename=sarah
dob=19/12/1956
GMC_no=39200456
salary=89K
gender=m
Because it has the same set of attributes as the doctor class i.e. surname, forename,
date of birth, GMC number, salary, age etc.
And each attribute has a specific value
Because it has the same set of operations as the doctor class (not shown in
instance/object diagram)
Another way of thinking about the bond between a class and instance is to think of the class as being the column
headings (= attributes + operation names) for a number of rows each of which is an instance of the class. For example
Doctor
surname
forename
date of birth
GMC number
salary
gender
examine
Request test
smith
Dow
19/12/1956
39200456
89K
male
yes
Blood for culture
Coates
Jill
03/05/1966
5748337
67K
female
no
Knee x ray
Worsley
Alan
11/07/1970
578493
80K
male
no
Barium enema
Six attributes shown
Two operations shown
Exercise 2. MCQs
1. Which one of the following is an example of a class:
a.
b.
c.
d.
e.
Robin Beaumont
Carrot
Date's book An Introduction to Database Systems on my shelf at home
Spike from the TV series "Buffy the Vampire Slayer"
My backup disk (in the second drawer of my desk)
2. Which one of the following is an example of an instance of a class:
a.
b.
c.
d.
e.
Course Manager
Health Informatics courses
Women
Tony Blair
Religion
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 14 of 53
Doctor class
with 3 instances
Health Informatics
Class modelling with UML
This is how I arrived at the answers for the exercise on the previous page
1. Which one of the following is an example of a class:
a.
Robin Beaumont could be:
First_name
robin
Tony
b.
Class / instances. Possible Class name: carrot
Germination_date
Seeding_position
manufacturer
04/09/2011
Plot4
thomsons
04/09/2011
Plot2
thomsons
Instances
taste
Honey sweat
sharp
etc
...
Spike from the TV series "Buffy the Vampire Slayer"
Class / instances. Possible Class name: buffy character
name
character
First appearance
James Marsters
spike
1997
Seth Benjamin Gesshel-Green
Seth Benjamin Gesshel-Green
1998
e.
etc
...
Date's book An Introduction to Database Systems on my shelf at home
Class / instances. Possible Class name: Book
name
author
publisher
date
UML for beginners
beaumont
Brewester_brown
01/02/2016
An intro to databases
date
wiley
??
d.
etc
...
Carrot could be:
Variety
Old_red
Tonys_special
c.
Attribute names
Class / instances. Possible Class name: person
surname
dob
Mobile_1
email
beaumont
12/05/87
0798675664
you@me.com
Milner
05/09/1967
0978675
tony@me.com
Last appearance
2003
2001
etc
...
My backup disk (in the second drawer of my desk)
Class / instances. Possible Class name:
name
size
manufacturer
Backup1
5.25
imac
My_backup_disk
3.25
dozik
Backup3
5.25
imac
Backup4
3.25
dozik
backup_disk
date
02/09/2010
10/09/2006
02/09/2010
10/09/2006
etc
...
So from the above only the carrot is at the class rather than instance level, the relevant entries are shaded yellow. A
similar approach can be taken to the second exercise
2. Which one of the following is an example of an instance of a class:
a.
b.
c.
d.
e.
Course Manager - This is probably a class with a name attribute.
Health Informatics courses - This is probably a class with attributes such as title, start_date etc
Women - This is probably a class with attributes such as gender, surname dob etc
Tony Blair - This is probably an instance of Human or Prime minister
Religion - This is probably a class with attributes such as name, leader, estimated number of followers etc
While the table format is nothing to do with UML it does help to understand the link between the class and its zero or
more instances
All instances of a particular class must have the same structure
as the class
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 15 of 53
Health Informatics
Class modelling with UML
Exercise 3. Classes and Instances
Spend five minutes filling in the tables below. List some possible classes along with examples of their instances. Some
of your classes may have no or several instances. The important thing is that each instance possesses the same set of
attributes as the entity type.
Class name:
Attributes names:
Attributes values:
Class name:
Attributes names:
Attributes values:
Class name:
Attributes names:
Attributes values:
Exercise 4. UML Classes and Instances
Part A
Consider your job to be a class. If you do not have a paid job, you may be a student for example, then use that instead.
List two of your (clinical) activities along with the information about them which you feel would be useful to collect. If
it helps, consider it in the context of a learning log book of some sort.
Part B
Draw a diagram that represents the following classes: community nurse, GP, clinical manager in a hospital, day care
coordinator, director of finance in an acute trust (hospital outside the UK), patient, yourself and your boss.
Part C
Draw an instance diagram that represents an instance of some of the classes you described in the above tasks.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 16 of 53
Health Informatics
Class modelling with UML
Exercise 5. MCQs
1. Which of the following provides the best description of a Class (select one)?
a. A specific concrete object with a defined set of processes (e.g. John Brown with diabetes)
b. A value given to a particular attribute (e.g. height - 230 cm)
c. A thing that we wish to collect data about where one or more, real world examples of it exist
d. A template for a group of things with the same set of characteristics that may exist in the real world
e. An undefined concept that needs further clarification
2. Which of the following provides the best description of a class instance (select one)?
a. A specific concrete object with a defined set of processes (e.g. John Brown with diabetes)
b. A value given to a particular attribute (e.g. height - 230 cm)
c. A thing that we wish to collect data about where one or more, real world examples of it exist
d. A template for a group of things with the same set of characteristics that may exist in the real world
e. An undefined concept that needs further clarification
3. From the following list, select two class instances:
a. Steinway piano model D design template
b. McGill type forceps as used in surgical operations
c. Tony Blair ( British prime minister)
d. PIII type chip that is found in many modern PCs
e. An advice leaflet for chronic back pain issued to Mrs Smith on 02/10/2002
4. Which one of the following statements is true (select one)?
a. A UML class diagram can only display class names.
b. Attributes are a rarely considered aspect of classes.
c. Attributes must always be displayed in UML class diagrams.
d. Attributes equate to table names in a database.
e. Attributes can optionally be displayed in UML class diagrams.
5. Select from the following the best list of attributes for the class SHOE for someone working in a shoe shop (select
one answer):
a. 1, 2, 6
b. 1, 2, 6, 3
c. 1, 2
d. 1, 6
e. 1, 2, 3, 4, 5, 6
6. Select from the following the best list of attributes for the class
RECIPE for someone following a recipe at home (select one):
a. 4, 5, 7, 8
b. 4, 5
c. 4, 5, 6
d. 4, 5, 8
e. 4, 5, 6, 8
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
1=size
2=number of lace holes
3=propulsion
4=cooking time
5=number of portions
6=material colour
7=volume (loudness)
8=cooking temperature
Page 17 of 53
Health Informatics
Class modelling with UML
8.3
Identifying Classes
While there is much written concerning UML and Class diagramming theory, far less has been written about actually
developing the models. Two of the most common ways of identifying classes for developing UML class diagrams are:

Narrative descriptions of requirements

Workshops
Both of the above methods rely to some extent on expert domain knowledge to identify and classify classes. We will
now look at the first method, using a narrative description of the system requirements on which to base the
development of a UML class diagram.
Rather than give a brief description of each stage and then visit each in turn, I will just take you on a journey and then
reflect upon what we will have done in a summary at the end. So now let’s start with the narrative description.
8.3.1 Analyzing a Narrative Description to identify candidate classes
Frequently the first thing to be produced when someone has the idea of developing a model (also called "the system"
or "database" below) is a paper document describing what he or she wants. This often includes something like the
following:
We wish to develop an information system for our hospital in which:
“Patients are treated in a single ward by the doctors assigned to them. Usually each patient will be assigned a single
doctor, but in rare cases they will have two. Patients either pay for their treatment directly or through an insurance
company.
Healthcare assistants also attend to the patients, and a number of these are associated with each ward.
Initially the system will be concerned solely with drug treatment. Each patient is required to take a variety of drugs a
certain number of times per day and for varying lengths of time.
The system must record details concerning patient treatment and staff payment. Some staff are paid part time, and
doctors and care assistants work varying amounts of overtime at varying rates (subject to grade).
The system will also need to track what treatments are required for which patients and when, and it should be capable
of calculating the cost of treatment per week for each patient.
When users use the system they will be able to print out as well as view on screen the results. (Although it is currently
unclear to what use this information will be put.) “
(taken from http://www.umsl.edu/~sauter/analysis/er/er_intro.html and expanded)
The first stage is to pick out all the nouns (names) in the above passage; this provides a good baseline from which to
consider possible entity types.
Exercise 6. Marking Nouns
Mark in the above narrative all the nouns (names) you see.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 18 of 53
Health Informatics
Class modelling with UML
You can see in bold below the possible set of nouns (names) that I have come up with:
“Patients are treated in a single ward by the doctors assigned to them. Usually each patient will be assigned a single
doctor, but in rare cases they will have two. Patients either pay for their treatment directly or through an insurance
company.
Healthcare assistants also attend to the patients, a number of these are associated with each ward.
Initially the system will be concerned solely with drug treatment. Each patient is required to take a variety of drugs a
certain number of times per day and for varying lengths of time.
The system must record details concerning patient treatment and staff payment. Some staff are paid part time and
doctors and care assistants work varying amounts of overtime at varying rates (subject to grade).
The system will also need to track what treatments are required for which patients and when and it should be capable
of calculating the cost of treatment per week for each patient.
When the users use the system they will be able to print out as well as view on screen the results. (Although it is
currently unclear to what use this information will be put.)”
(taken from http://www.umsl.edu/~sauter/analysis/er/er_intro.html and expanded)
Gathering together all the above nouns produces the following list, not in any specific order:
Candidate classes
Patients
System
Doctors
Users
Healthcare assistants
Cost
Care assistants
Time
Ward
Day
Drug treatment
Lengths
Drugs
Details
Patient treatment
Overtime
Treatment
Rates
Staff payment
Grade
Staff
Week
Insurance company
Results
Screen
Use
Information
Each of the above nouns can be considered to be a 'candidate class'. The next stage is to consider which of these are
appropriate classes to include in the UML class diagram. To do this we consider Rumbaugh et al (1991 p152-3,
repeated in Blaha & Rumbaugh 2005 p 185 -6) criteria.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 19 of 53
Health Informatics
Class modelling with UML
8.3.2 Developing candidate Classes
Rumbaugh et al (1991 p152-3, repeated in Blaha & Rumbaugh 2005 p 185 -6) provides some guidance as to how to
identify appropriate classes. He suggests that you consider the following issues:

Redundant class types Two class types may express the same information (i.e. two names for the same
concept, or synonyms). In the above example DOCTORS and HEALTHCARE ASSISTANTS (HCA) might be
considered to be just class instances of the class called STAFF; however, this is unlikely in the above example
because we know from our own expert domain knowledge that doctors are concerned with prescribing
whereas healthcare assistants are not, they therefore have different activities, furthermore some of the
attributes will be different, doctors possess a GMC number whereas HCA's do not. In addition the
information we plan to collect is specifically concerned with prescribing. We therefore consider the class type
STAFF to be redundant, at least for the time being; possibly when the system is developed further such
considerations can be re-visited.

Irrelevant class types If an class type has little or nothing to do with the problem, it should possibly be left
out. In the above example one would need to clarify with the person requesting the system if they need
information stored about INSURANCE COMPANIES. Also if the system is initially only concerned with drug
treatments, is there any point collecting information about other treatments?

Vague class types In a narrative description, often words are used indiscriminately. In the above example the
description states that “Initially the system will be concerned solely with drug treatment” yet the following
paragraphs refer to PATIENT TREATMENT and also TREATMENT. Are these three different class types or not?
Again we can only find out by discussing this issue with the person who requested the database. We would
probably suggest that we have two class types called DRUG TREATMENT and TREATMENT where TREATMENT
is concerned with information about any non-drug intervention and probably not included in the initial ERD.

Class types that are really attributes Often an initial class type is an attribute. In the above, COST has been
classified as a possible class yet it is probably an attribute of TREATMENT or DRUG TREATMENT or PATIENT
(renaming it BILL).

Multiple roles become class types "The name of a class type should reflect its intrinsic nature and not a role
that it plays. For example, OWNER would be a poor name for a class type in a car manufacturer's database.
What if a list of drivers is added latter? What about persons who lease cars? The proper class is PERSON (or
possibly CUSTOMER), which assumes various different roles, such as owner, driver, lessee." (Blaha &
Rumbaugh 2005 p 186). Similarly a doctor is not just a prescriber but a treatment giver and a reviewer of
results.

Implementation information The Class diagram is concerned with defining the data that needs to be stored.
It is not concerned with the hardware or processing of the data. Therefore, in the above example SYSTEM,
SCREEN and USER can be ignored. Similarly RESULTS are an outcome of processing data. Perhaps from your
knowledge of Access or other databases, you will realise that such things as RESULTS and reports are just a
process of using a query or report tool to interrogate the model.
Another type of problem occurs resulting from the existence of homonyms. This is where two classes with the same
name actually mean different things. For example the class TREATMENT may mean very different things to different
healthcare professionals. In this instance it may be necessary to add one or more additional class types to express the
different concepts more clearly (e.g. DRUG_TREATMENT, DIETARY_PRESCRIPTION and ART_THERAPY etc).
So what have we ended up with after all the above deliberations? The following is the revised list of class, for as very
simple first list which will obviously expand:
Patients, Doctors, Drug treatment, Drugs
By concentrating on the drug aspect of treatment and considering each of Rumbaugh’s guidelines we have reduced
the list from 27 to 4 for a possible initial UML class diagram.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 20 of 53
Health Informatics
Class modelling with UML
Exercise 7. Identifying Classes from a Narrative
Time: 60 minutes
Look through the DopeHead scenario, found in the scenarios handout, and:
1. Mark all the nouns and produce a list of them.
2. Using Rumbaugh’s guidelines revise your list to identify candidate classes.
8.3.3 Applying naming standards to Classes
While the previous page was concerned with identifying classes, we will now look at one of the many informal naming
standards suggested, this one is by Reingruber & Gregory 1994 (p65-77).
Class names:
Should be unique for the particular model. (This does not usually apply to attribute names which only need to
be unique to a particular class)
Should be a singular noun (e.g. PATIENT not PATIENTS).
Should be self-explanatory to those reading the UML class diagram.
Should follow any naming conventions locally defined by the modellers. For example, two common constraints
are that:
 They should be written in UPPER CASE.

Possible spaces should be represented by the _ character (eg DRUG_TREATMENT rather
than DRUG TREATMENT).
Should not be a name of an individual instance (e.g. Freeman Hospital Newcastle upon Tyne).
Should not express more than one concept (e.g. EQUIPMENT/BED).
Should be documented in addition to the diagram The description for each class should be clear, unambiguous
and supplemented with examples of instances.
When carrying out this process it is a good idea to draw up a table similar to the one below to make sure you carry out
the process, the initial proposed class type name on the left and the final class type name on the right.
Initial class
type name:
Unique
Singular
noun
Selfexplanatory
UPPER
CASE
The _
character
Not a
individual
object
Not more than
one concept
Documented
Final class
type name
Patients
Doctors
Drug
treatment
Drugs
Exercise 8. Applying standards to Classes
Time: 60 minutes
1. Looking back at the hospital example, consider the following four possible classes. Use the above guidelines to edit
them appropriately:




Patients
Doctors
Drug treatment
Drugs
2. Revisit the initial set of classes you defined for the DopeHead scenario and edit them accordingly. It may help to
draw up a table similar to the one above.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 21 of 53
Health Informatics
Class modelling with UML
8.3.4 Workshops
The alternative to using a paper document to partially derive a set of classes is to hold a series of interactive
workshops. This requires commitment, including the willingness to learn, from the person(s) who have requested the
system (i.e. database). They need to understand to a limited extent what you are learning now!
Often a mixed approach can be taken, using a paper document as the starting point, to a workshop. Running
workshops requires good group working skills, and must be carried out in a non-threatening manner. Often the
modellers need to show considerable tact when people get hung up on what the modellers themselves know to be
irrelevant issues (e.g. font size/colour, type of screen or computer etc) for the particular task at hand.
Now that we have looked at how to create an initial list of classes we will consider the actual mechanics of drawing
UML class diagrams
8.4 Drawing UML class diagrams - Case tools
It must be remembered that systems modelling, of which UML is one particular aspect, is a discipline that has only
been in existence for about a quarter of a century. I was recently looking at a book on systems analysis written in 1984
(Daniels & Yeates) and only 2 of the 300 pages was dedicated to a similar topic of databases, and within those two
pages no mention was made of diagramming.
To begin with learning to draw UML class diagrams is usually a pen and paper exercise and I would strongly encourage
you to practice using this simple technique at the start - be warned you'll also need a large rubber! Drawing informal
UML class diagrams and discussing them is a very good way of developing them in a measured and appropriate
manner, flip charts, or electronic white boards are excellent in this respect.
Other documents on my web site provide detailed tutorials on how to use specialised software (called case tools) to
draw UML class diagrams. http://www.robin-beaumont.co.uk/virtualclassroom/contents.htm
8.5 Class Diagrams and Amount of Detail Shown
In a uml class diagram, varying degrees of detail of a class
can be shown. Sometimes all that is shown is the class
name. Alternatively the class name and attributes are
shown, or alternatively both the attributes and operations
are shown.
Class name
Attributes
Operations
Can be dispayed
as:
Class name
or
8.6 Views
Class name
Attributes
or
Class name
Attributes
At the beginning of this document it was stated that the
identification and description of Classes/instances was
Operations
partly a matter of individual interpretation. This is clear
when one considers the examples given above. Now
considering the NHS, a patient as perceived by a hospital chaplain is a very different instance from that perceived by a
director of finance. If you asked each to draw a Class diagram like those given on the previous pages, each would
come up with a different set of data and activities.

A model is always context specific.

It is never purely a reflection of reality - whatever that is!
It is interesting to note that a large amount of effort in the modelling process is directed towards getting these
differing views consolidated in some way. The potential problem is tackled in different ways depending upon the
particular software development lifecycle chosen. Frequently a stakeholder or cultural/political analysis is carried out
to see how important each of the views are, thus allowing a way to prioritise one view over another. Another method
is used during the actual software development phase of the lifecycle where different views, or user interfaces, to the
data can be developed for different user types. These are just two of a whole host of techniques available to tackle
this problem. This concept of a view is similar to that of a 'semantic purpose’, which is described on page 22 of
Rumbaugh (both editions same page).
The importance of being aware of potential problems with differing views in the healthcare sector is discussed in:
Willcocks P L. Mark A L. (1989) IT systems implementation: Research findings from the [health care] public sector. J I T
[June] 92 – 103
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 22 of 53
Health Informatics
Class modelling with UML
Exercise 9. MCQs
1. Which of the following types of software (applications) is most suitable for developing UML class diagrams?
a. Desktop drawing package (e.g. Smartdraw)
b. Desktop publishing application to ease the use of textual explanations
c. Anything with drawing capabilities (e.g. Microsoft Word)
d. A CASE tool
e. A spreadsheet
Exercise 10. Different viewpoints
Describe what might be the main differences in viewpoints between some of the following:










community nurse
GP
clinical manager in a hospital
anaesthetist
day care coordinator
paediatrician
psychiatrist
microbiologist
director of finance in an acute trust
patient
You may want to devise some type of table to help you organise your thoughts.
8.6.1 Warning about the ‘is a Kind of’ Situation
To start with, people are often confused about the connection between classes and instances thinking that an
instance “is a kind of” class. An example will help to make this clearer. Someone might say that for the class ANIMAL
instances in this case might be BIRD or HUMAN. This is not usually the case. The reason for this is because thinking
about the structure, that is what attributes and behaviour you might want to collect about BIRDs and HUMANs would
probably be different in several respects for each of them. Would you really want to collect information about the size
of wingspan for a HUMAN or the IQ of a particular bird? In other words the set of attributes and operations for each
is different.
Unfortunately it is not always as simple as this. Here is the argument for keeping BIRD and HUMAN as instances of
HUMAN. Suppose you were an antique dealer and just wished to collect information about the instances of ANIMAL
statue you had. In this case you would probably just want to record the number of ANIMAL statues you had rather
than be animal specific, information in which the amount and type would vary for each. In this situation you are happy
about keeping the same type of information about each of the statues regardless of what they represent, probably
just species name would do for your attribute name. The context dictates what class types you will find.
Lest consider another example. This time assume we have a class called ??? with the following 5 instances with some
of the attributes shown. You will notice that you can divide up the instances into two groups based upon the empty
attributes. It look like we need actually two classes
Class = ???
here one for men and one for women? However
First_name Bra size Dress size Inside leg Date of birth Waist size
we do have a certain level of commonality between
Mary
aa
2
01/02/45
60
them with the First_name, Date_of_birth and
waist_size attributes.
John
90
23/12/67
89
Dave
86
10/10/68
103
Philip
110
14/08/98
98
26/04/78
70
Anne
d
14
We will learn latter that this 'is a kind of' situation
bed be very effectively modelled by using a
concept called inheritance in UML class diagrams.
Much more about this latter.
For now the take home message is each class in a UML diagram:
Has a DIFFERENT STRUCTURE (i.e. Different attributes and methods)
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 23 of 53
Health Informatics
Class modelling with UML
8.7 Tight coupling
From the above sections you will realise that each class has a distinct set of attributes and operations, not only it is
vitally important that each class is distinct from others in the model but the class must be a closely knit structure for
example a patient class should not have leakage from other classes in the model such as GP or APPOINTMENT in the
model below.
Exercise 11. Inappropriate attributes
Consider the following classes and mark the attributes you feel are inappropriate in each class.
Remember that the attributes in a class are those that define the class not aspects that may relate to it.
Model 1 - GP surgery
Model 2 Travel agency
8.8 Class diagrams and Databases
UML is often used, BUT NOT ALWAYS to develop computer systems and frequently these are databases. When people
first start developing databases they always make two fundamental errors. Firstly, they rush to a computer to play
with the DBMS (e.g. Access). Secondly, they believe they can create a perfect database by
Technical
Class Diagram
terminology:
specifying a model without creating a prototype of some sort.
=
Design Blueprint
Specify
(Data dictionary
database
Implement
It is vitally important to get the design right, but this involves many revisions resulting partly
from feedback from people using the actual database. For each iteration the Class diagram(s)
allow you to create a blueprint (model, specify, design, etc) of the data, and the DBMS allows
you to create (implement, develop, etc) the actual database.
In the diagram to the left, the data dictionary is shown as a half-way house between the
'high level' class model(s) and the actual database. Depending upon your inclination it is
often not necessary to produce a data dictionary as a detailed description of each instance is
adequate; it is basically up to you and whomever you may be working with. (See Blaha &
Premerlani 1998 for more detail.)
Again I must reiterate Class diagrams are not only used to develop databases!
8.8.1 The Relationship between Classes/Instances to Databases
If we accept the object oriented view of the world, databases themselves are also simply a collection of
classes/instances. More specifically a table is simply a way of allowing the computer, via a piece of software called a
DBMS (Database Management System, e.g. Access), to
Class:
Database table
store these classes/instances. This all sounds rather
Table name = Patient:
Patient
Class name
abstract, so I will now provide a example.
ID
First name
Surname
DOB
Etc.
Attributes
Patient ID
First name
Surname
DOB
Sex
Address
Operations
See doctor
The diagram opposite demonstrates the relationship
between the class Patient and a DBMS table structure.
mypatient2:Patient
Class name becomes table name (not always)
Attributes in class model = fields in database
Patient instances:
The attributes in the class diagram become fields in a table
where the table name is the same as the class name.
Taking this one step further, a class instance is equivalent to a
record in a table in the database.
Robin Beaumont robin@organplayers.co.uk
Id=214
fname=john
surname=smith
dob=01/01/55
gender=male
address=20 station st.
Doctorref=12345
…
…
mypatient1:Patient
Id=023
fname=Mary
surname=Allan
dob=21/11/65
gender=female
address=23 pink lane.
Doctorref=12345
…
…
08/02/2016 Document1
Page 24 of 53
Database table
Table name = Patient:
ID
214
023
First name
John
Mary
Surname
Smith
Allan
DOB
01/01/55
21/11/65
Class Instances become table records
attribute values = data items in database
Etc.
Health Informatics
Class modelling with UML
Exercise 12. Linking Classes and Instances to Databases
Spend a few minutes taking some of the classes / instances you have identified in the previous exercises and draw a
similar diagram to the appropriate one above.
8.8.2 Specifying data types
Fields in databases besides having a name also specify what type of data they store, for example it might be a number
of characters (called a string), a whole number (called an integer) or a true/false value
(called a Boolean) similarly in a uml class diagram you can specify the data type of individual
attributes providing an even greater degree of linkage between the UML class diagram and a
database structure.
8.8.3 Derived Attributes and Default values
Often in databases field (attribute) values are derived from other field (attribute) values and you can show this in UML
classes by using the forward slash(/) before the name, for
example say we have a derived attribute in the Patient class
called bmi (Body Mass Index) which is derived from two
other attributes in the class height and weight, the situation
opposite. Optionally you can add a note to the UML class
diagram to provide additional details, but I personally prefer
to add the detail to the narrative accompanying the diagram
as the diagram gets very cluttered with lots of notes. The
derived attribute does not necessarily use attributes from
within the class but can make use of attributes from others.
When a new record (instance) is created the actual value for each of the attributes is empty, however it is often useful
to set a default value for some of the attributes. In the example below we have two more attributes in the patient
class called dateRegistered data type date, and
isHypertensive with datatype Boolean, for the
former attribute the default value is the date their
instance was created i.e. today and for the latter
attribute it is given the value, False indicating that
they are not hypertensive.
.
8.9 Operations
So far we have not discussed the third section in each class in UML class diagrams which specifies the behaviour of the
class, its dynamic aspects. Although clearly this aspect is very important, discussion of it will be deferred to the
chapters concerned with dynamic modelling.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 25 of 53
Health Informatics
Class modelling with UML
8.10 Summary - identification and development of classes
In this section we have specifically gone through various stages to come up with a list of initial classes for both the
hospital and Dopehead scenarios and we have also considered how the class attributes relate to database structures
and the common misunderstanding that instances are considered to be a 'type' of class.
Obviously we can also use this class identification method to produce a list of classes from any narrative description
and the list below provides a resume:
1.
Identifying nouns and drawing up a list
2.
Removing:
3.
a. Redundant classes (e.g. synonyms)
b. Irrelevant classes
c. Vague classes
d. Classes that are really attributes
e. Multiple Roles amalgamated into a single class
f. Implementation information
Adding classes due to homonyms
4.
Considering Reingruber & Gregory 1994’s guidelines creating a table with the following columns:
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
Initial class type name
Unique
Singular noun
Self-explanatory
UPPER CASE
The _ character
Not an individual object
Not more than one concept
Documented
Final class type name
We could have also used a more interactive approach
with clients in a workshop environment, and developed
UML class diagrams with them.
After a few MCQs we will move onto the second aspect
of UML class diagrams, the relationships. If you feel like
one this would be a good time to take a break.
Exercise 13. MCQs
1. Which one of the following best describes the technique used to identify classes in a narrative?
a. Identification of verbs, the application of various criteria and standards (eg naming conventions etc) to refine
the list and then the creation of a list of appropriately named classes
b. Identification of nouns then the application of ISO standards to create a list of appropriately named classes
c. Identification of verbs then the application of standards (eg naming conventions etc) to create a list of
appropriately named classes
d. Identification of nouns, the application of various criteria (e.g. Reingruber & Gregory 1994’s) and standards
(e.g. naming conventions etc) to refine the list and then the creation of a list of appropriately named
classes
e. Identification of a few important nouns then the application of standards (e.g. naming conventions etc) to
create a list of appropriately named classes
2. Which of the following criteria are true (choose three)?
a. Attribute names must always be unique for a particular model.
b. Class names must be unique for a particular model.
c. Attribute names must be unique for a particular class within a model.
d. A class should only express one concept.
e. Class names should be either singular or plural nouns.
Space for you to make additional notes about Classes and Instances:
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 26 of 53
Health Informatics
Class modelling with UML
Part Two
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 27 of 53
Health Informatics
Class modelling with UML
9 Linking Classes
So far we have considered classes as being distinct discrete concepts with no linkage between them, however in
reality classes obviously link to one another in many different ways and UML provides methods for modelling this.
10 Learning Outcomes
This chapter aims to provide you with the following skills and knowledge. After you have completed it you should
come back to these points, ticking off those with which you feel happy.
Learning outcome
Tick box
Be able to identify and draw the different types of associations between classes including end names

Be able to describe the concepts of aggregation and composition

Be able to describe the way association lines in class/object models are implemented in a database

Be able to describe briefly the concept of semantic modelling

Be able to describe, and provide an example of inheritance

Be able to describe the various ways of modelling inheritance

Be able to demonstrate the usefulness of inheritance when modelling healthcare concepts

Be able to describe the concept of polymorphism

Be able to develop a class model for a familiar area


Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 28 of 53
Health Informatics
Class modelling with UML
11 UML Associations
When modelling a system, in terms of classes it is vital to be able to model the way in which classes relate to each
other. This is achieved by considering associations between classes. Although association modelling can be at a
number of levels of complexity, we will only consider some of the simpler techniques available.
An association often appears as a verb in a sentence, such as:
A person [class] eats bananas [class] or Sally [instance] eats the banana [instance] on her desk
The verb is often helpful to aid understanding of the association and is frequently used to provide a name for the
association. If this is the case it is placed somewhere beside the association line on the diagram. At a further level of
complexity, a 'role name' can be placed at either or both ends of the association. A role name is simply taking the
class and refining it in a particular way. For example:
UML 2.4
Person [class] works for NHS [class]. The association
line at the 'Person' end could have 'employee' as the
1
role name, with 'employer' as the role name at the
A
B Exactly one
NHS end.
One instance of A is always associated
with one instance of B
0..1
A
B
Zero or one
(optional)
with zero or one instances of B
One instance of A is always associated
*
A
One instance of A is always associated
B
Zero or more
(many)
1..*
One instance of A is always associated
B
One or more
*
A
B
Think:
One instance of A has zero or many
B's instances →
2..4,6..8
One instance of A is always associated
One instance of A is always associated
B
Numerical
range(s)
with 2 to 4 or 6 to 8 instances of B
{ordered}
A
B
ordered
with ordered instrances of B
A
B
Aggregation
(is made up of)
consists of several instances of B
A
One instance of A controls
The multiplicity indicator, that is the 1, or 0..* or *
etc. refers to the class close to it (i.e. proximal for the
medics among you) on the line
with one or more instances of B
in UML >2.0 can only specify
one lower and one upper
boundary?
One instance of A
Once again UML has a sets of symbols to describe
what are considered to be the common types of
associations that exist between classes I have listed
most of them opposite for easy reference:
with zero or more instances of B
A
A
An association at the instance level is called a link.
B
Composition
(is made up of
and controls)
All of the associations in the diagram opposite
provide information about how many instances of
one class can be associated with ('related to')
another. Because these associations are concerned
with the number of occurrences, they are often
classified by their 'multiplicity' and on the next page
examples are given of each type of multiplicity.
It should be noted that working out the type of
relationship that exists between classes is often done
after it is agreed that some type of relationship
exists. Therefore a first draft of a class diagram may
possess many unmarked ('unspecified') associations
which are only subsequently elucidated.
We will begin by looking at the first four associations.
several instances of B
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 29 of 53
Health Informatics
Class modelling with UML
11.1 Multiplicity
Multiplicity specifies how many instances of one class relate to a single instance of an associated class. The simplest
type of multiplicity is that of one-to-one. This is shown as the first example below. Two classes that have a one-to-one
association will therefore be drawn with a simple line between them with '1' at each end.. Such an example might be
a needle and syringe or a person and coffin. Considering a slightly more complex situation, a frying pan may optionally
have a lid, which would be represented by using the "0..1" multiplicity expression. You will also notice here that I have
multiplicities at both ends of the association line.
One instance of person is
associated with one
instance of coffin
Person
One instance of pan is
associated with zero or
one instances of lid
Pan
1
1
1
0..1
lid
8
One instance of owner is
associated with zero or
more instances of house
1..*
Owner
*
One instance of husband
is associated with one or
more instances of wife
*
8
Husband
House
8
1..*
Person
One instance of coffin is
associated with one
instance of person
One instance of lid is
associated with one
more instance of pan
8
8
One instance of person
is associated with zero
or more instances of
bank account
Coffin
1
Bank account
8
1..*
Wife
One instance of owner is
associated with one or
more instances of
person
One instance of bank
account is associated with
one or more instances of
person
One instance of wife is
associated with one
instance of husband
8
8
If the modeller wishes to explicitly state how many occurrences of one class are associated with another, a value can
be placed at the relevant end of the association line. For example, if a team leader always has four or more case
workers this situation would be represented with '4+' above the association line. Discrete values can also be modelled
such as in the situation where a team leader can only have 3, 5 or 6 case workers; this situation would be represented
by '3,5,6' above the association line in versions of UML before version 2 there seems to be no mention of the use of
such discontinuous sets which have again disappeared in version 2.4.
Multiplicity is directional; the end of the line where the symbol occurs relates to the class at that particular end of the
line. All the symbols mentioned above can occur at either end of the association. A few examples are given above
using the UML notation.
If you know about ERD's and the crows feet notation you will have realised that the above types of associations are
basically the same as those. However UML provides a much greater variety of association types not found in ERDs and
we will now move onto one of these, that is the diamond shape which we will discuss next.
Exercise 14. Associations
Draw some associations between the classes you defined in the earlier tasks.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 30 of 53
Health Informatics
Class modelling with UML
11.2 Aggregation and
Composition
Assembly consists of
components

Associations
These are special types of relationship. Let’s consider
aggregation first.
Aggregation
Aggregation can be translated into words as meaning
consists of. In the last example in the diagram on the
Composition
previous page, a person consisted of organs. In
technical speech we would say that the person was the
'assembly' class and the organ was the 'component'
class. The assembly class can be thought of as a type of collection. Taking another example, the MSc/DMI courses
consist of a collection of units/modules.
It is important to realise that the assembly class may have additional properties that the sum of the component
classes may not have. For example, considering the organ and body example each individual organ has a name but the
body adds additional details when they are all combined such as occupation.
An assembly class ('collection') can be made up of more than one type of component. For example, a hospital consists
of collections of hopefully both patients and staff.
Fowler, 2004 p.67 considered aggregation to be a problem because different people interpret it differently; he quotes
Jim Rumbaugh in saying “think of it as a modelling placebo”. I thought that the medics among you would appreciate
that!
Composition is more clearly defined as it includes the constraint of co-existence of the part as part of the whole,
quoting from the UML standard:
“A form of aggregation which requires that a part instance be included in at most one composite at a time, and that the composite
instance is responsible for the creation and destruction of the parts. Composition may be recursive. Synonym: composite
aggregation.” UML 2.0 Infrastructure Specification, Terms and definitions section.
In other words in composition the assembly class is in charge of destroying the component class and this implies that
both parts have a degree of co-existent life cycles; the part can not exist without the ‘whole’.
Thinking about the above definitions of Aggregation and
Composition you can see why it is often difficult to decide
which to use. For example, take the situation of the
PERSON has ORGANS, shown on the previous page. To a
priest this is a clear example of Composition; an ORGAN
can only exist as part of a PERSON. To an organ transplant
co-ordinator, however, it is very much an aggregation;
organs certainly do exist on their own!
Again, this
demonstrates how models are context specific.
Graphically the difference between aggregation and
composition is that aggregation is an open diamond while
the other is filled.
Organs
Person
Exercise 15. Aggregation and Composition
Draw class diagrams showing the data for each of the following aggregations / compositions: bed, ward and
hospital, canteen department and a department of your own choice.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 31 of 53
Health Informatics
Class modelling with UML
11.3 Ternary associations
So far I have only mentioned associations which involve two classes, however you can have associations which have
more than two classes involved called n-ary associations, specifically one involving three classes is called a Ternary
association.
Let's consider an example, below is shown a ternary association between Lecturer, Book and Module. What does this
mean? Well it indicates that there is a clear association between a specific lecturer, book and module. For example
with this diagram we could be able to discover that Lecturer Joan uses the book 'UML and spirituality' on the module
'modern theology'. In other words we are
defining a set of three specific values
lecturer
book
(L,B,M) in contrast to two specific values
for an association involving two classes.
module
ABC of UML
Robin
UML & spirituality
How to lie with UML
Joan
UML & kitchen design
Andrew
Modern theology
Salemanship
Joan teaches on modern
theology and uses the books
UML and spirituality and
How to lie with UML. She
also
teaches
on
the
salesmanship module for
which she uses the ABC of
UML book
Home improvements
ABC of UML
Robin
UML & spirituality
How to lie with UML
Joan
UML & kitchen design
Andrew
Robin teaches on modern
theology and uses the book
UML and spirituality. He also
teaches on the salesmanship
module for which he uses
the ABC of UML book
Modern theology
ABC of UML
UML & spirituality
Robin
How to lie with UML
Joan
UML & kitchen design
Andrew
All the associations.
Salemanship
Modern theology
Home improvements
Salemanship
Home improvements
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 32 of 53
Health Informatics
Class modelling with UML
ABC of UML
Robin
UML & spirituality
How to lie with UML
Joan
UML & kitchen design
Andrew
Modern theology
Salemanship
Robin teaches on the
salesmanship module using
the ABC of UML and How to
lie with UML books. He also
teaches on the Home
improvements modules and
uses the ABC of UML and
UML & kitchen design books.
Home improvements
The first three non uml diagrams above indicate instances between Robin, Joan and Andrew who are three instances
of Lecturer and other instances in the ternary association, the last one attempts to put them all together. Given this
complexity you may feel inclined to simplify the situation and model it with two or even three binary associations. Is
this possible?
11.3.1 Breaking Ternary associations into Binary ones
Most books recommend that it is sensible to convert ternary associations into a series of binary ones after one has
considered the semantics of the particular situation you are modelling. For example we might assume after
discussions with a group of lecturers that they ALWAYS
recommend one or more books for a module. If this is the
lecturer
book
case then you could re-model the situation as shown on
the left. But this means that any new lecturer instance
that came along would need to play by the same rules. Is
this reasonable?
module
Also more worryingly by following through the new
associations from Book to module, we do not really know
which module which lecturer teaches on. Take for
example, lecturer instance robin who is associated with
book instance ABC of UML, however the book instance ABC of UML is associated with module instances Modern
theology, Salesmanship and Home improvements, we might mistakenly now assume Robin teaches these, very
different from the ternary relationship!
Lecturer
Book
Robin
ABC of UML
Robin
UML and spirituality
Joan
ABC of UML
Joan
UML and spirituality
Joan
How to Lie with UML
Andrew
ABC of UML
Andrew
UML and kitchen design
Andrew
How to Lie with UML
Robin Beaumont robin@organplayers.co.uk
Book
Module
ABC of UML
Modern theology
UML and spirituality
Modern theology
ABC of UML
Salesmanship
UML and spirituality
Modern theology
How to Lie with UML
Modern theology
ABC of UML
Home improvements
ABC of UML
Salemanship
How to Lie with UML
Salemanship
UML and kitchen
design
Home improvements
08/02/2016 Document1
Page 33 of 53
Health Informatics
Class modelling with UML
Can we mimic the Ternary association by adding another binary relationship between Module and Lecturer?
In the above example by considering the association between Lecturer and book and Book to Module (the green lines)
Lecturer
Book
Robin
ABC of UML
Robin
UML and spirituality
Joan
ABC of UML
Joan
UML and spirituality
Joan
How to Lie with UML
Andrew
ABC of UML
Andrew
UML and kitchen design
Andrew
How to Lie with UML
Book
Module
ABC of UML
Modern theology
UML and spirituality
Modern theology
ABC of UML
Salesmanship
UML and spirituality
Modern theology
How to Lie with UML
Modern theology
ABC of UML
Home improvements
ABC of UML
Salemanship
How to Lie with UML
Salemanship
UML and kitchen design
Home improvements
Lecturer
Module
Robin
Modern theology
Robin
Modern theology
Joan
Modern theology
Joan
Modern theology
Joan
Salemanship
Andrew
Salemanship
Andrew
Home improvements
we have four possible instances. In addition considering the association between Lectuer and module we have
another four possible instances, How ever by considering the situation where both associations overlap (the shaded
row in the Book, module instances) there is a unique association. So in this example we can identify the specific Book
instance Lecturer Robin uses in the Modern theology module. But is this always the case?
Taking another example, that of a instance of Lecturer, Joan lets see if we can identify a unique instance of book she
uses for a particular instance of module, put simply can we identify which book(s) she uses for a particular module.
From the diagram below it looks that this time we can't because there are two possible instances of the book ABC of
UML associated with the Salesmanship module. In fact looking back at the ternary associations diagram we can tell
from that, that the other instance is associated with lecturer instance Andrew. But it is impossible to derive this
information from the binary associations we have set up below.
Lecturer
Module
Robin
Modern theology
Robin
Modern theology
Modern theology
Lecturer
Book
Joan
Robin
ABC of UML
Joan
Modern theology
Robin
UML and spirituality
Joan
Salemanship
Joan
ABC of UML
Andrew
Salemanship
Joan
UML and spirituality
Andrew
Home improvements
Joan
How to Lie with UML
Andrew
ABC of UML
Andrew
UML and kitchen design
Andrew
How to Lie with UML
Book
Module
ABC of UML
Modern theology
UML and spirituality
Modern theology
ABC of UML
Salesmanship
UML and spirituality
Modern theology
How to Lie with UML
Modern theology
ABC of UML
Home improvements
ABC of UML
Salemanship
How to Lie with UML
Salemanship
UML and kitchen design
Home improvements
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 34 of 53
Health Informatics
Class modelling with UML
In conclusion it is possible to say that:
While ternary associations can be occasionally broken down into a series of binary associations the resulting
semantics are subtly different
to those of the original
ternary association.
supplier
part
book
It is the responsibility of the
modeller to ensure that the
semantics of the final model
truly reflect what the client is
attempting to describe. On the
right are four examples of
possible ternary associations,
but
remember
that
in
particular circumstances they
might be broken down to
binary associations.
borrower
department
branch
student
Skill
instructor
project
course
employee
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 35 of 53
Health Informatics
Class modelling with UML
11.4 Recursive associations
Recursive relationships are also called unary or involuted relationships.
So far we have discussed examples of relationships between classes; however, it is possible to an association within a
class. Such a relationship is called recursive.
The usual example given is that of an EMPLOYEE class type that has a relationship with itself
called supervisor. In other words an EMPLOYEE instance can relate to another EMPLOYEE
instance in a supervisor role.
Clearly a ‘one to many’ or ‘many to many’ recursive relationship may also exist. (see Carter 1995 p61 - 68, Elmasri &
Navathe 1989 p. 49) Some writers suggest that these recursive relationships are acceptable in early models but should
be converted to ‘one to many’ or ‘one to one’ relationships, as the model is refined. For example the above recursive
relationship could be modelled by introducing a new class type called ROLE. This was discussed in the ERD document.
11.4.1 Association End Names
In UML the concept of Association end names s used to specify
a role a particular instance may play in the association.
Considering the above example an Employee may only have
one supervisor and the supervisor will manage one or more
employees.
Association end names may also be used to clarify the situation
where several associations exist between a single class. For
example consider the situation where a courier makes journeys
which require both a start address and a destination address,
this can easily be modelled using association end names as shown in the diagram below (adapted from p. 97 Bennett,
Skelton & Lunn 2005).
In contrast to the suggestion above concerning
the use of 'Role' classes Blaha & Rumbaugh
2005 p. 32 suggests that recursive associations
should be retained using association end names
and provides the following example.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 36 of 53
Health Informatics
Class modelling with UML
Exercise 16. MCQs
The following questions relate to the class diagram below, concerning farmers, farming locations and lambs.
Farmer
1
*
Lamb
Body Part
*
1..*
Farming
Location
1
1. In the above diagram, which is the correct statement?
a.
b.
c.
d.
e.
A farmer has one or more lambs.
A farmer has one lamb.
A farmer has zero or more lambs.
A lamb does not necessarily have a farmer associated with it.
It is impossible to ascertain the relationship between farmers and lambs in the above diagram.
2. In the above diagram, which is the incorrect statement?
a.
b.
c.
d.
e.
A farmer has one or more farming locations.
A farming location is associated with zero or more lambs.
A lamb is always associated with one farmer.
A lamb can be associated with more than one farming location.
A lamb consists of body parts.
3. The above diagram uses:
a.
b.
c.
d.
e.
OMT notation
UML notation
ERD notation
No formal notation
Chen notation
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 37 of 53
Health Informatics
Class modelling with UML
12 Mapping Associations to Databases
The instance modelling concept of association is pretty much the same as the database concept of a relationship. I will
not bore you with the technical details of relational databases, which are based upon mathematical set theory. If you
are interested you can consult the standard book on the subject - Date C J. 1995 (6th ed.) An Introduction to Database
Systems. The relational database model was first described by Codd in 1970 who subsequently defined a set of rules
based upon mathematical principles. His papers are referenced in Date 1995.
However what I will provide in the next sections are examples of the relationship between associations in instance
models and relationships in relational DBMSs.
12.1 One to Many Relationship
Consider the relationship between a doctor and patient. One doctor may have many patients. (Forget the situation of
a patient having more than one doctor for the
moment.) This can easily be drawn using UML:
Doctor
*
But how do we turn this into something that can be
represented as one or more tables (i.e. something that
can be used by a computer)? The answer is that we
make use of foreign keys.
Patient
'A doctor has zero or more patients'
If you do not understand the concept
of relationships and foreign keys see:
http://www.robinbeaumont.co.uk/virtualclassroom/chap
7/s3/dbcon2.pdf
A foreign key is a primary key in one
table that is embedded in another (or
the same) table. In the example given
below, doctor ID is the foreign key
value in the patient instance. It allows
the implementation in a DBMS of the
association shown in the class diagram
above. The diagram below shows
exactly how.
Dr Leg has two patients, John Smith and Mary Allan
mypatient1:Patient
Id=023
fname=Mary
surname=Allan
dob=21/11/65
gender=female
address=23 pink lane.
Doctorref=12345
…
…
mydoctor:Doctor
Doctor ID.
id=12345
fname=Walter
surname=Leg
gendar=male
dob=01/04/70
…
…
mypatient2:Patient
Id=214
fname=john
surname=smith
dob=01/01/55
gender=male
address=20 station st.
Doctorref=12345
…
…
The foreign key is in this
side of the relationship
*
Doctor
Patient
Exercise 17. Converting Classes/instances to tables/records
Re-draw the instance instances of the one to many situation shown above as records in two tables.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 38 of 53
Doctors ID
in the patient
object
'references'
the doctor
object.
Health Informatics
Class modelling with UML
12.2 Many to Many Relationship
Now for
situation.
Dr Leg has two patients, John Smith and Mary Allan
Dr Thomson has one patient, John Smith
myDoctor1 : Doctor
nicePatient : Patient
id=12345
fname=Walter
surname=Leg
gender=male
dob=01/04/70
…
…
id=023
fname=Mary
surname=Allan
dob=21/11/65
gender=female
address=23 pink lane.
myDoctor2 : Doctor)
id=98765
fname=Dave
surname=Thomson
gender=male
dob=06/04/50
…
…
Nastypatient : Patient
How do we
link them?
Id=214
fname=John
surname=Smith
dob=01/01/55
gender=male
address=23 station st.
A Dr has zero or more patients. A patient belongs to one or more Drs.
1+
Patient
Doctor
The foreign keys
added to a new
'resolution' table
Patient Table:
Doctor Table:
Walter
Dave
Leg
male
Thomson male
023
214
01/04/70
06/04/50
Mary
John
Allan
Smith
21/11/65 female
01/01/55 male
'resolution' table
12345
12345
98765
023
214
214
Exercise 18. MCQs
1. When mapping a class to a database, what does it become?
a.
b.
c.
d.
e.
A record
A database schema
An ERD
A table definition
An individual data item
2. When mapping an instance of a class (instance), what does it become?
a.
b.
c.
d.
e.
A record
A database schema
An ERD
A table definition
An individual data item
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
more
complex
The one to many situation
described
above
is
rather
restrictive as some patients may
have more than one doctor. In
other words the above model
does not cater for all situations
that could occur. The solution is to
create a separate table to link the
two called a resolution table. This
does not affect the instance
diagram as it is not really
necessary to show the table
required in the database to solve
the problem. However, some
people do prefer you to do this,
and it may help you create the
database.
*
12345
98765
the
Page 39 of 53
Health Informatics
Class modelling with UML
Exercise 19. Identifying foreign keys and associations
This exercise requires you to consider the models below and indicate in which class the foreign key(s) will need to be
added for implementation in a relational DBMS. This is not part of UML.
1. General Practitioner (GP) consultation model1:








A doctor has zero or more patients
A patient can only belong to one doctor
A patient can have zero or more episodes
A episode is related to one patient
A episode has zero or more primary, secondary and other diagnoses
associated with it
A diagnosis is only related to one episode.
A doctor has zero or more episodes
A episode is related to a single doctor
Doctor
*
1
Patient
1
*
*
*
Episode
*
Other
diagnosis
*
Primary
diagnosis
Secondary
diagnosis
2. The hospital model part A:
A operating theatre has zero or more sessions allocated to it which are either routine or emergency.
A theatre has one or more nurses allocated to it.
Operating
Theatre
+1
Nurse
*
*
Emergency
session
Routine
session
Adapted from OU M866 book 1 p52
1
Answer: In patient object: Dr ID. In Episode object: Dr ID and Patient ID. In each of the diagnosis tables: episode ID.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 40 of 53
Health Informatics
Class modelling with UML
3. The hospital conceptual model part B (adapted from Open University M866 book 1 p52):
A team of doctors provide treatment.
A team is specific to one specialty.
The team only has one consultant.
A team has one or more junior doctors.
1
Team
Consultant
Assumption:
A doctor may provide zero treatments
*
+1
Treatment
Junior Dr
Adapted from OU M866 book 1 p52
4. The hospital model part C (adapted from OU M866 book 1 p52):
This example requires you to first pf all annotate the uml diagram to identify the type of association, from the
narrative description before indicating where the foreign keys will be placed.
A ward has zero or more patients. Each ward has zero or more nurses.
Each nurse and patient is allocated to only one ward.
A patient has zero or more treatments. Each treatment is unique to a particular patient.
A treatment may consist of zero or more prescriptions. A prescription is unique to a treatment
A prescription has one or more drugs. A drug is related to one or more prescriptions.
Ward
Adapted from OU M866 book 1 p52
Nurse
Treatment
Patient
Prescription
+1
+1
Drug
The above exercise concerning foreign keys was to get you to understand the concept. You
would NOT normally display foreign keys in a UML class diagram. And therefore should not
usually do this.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 41 of 53
Health Informatics
Class modelling with UML
13 The Meaning of Relationships (Semantics)
People get very excited by attributing a great deal of knowledge and meaning to databases. In the 1980s a great deal
of research took place developing 'semantic models'. These were basically modelling techniques which had a wider
range of modelling symbols, such as inheritance, which we have come across in instance oriented modelling. The
standard semantics of models are entities (classes), properties (attributes or fields), relationships and subtypes (Date
p.350). Therefore, the meaning -- or rather the semantics -- of the model are these elements, nothing more and
nothing less. Date 1995 (p346 - 371), provides for this area of work an unusually lucid account of semantic modelling
(i.e. what we have been doing in this chapter with the models).
The term Ontologies has been used by the Artificial Intelligence (AI) community to describe these more complex
models, which also include a controlled vocabulary. You can find a good introduction to the subject in Mustafa
Jarrar’s PHd thesis at his web site http://www.starlab.vub.ac.be/staff/mustafa/ (unfortunately he seems to have
recently removed the content and left the table of contents only); his article Data modelling versus Ontology
engineering
provides
an
alternate
source
at
http://www.starlab.vub.ac.be/staff/mustafa/publications/[JDM03]LNCS03_V1-11.pdf.
Because no diagrammatic modelling technique can fully explain the complexity required in some databases, narratives
are added which frequently take the form of sets of rules or constraints (e.g. if a patient is female and aged between
15 and 40 years, alert a doctor to take a cervical screening). They usually require programmers to implement,
although a lot can be done with filtering out certain records and querying the records in some way. Such databases
that contain these rules are frequently referred to as knowledge bases. Nowadays, though, the word is often used for
any database regardless of its complexity.
It is possible to derive the models we have been using from a set of narrative statements. Such statements have in the
past been called predicates (Date p.97) but are now more commonly called business rules. We have been doing this
in a very simple way by providing a set of sentences (a narrative) describing the instance model in each of the instance
diagrams so far.
The 'meaning' of the data is also closely related to the very important idea of 'functional dependency' -- basically, the
dependency between various pieces of data (e.g. you can't have a blood result without first having a patient). This is
closely related to a process known as normalisation, which provides a method to ensure the data is correctly
structured in terms of functional dependency. These issues are considered in more detail in the Database section at
http://www.robin-beaumont.co.uk/virtualclassroom/contents.htm
14 Inheritance
Inheritance is a very powerful tool for organising what often appear to be
very complex situations into something that is more manageable. When
modelling a situation, this is one of the later actions that takes place after
all the classes and associations have been quite thoroughly described. This
process itself involves the development of several drafts.
Inheritance is the process of inheriting data and/or activities from a parent
(superclass) to that of a child class (subclass). An example would be the
subclass male person who would inherit all the detail in the human
superclass but add some of his/her own. Often the parent 'superclass' is
something that exists in the model but not in the real world, although this
does not have to be the case as in this example. When an instance of the
parent class does not exist, it is known as an abstract class.
Generalisation is just describing inheritance from the opposite perspective.
The subclass is a specialization of the superclass and therefore the
superclass is a generalisation of several subclasses.
In a UML Class diagram you show inheritance by using either a single triangle or one for each (generalisation) line, but
this can lead to confusion (see below for why this is the case).
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 42 of 53
Health Informatics
Class modelling with UML
14.1 Generalisation Sets
From the above diagrams concerning various shapes it is possible to see that while it is helpful to show various
generalisations it could also be confusing, Take for example:
Does this mean that a employee can not have male o
female specific attributes / operations? Unfortunately it
is not clear from the diagram that what we want to
describe is that a person is either male or female and
also has an employment status.
This can be achieved by using Generalisation sets to
redraw the diagram. Each generalisation set is given a
name (i.e. gender and employment status). In the UML this is called the powertype classifier, but I
wouldn’t worry about that too much.
Employment
generalisation
set
However this can still be confusing for within a
particular Generalisation set we
Gender
might want to specify that an
generalisation
set
instance of person might
possess characteristics of more
than one subtype. This can be achieved by using Constraints.
14.2 Constraining Subclasses
A constraint is a UML defined term that is shown in curly brackets { . . .
.} near the inheritance triangle on the diagram. The constraint consists of two words, one from two mutually exclusive
options.
First two mutually exclusive options:


Complete – All children (i.e. subclasses) have been specified (whether or not shown). No additional children
are expected.
Incomplete – Some children (i.e. subclasses) have been specified, but the list is known to be incomplete.
There are additional children that are not yet in the model. This is a statement about the model itself. Note
that this is not the same as the ellipsis, which states that additional children exist in the model but are not
shown on the current diagram.
Second two mutually exclusive options:


Disjoint – A class only inherits from one subclass within each Generalisation relationship.
Overlapping – A class can inherit from several subclasses within each Generalisation relationship.
Let’s consider an example given in the UML 2.0 superstructure (p76). Person could have two Generalisation
relationships: Manager or Staff. This would be disjoint because every instance of Person must either be a
Manager or Staff. In contrast, Person could have two Generalisation relationships: Sales Person and Manager.
This Generalisation set would not be disjoint because there are instances of Person which can be a Sales Person
and a Manager.
If no constraint is shown on the generalisation line, the Default is {incomplete, disjoint} (p.77 uml 2.0
superstructure).
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 43 of 53
Health Informatics
Class modelling with UML
Here are some more examples from the UML 2.0 Superstructure specification document:
And some more:
We end this section by considering a hospital example.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 44 of 53
Health Informatics
Class modelling with UML
14.3 Inheritance - Hospital Example
Procedure
Inheritance
Example:
ID
Name
Description
Available to GPFH
Cost
Use services
Debit
Procedure type
{disjoint}
Day case Procedure
Inpatient
Procedure
Maximum a day
Length of stay
Real Cost so far
Use IP services
Use DC services
The diagram below considers the idea of a procedure
in a hospital. Procedures can, for this example, be of
two types: inpatient and outpatient. However, both
have a subset of identical characteristics and only
differ on a few. We therefore create a 'procedure'
class that is neither an inpatient nor outpatient
procedure but contains the common characteristics of
both. This procedure class is therefore something that
does not exist in terms of instances (instances) but
provides the basis to create other classes which would
have instances such as day case hernia or inpatient
varicose vein operation. It is important to realise that
any instance of Daycase Procedure will possess the ID,
name, Description, Available to GPFH, and cost
attributes in addition to (i.e. inherited from) those
attributes in the daycase procedure class. So it would
end up with ID, name, Description, Available to GPFH,
cost and maximum a day attributes. The same
situation applies to the operations.
Let’s recap:
The hollow triangle in the above diagram indicates that both inpatient and day case procedures are inherited from the
procedure class. It can be read as 'is of type'. The above diagram can therefore be interpreted as:
Procedure is of type inpatient OR day case
Note the 'OR' in the above sentence. If we wished to replace it with an 'and' we would need to indicate it on the
diagram. UML uses '{overlapping}'. The 'OR' situation is known as a disjoint situation whereas the 'and' situation is
known as overlapping. OMT used a different symbol for this: a filled in triangle; UML does not.
The text beside the triangle 'procedure type' is known as a discriminator and is an attribute (data) whose value
differentiates between the subclasses. Often this data item is contained in the superclass.
Additional subclasses not shown on a diagram because of space constraints can be indicated by three black circles:
· · · at the end of the association line.
Rumbaugh (2005) also suggests you can just add another sub class called
'other' as well.
Exercise 20. Generalisation/Inheritance
Draw class diagrams showing inheritance in one or more of the following situations:
 Cake mix as superclass; define some subclasses
 Employee payment as a superclass; define some subclasses
 NHS provider unit as a superclass; define some subclasses
 A superclass of your own choice; define some subclasses
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 45 of 53
Health Informatics
Class modelling with UML
15 Encapsulation
Encapsulation has two different but related meanings. Firstly, it is used to mean the idea of an instance/class, in the
manner we have been describing it above. That is, something that has both data and actions (Blair, 1989 quoted in
Appleby 1991; Programming language concepts and paradigms). It can also be used simply to mean 'information
hiding', meaning that other instances have to ask permission of the instance before being allowed to see its data.
However, both these uses have the same fundamental idea behind them: the data in an instance should not be
directly accessible outside of the instance. For example, if another instance wishes to discover the waist measurement
of the instance girl the requesting instance should not be able to just examine the value of the data item waist but
request it via an activity of the girl instance such as 'request waist measurement'. Doing this, the girl instance has the
ability to refuse. Often activities that provide some sort of information are called 'services'.
Although this aspect of the instance paradigm is very important when it comes to actually writing the software, it is of
little importance when beginning to model a system.
Exercise 21. MCQs
The following class diagram is of a prescription class. Formulation is to do with how the drug is prepared (e.g. tablet,
paste etc). Administration route is the method of taking the drug (e.g. oral etc), and usage details are basically
instructions for the patient besides administration route.
usage
Prescription
*
Drug item
{complete}
noPerDose
*
frequency
*
courseLength
Strength
usage
Prescriptio
n
*
*
Medical
device
*
Drug item
*
{complete}
doseStrength
doseStrength
noPerDose
Strength
frequency
courseLength
Administration
route
Formulation
*
Medical device
Administration
route
Formulation
1. In the above diagram, which is the incorrect statement?
a. A prescription has zero or more drug items.
b. A medical device is related to zero or more prescriptions.
c. Each drug item consists of usage, strength, administration route and formulation details.
d. Each drug item can contain a single usage detail.
e. A single drug item can be related to zero or more prescriptions.
2. In the above diagram, what does the symbol
indicate?
a.
b.
c.
d.
e.
Usage details consist of one or more such sets of details.
Usage details consist of zero or more such sets of details.
Usage details are related to several other usage details.
Usage details are not clearly defined.
The relationship is ambiguous.
3. The "{complete}" indication means the following:
a.
b.
c.
d.
e.
A drug item must contain details of one or more of the following: usage, strength, administration and
formulation details.
A drug item must contain details of usage, strength, administration and formulation.
A drug item is only 'complete' when it contains information about the frequency details.
A drug item is only 'complete' when it contains information of usage, strength, administration and
formulation.
A drug item is also called a 'complete' item.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 46 of 53
Health Informatics
Class modelling with UML
16 Polymorphism
This is another aspect of the 'instance' paradigm that is not so important during the modelling stage but more
important during the software development stage.
Procedure
Polymorphism
Example:
ID
Name
Description
Available to GPFH
Cost
Responses
differently
depending upon
who called it
Use services
Debit
Procedure type
{disjoint}
Inpatient
Procedure
Day case Procedure
Maximum a day
Length of stay
Real Cost so far
Polymorphism means that activities with the same
name can behave differently in different classes.
For example, consider the above diagram of
various procedure types. The inpatient procedure
class has an activity called 'use inpatient services'
and the outpatient procedure class has an activity
called 'use outpatient services'. It would be
possible to have both the activities called 'use
services' and the individual instances taking care of
what actually happened. The advantage of this
would be that the hospital manager instance
would then only need to send one message to both
instances 'use services' rather than a different one
to each.
17 Larger models and using Case tools
We have now covered the main characteristics of Instance Oriented Modelling. However, there are two additional
concepts which are important in UML which need consideration: Packages and Stereotypes. Both of these concepts
become more important in larger models or when one uses a case tool such as System Architect.
17.1 Packages
A Package in UML is just a container. They are used to break up larger structures into more manageable bits. For
example, if we tried to model the whole healthcare system we could divide it up into numerous packages possibly
including medical services, financial management, research, community services etc.
The System Architect case tool has a good tutorial which involves modelling a hotel business, where you divide the
model into three separate packages: Reservations, Human Resources and Building Maintenance.
In ERD modelling in System Architect they talk about ‘subject areas’ (see the SA advanced ERD tutorial) which are
basically the same as UML packages. Packages can be represented three different ways, as illustrated in the abstract
from the UML 2.0. infrastructure document below for a package called ‘Types’
When using case tools, the user interface often demands that you place each diagram / class etc. in a particular
package, obviously with a small project you can simply call the package ‘the project’. However even with small
projects where there are more than 20 classes it is often sensible to divide up the classes into different packages.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 47 of 53
Health Informatics
Class modelling with UML
People often get unduly nervous about packages. Just think of them as folders for keeping similar UML elements; after
all, the visual icon does look like a Microsoft folder icon.
17.2 Stereotypes
I have really included this subsection to prevent you from using them!
Again this is a type of UML element which allows you to group others together. In this instance a stereotype is a
special type of class which you cannot use on its own but which you can use as a basis for classes that you create in
your models. Each class that makes use of the Stereotype indicates this by including the name of the stereotype
above its name.
Three cases that make use of a stereotype called ‘user_interface’ (from Pender, p.9):
<<user interface>>
<<user interface>>
<<user interface>>
frame
Button
DropDownList
UML has a number of pre-defined Stereotypes you can use. However as I said above I would warn you against using
Stereotypes unless you are going to become a UML guru. Fowler 2004, who always offers sensible advice, hints at this
(p66) as well.
What you think is a stereotype is usually just an abstract superclass. For example the class Employee might be used in
a model of an institution showing all the types of employees, but will be represented as a particular subtype such as
full-time employee or student etc.
Exercise 22. Developing packages
You should spend no more than 20 minutes on this task.
Suggest what packages you might consider for one or two of the scenarios in the scenarios document
You can find the document at: http://www.robin-beaumont.co.uk/virtualclassroom/contents.htm and
follow the links.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 48 of 53
Health Informatics
Class modelling with UML
18 Exercises
You have now covered the most important aspects of Instance Oriented Modelling, particularly that concerned with
looking at the ‘What’ rather than ‘How’ aspect. To help you consolidate your knowledge I have provided a few
exercises below.
Exercise 23. Developing a Class diagram from a narrative
You should spend no more than 20 minutes on this task.
Draw the Class diagram which is implied from the information given below:
 A dental practice has one or more dentists and zero or more dental nurses.
 Each dentist has zero or more clients.
 Each client receives zero or more treatment sessions.
 Each session has a cost associated with it.
Exercise 24. Developing a Class diagram for a logbook
You should spend no more than 120 minutes on this exercise.
Imagine you have been asked to develop an electronic logbook for a doctor to allow you to analyse the
following:





Type of patients seen
Type of procedures you were involved in
Level of competence for each procedure
Success of the interventions you were involved with
Any other areas you might consider to be important
Using the knowledge you gained from the document “An Introduction to Class Relationship Diagrams
(ERDs)” define and develop a possible set of Classes and associations.
When you are sufficiently happy with your Class diagram, if at all possible enter it into a case tool. If not, use
a drawing tool, or as a last resort use the drawing tools in MS Word.
If you are not a clinician, imagine that you are one. (You may want to talk to one after completing this task!)
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 49 of 53
Health Informatics
Class modelling with UML
Exercise 25. Developing Class diagrams as a group exercise
It is all very well developing Class diagrams as a solitary activity. The real learning starts when you are doing
it as a group.
Work as a group either face to face or using e-mail or a discussion board to carry out the following exercise.
Warning: Only choose one of the tasks below, and only spend a maximum of two hours on it.
 Develop an instance model for a work experience logbook.
 Consider developing a model for a prescription, which can consist of several different items.
 Develop a model for the area in which you work from two different perspectives.
At the end of the task, discuss amongst yourselves how you might check that you all have an agreed shared
understand of the model(s).
You might want to use a group working evaluation sheet.
Optional Exercise 26. Developing Class diagrams for patient advice leaflets
The three following exercises are related:
1. Obtain several patient advice leaflets and see if you can come up with some standard section headings for
each of the leaflets. Attempt to find advice leaflets from different sources and of different types.
2. Consider what type of advice leaflets you would have if you possessed all the patient advice leaflets which
have been developed.
3. Attempt to amalgamate the headings you developed from the leaflets you obtained into a primitive type
which would only need a few additional headings for any particular advice leaflet. (Look back at the section
on inheritance.)
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 50 of 53
Health Informatics
Class modelling with UML
19 Summary
After all the information and exercises that you should have done to get this far, you must feel quite exhausted! Let’s
recap what has been covered:







Description of the key characteristics of instance oriented modelling
Details of Class diagrams
Experience of creating Class diagrams from narratives
Experience of indicating on Class diagrams the necessary foreign keys to implement them in a database
Discussion of the differences between UML and OMT Class diagrams
Discussion of Generalisation sets and how useful the concept is in developing Class diagrams
Introduction to Packages and Stereotypes
To check exactly how much you have learned, you should go back to the learning outcomes at the beginning of this
document and tick off those with which you feel happy.
There are other areas of instance oriented modelling that has not been covered in this document. One important
aspect is the dynamic (“How”) side of things. You will find details of this aspect in other documents at
http://www.robin-beaumont.co.uk/virtualclassroom/contents.htm
20 References
Alavi M Wetherbe J C 1991 Mixed prototyping and data modelling for information system design. IEEE software May
87 – 91. One of very few articles which uses an experimental design in place of the purely non experimental case
study, to assess various methodologies.
Bennett S, Skelton J, Lunn K, 2005 UML: Schaum’s outlines. ISBN 0-07-710741-1 £10.99 [A much improved second
edition – no CD but what can you expect at this price]
Bertalanffy Ludwig von 1968 [but still published] General System Theory; Foundations, Development, Applications.
George Braziller New York.
Blaha M Premerlani W 1998 Instance-oriented Modelling and design for Database applications; Includes UML.
Prentice Hall
Blaha M, Rumbaugh J, 2005 Instance-Oriented Modelling and Design with UML (International Edition ISBN:
0131968599) Prentice Hall An e-book version is available (at: http://www.safarix.com/ ISBN: 013132894-8 You can see
quite a lot of the book from the free review sections.
Checkland P 1981 Systems thinking: systems practice. John Wiley An excellent introduction to the history of systems
analysis as well as introducing Checkland's own 'soft systems' methodology.
Checkland P Scholes J 1990 Soft Systems Methodology in action John Wiley. This book includes a case study from the
NHS.
Date C J. 1995 (6th ed.) An introduction to database systems
Fowler M Scott K 1998 UML distilled: Applying the standard instance language. Addison Wesley
Friedman A L Cornford DS 1989 Computer Systems Development: History, organisation and implementation. John
Wiley. A wonderful book, excellent references, clear penetrating insights. etc.
Klein H K Hirschheim R A 1987 A Comparative Framework of Data Modelling Paradigms and Approaches. The
Computer Journal 30 1 9 - 15.
Martin James 1989 - 1990 Information Engineering 3 volumes now published by Prentice Hall. The classic texts
concerned with business process analysis. Very easy to read. £30 each volume. Moves from information strategy
planning through business area analysis, technology impact analysis, to low level design. Firmly based in the business
process paradigm.
Newman M. Rosenberg D. 1985 Systems analysts and the politics of organisational control OMEGA int. j. of mgmt sci.,
13 (5) 393 - 406
Open University 1993 Relational Database Systems M866 (Five books; Introduction to database technology, The
Relational Modal, Normalisation, Using SQL, SQL database management) [These are excellent resources with many
exercises and clear concise explanations].
Pender A Thomas 2002 UML weekend crash course. Wiley publishing inc.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 51 of 53
Health Informatics
Class modelling with UML
Reingruber Michael C. Gregory William W 1994 The Data Modelling Handbook John Wiley & Sons Chichester
Rumbaugh J, Blaha M, Premerlani W et al 1991 Instance-Oriented Modelling and Design. Prentice Hall. See Blaha,
Rumbaugh J, 2005
Schmuller Joseph 2004 Sams Teach Yourself UML in 24 hrs ISBN 0-672-3260-40 Third edition. [This new edition has a
CD containing a pdf version of the book and a Case Tool called Poseidon (no time limit). Costs around £20]
Tsang C H K, Lau C S W, Leung Y K, 2005 Instance-Oriented Technology ISBN: 0071240462 McGraw-Hill Education
[rather overly concerned with programming for this course however it does come with a CD of the case tool VP-UML
but the book is not on the disk]
Joubert M The Use of Conceptual Graphs for Knowledge Bases, Customisation and Actual Data Organisation,
Unpublished project working paper (AIM NUCLEUS)
Wood-Harper AT Fitzgerald G 1982 A Taxonomy of Current Approaches to Systems Analysis The Computer Journal 25
1 12 - 16.
Yourden 1989 Modern structured analysis Prentice hall. One of the standard texts on structured analysis again from
the business process paradigm.
21 Web Links
An excellent glossary of UML and instance modelling terms can be found at:
http://www.csci.csusb.edu/dick/samples/uml.glossary.html The relative link also contains a good
example of a teacher/student/course class model at http://www.csci.csusb.edu/cs202/uml1.html
Links to most UML sources including all reference documents including most current as well as introductory tutorials:
http://www.rational.com/uml/resources/documentation/index.jtmpl
Quick reference guide to UML:
http://www.rational.com/uml/resources/quick/index.jtmpl
Instance Modelling group - International body responsible for setting OO standards:
http://www.omg.org
Alistair Cockburn's stuff on use cases:
http://alistair.cockburn.us/crystal/articles/sucwg/structuringucswithgoals.htm
The UML bibliography:
http://www.db.informatik.uni-bremen.de/umlbib/
Past student's recommendations:
A quick introduction to UML:
http://bdn.borland.com/article/0,1410,31863,00.html#use-case-diagram
Class and sequence diagram guidelines and more:
http://www.agilemodeling.com/style/classDiagram.htm
http://www.agilemodeling.com/artifacts/sequenceDiagram.htm
All above links were active on 18/03/2007.
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 52 of 53
Health Informatics
Class modelling with UML
Appendix - OMT
Types of Association Based on Fowler & Scott 1997 p59
UML
OMT
1
A
B
Exactly one
A
B
An A is always associated with one B
0..1
A
B
Zero or one
(optional)
A
B
An A is always associated with zero or one B
*
A
B Zero or more
(many)
B
A
An A is always associated with zero or more B
1..*
B
A
Not in UML
2.0
A
One or more
1+
A
B
An A is always associated with one or more B
2..4,6..8
2..4,6..8
B
Numerical
range(s)
A
B
An A is always associated with 2 to 4 or 6 to 8 B
A
{ordered}
B
ordered
A
{ordered}
B
An A is always associated with ordered B
A
B
Aggregation
(is made up of)
B
A
An A is made up of B
Robin Beaumont robin@organplayers.co.uk
08/02/2016 Document1
Page 53 of 53