UML 2.4 Tutorial

Thomas Bosch

GESIS - Leibniz Institute for the Social Sciences, Mannheim, Germany [email protected]

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 following 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 german micro- census of the year 2009, represents such an instance of the class ‘Study’. For the further 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 abstract 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

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 properties are ‘overlapping’ and ‘incomplete’ representing the inverse properties. Between the classes ‘StudyGroup’ and ‘Study’ an aggregation and also cardinalities 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 associations cardinalities can be stated. In our example, each variable has exactly one representation 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 visibility 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

indicates the reading direction of the association. The arrow at the end of the association 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 n codes 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

without all parts (the codes). In the case of an aggregation, in contrast to a composition, the whole thing could exist further when a part is deleted. Figure 3 displays questions which may be contained in questionnaires and comments 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 can be seen as an association that also has class properties, or as a class that also has association properties. It not only connects a set of classifiers but also defines a set of features that belong 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 only 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 <>.

2 Activity Diagrams

Activity modeling is a specialized type of behavioral modeling concerned with modeling the activities and responsibilities of elements. Using UML activity diagrams, you can display the processing of use cases, operations, and complete business processes. An activity is the specification of parameterized behavior as the coordinated sequencing of 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 a kind of activity group for identifying actions that have some characteristic 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 activity [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.

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 token flowing in the portions of an activity [1]. Whenever an exception occurs in this special 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 ‘<>’ 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 incoming 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 concurrent 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 - Objektorien- tierte 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)