Asset Oriented Modeling (AOM)

- Annotation -

Annotations are an extension mechanism, similar to tagged values in UML. The definition of annotations is optional.

Annotations can be defined on model level, in Level 2 Structures and in assets. The application target of an annotation can be different from the place of their definition. Annotations can be applied to assets, arcs or properties. The application target can be specified with a context expression.

However, the application target of an annotation must reside inside the borders of the annotation's container. An annotation defined in an asset can be applied to the asset itself, to outgoing arcs of that assets and to properties (or sub-properties) of that asset. An annotation defined in an L2S can be applied to assets within this L2S and their outgoing arcs and properties.

Annotations can contain plain text or an XML element. The element tag can be equipped with a namespace prefix which must be declared in the global model settings. 

Example

The following annotation could be defined in an asset. It applies to property color and annotates it with value blue.

color::blue

The following annotation could be defined on model level or in an L2S. It applies to property id of asset customer and annotates it with value <xsg:attribute>. The namespace prefix xsg must be specified in the global model settings.

/customer/id::<xsg:attribute/>

Annotation scripts

Often annotations are used to define implementation specific extensions. This can become contra productive - models are overcrowded with implementation detail. An ideal model should not contain implementation detail.

Annotations describing implementation detail should therefore be defined separately in an annotation script. Annotation scripts can be tied to a model via the models default namespace - each annotation script belonging to the model has the same default namespace. One model can own several annotation scripts describing different implementation variants.

Conflict resolution

Depending on the semantics of the respective extension mechanisms, annotation definitions within a model may conflict with each other. If such conflicts occur, they are resolved in the following order:

• Annotations defined in an L2S override conflicting annotations defined on model level.
• Annotation defined in an inner L2S override conflicting annotations defined in an outer L2S.
• Annotations defined in an asset override conflicting annotations defined in an L2S or on model level.
• Annotations defined in an annotation script will override any conflicting annotations in the model definition (when the script is applied to the model).
• Within the same structure, later annotations will override preceding conflicting annotations.

Contact: info@aoModeling.org