The Unified Modeling Language (UML) is made up of in­teg­rated diagrams used by IT de­velopers for the visual rep­res­ent­a­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­form­a­tion ar­chi­tec­ture; and also can help de­velopers present their de­scrip­tion of a system in a com­pre­hens­ible 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­res­ent­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 everything 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­vidu­al object is an example of its su­per­or­din­ate class. The class itself also acts as an object, and de­term­ines 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­utes. The code de­term­ines their procedure or method.

From the late 1980s to the 1990s, many methods and languages for the rep­res­ent­a­tion of OOP were developed and put into use. The result was a variety of methods that were largely dis­sim­il­ar. To unify these, the three de­velopers James Rumbaugh, Grady Booch and Ivar Jacobson decided to merge several existing languages into a common, stand­ard­ised 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­gin­eer­ing method (OOSE)

UML should define the semantics for the rep­res­ent­a­tion of these methods as the modeling language. Under the name “UML Partners”, the de­velopers 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­velopers set up a task force to improve the language over several versions. Existing cri­ti­cisms included imprecise, un­ne­ces­sar­ily complex semantics, a lack of ad­apt­ab­il­ity, and fairly poor stand­ard­isa­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 stand­ard­isa­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 visu­al­ises 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­trib­utes to this. UML diagrams show the following system com­pon­ents:

  • In­di­vidu­al objects (basic com­pon­ents)
  • Classes (com­bin­a­tion of elements with the same prop­er­ties)
  • Re­la­tion­ships between objects (hierarchy and behaviour/com­mu­nic­a­tion between objects)
  • Activity (complex com­bin­a­tion of actions/be­ha­vi­our­al building blocks)
  • In­ter­ac­tions between objects and in­ter­faces

Metamod­el­ing

UML 2.0 defines language units that operate on different levels. You use these to express the structure and behaviour of a system. Meta-modelling includes all elements of UML, including those that describe UML itself. It uses four hier­arch­ic­ally 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­at­ive 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 hier­arch­ic­al re­la­tion­ship between language levels.

The image shows that the metamod­el­ing of UML 2.0, level M0 is the basic level. It rep­res­ents concrete, real objects and in­di­vidu­al 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 spe­cific­a­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­din­ate 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­res­ent­a­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­res­ent­able form. Depending on the hierarchy level within the model, elements take on more spe­cial­ised 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­ation classes
  • In­ter­faces
  • Power­types (classes whose instances are sub­classes within this class)

Com­pon­ents: Com­pon­ents 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­pos­i­tion connector es­tab­lishes a con­nec­tion to another component via the interface. The del­eg­a­tion connector links internal elements with an interface at the external border. Com­pon­ents 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­pon­ents. Only ports connect the content to the external system. The so-called en­cap­su­lated clas­si­fi­ers are composed of elements called parts. Parts com­mu­nic­ate via con­nect­ors.

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 behaviour of a system. This also includes external in­flu­ences such as actors.

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

  • Fill order
  • Show error page
  • Process order

Behaviour: The language unit “behaviour” or “behaviour de­scrip­tion” means the modeling of dynamic aspects within a system. It contains three spe­cific­a­tions:

  • Activity: Actions interact through data and control flows. This results in a complex system of be­ha­viours - the activ­it­ies.
  • 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 (situ­ations with un­change­able prop­er­ties) and pseudo-states (states without value as­sign­ment) along with their trans­itions. Objects in a state can be assigned to actions or activ­it­ies.

Dis­tri­bu­tion: A network consists of objects that are connected to each other in meshes. A special case of ap­plic­a­tion exists if these elements represent ex­ecut­able software or artifacts. These artifacts run on execution en­vir­on­ments or devices that UML 2.0 cat­egor­ises as nodes. The artifact is therefore dependent on the node. The dis­tri­bu­tion rep­res­ents this de­pend­ency re­la­tion­ship that arises during in­stall­a­tion.

Ap­plic­a­tion case: The ap­plic­a­tion case (as a language unit) rep­res­ents system re­quire­ments. The actor (a person or a system) is an element that de­term­ines 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 behaviour is expected that is visible to the outside world. It does not usually show the exact actions. Within a be­ha­vi­our­al de­scrip­tion, modeling assigns the detailed re­quire­ments to the ap­plic­a­tion case.

In­form­a­tion flow: This UML language unit describes the elements in­form­a­tion unit and in­form­a­tion flow. These model elements define tech­niques for de­scrib­ing behaviour that can be very detail-oriented, such as activ­it­ies or in­ter­ac­tions. This sim­pli­fied rep­res­ent­a­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­egor­ies. The main cat­egor­ies “structure” and “behaviour” represent the basic concepts rep­res­en­ted by UML diagrams. Within the group of be­ha­vi­our­al diagrams, UML specifies the sub­cat­egory “in­ter­ac­tion diagrams”. A fourth sub-spe­cific­a­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­vidu­al elements in a system. Therefore, they are par­tic­u­larly suitable for rep­res­ent­ing software ar­chi­tec­ture. The static rep­res­ent­a­tion does not represent a change, but rather rep­res­ents states and de­pend­en­cies at a certain point in time. The in­di­vidu­al elements, or objects, are related to each other. For example, an object belongs to a class. Other com­pon­ents are computer nodes or artifacts - an artifact rep­res­ents 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 behaviour or the same structure, you can classify them or assign them to a class. The class is therefore a sim­pli­fy­ing, sum­mar­iz­ing element (ab­strac­tion) for visual rep­res­ent­a­tion. Classes and objects are linked to each other using in­ter­faces. All these com­pon­ents and their re­la­tion­ships to each other can be rep­res­en­ted in a class diagram. A class rep­res­ents 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­utes “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 spe­cific­a­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­pon­ents via defined in­ter­faces. It's a subtype of the class. Therefore, struc­tur­al char­ac­ter­ist­ics such as op­er­a­tions and at­trib­utes 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­fi­ers in UML. The composite structure diagram rep­res­ents the in­di­vidu­al parts and con­nect­ors of a clas­si­fi­er. Parts are always part of the whole, even if they are not ne­ces­sar­ily needed to complete the clas­si­fi­er. Con­nect­ors are the links between parts. Features or services that require com­pon­ents 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 hier­arch­ic­ally, 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­pon­ents must have a name, and one of the following vis­ib­il­ity at­trib­utes: 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­bu­tion of artifacts on nodes. Nodes are either hardware (device nodes) that can provide memory, or software (execution en­vir­on­ment nodes) that provides an en­vir­on­ment for executing processes. They are rep­res­en­ted as three-di­men­sion­al cuboids. These contain the file name. To dis­tin­guish them from a class, the cuboids have ste­reo­types such as <<artifact>>. The diagram is suitable for dis­play­ing de­pend­en­cies between nodes and artifacts, so-called dis­tri­bu­tion re­la­tion­ships.

    </artifact>
  • Profile diagram: Profile diagrams are used at the meta-model level. They are used to assign a ste­reo­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 spe­cific­a­tions to the sub­or­din­ate classes.

Behaviour Diagrams

Behaviour diagrams cover the remaining spe­cific­a­tions under UML. Unlike structure diagrams, they aren’t static, but represent processes. Behaviour diagrams also include in­ter­ac­tion diagrams (see below).

  • Use case diagram: Use case diagrams show which behaviour is expected from a system later. This modeling is not only suitable for software systems, but also to predict pro­ced­ures 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­res­ents UML using a rectangle labelled “use case”. The sender is the actor (this is rep­res­en­ted as a stick figure, even if it is a system – see below). The actor is connected to the ap­plic­a­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: Activ­it­ies 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­it­ised, and receive resources (for example, working memory).

  • State machine diagram: A state machine, also called finite automaton, rep­res­ents 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­res­pond­ing reaction happens. This may include activ­it­ies or in­ter­ac­tions. Under UML 2.0, a state rep­res­ents this situation. States are regarded as vertices, and are displayed as rect­angles with rounded corners. In addition, the state machine diagram models trans­itions 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­ha­vi­our­al diagrams. They also depict processes. They are par­tic­u­larly suitable for modeling behaviour in which elements exchange in­form­a­tion. The diagrams define the role of the objects involved. They also name and pri­or­it­ise the messages that are sent back and forth between the objects. In­ter­ac­tion diagrams also show how these messages affect be­ha­vi­our­al elements, such as starting or stopping activ­it­ies:

  • Sequence diagrams: As an in­ter­ac­tion diagram, the sequence diagram rep­res­ents 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­ha­vi­our­al diagrams such as the activity diagram. In contrast to these, however, a sequence diagram is not used to obtain a broad overview of the behaviour of a system, but to present in detail one possible behaviour among many. It pre­scribes a chro­no­logy, and a dashed line rep­res­ents the course of time.

    UML 2.0 displays syn­chron­ous messages (an arrow with filled-in head), and asyn­chron­ous messages (an arrow with open head). Syn­chron­ous messages are messages that block a channel until they receive a response from the target object. They determine be­ha­vi­our­al char­ac­ter­ist­ics in the form of syn­chron­ous op­er­a­tions. Asyn­chron­ous messages control the calling source object. These include both asyn­chron­ous op­er­a­tions and signals (data packets sent between actions).
  • Com­mu­nic­a­tion diagram: Similar to a sequence diagram, com­mu­nic­a­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 hier­arch­ic­al level (as shown in the figure below).
Image: Communication diagram with synchronous and asynchronous messages and hierarchy
Asyn­chron­ous 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 behaviour of systems in detail under the aspect of time se­quen­cing. 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­res­ents 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 activ­it­ies. 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­egor­ies and possible ap­plic­a­tions of the in­di­vidu­al 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 re­com­mend­a­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­res­ents classes
Structure diagrams Object diagram Shows a system’s state at a specific moment
Structure diagrams Component diagram Shows de­pend­en­cies and structure com­pon­ents
Structure diagrams Composite structure diagram Divides modules or classes into their com­pon­ents, and clarifies their re­la­tion­ships
Structure diagrams Package diagram Groups classes into packages, rep­res­ents package hierarchy and structure
Structure diagrams De­ploy­ment diagram Shows the dis­tri­bu­tion of com­pon­ents to computer nodes
Structure diagrams Profile diagram Il­lus­trates usage re­la­tion­ships through ste­reo­types, boundary con­di­tions, etc.
Behaviour diagrams Use case diagram Rep­res­ents various uses
Behaviour diagrams Activity diagram Describes the behaviour of different (parallel) processes in a system
Behaviour diagrams State machine diagram Documents how an object is changed from one state to another through an event
Behaviour diagrams - in­ter­ac­tion diagrams Sequence diagram Rep­res­ents the timing of in­ter­ac­tions between objects
Behaviour diagrams - in­ter­ac­tion diagrams Com­mu­nic­a­tion diagram Shows the role dis­tri­bu­tion of objects within an in­ter­ac­tion
Behaviour diagrams - in­ter­ac­tion diagrams Timing diagram Demon­strates the temporal lim­it­a­tion for events that lead to a change of state
Behaviour diagrams - in­ter­ac­tion diagrams In­ter­ac­tion overview diagram Shows how sequences and activ­it­ies interact
Tip

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

Go to Main Menu