The Unified Modeling Language (UML) is made up of in­te­grat­ed diagrams used by IT de­vel­op­ers for the visual rep­re­sen­ta­tion of objects, states and processes within a software or system. The modeling language can serve as a blueprint for a project and guarantee a struc­tured in­for­ma­tion ar­chi­tec­ture; and also can help de­vel­op­ers present their de­scrip­tion of a system in a com­pre­hen­si­ble way for external spe­cial­ists. UML is mainly used in object-oriented software de­vel­op­ment. En­hance­ments to the standard in version 2.0 also make it suitable for rep­re­sent­ing business processes.

Unified Modeling Language’s de­vel­op­ment

Even before UML was in­tro­duced to software de­vel­op­ment, the field of object-oriented pro­gram­ming (OOP) was already growing. This pro­gram­ming style is based on the concept that every­thing is an object: the building blocks of a program are objects that interact with each other. The messages sent back and forth also consists of objects. Each in­di­vid­ual object is an example of its su­per­or­di­nate class. The class itself also acts as an object, and de­ter­mines the behavior of the object instances it contains. Objects consist of data and code. The object arranges the data in fields, also called at­trib­ut­es. The code de­ter­mines their procedure or method.

From the late 1980s to the 1990s, many methods and languages for the rep­re­sen­ta­tion of OOP were developed and put into use. The result was a variety of methods that were largely dis­sim­i­lar. To unify these, the three de­vel­op­ers James Rumbaugh, Grady Booch and Ivar Jacobson decided to merge several existing languages into a common, stan­dard­ized one.

The three had already created their own object-oriented software de­vel­op­ment methods:

  • The Booch method
  • The object modeling technique (OMT)
  • The object-oriented software en­gi­neer­ing method (OOSE)

UML should define the semantics for the rep­re­sen­ta­tion of these methods as the modeling language. Under the name “UML Partners”, the de­vel­op­ers started working on the com­ple­tion of UML in a team in 1996. They then handed it over to the Object Man­age­ment Group (OMG), who in­tro­duced the unified modeling language version 1.1 as the standard in 1997.

Not satisfied, the de­vel­op­ers set up a task force to improve the language over several versions. Existing crit­i­cisms included imprecise, un­nec­es­sar­i­ly complex semantics, a lack of adapt­abil­i­ty, and fairly poor stan­dard­iza­tion. For this reason, a major revision was carried out. The result was UML 2.0, which set the new standard in 2005. Version 2.4.1 forms the basis for the ISO stan­dard­iza­tion 19505-1 (In­fra­struc­ture) and 19505-2 (Su­per­struc­ture) of 2012. UML Version 2.5.1 appeared in December 2017.

UML: Key terms

Some call “unified modeling language” the lingua franca among the modeling languages, which is really what it aimed to become. As mentioned above, UML vi­su­al­izes the states of objects and in­ter­ac­tions between them within a system. Its wide­spread use may be due to the great influence of object man­age­ment group (OMG) members (including IBM, Microsoft and HP). Struc­tured semantics also con­tributes to this. UML diagrams show the following system com­po­nents:

  • In­di­vid­ual objects (basic com­po­nents)
  • Classes (com­bi­na­tion of elements with the same prop­er­ties)
  • Re­la­tion­ships between objects (hierarchy and behavior/com­mu­ni­ca­tion between objects)
  • Activity (complex com­bi­na­tion of actions/be­hav­ioral building blocks)
  • In­ter­ac­tions between objects and in­ter­faces

Meta­mod­el­ing

UML 2.0 defines language units that operate on different levels. You use these to express the structure and behavior of a system. Meta-modelling includes all elements of UML, including those that describe UML itself. It uses four hi­er­ar­chi­cal­ly arranged levels (M0 to M3).

The meta-meta level M3 specifies the metadata of the modeling language and its re­la­tion­ships using the metaob­ject facility (MOF). It defines the meta-model, and also enables metadata transfer. The XMI format defined by the object man­age­ment group members is a practical tool for sharing object-oriented data at the meta-meta level between de­vel­op­ment tools. The object con­straint language (OCL), a de­clar­a­tive pro­gram­ming language, sup­ple­ments UML and regulates the modeling’s boundary con­di­tions. As a text language, however, it’s only sup­port­ive and can’t be used for modeling.

Image: Meta-modeling on four levels: from runtime instances to user models, meta-model UML 2.0 to the meta-meta-model MOF 2.0Foxy burrowShut­ter­stock
Meta-modeling shows the hi­er­ar­chi­cal re­la­tion­ship between language levels.

The image shows that the meta­mod­el­ing of UML 2.0, level M0 is the basic level. It rep­re­sents concrete, real objects and in­di­vid­ual data records - e.g. an object or a component. Level M1 comprises all models that describe and structure the data of level M0. These are UML diagrams such as the activity diagram or the package diagram (explained below). To define the structure of these models, M2 meta-models define the spec­i­fi­ca­tions and semantics of the model elements.

If you want to create an un­der­stand­able UML diagram, you need to know the UML meta-model and its rules. The highest level, M3, is a meta-model of the meta-model. The mentioned meta-object facility works on an abstract level that defines meta-models. This level defines itself, since otherwise further, su­per­or­di­nate meta-levels would arise.

Language Units

UML (layer M2) defines the rules for its own semantics. The language units are terms defined in UML 2.0 su­per­struc­ture. This means a formal rep­re­sen­ta­tion that everyone involved can un­der­stand is possible. Language units abstract similarly struc­tured and similarly func­tion­ing objects and processes, and give them a visually rep­re­sentable form. Depending on the hierarchy level within the model, elements take on more spe­cial­ized tasks or define other elements more closely.

Class: As a language unit, classes are a core aspect of UML. You define what a class is and how classes interact with each other. This language unit has four levels, ranging from simple elements to more complex re­la­tion­ships:

  • Core (describes elements from the UML 2.0 in­fra­struc­ture such as package, namespace, attribute, etc.)
  • As­so­ci­a­tion classes
  • In­ter­faces
  • Pow­er­types (classes whose instances are sub­class­es within this class)

Com­po­nents: Com­po­nents are software modules that separate their contents from the external system. There is only a con­nec­tion to the outside through in­ter­faces or port. A com­po­si­tion connector es­tab­lish­es a con­nec­tion to another component via the interface. The del­e­ga­tion connector links internal elements with an interface at the external border. Com­po­nents are modular and in­ter­change­able.

Composite structure: The composite structure of language units describes elements that are shielded inwards and outwards like com­po­nents. Only ports connect the content to the external system. The so-called en­cap­su­lat­ed clas­si­fiers are composed of elements called parts. Parts com­mu­ni­cate via con­nec­tors.

Profile: A profile con­fig­ures UML 2.0 for specific needs. Abstract terms such as activity or object must be specified for some projects to increase un­der­stand­ing. You can use a profile to adjust semantics and notations that are loosely set.

Model: The model includes all elements necessary to represent a specific view of the structure or behavior of a system. This also includes external in­flu­ences such as actors.

Action: When it comes to depicting behavior, actions are central. They represent a single step within an activity – an activity, in turn, is a behavior which is made up of a col­lec­tion of actions. Here are some examples of actions:

  • Fill order
  • Show error page
  • Process order

Behavior: The language unit “behavior” or “behavior de­scrip­tion” means the modeling of dynamic aspects within a system. It contains three spec­i­fi­ca­tions:

  • Activity: Actions interact through data and control flows. This results in a complex system of behaviors - the ac­tiv­i­ties.
  • In­ter­ac­tion: This meta-model describes how message flows are exchanged between objects, when a message is sent and to which object, and which other elements are affected by it.
  • State machines: In a state diagram, this meta-model shows states (sit­u­a­tions with un­change­able prop­er­ties) and pseudo-states (states without value as­sign­ment) along with their tran­si­tions. Objects in a state can be assigned to actions or ac­tiv­i­ties.

Dis­tri­b­u­tion: A network consists of objects that are connected to each other in meshes. A special case of ap­pli­ca­tion exists if these elements represent ex­e­cutable software or artifacts. These artifacts run on execution en­vi­ron­ments or devices that UML 2.0 cat­e­go­rizes as nodes. The artifact is therefore dependent on the node. The dis­tri­b­u­tion rep­re­sents this de­pen­den­cy re­la­tion­ship that arises during in­stal­la­tion.

Ap­pli­ca­tion case: The ap­pli­ca­tion case (as a language unit) rep­re­sents system re­quire­ments. The actor (a person or a system) is an element that de­ter­mines who or what is to perform a par­tic­u­lar activity through the system. The system can also be a class or component, and is therefore described as a subject. The use case (as a model element) only informs that a named behavior is expected that is visible to the outside world. It does not usually show the exact actions. Within a be­hav­ioral de­scrip­tion, modeling assigns the detailed re­quire­ments to the ap­pli­ca­tion case.

In­for­ma­tion flow: This UML language unit describes the elements in­for­ma­tion unit and in­for­ma­tion flow. These model elements define tech­niques for de­scrib­ing behavior that can be very detail-oriented, such as ac­tiv­i­ties or in­ter­ac­tions. This sim­pli­fied rep­re­sen­ta­tion allows the universal use of these modeling elements in all UML diagram types.

UML diagrams: their usage and a short general in­tro­duc­tion

The modeling language defines 14 diagram types, which are divided into two cat­e­gories. The main cat­e­gories “structure” and “behavior” represent the basic concepts rep­re­sent­ed by UML diagrams. Within the group of be­hav­ioral diagrams, UML specifies the sub­cat­e­go­ry “in­ter­ac­tion diagrams”. A fourth sub-spec­i­fi­ca­tion has existed since UML 2.0 was developed, and defines the design of the model diagrams.

Structure Diagrams

Structure diagrams represent the in­di­vid­ual elements in a system. Therefore, they are par­tic­u­lar­ly suitable for rep­re­sent­ing software ar­chi­tec­ture. The static rep­re­sen­ta­tion does not represent a change, but rather rep­re­sents states and de­pen­den­cies at a certain point in time. The in­di­vid­ual elements, or objects, are related to each other. For example, an object belongs to a class. Other com­po­nents are computer nodes or artifacts - an artifact rep­re­sents a result, for example a finished script file.

UML diagrams of this category represent an entire system or a sub­struc­ture. The latter helps, for example, to clarify the structure in detail. The language of the “structure” category assigns seven UML diagram types in UML 2.0:

  • Class diagram: If objects have a common behavior or the same structure, you can classify them or assign them to a class. The class is therefore a sim­pli­fy­ing, sum­ma­riz­ing element (ab­strac­tion) for visual rep­re­sen­ta­tion. Classes and objects are linked to each other using in­ter­faces. All these com­po­nents and their re­la­tion­ships to each other can be rep­re­sent­ed in a class diagram. A class rep­re­sents its diagrams using a rectangle. The name of the class is in bold type, as shown below.
Image: Display of a class, right with class name “person” in a rectangle, left with class name as well as attributes and operations.
The class “person” has the at­trib­ut­es “first name” and “last name”. The op­er­a­tions determine whether the instance is shown (display) or hidden (hide).
  • Object diagram: An object diagram has a similar structure to a class diagram. Instead of the name as it appears in the class diagram (see “person” above), the object diagram puts the name along with the clas­si­fi­er/category name. According to the spec­i­fi­ca­tion, this is un­der­lined (e.g.: Helga:Person)

  • Component diagram: A component is a module that is isolated from the external system and interacts with other com­po­nents via defined in­ter­faces. It's a subtype of the class. Therefore, struc­tur­al char­ac­ter­is­tics such as op­er­a­tions and at­trib­ut­es define the component more clearly. There are two display options for modeling, depending on re­quire­ments: the black box view (content is hidden) and the white box view (content is visible).
Image: Component diagram with two components in black box view connected to one component in white box view
White box view of a component. Necessary in­ter­faces are shown as boxes (“socket”), or as a circle (“lollipop”).
  • Composite structure diagram: Objects belong to classes, which in turn can also be clas­si­fied. These so-called meta-classes are called clas­si­fiers in UML. The composite structure diagram rep­re­sents the in­di­vid­ual parts and con­nec­tors of a clas­si­fi­er. Parts are always part of the whole, even if they are not nec­es­sar­i­ly needed to complete the clas­si­fi­er. Con­nec­tors are the links between parts. Features or services that require com­po­nents outside the clas­si­fi­er send parts via an interface.

  • Package diagram: A package combines elements such as in­ter­faces or classes in a namespace (see note below diagram). Packages can also merge with other packages (package merge), import them (package import), or contain other packages (sub-packages). Package structure diagrams link contents hi­er­ar­chi­cal­ly, like in a tree diagram. The package diagram is used, for example, in the meta-model of UML 2, and is modular in software systems. Strictly specified, a package consists of a head and a content area.
Image: package with class A and B and an interface
In the header, the keyword “package” describes the element. In the content area, the package includes an interface and two classes
Note

A namespace is an element of the UML-2 meta-model. Com­po­nents must have a name, and one of the following vis­i­bil­i­ty at­trib­ut­es: package, private, protected or public. The package is a special case of the namespace.

  • De­ploy­ment Diagram: A de­ploy­ment diagram models the physical dis­tri­b­u­tion of artifacts on nodes. Nodes are either hardware (device nodes) that can provide memory, or software (execution en­vi­ron­ment nodes) that provides an en­vi­ron­ment for executing processes. They are rep­re­sent­ed as three-di­men­sion­al cuboids. These contain the file name. To dis­tin­guish them from a class, the cuboids have stereo­types such as <<artifact>>. The diagram is suitable for dis­play­ing de­pen­den­cies between nodes and artifacts, so-called dis­tri­b­u­tion re­la­tion­ships.

    </artifact>
  • Profile diagram: Profile diagrams are used at the meta-model level. They are used to assign a stereo­type to classes, or a profile to packages. On the meta-level, it is possible to adapt the model for another platform or domain. For example, if you restrict the UML semantics within a profile, it passes on the spec­i­fi­ca­tions to the sub­or­di­nate classes.

Behavior Diagrams

Behavior diagrams cover the remaining spec­i­fi­ca­tions under UML. Unlike structure diagrams, they aren’t static, but represent processes. Behavior diagrams also include in­ter­ac­tion diagrams (see below).

  • Use case diagram: Use case diagrams show which behavior is expected from a system later. This modeling is not only suitable for software systems, but also to predict pro­ce­dures in business, for example. The use case involves an actor (human or system) with a goal. The diagram usually has the target as its name. The different use cases within the system fulfill the actor’s objective.

The use case diagram rep­re­sents UML using a rectangle labelled “use case”. The sender is the actor (this is rep­re­sent­ed as a stick figure, even if it is a system – see below). The actor is connected to the ap­pli­ca­tion case (ellipse with label) within a system (rectangle with label <<system>>, and name of the system).

Image: Use case diagram with one actor and two use cases in the system
The use case diagram in the example has an actor who can expect two use cases within the system “social network XYZZY”.
  • Activity diagram: Ac­tiv­i­ties consist of a network of actions that are linked by data and control flows. While the use case diagram shows system re­quire­ments, the activity diagram shows how these use cases run. In this type of diagram, tokens play a role. In parallel processes, they are a marker for which processes are pri­or­i­tized, and receive resources (for example, working memory).

  • State machine diagram: A state machine, also called finite automaton, rep­re­sents a finite set of states in a system. If a fixed condition is fulfilled in the system (i.e. a trigger goes off), a cor­re­spond­ing reaction happens. This may include ac­tiv­i­ties or in­ter­ac­tions. Under UML 2.0, a state rep­re­sents this situation. States are regarded as vertices, and are displayed as rec­tan­gles with rounded corners. In addition, the state machine diagram models tran­si­tions from one state (source node), to the other (target node).

In­ter­ac­tion diagrams

In­ter­ac­tion diagrams are a subtype of be­hav­ioral diagrams. They also depict processes. They are par­tic­u­lar­ly suitable for modeling behavior in which elements exchange in­for­ma­tion. The diagrams define the role of the objects involved. They also name and pri­or­i­tize the messages that are sent back and forth between the objects. In­ter­ac­tion diagrams also show how these messages affect be­hav­ioral elements, such as starting or stopping ac­tiv­i­ties:

  • Sequence diagrams: As an in­ter­ac­tion diagram, the sequence diagram rep­re­sents the exchange of messages between objects. The UML diagram type models these objects as a so-called lifeline. In this sense, it is similar to other be­hav­ioral diagrams such as the activity diagram. In contrast to these, however, a sequence diagram is not used to obtain a broad overview of the behavior of a system, but to present in detail one possible behavior among many. It pre­scribes a chronol­o­gy, and a dashed line rep­re­sents the course of time.

    UML 2.0 displays syn­chro­nous messages (an arrow with filled-in head), and asyn­chro­nous messages (an arrow with open head). Syn­chro­nous messages are messages that block a channel until they receive a response from the target object. They determine be­hav­ioral char­ac­ter­is­tics in the form of syn­chro­nous op­er­a­tions. Asyn­chro­nous messages control the calling source object. These include both asyn­chro­nous op­er­a­tions and signals (data packets sent between actions).
  • Com­mu­ni­ca­tion diagram: Similar to a sequence diagram, com­mu­ni­ca­tion diagrams model a message transfer using lifelines. However, this UML diagram does not use dashed lines for time sequences, but instead numbers the sequences with digits and letters. These so-called sequence terms are located above an arrow whose tip points in the direction of the receiver. Numbers represent the order in which messages are sent, letters for the hi­er­ar­chi­cal level (as shown in the figure below).
Image: Communication diagram with synchronous and asynchronous messages and hierarchy
Asyn­chro­nous messages 1a and 1b are sent in parallel. The message with the label 1a.1 sends object :B before the message 1a.2b. Object :D sends message 1a.2b.1 only after message 1a.2b is received
  • Timing diagram: A timing diagram makes it possible to show the behavior of systems in detail under the aspect of time se­quenc­ing. Real-time systems, for example, have to complete certain processes within a certain period of time. To better represent a time plane, UML 2.0 models timing diagrams as two-di­men­sion­al diagrams, with an x-axis and a y-axis. In this sub-category of the sequence diagram, the object states are on the y-axis, and the time sequences assigned to them run along the y-axis.
Image: Time course diagram with seven color values in the y-axis and time course on the x-axis
Timing diagram of an LED lamp with color changer: color instances alternate, and are active for the same time interval
  • In­ter­ac­tion Overview Diagram: The in­ter­ac­tion overview diagram newly added in UML 2.0 helps to display a very complex system in a rough outline when a normal in­ter­ac­tion diagram would be too confusing. A sequence diagram is suitable for a detailed display. The UML diagram is similar to the activity diagram with nodes. It rep­re­sents control flows between in­ter­ac­tions. This is different than an activity diagram, because an entire in­ter­ac­tion diagram can be nested within nodes that stand for ac­tiv­i­ties. These nestings can be shown directly in the diagram (inline) or refer to the model (keyword: ref) which is shown in detail elsewhere.

UML diagrams: an overview

The following overview shows the cat­e­gories and possible ap­pli­ca­tions of the in­di­vid­ual UML diagram types in short form. If you want to visually represent a model-oriented software system, you should first select one of the UML diagram types according to the rec­om­men­da­tion of the UML task force. Only then is it worth­while to choose one of the many UML tools, since these often require a certain method. Then you can then create a UML diagram.

Category Diagram type Use
Structure diagrams Class diagram RepĀ­reĀ­sents classes
Structure diagrams Object diagram Shows a systemā€™s state at a specific moment
Structure diagrams Component diagram Shows deĀ­penĀ­denĀ­cies and structure comĀ­poĀ­nents
Structure diagrams Composite structure diagram Divides modules or classes into their comĀ­poĀ­nents, and clarifies their reĀ­laĀ­tionĀ­ships
Structure diagrams Package diagram Groups classes into packages, repĀ­reĀ­sents package hierarchy and structure
Structure diagrams DeĀ­ployĀ­ment diagram Shows the disĀ­triĀ­bĀ­uĀ­tion of comĀ­poĀ­nents to computer nodes
Structure diagrams Profile diagram IlĀ­lusĀ­trates usage reĀ­laĀ­tionĀ­ships through stereoĀ­types, boundary conĀ­diĀ­tions, etc.
Behavior diagrams Use case diagram RepĀ­reĀ­sents various uses
Behavior diagrams Activity diagram Describes the behavior of different (parallel) processes in a system
Behavior diagrams State machine diagram Documents how an object is changed from one state to another through an event
Behavior diagrams - inĀ­terĀ­acĀ­tion diagrams Sequence diagram RepĀ­reĀ­sents the timing of inĀ­terĀ­acĀ­tions between objects
Behavior diagrams - inĀ­terĀ­acĀ­tion diagrams ComĀ­muĀ­niĀ­caĀ­tion diagram Shows the role disĀ­triĀ­bĀ­uĀ­tion of objects within an inĀ­terĀ­acĀ­tion
Behavior diagrams - inĀ­terĀ­acĀ­tion diagrams Timing diagram DemonĀ­strates the temporal limĀ­iĀ­taĀ­tion for events that lead to a change of state
Behavior diagrams - inĀ­terĀ­acĀ­tion diagrams InĀ­terĀ­acĀ­tion overview diagram Shows how sequences and acĀ­tivĀ­iĀ­ties interact
Tip

The Object Modeling Group issues UML cer­tifi­cates. If you would like to further your knowledge, find out more about UML tutorials.

Go to Main Menu