Reader chapter 1

UML (unified modeling language) is the product of a long history of ideas in computer science and
software engineering and is a result of the object-oriented information modeling trends.
Development began in 1994. With UML, we create an information model in terms of objects and
classes and their relationships. Objects of the same type are classified by means of an object class.
Information models are called class models which are visualised as class diagrams. This chapter will
teach the basic elements of a UML class model (objects, object classes, attributes, links and
associations) and their meaning; how to make a UML class diagram for simple problems; and how to
populate a class diagram.

The information that you’re modeling comes from the Problem Domain (or Universe of Discourse).
The goal is to present this in a structured and unambiguous way. This presentation can facilitate
communication between peers or higher level managers, but can also be used as input in the design
of an information system for the problem domain. These different purposes imply different “levels”
or types of information modeling. We distinguish between two levels: information models
representing information from the UoD from a human perspective and those from the perspective of
an information system (Section 6 will introduce a third level).

Models map the complex reality of a business domain and simplify it. Only things that are relevant
for the information system (that are required to enable the desired functions) should be contained.
We want to reduce complexity as much as possible, but also provide enough details for a complete
representation.

An example of a doctor is used. The doc has patient files that she adds to during consultations. These
contain personal info, medical conditions, diagnoses, treatments, and remarks. As far as the data of
individual patients is concerned, the doc is content, but there are shortcomings too. Prescriptions, for
example, have to be written twice: once on the file card and a note for the patient. Looking up stuff
takes time, as she’d have to go through all file cards. Systematic search tasks and automated
communication are well supported by computerised information systems. We assume we can store,
change, and retrieve patient data, the medical history, and information about available drugs,
prescriptions, and treatments. We restrict considerations to static aspects and don’t try to make a
complete model.

The computerised information system can replace or extend existing manual information systems.
We can analyse documents about and forms of the existing system for the new one. All databases,
files, documents, and other information items from the old system form the domain of the IS. In this
example, the file cards can be used for modeling. Not all information can be simply extracted: the file
cards do not say that its about data of patients and consultations. For the doctor and assistants, this
is obvious, but omission of explicit declarations of information items is a source of confusion for the
designer (especially when jargon is involved). Therefore, we need the doc’s help for analysis to get a
complete picture of what information is used, what activities are performed, etc. Using the file cards,
we see that patients have a name, address, gender, and a date, which the doc has clarified to be their
date of birth (not the date of registration with the practice).

Objects are things that exist in a problem domain. They can be both tangible or intangible. In the
example, these are physical objects like patients, file cards, and, and conceptual objects, like the
consultations and diagnoses. We cannot store real-world objects, but we can store information about
them. These are called information objects – for simplicity often called object for both the real-world
object and corresponding information object. These objects have properties, like names, addresses,
etc., which we call attributes. These have certain values: a name attribute may have “Stef van Bracht”
as a value. These values may change over time: an address attribute may change when a patient
moves. The current values of an object’s attributes is called its state. UML shows the state by objects
as shown in figure 1.3.

We need to be able to distinguish patients from each other, but two patients might have the same
name, or address, or date of birth, so we cannot use those attributes. To avoid problems like those,
we need identification criterion that guarantees the unique identity of information objects. Object
identifiers (OIDs) are attributes that ensure identification among other objects. Examples are student
numbers, flight numbers, etc. An alternative is making a combination of attributes to be such a
primary key. Sometimes you can use existing unique identifiers, like social security numbers, but
other times you can create a new ‘artificial’ identifier, like a patient ID, which can include numbers
and letters.

Each patient has been in for a number of consultations, so there are relationships between patient
objects and consultation objects. Such a relationship is called a link. This link can have a name, which
is typically a verb phrase to illustrate what it represents (patient has consult, person ismarriedto
person). Links are shown as a line connecting two objects. These links are to be read from left to
right, unless an arrow is present, which then shows how to interpret it.

Object diagrams show both the state and structure (relationship between) objects. It represents the
abstraction of a domain, we abstract from the specific states of the individual object and focus on
their structure. Certain objects have the same structure (like the patients). An object type is such an
abstraction that unifies all objects of the same structure, it’s an object without attribute values.
“Patient” is an abstraction that is not related to one concrete person, but to people who visit a
doctor in general. The object type is called an object class or class in short in UML. A specific objects
that belongs to a certain class is called an instance of the class: Stef is an instance of the class patient.
Classes and their relationships with each other are described in a class diagram.

Classes can be visualised as boxes with the names of the classes and can be expanded to include the
attributes in a class rectangle below it, see figures 1.7 and 1.8. There is a certain number of objects
that exist for a particular class, like the number of patients. The set of instances of a class are called
the current population of the class. This population is depicted in the form of a table, where each
column represents an attribute and each row represents an instance. The first column is usually
reserved for the OID.

Object classes are the basic building blocks of a class diagram. To make the picture complete, we
need to include the relationships between object classes. A relationship between classes is called an
association. Objects can be related by links (like between Patient Stef and consultation on a set date).
Objects of the same type are classified by means of object classes, links of the same type are
classified by means of associations. In other words, the instances of associations are links, like the
instances of object classes are objects. Like links, associations have names that are typically verb
phrases. Associations are called binary if it relates exactly two object classes with each other.
Sometimes, we deal with n-ary associations relating n object classes (section 3).
Figure 1.9 shows the association between object classes patient and consultation. To clarify: if you
would fill this out for a specific patient with a specific consultation, that would be objects and links.

The population of an association is the set of all corresponding links that are instances of this
association at a certain point in time. Like with a class, this can be represented in a table. If it’s a
binary association (between two classes), the table has two columns: the first has the identifier of the
‘first’ class, the second has the identifier of the ‘second’ class. This is typically used to show the
sample population, because the complete population is often too large to display. If the association is
inverted, the table has to swap the columns.
The first examples were relationships between objects of different classes, but objects from one class
may be linked to each other too. This is called recursion. An example can be found in figure 1.12,
where employees manage each other. Role names can be used to make the roles specific. They
indicate how the object participates in the relationship. This could help clarify that one employee is
the superior and the other one is the subordinate, for example, see figure 1.13.