(1) Hyperlink for Chapter Header: Aqua
(2) Hyperlinks for Section Heade: Fuchcia
(3) Chapter Header: Green
(4) Paragraphs inside the Chapters: Black
(5) Section Header: Lime
(6) Paragraphs inside the Sections: Purple
(7) Simple lists: Navy
(8) Firts Part of the Nested Lists: Maroon
(9) Second Part of the Nested Lists: Olive
(10) Figure Captions: Red
(11) Table Captions: Yellow
(12) Table Header: Gray
(13) Table Cells: Teal
(14) Other Hyperlinks: Blue
(15) End section and Date: Silver

     2 Conformance

          2.1 Language Units

          2.2 Compliance Levels

          2.3 Meaning and Types of Compliance

          2.4 Compliance Level Contents

2 Conformance     ^

UML is a language with a very broad scope that covers a large and diverse set of application domains. Not all of its modeling capabilities are necessarily useful in all domains or applications. This suggests that the language should be structured modularly, with the ability to select only those parts of the language that are of direct interest. On the other hand, an excess of this type of flexibility increases the likelihood that two different UML tools will be supporting different subsets of the language, leading to interchange problems between them. Consequently, the definition of compliance for UML requires a balance to be drawn between modularity and ease of interchange.

Experience with previous versions of UML has indicated that the ability to exchange models between tools is of paramount interest to a large community of users. For that reason, this specification defines a small number of compliance levels thereby increasing the likelihood that two or more compliant tools will support the same or compatible language subsets. However, in recognition of the need for flexibility in learning and using the language, UML also provides the concept of language units.

2.1 Language Units     ^

The modeling concepts of UML are grouped into language units. A language unit consists of a collection of tightly-coupled modeling concepts that provide users with the power to represent aspects of the system under study according to a particular paradigm or formalism. For example, the State Machines language unit enables modelers to specify discrete event-driven behavior using a variant of the well-known statecharts formalism, while the Activities language unit provides for modeling behavior based on a workflow-like paradigm. From the user’s perspective, this partitioning of UML means that they need only be concerned with those parts of the language that they consider necessary for their models. If those needs change over time, further language units can be added to the user’s repertoire as required. Hence, a UML user does not have to know the full language to use it effectively.

In addition, most language units are partitioned into multiple increments, each adding more modeling capabilities to the previous ones. This fine-grained decomposition of UML serves to make the language easier to learn and use, but the individual segments within this structure do not represent separate compliance points. The latter strategy would lead to an excess of compliance points and result to the interoperability problems described above. Nevertheless, the groupings provided by language units and their increments do serve to simplify the definition of UML compliance as explained below.

2.2 Compliance Levels     ^

The stratification of language units is used as the foundation for defining compliance in UML. Namely, the set of modeling concepts of UML is partitioned into horizontal layers of increasing capability called compliance levels. Compliance levels cut across the various language units, although some language units are only present in the upper levels. As their name suggests, each compliance level is a distinct compliance point.

For ease of model interchange, there are just four compliance levels defined for the whole of UML:

     • Level 0 (L0). This compliance level is formally defined in the UML Infrastructure. It contains a single language unit that provides for modeling the kinds of class-based structures encountered in most popular object-oriented programming languages. As such, it provides an entry-level modeling capability. More importantly, it represents a low-cost common denominator that can serve as a basis for interoperability between different categories of modeling tools.

     • Level 1 (L1). This level adds new language units and extends the capabilities provided by Level 0. Specifically, it adds language units for use cases, interactions, structures, actions, and activities.

     • Level 2 (L2). This level extends the language units already provided in Level 1and adds language units for deployment, state machine modeling, and profiles.

     • Level 3 (L3). This level represents the complete UML. It extends the language units provided by Level 2 and adds new language units for modeling information flows, templates, and model packaging.

The contents of language units are defined by corresponding top-tier packages of the UML metamodel, while the contents of their various increments are defined by second-tier packages within language unit packages. Therefore, the contents of a compliance level are defined by the set of metamodel packages that belong to that level.

As noted, compliance levels build on supporting compliance levels. The principal mechanism used in this specification for achieving this is package merge (see PackageMerge (from Kernel) on page 113). Package merge allows modeling concepts defined at one level to be extended with new features. Most importantly, this is achieved in the context of the same namespace, which enables interchange of models at different levels of compliance as described in Meaning and Types of Compliance on page 5.

Issue 9182 - clarify that UMLis a model package; also replace ‘UML’ with ‘L0’

For this reason, all compliance levels are ultimately merged into a single core UML model package that defines the common namespace shared by all the compliance levels. Level 0 is defined by the top-level metamodel shown in Figure 2.1. In this model, L0 is originally an empty package that simply merges in the contents of the Basic package from the UML Infrastructure. This package is then merged into the UML model. Package L0 contains elementary concepts such as Class, Package, DataType, Operation, etc. merged in from Basic and Primitive Types (see the UML 2.0 Infrastructure specification for the complete list of contents of these two packages).

Issue 9180 - replace with new L0 diagram

Issue 9182 -remove reference to UML package

At the next level (Level 1), the packages merged into Level 0 and their contents, are extended with additional packages as shown in Figure 2.2 on page 3. Note that each of the four packages shown in the figure merges in additional packages that are not shown in the diagram. They are defined in the corresponding package diagrams in this specification. Consequently, the set of language units that results from this model is more than is indicated by the top-level model in the diagram. The specific packages included at this level are listed in Table 2.3 on page 7.

Issue 9182 - replace with new L1 diagram

Issue 9182 -remove reference to UML package

Level 2 adds further language units and extensions to those provided by the Level 1. The actual language units and packages included at this level of compliance are listed in Table 2.4 on page 8.

Issue 9182 - replace with new L2 diagram

Finally, Level3, incorporating the full UML definition, is shown in Figure 2.4 on page 5. Its contents are described in Table 2.5 on page 8.

Issue 9182 - replace with new L3 diagram

2.3 Meaning and Types of Compliance     ^

Compliance to a given level entails full realization of all language units that are defined for that compliance level. This also implies full realization of all language units in all the levels below that level. Full realization for a language unit at a given level means supporting the complete set of modeling concepts defined for that language unit at that level.

Thus, it is not meaningful to claim compliance to, say, Level 2 without also being compliant with the Level 0 and Level 1. A tool that is compliant at a given level must be able to import models from tools that are compliant to lower levels without loss of information.

There are two distinct types of compliance. They are:

     • Abstract syntax compliance. For a given compliance level, this entails:

          • compliance with the metaclasses, their structural relationships, and any constraints defined as part of the merged UML metamodel for that compliance level and,• the ability to output models and to read in models based on the XMI schema corresponding to that compliance level.

          • Compliance to the notation defined in the Notation sections in this specification for those metamodel elements that are defined as part of the merged metamodel for that compliance level and, by implication, the diagram types in which those elements may appear. And, optionally: • The ability to output diagrams and to read in diagrams based on the XMI schema defined by the Diagram Interchange specification for notation at that level. This option requires abstract syntax and concrete syntax compliance.

Concrete syntax compliance does not require compliance to any presentation options that are defined as part of the notation.

Compliance for a given level can be expressed as:

     • abstract syntax compliance.

     • concrete syntax compliance .

     • abstract syntax with concrete syntax compliance.

     • abstract syntax with concrete syntax and diagram interchange compliance.

In case of tools that generate program code from models or those that are capable of executing models, it is also useful to understand the level of support for the run-time semantics described in the various Semantics subsections of the specification. However, the presence of numerous variation points in these semantics (and the fact that they are defined informally using natural language), make it impractical to define this as a formal compliance type, since the number of possible combinations is very large.

A similar situation exists with presentation options, since different implementors may make different choices on which ones to support. Finally, it is recognized that some implementors and profile designers may want to support only a subset of features from levels that are above their formal compliance level. (Note, however, that they can only claim compliance to the level that they fully support, even if they implement significant parts of the capabilities of higher levels.) Given this potential variability, it is useful to be able to specify clearly and efficiently, which capabilities are supported by a given implementation. To this end, in addition to a formal statement of compliance, implementors and profile designers may also provide informal feature support statements. These statements identify support for additional features in terms of language units and/or individual metamodel packages, as well as for less precisely defined dimensions such as presentation options and semantic variation points.

An example feature support statement is shown in Table 2.2 for an implementation whose compliance statement is given in

Table 2.1. In this case, the implementation adds two new language units from higher levels.

Note (1): States and state machines are limited to a single region Shallow history pseudostates not supported Note (2): FIFO queueing in event pool Note (3): Inherited elements indicated using grey-toned lines, etc.

2.4 Compliance Level Contents     ^

The following tables identify the packages by individual compliance levels in addition to those that are defined in lower levels (as a rule, Level (N) includes all the packages supported by Level (N-1)). The set of actual modeling features added by each of the packages are described in the appropriate chapters of the related language unit.

Issue 8459 - add CommonBehaviors::Communications entry

Issue 8459 - remove CommonBehaviors::Communications entry

Table 2.5 Metamodel packages added in Level 3