UML profile

Overview

To be a valid input into the mapping the application schema should conform to ISO 19109:2005, and GML 3.2 (ISO 19136) Annex E, GML 3.3 and/or ISO/TS 19139.

In addition, extensions to these latter specifications are supported, too, but must be activated in extended encoding rules; see here for details.

 

Stereotypes

Well-known stereotypes for the purposes of ShapeChange are those defined in the UML specification, and in the ISO 19100-series of specifications, specifically ISO/TS 19103:2005, ISO 19109:2005 and GML 3.2/ISO 19136:2007.

Stereotypes are not case-sensitive. The stereotypes used in the ISO 19100 standards usually start with a upper case letter, but today the common practice is to start with a lower case letter and avoid whitespace.

Standard aliases listed for a stereotype can be used, too. Aliases can be configured.

All stereotypes not listed below are ignored.

In UML 1, only one stereotype per model element are supported. UML 2 introduced the capability of model elements to carry more than one stereotype. This capability is not yet supported by ShapeChange. If a model element has more than one stereotype, an arbitrary stereotype from the list is used.

Stereotypes of packages

Stereotype Aliases Description
no stereotype <<bundle>>,<<leaf>> A <<leaf>> package is a package that is not an application schema and contains no packages. [ISO/TS 19103]. A <<bundle>> package is a package that is not an application schema and contains other packages [GSIP]. For encoding purposes, these stereotypes are not relevant and thus specified as an aliases to no stereotype.
<<Application Schema>> <<applicationSchema>>,<<schema>>,<<requirementsClass>> An application schema according to ISO 19109 [ISO 19109]. The alias <<schema>> has been introduced for packages that should be treated like application schemas, but do not contain feature types.

Stereotypes of classes

Stereotype Aliases Description
no stereotype <<abstract>> A standard class, instances are plain objects with identify. The stereotype <<abstract>> is used by some models, but should be avoided. If a class is abstract, this must be indicated using the UML flag for abstractness, not the stereotype. If the stereotype is provided, it is ignored.
<<DataType>> <<request>>, <<response>> A structured data type without identity [ISO/TS 19103]. The <<request>> and <<response>> stereotype were originally used in AFIS-ALKIS-ATKIS to distinguish data types for use in messages of services. For all encoding purposes these are treated as data types and are configured as aliases.
<<FeatureType>> <<feature>> A feature type [ISO 19136]. Some schemas have used <<Feature>>, so this has been added as an alias.
<<Enumeration>> An enumeration.
<<CodeList>> <<conceptScheme>>, <<vocabulary>> A code list. <<conceptScheme>> and <<vocabulary>> have been used to identify collections of enumerated values that may also have relationships like 'narrower'; for encoding purposes these are treated like code lists.
<<Union>> A structured data type without identity where exactly one of the properties of the type is present in any instance [ISO/TS 19103].
<<BasicType>> A basic type with a simple representation on most platforms. Usually it is a restriction of CharacterString or Number.
<<Interface>> For the purpose of transfer application schemas, this is the same as <<Type>>, see below.
<<Type>> <<interface>> A type that is not directly instantiable, but is used as an abstract collection of operation, attribute and relation signatures. This stereotype should usually not be used in application schemas as these are on a different conceptual level than classes with the <<type>> stereotype. In the encoding these will usually be treated as if no stereotype has been set. <<Type>> has been deprecated in UML 2 and <<Interface>> should be used instead.
<<FachId>> OKSTRA feature types where instances may be referenced through symbolic links. See the OKSTRA documentation (in German)."
<<Schluesseltabelle>> OKSTRA Schlüsseltabellen. See the OKSTRA documentation (in German)."
<<ADEElement>> Feature type in an CityGML Application Domain Extension (ADE) that contains only properties that are generic application extensions.
<<featureConcept>> A feature concept in a feature concept dictionary (see ISO 19126). If a feature type classifier has a dependency to a feature concept classifier of the same name, ShapeChange will use the documentation of the concept as the documentation of the feature type, if the documentation of the feature type classifier is empty.
<<attributeConcept>> An attribute concept in a feature concept dictionary (see ISO 19126). If a feature type classifier has a dependency to an attribute concept classifier and a property of the same name, ShapeChange will use the documentation of the concept as the documentation of the property, if the documentation of the property is empty.
<<valueConcept>> A nominal value concept in a feature concept dictionary (see ISO 19126). If an enumeration has a dependency to an value concept classifier and an enumerant of the same name, ShapeChange will use the documentation of the concept as the documentation of the enumerant, if the documentation of the enumerant is empty.
<<AIXMExtension>> Type defined in an AIXM extension schema. It extends a specific feature or object type or all feature types, usually from the core AIXM schema.

Stereotypes of properties

Stereotype Aliases Description
no stereotype <<property>> The standard case for properties.
<<version>> If in an application schema an association role ends at a spatial object type, this stereotype denotes that the value of the property is meant to be a specific version of the spatial object, not the spatial object in general. [INSPIRE]
<<voidable>> If a characteristic of an object is not present, but may be present or applicable in the real world, this can be reflected using this stereotype. This is a shorthand notation for a union type of the normal value range with a void/nil value plus an optional reason for the void/nil value. [INSPIRE]

Stereotypes of dependencies

Stereotype Aliases Description
no stereotype For package dependencies without a stereotype, <<import>> is implied (source: ISO 19136:2007, section E.2.1.1.1).
<<import>> The model elements of the supplier package are imported.

NOTE: ShapeChange stores package dependencies without stereotypes. In other words, stereotypes on package dependencies are ignored (thus, it does not matter if such a dependency has the stereotype <<import>>, <<include>>, or any other stereotype). ShapeChange determines if an application schema has a dependency on a different application schema by examining the target namespaces of both packages; if they are different, the two packages belong to different application schema – otherwise, they belong to the same schema.

Stereotypes of generalizations

Stereotype Aliases Description
no stereotype The standard case.
<<disjoint>> The constraint added to a set of generalization relationships indicates that an instance of the parent may be an instance of one and only one of the children within the set. This is implicitly assumed to be the case.

NOTE: ShapeChange ignores stereotypes on generalizations.

Tagged Values

Tagged values are used to represent additional information in the UML model that are either specific to an encoding or which require a name-value-pair.

To document: “xsdDerivation”, “gmlAsGroup”, “length”, “base”, “rangeMinimum”, “rangeMaximum”, “default”, “nilReasonAllowed”, “gmlImplementedByNilReason”, “primaryCode”, “secondaryCode”, “oclExpressions”, “schPatterns”, “unitMeasure”, “voidable”, “description”, “infoURL”, “gmlAsCharacterString”, “gmlMixin”, “nillable”, “suppress”, “codeList”, “codeListValuePattern”, “codeListRepresentation”, “uomResourceURI”, “uomResourceValuePattern”, “uomResourceRepresentation”, “physicalQuantity”, “recommendedMeasure”, “noncomparableMeasure”

Tagged values of all model elements

Tagged Value Stereotype Description
documentation any stereotype The documentation for the model element. [UML]
xsdEncodingRule any stereotype XML Schema encoding rule to apply. Default is iso19136_2007.
alias any stereotype An alias of the name of the model element, usually for presentation to a human.

Tagged values of packages

Tagged Value Stereotype Description
targetNamespace <<applicationSchema>>  The target XML namespace of the application schema [ISO 19136]
xmlns <<applicationSchema>> Namespace prefix to be used as short form of the target namespace [ISO 19136]
version <<applicationSchema>> Current version of the application schema [ISO 19136]
xsdDocument <<applicationSchema>>, no stereotype Name of an XML Schema document to create representing the content of the package [ISO 19136]
gmlProfileSchema <<applicationSchema>> URL of the schema location of a GML profile (where applicable) [ISO 19136]

Tagged values of classes

Tagged Value Stereotype Description
noPropertyType no stereotype,<<featureType>>,<<type>>,<dataType>>,<<union>> Suppress creation of a standard property type that supports inline or by-reference encoding [ISO 19136]. For data types only inline encoding is supported. Should usually be set to false.
byValuePropertyType no stereotype,<<featureType>>,<<type>> Create a property type that requires that the instance is encoded inline [ISO 19136]. Should usually be set to false.
isCollection no stereotype,<<featureType>>,<<type>> Identifies the type as a collection [ISO 19136].
asDictionary <<codeList>> If the value is 'false' the code list will be encoded with the pre-defined enumerants as values in the schema, if 'true' all enumerants will only be maintained in external dictionaries. The default depends on the encoding rule used [ISO 19136, GML 3.3].
defaultCodeSpace <<codeList>> The URI of the default dictionary that contains code list [ISO 19136].
codeList <<codeList>> The URI of the code list dictionary. This is similar to 'defaultCodeSpace', but is less GML-specific. Alias to 'vocabulary'.
resourceURI <<codeList>> Alias to 'vocabulary'.
xmlSchemaType <<type>> If the type has a canonical XML Schema encoding the XML Schema typename corresponding to the data type shall be given as the value [ISO 19136].
gmlMixin no stereotype, <<type>>, <<featureType>> Identifies the type as a mixin type that will not be encoded as a separate element/type in the XML encoding, but properties will be copied to subtypes. This is a ShapeChange extension.
extensibility <<codeList>> This refers to extensions by a third party, not to extensions by the owner of the vocabulary; the owner will always be able to revise the vocabulary. I.e., if the value is 'none', the referenced vocabulary may not be extended by third parties; if the value is 'narrower', the vocabulary may be extended by narrower terms that have an existing term as a parent; if the value is 'any', the vocabulary may be extended by additional terms on any level. This value must be 'any', empty or missing, if the value 'vocabulary' is empty or missing; in this case any vocabulary may be used. [INSPIRE]
vocabulary <<codeList>> URI of the vocabulary/code list in a registry. [INSPIRE]

Tagged values of properties

Tagged Value Stereotype Description
sequenceNumber any stereotype Unique integer value for properties of the type used to sort properties [ISO 19136].
inlineOrByReference any stereotype Controls whether property values may be encoded inline or by reference. Valid values are 'inline', 'byReference' and 'inlineOrByReference'. Default is 'inlineOrByReference'. [ISO 19136]
isMetadata any stereotype Indicates whether the property is considered metadata about the instance – and not information about the phenomenon in the real world [ISO 19136]. 'true' or 'false', the default is 'false'.
obligation any stereotype The value type of the property must be a <<codeList>>. The use of the referenced code list may be made legally required in the implementing rule ('implementingRule') or only in the technical guidance ('technicalGuidance'). This value must be empty or missing, if the value 'vocabulary' in the value type is empty or missing. [INSPIRE]
xsdAsAttribute any stereotype If set to true, the property has a maximum multiplicity of 1 and the value of the property is simple, a value of 'true' converts the property to an XML attribute instead of an XML element.

 

OCL Constraints

In an extension to the standard encoding rules, ShapeChange supports also parsing of OCL constraints in the application schema (not for XMI 1.0 models, as these have no standard mechanism for representing constraints). The supported set of expressions is documented here.

If the UML tool does not support OCL constraints directly, constraints may also be represented in a tagged value “oclExpressions”.

 

Requirements of the XML Schema output target

All model elements in application schema packages must meet the requirements in this section, if the XML Schema target is used.

Requirements for all model elements

None at the moment

Requirements for packages

Identifier Descriptions
req-xsd-pkg-xsdDocument-unique All tagged values xsdDocument in a UML model must be unique.

Requirements for classes

Identifier Descriptions
req-xsd-cls-ncname Each class name must be a NCName.
req-xsd-cls-name-unique All class names within the same application schema must be unique.
req-xsd-cls-mixin-supertypes Mixin classes must have no instantiable supertypes.
req-xsd-cls-mixin-supertypes-overrule Overrules req-xsd-cls-mixin-supertypes and allows that mixin classes may have supertypes that are not mixin.

Requirements for properties

Identifier Descriptions
req-xsd-prop-value-type-exists The value type shall either be a predefined type or a class defined in the UML model.
req-xsd-prop-data-type If the value type is data type, the property must be an attribute or a composition.
req-xsd-prop-ncname The property name must be a NCName.

GML requires that a tagged value “sequenceNumber” shall be specified for every attribute. The value shall be an integer and be unique for all attributes and association ends of a class. As the sequenceNumber values are used to organize the properties of a class, this cannot be tested in the validation step, but errors are reported during the initial processing of the model.

ShapeChange supports a more flexible approach for sequenceNumber values than the GML standard:

  • the value may omitted in which case ShapeChange determines its own order;
  • the value may be a structured integer, e.g. values like “4.2.3”.

Multiplicities and visibility are also evaluated during the initial model read process and cannot be validated at a later stage. Any errors and warnings are reported while reading the model.

Requirements for associations

Navigability is evaluated during the initial model read process and cannot be validated at a later stage. Any errors and warnings are reported while reading the model.

 

Additional Requirements

These requirements may be added in encoding rules.

Requirements for all model elements

Identifier Descriptions
req-all-all-documentation Name and definition separators ('– Name –' and '– Definition –') must be included in the documentation (Source: INSPIRE).

Requirements for packages

Identifier Descriptions
req-xsd-pkg-targetNamespace The tagged value targetNamespace must be set, if the package is an application schema. If the tagged value is missing a default value will be used.
req-xsd-pkg-xmlns The tagged value xmlns must be set, if the package is an application schema.
rec-xsd-pkg-version The tagged value version should be set, if if the package is an application schema. If the tagged value is missing a default value will be used.
req-xsd-pkg-xsdDocument The tagged value xsdDocument must be set, if the package is an application schema. If the tagged value is missing a name will still be constructed from the package name.
req-xsd-pkg-dependencies All dependencies must be between schema packages (i.e., packages with a targetNamespace).
"req-xsd-pkg-namespace-schema-only"
The tagged values targetNamespace and xmlns may only be set, if the package is an application schema.

Requirements for classes

Identifier Descriptions
req-xsd-cls-generalization-consistent A generalization relationship may be specified only between two classes that are either: both feature types, both object types, or both data types.
req-xsd-cls-codelist-asDictionary-true For code lists the tagged value asDictionary must be 'true' (Source: INSPIRE).
req-xsd-cls-codelist-extensibility-values For code lists the tagged value extensibility must be empty, narrower, any (Source: INSPIRE).
req-xsd-cls-codelist-extensibility-vocabulary For code lists the tagged value extensibility!=any implies that a vocabulary is provided (Source: INSPIRE).
req-xsd-cls-codelist-no-supertypes Code lists must have no supertypes (Source: INSPIRE?).
req-xsd-cls-datatype-noPropertyType For data types the tagged value noPropertyType must be 'false' (Source: INSPIRE).
req-xsd-cls-enum-no-supertypes Enumerations must have no supertypes (Source: INSPIRE).
req-xsd-cls-objecttype-byValuePropertyType For types with identity the tagged value byValuePropertyType must be 'false' (Source: INSPIRE).
req-xsd-cls-objecttype-noPropertyType For types with identity the tagged value noPropertyType must be 'false' (Source: INSPIRE).
req-xsd-cls-suppress-no-properties If the tagged value suppress is 'true' the class must have no properties (Source: Metadata profiling).
req-xsd-cls-suppress-subtype If the tagged value suppress is 'true' the class must have no unsuppressed subtype (Source: Metadata profiling).
req-xsd-cls-suppress-supertype If the tagged value suppress is 'true' the class must have an instantiable supertype (Source: Metadata profiling).

Requirements for properties

Identifier Descriptions
req-xsd-prop-codelist-obligation For code lists, a tagged value obligation must exist (Source: INSPIRE).

Requirements for associations

None at the moment