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 63 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 70. In this case, the instance of Class2 is navigable via the instance of the owning class Class1.^[1]

Figure 64 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 65 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 66 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 67 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 68 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 69 shows the composition using an association relationship with a filled diamond as composition adornment.

Figure 69 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 69 shows the shared aggregation using an association relationship with a hallow diamond as aggregation adornment.

Figure 70 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 71 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 72 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 73 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 74 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 75 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>>.

Figure 76 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 78 shows how a note can be attached to an element, in this example to class "Class1".

Figure 79 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 81 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 82 shows different representations of a shared aggregation: a Class2 instance can exist independently of a Class1 instance; it only references the instances of Class2. Now an attribute with the same semantics is defined In Variant B. The reference is denoted by a star added after the type of the attribute.

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. Otherwise, variant B would not be identical to Variant A.

A specialty in Figure 82 is that the aggregated instances are referables in the sense of the Asset Administration Shell metamodel (i.e. they inherit from the predefined abstract class "Referable"). This is why Variant B is identical to Variant A. This would not be the case for non-referable elements in the metamodel. The structure of a reference to a model element of the Asset Administration Shell is explicitly defined. A model reference consists of an ordered list of keys. The last key in the key chain shall reference an instance of type Class2 (i.e. Reference.

Figure 83 show different graphical representations of generalization. Variant A is the classical graphical representation as defined in [12]. Variant B is a short form, if Class1 is not on the same diagram. 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 84 depicts different graphical notations for enumerations in combination with inheritance. On the left side "Enumeration1" additionally contains the literals as defined by "Enumeration2".

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

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

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