The OMG's UML Specification

Using UML in Innovator

Innovator for Software Architects contains model templates with special profiles which implement the Object Management Group's (OMG) "Unified Modeling Language" (UML) standard. Other Innovator products also use some UML elements (e.g. classes, use cases).

All essential UML 2 specification aspects are addressed in this document; this is done to highlight the transfer of these constructs in the Innovator profiles.

You will learn

• How the OMG's UML specification is structured

• Which base constructs are used in the UML 2 metamodel

• How models and packages are defined

• How elements and relationships are assigned to semantic levels

• How the extension mechanism is defined with profiles

Structure

The OMG UML 2 specification comprises two documents:

• "Infrastructure" is an MOF 2-compliant metamodel for UML 2
• "Superstructure" defines the syntax and semantic of the UML 2 model elements

This document directly affect UML:

• "Object Constraint Language (OCL)" defines how restrictions are expressed in the three other documents

It is essential to understand the "Superstructure" document to be able to configure profiles. The other documents are not taken into consideration here.

The most important concepts of the "UML 2 Superstructure" specification shall be mentioned here in short form. Extracts from the "OMG Unified Modeling Language (OMG UML), Superstructure, V2.4.1" (OMG Document Number: formal/2011-08-06) will be used during the following explanations.

The following illustration identifies the areas covered by the current UML standard and how they relate to each other. The items in the upper layers depend on those in the lower layers but not the other way round.

Figure: A Schematic of the UML Semantic Areas (UML Superstructure V2.4.1, Figure 6.1)

The three layers separated from each other in the highest level of abstraction can be differentiated from one another:

• The base of the hierarchy describes the statistical part of a model using "structural entities". This reflects the premise that there is no disembodied behavior in UML – all behavior is the consequence of the actions of structural entities.

  This level is described in the four chapters of part I:

  • "Classes"

  • "Components"

  • "Composite Structures" and

  • "Deployments"

• The layer above is the dynamic nature and shows the basis for semantic description of all complex behavior patterns. This layer is made up of three separate areas which are, in turn, combined into two sub layers:

  • The bottom layer consists of the "inter-object behavior base" (which deals with how structural entities communicate with each other) and the "intra-object behavior base" (which addresses the behavior occurring within structural entities). This layer is described in the "Common Behavior" chapter of part II.

  • The "actions" layer defines the semantics of a multitude of actions. Actions show the most basic entities which a behavior can be defined with in the UML. This layer is described in the "Actions" chapter of part II.

• The top-most hierarchy level defines the semantic of the UML's most significant behavior models: "activities", "state machines" and "inter-actions". This level is described in three chapters of part II:

  • "Activities"

  • "Interactions" and

  • "State Machines"

The "Use Cases" chapter can also be found in the behavior section in UML, even though the individual constructs are clearly of a static nature.

The third section (part III) of the specification concerns the constructs supported (models, profiles).

Base constructs

The "Kernel" package (from the lowest layer) contains the core concept for modeling in UML. It represents the core modeling concepts of the UML, such as e.g. classes, (directional and non-directional) relationships and packages. Many of these base constructs are specialized at a later stage and given additional properties and relationships.

Figure: Root Diagram of the Kernel Package (UML Superstructure V2.4.1, Figure 7.3)

Multiplicities Diagram of the Kernel Package (UML Superstructure V2.4.1, Figure 7.5)

A large number of relationships between UML 2 metaclasses are specializations of both the "ownedElement" or "source" and/or "target" elementary relationships from the section of the kernel package shown. Special "ownedElement" relationships can be found between a great variety of metaclasses, "source" and/or "target" relationships are, on the other hand, are substantiated by a respective directed relationship's instance.

There are other generic relationships, such as e.g. the "type" relationship between both the abstract metaclasses "TypedElement" (this includes attributes and parameters etc.) and "Type" (this includes all "Classifier", i.e. similar metaclasses, such as components, interfaces etc.).

Models and Packages

A model is an abstraction of a physical system from a certain perspective and for a defined purpose. This purpose determines which information is stored in a model and, vice versa, what is irrelevant for this model. A model is complete in the sense that it covers the whole physical system, although only those aspects relevant to its purpose are represented in the model.

A model contains three major categories of elements: classifiers, events and behaviors. Each main category abstracts specific "individuals" from an implementation of the modeling system:

• A classifier describes a set of objects; an object is an individual thing with a state and relationships to other objects.

• An event describes a set of possible occurrences; an occurrence is something that "happens" that has some consequence within the system.

• A behavior describes a set of possible executions; an execution is the performance of an algorithm according to a set of rules.

The elements in a model are organized into a containment hierarchy where the top-most package or subsystem represents the boundary of the physical system.

The model may also contain elements describing relevant parts of the system's environment. The environment is typically modeled by actors and their interfaces.

As these are external to the physical system, they reside outside the package/ subsystem hierarchy. They are then either immediately stored in the model itself or collected in a separate package.

A system model is a stereotyped (see below for more information about stereotypes) model in the UML which contains various models of the same physical system.

Figure: Packages Diagram of the Kernel Package, Detail (UML Superstructure V2.4.1, Figure 7.14)

A package is used to group elements and provides a joint namespace for these elements. A package's contents consists of so-called "packageable elements". Classes, events etc. belong to these, as well as packages themselves; this enables the packages to be hierarchically arranged. A package is the owner of these elements. This means that all elements contained are deleted from a model as soon as this package is deleted.

Semantic Levels

A large number of UML metaclasses can be arranged into 4 semantic levels relationships among the metaclasses in the different levels that often transcend different semantic categories (e.g., classifiers, events, behaviors) are normally found within the same semantic level.

The type level represents generic entity types, such as classes, states, activities, events, etc. A model is normally made up of elements from this semantic level.

The runtime environment's elements which are abstracted by a model are found in the instance level. Even though these elements would be sufficient for the term model for all intents and purposes, there are no corresponding metaclasses in the UML 2 metamodel or the UML 2 models (unlike the other levels, the instance level describes the MOF level 0 and not the level 1 and, therefore, do not belong to the UML 2 specification).

Value specification. The specification of a value is not necessarily an instance; it might be a large set of possible instances consistent with certain conditions. Instances are not normally present in models (individual values) but specifications of values that may or may not be limited to a single value. Due to this, UML 2 models only ever contain specifications of values and not the values themselves; these only exist upon runtime.

Individual appearances of a type within a context. This level describes roles within a generic, reusable context. When their context is instantiated, they are also bound to contained instances, but as model elements they are reusable structural parts of their context; they are not instances themselves.

Due to a (largely) consistent naming of metaclasses, the OMG tried to highlight the assignment of an element or a relationship to one of the four semantic levels.

Table: Examples for Metaclasses in the Semantic Levels of UML 2

Type Level	Instance Level	Value Specification	Use
Classifier, Class	Instance, Object	Instance Specification	Role, Attributes etc.
Event	Incidence	Existence Specification	Varies (e.g. Trigger)
Behaviors	Execution	Execution Specification	Reference (e.g. interaction reference) but not standard (e.g. also activity nodes)

UML Extension Mechanism

Further Information

http://www.uml.org/