Unified Modeling Language

2.4.1 UML Superstructure Specification ( English) ( PDF)
UML Specification in all versions

The Unified Modeling Language ( Unified Modeling Language ), UML in short, is a graphical modeling language for the specification, design and documentation of software parts and other systems. It is developed by the Object Management Group (OMG) and is standardized by both you and by the ISO ( ISO / IEC 19505 for version 2.1.2). In terms of language UML defines identifiers for most at a modeling important terms and defines possible relationships between these terms. UML defines graphical notations for these concepts further and models for static structures and dynamic processes, which can be formulated with these terms.

UML is now the dominant language for software system modeling. The first contact with UML often is that diagrams in UML to make during the course of software projects, to understand or to be assessed:

Check Project, Client and representatives and confirm, for example, requirements for a system, the business analysts or business analysts have captured in use case diagrams in UML;
Software developer implement workflows, the business analysts or business analysts have described in association with specialist representatives in activity diagrams;
Install systems engineers and software systems operate based on an installation plan, which is available as distribution diagram.

However, the graphical notation is only one aspect of which is regulated by UML. UML defines primarily, with what terms and which relationships between these terms so-called models are specified - in UML diagrams only show a graphical view of excerpts of these models. UML also proposes a format that can be exchanged between tools in the models and diagrams.

2.1 part specifications
2.2 Metamodeling
2.3 units of speech
2.4 Classification of speech units in layers

3.1 Actions
3.2 activities
3.3 General behavior
3.4 Use Cases
3.5 Information flows
3.6 interactions
3.7 classes
3.8 components
3.9 compositional structures
3:10 models
3:11 profiles
3:12 templates
3:13 distributions
3:14 State Machines

4.1 Creating Charts

7.1 For the certification
7.2 Coupled with process models

8.1 Specifications for UML2
8.2 Further

Genesis

The first version of UML was developed in the 1990s in response to numerous proposals for modeling languages and methodologies, which should support the emerging at this time object-oriented software development. The first episode of languages , also known under the name UML 1.x, in 2005, replaced by a substantially revised version, often referred to as UML2.

From the beginnings to the Unified Modeling Language 1.x

The fathers of UML, Grady Booch particular, Ivar Jacobson and James Rumbaugh, also called "The Three Amigos " were prominent in the 1990s, representatives of the object-oriented programming. They all had already developed their own modeling languages . When they were working together at the software company Rational, the idea that different systems of notation bring together structured arose. A variety of different modeling languages had direct or indirect influence on the design of UML, including OOSE, RDD, OMT, OBA, OODA, SOMA, MOSES and OPEN / OML.

As a result of these efforts, the UML was created. The standardization, maintenance and development of the language was passed to the OMG, the default language accepted on 19 November 1997.

Genesis of the Unified Modeling Language 2

In August 1999, the OMG nudged the development of UML2, published by a corresponding Request for Information ( RFI).

A year later, in September 2000, the OMG asked its members and other interested parties to submit proposals for UML2. According to the newly defined for UML2 architecture published the OMG three Requests for Proposals ( RFP): a UML 2.0 Infrastructure RFP, a UML 2.0 Superstructure RFP and a UML 2.0 OCL RFP. Those who wanted to submit proposals had to approximately one additional year.

In a first round of various groups and individuals submitted designs. Mid-2002 were from these consortia repeatedly revised and consolidated responses to individual Request for Proposals before. Only in October 2002, all proposals for the UML 2.0 Infrastructure and the UML 2.0 Superstructure could then be presented at the meeting of the relevant working group in Helsinki. An appointment for a further revised version of the proposals submitted, the Working Group established to early January 2003. The main difficulty now was to merge the different drafts of a specification. On one hand, criticism was that the different philosophies in the submitted proposals would hardly be clean, on the other hand submitted in January 2003, a new consortium under the name 4M a proposal ( UML4MDA ) one who tried to bridge the differences between the previous specifications.

In March 2003, the relevant group then recommended the proposals of the consortium U2 for the UML 2.0 Infrastructure and for the UML 2.0 OCL for release in May for the UML 2.0 Superstructure of the same consortium, so that from June 2003, three Finalization Task Forces of the OMG could start working to complete the part specifications. However, the task forces were unable to complete as planned until April 2004 their work and therefore set up a second Finalization Task Force, which should solve the remaining issues by September 2004.

In September 2004, were finally able to finish their work all Finalization Task Forces. For the UML 2.0 OCL and the UML 2.0 Infrastructure were thus taken off before final documents (Final Adopted Specification). Only in the UML 2.0 Superstructure, this last step seemed a little delay: in March 2005, the OMG website only a temporary document with the informal designation UML 2.0 Superstructure FTF convenience document offered to continue to download.

On 21 October 2008, the Beta 1 version of UML 2.2 has been released by the OMG that was present again in February 2009 in the final version. Newly added in version 2.2, the profile diagram to structure user-defined stereotype collections can.

In May 2010, UML 2.3 has been released. This version contains mainly bug fixes at the metamodel and sharpening the semantics of model elements in the UML specification document. The current version 2.4.1 was released in August 2011.

Structuring

The scope of the UML to UML 2 grown during the development of UML 1.0 constantly. For the development of UML 2 as well as for teaching, application, and not least for the readability of the UML 2 specification structuring is very important. What could be specified in the first versions of UML in a document, therefore, must be divided into sub for UML 2 specification. In the following paragraphs, the construction of UML 2 will be described.

Part specifications

UML2 is divided into three sub- specifications. The UML 2.0 Infrastructure Specification lays the foundation for UML2 by describing the most frequently used elements of UML2 and the model elements that specialize the rest of the model elements. In this document, concepts such as class, the association or the multiplicity of an attribute can be specified. The UML 2.0 Superstructure Specification builds on the foundation of the UML 2.0 Infrastructure Specification on and defines the model elements of UML2, which are suitable for a particular purpose. Typical approaches, which are specified in this document are of the case of application, the type or the state machine. Finally, the document specifies entitled UML 2.0 Object Constraint Language the Object Constraint Language 2.0 ( OCL2 ).

Another fourth part does not deal with the semantic model of UML, but specifying the layout of diagrams. This document is entitled UML 2.0 Diagram Interchange and is an innovation in UML 2.0; UML 1.x knew no standardized format, with the diagram layout could be exchanged between different tools. The semantic information in a UML model could also been passed to another tool, a tool; the appearance of the graphs, ie the positions and size of individual chart elements, but it was lost. Diagram Interchange (DI ) seeks to eliminate this shortcoming.

Metamodeling

Similar to describe natural languages in dictionaries or grammars themselves, even UML was conceived as a language tool that can be explained by some language components themselves.

The language concepts are divided in to four layers M0 to M3.

With the Meta Object Facility (MOF) model elements are specified by UML2 and thus, for example, with the format Meta Interchange XMI interchangeable. This MOF is at the level M3, and is one of the four layers dar. It is the meta of meta languages ( the Metametamodell ) and includes basic elements (such as packages, classes, attributes and associations ). The UML2 meta-language (M2 ) is defined in MOF and represents the known language features available on the concepts of MOF also still use cases, state machines, and more. The created in practice UML models are on the level M1. Thus the objects of the M0 layer are shown. These are the actual runtime instances of the system.

As in UML2.0 also UML1.x was arranged on the third of four Metamodellierungsebenen. However, there is to UML 1.x, an essential difference: the modeling languages used on the planes M2 and M3 ( ie MOF and UML ) can share a common language unit of the infrastructure library ( Infrastructure Library ). It is defined in the UML 2.0 Infrastructure and forms a core of basic modeling elements of both the UML 2.0 Infrastructure and in the UML 2.0 Superstructure and in the MOF 2.0 is employed.

Speech units

The UML 2.0 Superstructure is based on a first-level modular in units of speech (English language units). A speech unit includes a set of closely related modeling elements with which a user can model a selected aspect of a system with a specific formalism. The speech unit activities (English Activities) includes, for example, elements for modeling of system behavior, which can be best represented with the formalism of data and control flows.

Classification of speech units in layers

In a third stage, most language units into several layers ( engl. compliance level ) are organized. The bottom layer each comprises the simplest and most frequently used modeling elements, while higher layers introduce increasingly complex modeling elements. The speech unit activities includes, for example fundamentals Activities as the bottom layer and, based on the layer Basic Activities. Fundamental Activities defined initially only that activities structurally consist of hierarchically nested groups of actions. Basic Activities extends this framework to edges and other auxiliary node to a graph, which can then visually represents the activity diagram in UML 2.

Speech units

Actions

The speech unit actions ( engl. actions ), the definition of the actions in UML2. Actions are the basic building blocks for modeling a behavior. You can accept input values of so-called input pins and output values to produce so-called output pins.

UML2 defined in this speech unit several groups of basic actions, see action.

Activities

The activity is the central element that is defined in the speech unit activities. She is also one of the main innovations of UML2 against UML 1.4. An activity is a model for a behavior that is described as a set of elementary actions, between which there are control and data flows. From the perspective of a software system an activity diagram would represent the dynamic behavior of the corresponding system.

Activities have the structure of a graph. Nodes represent actions and points, where the flows are controlled between actions; Edges represent the object and control flows. The task of the language pack activities is to define all the types of nodes and edges that are needed for modeling activities.

Nodes are divided into object and control nodes, edges, by analogy, in object and control flows.

More complex activities can be nested and modularized control structure.

Graphically activities are modeled in activity diagrams.

General behavior

The speech unit General behavior includes the general model elements for the specification of the behavior of a modeled system with UML2. Here, the model elements are grouped together, that are required for the specification of activity, interactions, or state machine.

The speech unit defines the common behavior of any description and that an active class can have its own behavior. Behave in a system that is modeled with UML2 always starts on the basis of discrete events. This language package defines what types of events UML2.

The treatment time is also largely governed by this language pack. It defines metaclasses for the observation time (Time Observation Action ) for the notation of time expressions (time expression ), for the definition of time intervals ( TimeInterval ) and for the concept of a temporal duration (duration).

Applications

The speech unit applications ( engl. use case ) provides elements for the modeling of requirements for a system. The key element is the use case. Applications hold fast what to do a system. The second important element is the actor. Specify actors, who (in the sense of a person ) or what should (in the sense of another system ) to do something with the system.

Graphical applications are shown in use case diagrams.

Information flows

The techniques offered UML2 for the specification of the behavior of a system is based on precise semantic models. This is especially true for behavioral descriptions with the help of interactions or activities that are also geared to specify a system's behavior very fine granularity. If the model is a system to show only some basic information flows in the system, these techniques are therefore limited.

The speech unit information flows, which was introduced in UML2, provides model elements are available in order to improve this situation. It offers the model elements unit of information and information flow with which a modeler information flows can hold in a system at a high abstraction level.

Information flows can thereby connect a variety of other model elements of UML2, in particular classes, use cases, occurrence specifications, actors, interfaces, ports, and then some.

UML2 does not specify a chart type for information flows. The graphical notation for information flows and information units can occur in all structure diagrams.

Interactions

The behavior of a modeled system can be specified in UML2 in different ways. One is the modeling of interactions. An interaction is the specification of a behavior that is best described by the exchange of messages between independent objects. The speech unit provides for the appropriate model elements.

Who modeled interactions assumes that the modeled system consists of a network of objects, with each other to exchange messages. Sends an object to another object a message, one can identify two event appearances: first, the occurrence of an event message when the message is sent from the first object, and second, a message event when the message arrives at the second object. Other events occur when an action or a different behavior in the context of an object begins or ends. A trace (trace ) denotes a sequence of such events. Interactions specify now a behavior as two sets of tracks, a set of valid and invalid traces a lot.

That is to say precisely what we mean when we speak of interactions: the meaning ( semantics) of an interaction is given by sets of tracks. Are modeled as sets of interactions, however, life lines on which to run actions and other behaviors and between which messages are exchanged.

Interactions are modeled graphically in communication diagrams, sequence diagrams or in timing diagrams.

Classes

The speech unit classes is the actual core of the modeling language. It defines, in particular, what is meant in UML2 taking a class and the relationships between classes are possible. In this speech unit basic principles of UML2 defined. The metaclass element is the root element for all other model elements. Each element can have other elements, even as many comments, which in turn can comment on other elements. Relationships between elements can be defined. Elements can be named and include in this case to a namespace. Further, certain elements have a type. You will then be referred to as typed elements. An element can be associated with a lower and an upper bound, a multiplicity.

This speech unit contains four sub-packages. The sub-package kernel includes central modeling elements that are re-used from the UML 2.0 Infrastructure. These include the class, the expression specification, the namespace, the package attribute, association, dependency relationship, the package import, package merger and the generalization. The second sub- package, AssociationClasses, includes the definition of association classes. Interface, the third sub-packet, provides the interface definition. Finally, the sub-package power type model elements declared for the so-called power type.

Elements of this speech unit are mostly represented in class diagrams, object diagrams and package diagrams.

Components

Components are modular parts of a system which are structured so that they may be in their environment is replaced by another functionally equivalent component. In software development, one in particular uses the concept of software component to structure a software system into modular components. The speech unit components UML2 provides constructs are available to model systems are made up of components.

The main element is the component that defines an inner structure to the outside. The specification of a component declared before all the visible from the outside edge and thus defines a black-box view of the component. Visible are a lot of interfaces offered and required and possibly a lot of ports.

The speech unit further comprises the delegation and the composition connector. The delegation connector connects ports on the hull of a component with elements inside the component. The composition connector connects offered interfaces of a component with another component required interfaces.

The elements of this language unit but are usually shown in component diagrams, some of them in class diagrams or deployment diagrams.

Compositional structures

The speech unit compositional structures enriched UML2 a new approach for modeling the internal structure of a composite whole. The "whole " is modeled as an encapsulated classifier, for the "parts", this linguistic unit the Parts. Among themselves Parts can be connected by connectors. Thus, the encapsulated classifier represents a system with clear demarcation between inside and outside, its internal structure is specified using parts and connectors. Thus, the boundary between inside and outside is at least partially permeable to the encapsulated classifier can on the envelope on a lot of input and output points, called ports have.

Elements of this speech unit are mostly represented in composite structure diagrams.

Models

The speech unit models includes only one model element: the model.

Profiles

UML2 is with the speech unit profiles a lightweight extension mechanism available with which it can be adapted to specific applications. The mechanism is called lightweight because he lets the metamodel of UML2 unchanged, often a decisive advantage, because on the market tools for the creation and maintenance of UML 2 models can often only deal with models based on the standard UML2 metamodel.

UML2 includes speech units in their different ways for modeling the structure and behavior of a system, but must remain on a generic level. They used, for example, the generic terms activity or artifact and does not know the specific term business process from the business modeling and Enterprise Java Beans Java platform. If these terms are needed in the modeling, it must be added using the extension mechanism of the profiles to UML2. Also, special notations, for example, a more realistic drawing instead of the stick figure that represents an actor, UML2 can be added using the profiles. Next to close gaps in the semantics definition of UML 2 that were left there intentionally for specific applications open profiles (English semantic variation points). Finally profiles may define restrictions to limit the manner in which such an element from UML2 is used.

Using the extension mechanism of the profiles, however, the meta-model of UML2 can not be adjusted arbitrarily. Thus, for example, no elements from the metamodel from UML2, lifted no restrictions and no real new metaclasses, but only extensions ( stereotypes ) of existing metaclasses are declared.

The speech unit first defines the concept of a profile. A profile is a collection of stereotypes, and defines the actual extension. A profile is a packet, and is applied to other packets, whereby the extension of which defines the profile is valid for the respective packet.

UML2 has known since the UML 2.2 a special type of chart for profiles. The graphical notations for elements of this speech unit can or package diagrams and class diagrams.

Templates

The speech unit templates (English templates) includes model elements for the parameterization of classifiers, classes, and packages.

Distributions

The speech unit distributions ( engl. deployments ) is focused on a very specific area of application, namely the distribution of executable software installed on a network. UML2 referred to as a installable unit as an artifact, and assumes that they are installed on nodes. Nodes can be either devices or execution environments. A distribution relationship, that is a special dependency relationship, modeled that an artifact is installed on a node.

Elements of this speech unit are normally presented in deployment diagrams.

State machine

The speech unit state machine (german state machines ) includes model elements that are used for the modeling of state machines.

UML2 state machine is primarily a specification for the behavior of a system. Thus, a state machine, for example, model the behavior of instances of an active class. In addition, state machines may, however, also be used to specify a permissible use of an interface or a port. The state machine modeled here, for example, the order in which operations of an interface may not be called. In the first case we speak of a behavioral state machines, in the second of a protocol state machine.

State machines are shown graphically in state diagrams. These are available in UML, a variant of classical statecharts.

Representation in diagrams

The diagrams in UML can be divided into two main groups: structure diagrams and behavior diagrams.

UML2.3 knows seven structural diagrams:

The class diagram,
The composite structure diagram (also: assembly diagram)
The component diagram,
The deployment diagram,
The object graph
The package diagram and
The profile graph.

There are also seven behavior diagrams:

The activity diagram,
The use case diagram (also: Use Case o Nutzfalldiagramm called ),
The interaction overview diagram
The communication graph
The sequence diagram,
The timing diagram and
The state diagram.

The boundaries between the fourteen types of diagrams have been less sharp than suggests this classification. UML2 does not prohibit a diagram contains graphical elements that actually belong to different chart types. It is even conceivable that elements of a structure graph and a behavior chart on the same graph are shown when thus a particularly incisive statement is reached at a model.

But UML2 is in other respects far as to formal diagrams with UML 1.4. Newly defined UML2 under the name UML 2.0 Diagram Interchange an exchange format for graphs, so that different tools with which models are created based on UML2, exchange and reuse the diagrams. In UML 1.x, this was only possible for the repository models behind the charts, but not for the actual diagrams.

Creating Charts

Diagrams of UML 2 can be created in various ways. If the notation of UML2 is used as a common language to be recorded in an analysis team draft analysis models on the whiteboard ( whiteboard ), rich pencils and paper as a tool. Often diagrams are created by UML2 but with the help of special programs ( UML tools ), which can be divided into two classes.

Programs in the first group assist in drawing diagrams of UML2, without having to take the model elements that correspond to the graphic elements on the charts, in a repository. This group includes all programs to create drawings.

The second group consists of programs that support the creation of models and drawing diagrams of UML2.

Exchange models and diagrams

Thus, models can be transferred from one tool to another, defines the Object Management Group is a standardized exchange format that is used for UML models. The format is based on the markup language XML and is called the XML Metadata Interchange ( XMI). The foundation for the interchangeability of the MOF, on the concept of both languages, UML and XMI are based.

For the UML 1.x versions of the format did not provide opportunity to exchange diagrams in a standardized format, which was perceived by many users as a major gap. Parallel to the development of the UML2 OMG has therefore also revised the standardized interchange format XMI. Described, inter alia, the gap is closed by the specification has been extended under the name UML 2.0 Diagram Interchange a format for the exchange of diagrams.

An exchange with other modeling languages is also possible by means of model-to- model transformation. To this end, the OMG standard MOF QVT defined. In contrast to a pure interchange format, a transformation can also include its own semantics. Thus it can be determined, for example, as a class model is mapped onto an ER model. The accompanying flexibility is particularly useful in the exchange between tools, since different providers almost always have individual variants of the UML metamodel.

Object-Modeling Technique Rational Software Association (object-oriented programming) Action (UML) Event (UML) Actor (UML) Timing diagram (Unified Modeling Language) Package (UML) Component (UML) Artifact (UML) Profile (UML) Node (UML) Finite-state machine IBM Rational Unified Process Round-Trip-Engineering Fundamental Modeling Concepts Martin Fowler Integrated Authority File

414232