1. UML 2.4 Tutorial
Thomas Bosch
GESIS - Leibniz Institute for the Social Sciences, Mannheim, Germany
thomas.bosch@gesis.org
Abstract.The purpose of the Unified Modeling Language (UML) is to model,
document, specify, and visualize complex systems. The UML delivers notation
elements for static as well as dynamic models of analysis, design, and architec-
ture and supports object-oriented procedures in particular. This tutorial serves
the attendees of the workshop „DDI Lifecycle – Moving Forward‟ as a guide
and a reference to understand the most important elements of class diagrams
and activity diagrams of the actual version of the UML 2.4 standard.As exam-
ples excerpts from the statistical domain are modeled. The references section
contains a list of books, which I recommend to read in order to get a detailed
understanding of the UML modeling standard. This list is ordered according to
my personal preferences.
Keywords: UML 2.4, class diagrams, activity diagrams.
1 Class Diagrams
Using class diagrams the structure of systems is visualized. Class diagrams show
relevant static concepts and their relationships to each other [1]. In this section, only
the most relevant components of class diagrams are explained in detail. In the follow-
ing figure, the classes „Study‟ and „StudyGroup‟ are defined. Classes stand for real as
well as digital objects or instances. A specific study, for instance the germanmicro-
census of the year 2009, represents such an instance of the class „Study‟. For the fur-
ther description of classes attributes can be specified. In the example, the attribute
„title‟ is defined in the class „Study‟. This attribute stands for study titles of concrete
„study‟ objects. Study titles are of the datatype „String‟ and have the default value
“studyTitle”. The visibility of the attribute „title‟ is set to private (-). This means that
only concrete study objects are aware of the existence of this attribute and can see the
attribute‟s actual value. The visibility can also be set to public (+). As a consequence,
other classes and their concrete instances can see these attributes and their values at
runtime.
These classes „Study‟ and „StudyGroup‟ are both defined as sub-classes of the ab-
stract super-class „StudyOrStudyGroup‟, as for this super-class common attributes
may be defined. Common attributes are then inherited by all the sub-classes. The class
„StudyOrStudyGroup‟ is specified as „abstract‟, since it makes no sense to generate
instances of this class. There‟s no concrete object, which is at the same time a study

2. and a group of studies. For the abstract super-class a generalization set is specified.
The property „complete‟ indicates that the set of sub-classes is complete, i.e. all rea-
sonable sub-types are modeled. The property „disjoint‟ indicates that no instance of a
sub-type is at the same time an instance of the other sub-class. The remaining proper-
ties are „overlapping‟ and „incomplete‟ representing the inverse properties.
Between the classes „StudyGroup‟ and „Study‟ an aggregation and alsocardinali-
ties are defined. This means that groups of studies may contain multiple studies. But
Study groups may also include no studies, as the range 0 to n (n indicated by *) is
specified. Studies may be contained in groups of studies, since the multiplicity 0 to n
is stated. In contrast to a composition, an aggregation is used as the relation between
the whole thing (the study group) and the parts (the studies) is not existence-
depending, i.e. if a study, contained in a particular group of studies, is deleted, the
including study group will not be deleted.
Fig.1. Studies and goups of studies
Figure 2 shows code lists as representations of variables. An association is defined
between the class „Variable‟ and the class „Representation‟. Associations stand for
relationships between concrete objects of the source and target classes. For associa-
tions cardinalities can be stated. In our example, each variable has exactly one repre-
sentation and specific representations may represent more than one variable (0..*).
The roles, classes have in associations, may be defined at each association end. The
role, particular variables have when they are in the association „representation‟, is in
this case „variable‟. Concrete representations are in the role „representation‟ when
they are related to certain variables using the association „representation‟. As the visi-
bility of the roles is declared as public (+), other classes within the same package can
see objects which are in these roles.The arrow next to the name of the association

3. indicates the reading direction of the association. The arrow at the end of the associa-
tion shows that only variables know their specific representation and not the other
way around - concrete representations don‟t know the represented variables, i.e. they
do not have to store represented variables or references to these variables.
Fig. 2. Representation of variables
Between the class „Representation‟ and the class „Code‟ a composition is defined.
This means that representations may contain 0 to ncodes and if a specific included
code is deleted, the representation itself will also be deleted afterwards. This relation-
ship is therefore existing-dependent. The whole thing (the representation) can‟t exist-

4. without all parts (the codes). In the case of an aggregation, in contrast to a composi-
tion, the whole thing could exist further when a part is deleted.
Figure 3 displays questions which may be contained in questionnaires and com-
ments which are associated with questionnaires and questions. As comments about a
certain question in a particular questionnaire depend on both the questionnaire and the
question, an association class - a model element that has both association and class
properties - has to be specified. An association class canbe seen as an association that
also has class properties, or as a class that also has associationproperties. It not only
connects a set of classifiers but also defines a set of features thatbelong to the rela-
tionship itself and not to any of the classifiers [1].Comments have a string text and a
comment type as attributes.
Fig. 3. Questionnaires and questions
The comment type‟s values are „internalComment‟ and „externalComment‟. As on-
ly these two values are allowed, an enumeration is added. Enumerations are modeled
as classes with the stereotype „enumeration‟, displayed in the UML class diagram as
<<enumeration>>.
2 Activity Diagrams
Activity modeling is a specialized type of behavioral modeling concerned with
modeling the activities and responsibilities of elements. Using UML activity dia-
grams, you can display the processing of use cases, operations, and complete business
processes. An activity is the specification of parameterized behavior as the coordinated
sequencingof subordinate units whose individual elements are actions [1]. The next figure
visualizes the activity or the business process to publish variable lists in different
formats.The overall activity is divided into two activity partitions. An activity partition is

5. a kind of activity group for identifying actions that have somecharacteristic in common
[1]. The actions of the activity „publish variable lists‟ are executed in the first activity
partition by a national statistical office and in the second activity partition by a statistical
research institute.
An initial node is a control node at which flow starts when the activity is invoked. An
activity final node is a final node that stops all flows in an activity [1]. The activity to
publish variable lists starts at the initial node within the context of the national statistical
office and ends in the area of responsibility of the statistical research institute. First, the
national statistical office sends a signal whose event is received by the statistical research
institute. As signal a variable list is sent which is received by the corresponding event.
Fig. 4. Publishing variable lists
The result of the event is the list of variables which is represented using an object node.
An object node is an abstract activity node that is part of defining object flow in an activi-
ty [1]. There are two kinds of flows in an activity diagram: control flows and object
flows. These flows are visualized by arrows in the diagram. Whenever the source or the
target node of an arrow is an object node, the flow is an object flow.

6. The next control flow points from the object node „variable list‟ to the action node
„check variable list‟. An action is a named element that is the fundamental unit of execut-
able functionality. The execution of an action represents some transformation or
processing in the modeled system, be it a computer system or otherwise [1]. The action to
check the variable list is in this case a special kind of action, a so-called call behavior
action, as an appropriate activity is invoked. Using such an approach activities can be
nested and the entire activity diagram is much clearer. Call behavior actions have a little
rake in their rounded rectangle. Moreover, this action is framed by an interruptible activity
region. An interruptible activity region is an activity group that supports termination of
tokenflowing in the portions of an activity [1]. Whenever an exception occurs in this spe-
cial framed area, the flow continues over the flashed control flow to the following action
which is in this case the notification of the colleagues. If the file containing the variable
list is broken, the colleagues will be notified. After one week a time event is received
and the control flow continues in this branch.
In case the file including the variable list is not damaged, a decision has to be tak-
en. In activity diagrams decisions are visualized using decision nodes. A decision
node is a control node that chooses between outgoing flows [1]. The associated condition
„all variables available?‟ is stated after the stereotype „<<decisionInput>>‟ in a note linked
to the decision node. If all variables are available (the condition is evaluated to the boolean
value true [true]), the left branch will be executed and if not all variables are available
([false]), the right branch will be followed. As actions cannot have more than one incom-
ing control flow, a merge node has to join all the incoming control flows of the action
„notify national statistical office (NSO)‟ on the outmost branch of the activity. A merge
node is a control node that brings together multiple alternate flows. It is not used to syn-
chronize concurrent flows but to accept one among several alternate flows [1].
If all variables are available in the variable list [the condition is evaluated to true], two
parallel control flows will be executed indicated by a fork node. A fork node is a control
node that splits a flow into multiple concurrent flows [1]. At the same time an html view
and a pdf view of the variable list can be created simultaneously. At the end of these con-
current control flows a join node has to be set. A join node is a control node that synchro-
nizes multiple flows [1]. The following merge node joins the two conditional branches and
then the variable list can be published. The activity final node closes the activity at the
end.
References
1. Rupp, C., Queins, S.: UML 2 glasklar - Praxiswissen für die UML-Modellierung. Carl
hanser Verlag (2012)
2. Hitz, M., Kappel, G., Kapsammer, E., Retschitzegger, W.: UML @ Work -
Objektorientierte Modellierung mit UML 2. dpunkt.verlag (2005)
3. Fowler, M.: Uml Distilled: A Brief Guide to the Standard Object Modeling Language. Ad-
dison-Wesley Professional (2004)
4. Pilone, D., Pitman, N.: UML 2.0 in a Nutshell. O‟Reilly (2005)