Legend for UML Modelling

This annex explains the UML elements used in this specification. For more information, please refer to the comprehensive literature available for UML. The formal specification can be found in [12].

Figure 1 shows a class with name "Class1" and an attribute with name "attr" of type Class2. Attributes are owned by the class. Some of these attributes may represent the end of binary associations, see also Figure 9. In this case, the instance of Class2 is navigable via the instance of the owning class Class1.^[1]

Figure 2 shows that Class4 inherits all member elements from Class3. Or in other word, Class3 is a generalization of Class4, Class4 is a specialization of Class3. This means that each instance of Class4 is also an instance of Class3. An instance of Class4 has the attributes attr1 and attr2, whereas instances of Class3 only have the attribute attr1.

Figure 3 defines the required and allowed multiplicity/cardinality within an association between instances of Class1 and Class2. In this example, an instance of Class2 is always related to exactly one instance of Class1. An instance of Class1 is either related to none, one, or more (unlimited, i.e. no constraint on the upper bound) instances of Class2. The relationship can change over time.

Multiplicity constraints can also be added to attributes and aggregations.

The notation of multiplicity is as follows:

<lower-bound>.. <upper-bound>

where <lower-bound> is a value specification of type Integer - i.e. 0, 1, 2, … - and <upper-bound> is a value specification of type UnlimitedNatural. The star character (*) is used to denote an unlimited upper bound.

The default is 1 for lower-bound and upper-bound.

A multiplicity element represents a collection of values. The default is a set, i.e. it is not ordered and the elements within the collection are unique and contain no duplicates. Figure 4 shows an ordered collection: the instances of Class2 related to an instance of Class1. The stereotype <<ordered>> is used to denote that the relationship is ordered.

Figure 5 shows that the member ends of an association can be named as well, i.e. an instance of Class1 can be in relationship "relation" to an instance of Class2. Vice versa, the instance of Class2 is in relationship "reverseRelation" to the instance of Class1.

Figure 6 depicts two classes connected by a unidirectional association from Class1 to Class2. In this association, only the endpoint is navigable, meaning it is possible to navigate from an instance of Class1 to an instance of Class2, but not the other way around. An instance of Class1 can be in a 'relation' with an instance of Class2, and the association is labeled 'Reference'.

A specialty in Figure 6 is that the label 'Reference' indicates the relationship between Class1 and Class2 is of a Reference type. This means that an instance of Class1 holds a reference to an instance of Class2. Furthermore, the instance of Class2 is considered 'referable' according to the Asset Administration Shell metamodel, implying that it inherits from the predefined abstract class 'Referable' in the AAS framework. The structure of a reference to a model element of the Asset Administration Shell is explicitly defined.

Figure 7 shows a composition, also called a composite aggregation. A composition is a binary association, grouping a set of instances. The individuals in the set are typed as specified by Class2. The multiplicity of instances of Class2 to Class1 is always 1 (i.e. upper-bound and lower-bound have value "1"). One instance of Class2 belongs to exactly one instance of Class1. There is no instance of Class2 without a relationship to an instance of Class1. Figure 7 shows the composition using an association relationship with a filled diamond as composition adornment.

Figure 8 shows an aggregation. An aggregation is a binary association. In contrast to a composition, an instance of Class2 can be shared by several instances of Class1. Figure 8 shows the shared aggregation using an association relationship with a hallow diamond as aggregation adornment.

Figure 9 illustrates that the attribute notation can be used for an association end owned by a class. In this example, the attribute name is "attr" and the elements of this attribute are typed with Class2. The multiplicity, here "0..*", is added in square brackets. If the aggregation is ordered, it is added in curly brackets like in this example.

Figure 10 shows a class with three attributes with primitive types and default values. When a property with a default value is instantiated in the absence of a specific setting for the property, the default value is evaluated to provide the initial values of the property.

Figure 11 shows that there is a dependency relationship between Class1 and Class2. In this case, the dependency means that Class1 depends on Class2 because the type of attribute attr depends on the specification of class Class2. A dependency is depicted as dashed arrow between two model elements.

Figure 12 shows an abstract class. It uses the stereotype <<abstract>>. There are no instances of abstract classes. They are typically used for specific member elements that are inherited by non-abstract classes.

Figure 13 shows a package named "Package2". A package is a namespace for its members. In this example, the member belonging to Package2 is class Class2.

Figure 14 shows that all elements in Package2 are imported into the namespace defined by Package1. This is a special dependency relationship between the two packages with stereotype <<import>>.

[image-76-enumeration] shows an enumeration with the name "Enumeration1". An enumeration is a data type with its values enumerated as literals. It contains two literal values, "a" and "b". It is a class with stereotype <<enumeration>>. The literals owned by the enumeration are ordered.

Figure 15 shows how a note can be attached to an element, in this example to class "Class1".

Figure 16 shows how a constraint is attached to an element, in this example to class "Class1".

The following rules are used for naming of classes, attributes etc.:

In UML, the convention is to name associations and aggregations in singular form. The multiplicity is to be taken into account to decide on whether there are none, a single, or several elements in the corresponding association or aggregation.

At first glance, there seems to be some overlapping within the concepts of data specification templates, extensions, inheritance, qualifiers, and categories introduced in the metamodel. This clause explains the commonalities and differences and gives hints for good practices.

In general, an extension of the metamodel by inheritance is foreseen. Templates might also be used as alternatives.

Specific graphical modelling rules, which are used in this specification but not included in this form, are explained below [12].

Figure 17 shows different graphical representations of a composition (composite aggregation). In Variant A, a relationship with a filled aggregation diamond is used. In Variant B, an attribute with the same semantics is defined. And in Variant C, the implicitly assumed default name of the attribute in Variant A is explicitly stated. This document uses notation B.

It is assumed that only the end member of the association is navigable per default, i.e. it is possible to navigate from an instance of Class1 to the owned instance of Class2 but not vice versa. If there is no name for the end member of the association given, it is assumed that the name is identical to the class name but starting with a small letter – compared to Variant C.

Class2 instance only exists if the parent object of type Class1 exists.

Figure 18 shows a representation of a shared aggregation: a Class2 instance can exist independently of a Class1 instance. It is assumed that only the end member of the aggregation association is navigable per default, i.e. it is possible to navigate from an instance of Class1 to the owned instance of Class2 but not vice versa.

Figure 19 show different graphical representations of generalization. Variant A is the classical graphical representation as defined in [12]. Variant B is a short form. The name of the class that Class3 is inheriting from is depicted in the upper right corner.

Variant C not only shows which class Class3 instances are inheriting from, but also what they are inheriting. This is depicted by the class name it is inheriting from, followed by "::" and then the list of all inherited elements – here attribute class2. Typically, the inherited elements are not shown.

Figure 20 depicts different graphical notations for enumerations in combination with inheritance. On the left side "Enumeration1" additionally contains the literals as defined by "Enumeration2".

Figure 21 shows an experimental class, marked by the stereotype "Experimental".

Figure 22 depicts a deprecated class, which is marked by the stereotype "Deprecated".

Figure 23 shows a class representing a template. It is marked by the stereotype "Template".