UML 2.4 Tutorial Thomas Bosch GESIS - Leibniz Institute for the Social Sciences, Mannheim, Germany email@example.com 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 showrelevant static concepts and their relationships to each other . In this section, onlythe 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 aswell 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 thatonly concrete study objects are aware of the existence of this attribute and can see theattribute‟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 atruntime. These classes „Study‟ and „StudyGroup‟ are both defined as sub-classes of the ab-stract super-class „StudyOrStudyGroup‟, as for this super-class common attributesmay 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 generateinstances 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 asub-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. ButStudy groups may also include no studies, as the range 0 to n (n indicated by *) isspecified. Studies may be contained in groups of studies, since the multiplicity 0 to nis stated. In contrast to a composition, an aggregation is used as the relation betweenthe 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, theincluding 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 definedbetween the class „Variable‟ and the class „Representation‟. Associations stand forrelationships 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. Therole, particular variables have when they are in the association „representation‟, is inthis case „variable‟. Concrete representations are in the role „representation‟ whenthey 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 cansee 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 associa-tion shows that only variables know their specific representation and not the otherway around - concrete representations don‟t know the represented variables, i.e. theydo 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 includedcode 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 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 acertain question in a particular questionnaire depend on both the questionnaire and thequestion, an association class - a model element that has both association and classproperties - has to be specified. An association class canbe seen as an association thatalso has class properties, or as a class that also has associationproperties. It not onlyconnects a set of classifiers but also defines a set of features thatbelong to the rela-tionship itself and not to any of the classifiers .Comments have a string text and acomment 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 modeledas 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 withmodeling the activities and responsibilities of elements. Using UML activity dia-grams, you can display the processing of use cases, operations, and complete businessprocesses. An activity is the specification of parameterized behavior as the coordinatedsequencingof subordinate units whose individual elements are actions . The next figurevisualizes the activity or the business process to publish variable lists in differentformats.The overall activity is divided into two activity partitions. An activity partition is
a kind of activity group for identifying actions that have somecharacteristic in common. The actions of the activity „publish variable lists‟ are executed in the first activitypartition by a national statistical office and in the second activity partition by a statisticalresearch institute. An initial node is a control node at which flow starts when the activity is invoked. Anactivity final node is a final node that stops all flows in an activity . The activity topublish variable lists starts at the initial node within the context of the national statisticaloffice and ends in the area of responsibility of the statistical research institute. First, thenational statistical office sends a signal whose event is received by the statistical researchinstitute. 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 . There are two kinds of flows in an activity diagram: control flows and objectflows. These flows are visualized by arrows in the diagram. Whenever the source or thetarget 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 orprocessing in the modeled system, be it a computer system or otherwise . The action tocheck the variable list is in this case a special kind of action, a so-called call behavioraction, as an appropriate activity is invoked. Using such an approach activities can benested and the entire activity diagram is much clearer. Call behavior actions have a littlerake in their rounded rectangle. Moreover, this action is framed by an interruptible activityregion. An interruptible activity region is an activity group that supports termination oftokenflowing in the portions of an activity . Whenever an exception occurs in this spe-cial framed area, the flow continues over the flashed control flow to the following actionwhich is in this case the notification of the colleagues. If the file containing the variablelist is broken, the colleagues will be notified. After one week a time event is receivedand 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 decisionnode is a control node that chooses between outgoing flows . The associated condition„all variables available?‟ is stated after the stereotype „<<decisionInput>>‟ in a note linkedto the decision node. If all variables are available (the condition is evaluated to the booleanvalue 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 mergenode 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 . If all variables are available in the variable list [the condition is evaluated to true], twoparallel control flows will be executed indicated by a fork node. A fork node is a controlnode that splits a flow into multiple concurrent flows . At the same time an html viewand 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 . The following merge node joins the two conditional branches andthen the variable list can be published. The activity final node closes the activity at theend.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)