|Previous||UML Classes||Table of Contents||UML Packages||Next|
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.
• Concrete syntax compliance. For a given compliance level, this entails
• 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.
|Compliance level||Abstract Syntax||Concrete Syntax||Diagram Interchange Option|
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.
Feature Support Statement
|Language Unit||Packages||Abstract Syntax||Concrete Syntax||Semantics||Presentation Options|
|Deployments||Deployments::Artifacts (L2) Deployments::Nodes (L2)||YES||YES||Note (4)||Note (5)|
|State Machines||StateMachines::BehaviorStateMachines (L2) StateMachines::ProtocolStateMachines (L3)||Note (1)||YES||Note (2)||Note (3)|
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.