5 Model elements and notations

32.1563GPPFixed Mobile Convergence (FMC) model repertoireRelease 17Telecommunication managementTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 General

Note that the graphical notation in this document is only used to represent particular model elements. Although the graphical notation is a correct representation of the model element, it may not be a valid representation of a UML class diagram.

The examples used in this document are for illustration purposes only and may or may not exist in specifications.

UML properties not described in this document shall not be used in specifications based on this repertoire.

5.2 Basic model elements

UML has defined a number of basic model elements. This subclause lists the subset selected for use in specifications based on this repertoire. The semantics of these selected basic model elements are defined in [1].

For each basic model element listed, there are three parts. The first part contains its description. The second part contains its graphical notation examples and the third part contains the rule, if any, recommended for labelling or naming it.

The graphical notation has the following characteristics:

 Subclause 7.2.7 of [2] specifies "A class is often shown with three compartments. The middle compartment holds a list of attributes while the bottom compartment holds a list of operations" and "Additional compartments may be supplied to show other details". This repertoire only allows the use of the name (top) compartment and attribute (middle) compartment. The operation (bottom) compartment may be present but is always empty.

 Classes may or may not have attributes. The graphical notation of a class may show an empty attribute (middle) compartment even if the class has attributes, as shown in figure below.

 The visibility symbol shall not appear along with the class attribute, as shown below.

 The use of the decoration, i.e. the symbol in the name (top) compartment, is optional.

5.2.1 Attribute

5.2.1.1 Description

An attribute is a typed element representing a property of a class (Unified Modelling Language (OMG UML), Infrastructure [1], clause 10.2.5.). An element that is typed implies that the element can only refer to a constrained set of values. See clause 10.1.4 of [1] for more information on type.

See clauses 5.3.4 and 5.4.3 for predefined data types and user-defined data types that can apply type information to an attribute.

The properties of an attribute are described by a set of attribute properties categorized as follows:

– Attribute properties defining valid attribute values: type, allowedValues, multiplicity, isOrdered, isUnique, isNullable, passedById.

– Attribute properties defining valid interactions of managers and agents with attributes values: isInvariant, isWritable, isReadable, isNotifyable, defaultValue.

– Other attribute properties: documentation, supportQualifier.

The following tables provide definitions for the attributes of the three categories.

Table 5.2.1.1-1: Attribute properties defining valid attribute values

Property name	Description	Legal values
type	Refers to a predefined (subclause 5.4.3) or user defined data type (section 5.3.4). See also subclause 7.3.44 of [2], inherited from StructuralFeature.	NA
allowedValues	Specifies restrictions to the data type defined by type. This property is useful when no dedicated data type, that includes the restriction, shall be defined. The property may be absent when no restrictions are defined.	Dependent on type
defaultValue	Identifies a value at specification time that is used at object creation time under conditions defined in Annex B. If there is no defined default value, the property shall be omitted from the attribute description or specified as ‘defaultValue: None.’.	None (default) or a value that is dependent on allowedValues
multiplicity	Defines the number of values the attribute can simultaneously have. See subclause 7.3.44 of [2]; inherited from StructuralFeature.	See 5.2.8 Default is 1
isOrdered	For a multi-valued multiplicity, this specifies if the values of this attribute instance are sequentially ordered. See subclause 7.3.44 and its Table 7.1 of [2]. If the property is present for attributes with a multiplicity of greater than “1”, it shall be set to either “True” or “False”. It shall not be set to “N/A”.	True, False (default)
isUnique	For a multi-valued multiplicity, this specifies if the values of this attribute instance are unique (i.e., no duplicate attribute values). See subclause 7.3.44 and its Table 7.1 of [2]. If the property is present for attributes with a multiplicity of greater than “1”, it shall be set to either “True” or “False”. It shall not be set to “N/A”.	True (default), False
isNullable	Identifies if an attribute can carry no information. The implied meaning of carrying “no information” is context sensitive and is not defined in this Model Repertoire. Note, the property "isNullable: True" is semantically identical to adding the value "0" to the "multiplicity" specified. Usage of the "multiplicity" property is preferred to express an attribute can have no value or carry no information.	True, False (default)
passedById	See Table 5.2.9.1-1: passedById property	True, False (default)

Table 5.2.1.1-2: Attribute properties defining valid interactions with attributes

Property name	Description	Legal values
isInvariant	If an attribute has an "isInvariant: True" property, its value can be set only upon object creation. After object creation, the initial value cannot be modified. If an attribute has an "isInvariant: False" property, its value can be set at object creation time. After object creation, the initial value can be modified. Details on how initial values are provided upon object creation are specified in Annex B.	True, False (default)
isWritable	If an attribute has an "isWritable: True" property, a manager can set its value upon object creation. After object creation, a manager can modify the initial value if "isInvariant: False". If "isInvariant: True", a manager cannot modify the initial value. The "isInvariant" property supersedes hence the "isWritable" property. If an attribute has an "isWritable: False" property, a manager cannot set the value upon object creation nor modify it later. A "isWritable: True" property might be restricted by access control.	True, False (default)
isReadable	Specifies if the attribute can be read by a manager. A "isReadable: True" property might be restricted by access control.	True , False (default)
isNotifyable	Identifies if a notification shall be sent in case of an attribute value change.	True (default), False

Table 5.2.1.1-3: Attribute properties related to the specification of attributes

Property name	Description	Legal values
documentation	Contains a textual description of the attribute. Should refer (to enable traceability) to the specific requirement.	Any
supportQualifier	Identifies the required support of the attribute. See also subclause 6.	M, O (default), CM, CO, C

Upon completion of any manipulation of an attribute the attribute properties related to valid attribute values shall be respected. If an interaction results in violating at least one of these properties, the manipulation request shall be rejected.

5.2.1.2 Example

This example shows three attributes, i.e., a, b and c, listed in the attribute (the second) compartment of the class Xyz.

Figure 5.2.1.2-1: Attribute notation

5.2.1.3 Name style

An attribute name shall use the LCC style.

Well Known Abbreviation (WKA) is treated as a word if used in a name. However, WKA shall be used as is (its letter case cannot be changed) except when it is the first word of a name; and if so, its first letter must be in lower case.

5.2.2 Association relationship

5.2.2.1 Description

It shows a relationship between two classes and describes the reasons for the relationship and the rules that might govern that relationship.

It has ends. Its end, the association end(s), specifies the role that the object at one end of a relationship performs. Each end of a relationship has properties that specify the role (see 5.2.9), multiplicity (see 5.2.8), visibility and navigability (see the arrow symbol used in Figure 5.2.2.2-2: Unidirectional association relationship notation) and may have constraints. Note that visibility shall not be used in models based on this Repertoire (see bullet 3 of 5.2).

See 7.3.3 Association of [2].

Three examples below show a binary association between two model elements. The association can include the possibility of relating a model element to itself.

The first example (Figure 5.2.2.2-1) shows a bi-directional navigable association in that each model element has a pointer to the other. The second example (Figure 5.2.2.2-2) shows a unidirectional association (shown with an open arrow at the target model element end) in that only the source model element has a pointer to the target model element and not vice-versa. The third example (Figure 5.2.2.2-3) shows a bi-directional non-navigable association in that each model element does not have a pointer to the other; i.e., such associations are just for illustration purposes.

5.2.2.2 Example

An association shall have an indication of cardinality (see 5.2.8).

It shall, except the case of non-navigable association, have an indication of the role name (see 5.2.9). The model element involved in an association is said to be “playing a role” in that association. The role has a name such as aClass in the first example below. Note that the use of "+" character in front of the role name, indicating visibility, is optional.

Figure 5.2.2.2-1: Bidirectional association relationship notation

Figure 5.2.2.2-2: Unidirectional association relationship notation

Figure 5.2.2.2-3: Non-navigable association relationship notation

Note that some tools do not use arrows in the UML graphical representation for bidirectional associations. Therefore, absence of the two arrows is not an indication of a non-navigable association between the two Information Object Class involved; but the absence of the attributes related to role in the two Information Object Class involved is

5.2.2.3 Name style

An Association can have a name. Use of Association name is optional. Its name style is LCC style.

A role name shall use the LCC style.

NOTE: The role name needs not resemble the class name.

5.2.3 Aggregation association relationship

5.2.3.1 Description

It shows a class as a part of or subordinate to another class.

An aggregation is a special type of association in which objects are assembled or configured together to create a more complex object. Aggregation protects the integrity of an assembly of objects by defining a single point of control called aggregate, in the object that represents the assembly.

See 7.3.2 AggregationKind (from Kernel) of [2].

5.2.3.2 Example

A hollow diamond attached to the end of a relationship is used to indicate an aggregation. The diamond is attached to the class that is the aggregate. The aggregation association shall have an indication of cardinality at each end of the relationship (see 5.2.8).

Figure 5.2.3.2-1: Aggregation association relationship notation

5.2.3.3 Name style

An Association can have a name. Use of Association name is optional. Its name style is LCC.

5.2.4 Composite aggregation association relationship

5.2.4.1 Description

A composite aggregation association is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are deleted as well.

A composite aggregation shall contain a description of its use.

See 7.3.3 Association (from Kernel) of [2].

5.2.4.2 Example

A filled diamond attached to the end of a relationship is used to indicate a composite aggregation. The diamond is attached to the class that is the composite. The composite association shall have an indication of cardinality at each end of the relationship (see 5.2.8).

Figure 5.2.4.2-1: Composite aggregation association relationship notation

5.2.4.3 Name style

An Association can have a name. Use of Association name is optional. Its name style is LCC.

5.2.5 Generalization relationship

5.2.5.1 Description

It indicates a relationship in which one class (the child) inherits from another class (the parent).

See 7.3.20 Generalization of [2].

5.2.5.2 Example

This example shows a generalization relationship between a more general model element (the SubNetwork) and a more specific model element (the NetworkSliceSubnet) that is fully consistent with the first element and that adds additional information.

Figure 5.2.5.2-1: Generalization relationship notation

5.2.5.3 Name style

It has no name so there is no name style.

5.2.6 Dependency relationship

5.2.6.1 Description

“A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s)…“, an extract from 7.3.12 Dependency of [2].

5.2.6.2 Example

This example shows that the BClass instances have a semantic relationship with the AClass instances. It indicates a situation in which a change to the target element (the AClass in the example) will require a change to the source element (the BClass in the example) in the dependency.

Figure 5.2.6.2-1: Dependency relationship notation

5.2.6.3 Name style

A Dependency can have a name. Use of Dependency name is optional. Its name style is LCC.

5.2.7 Comment

5.2.7.1 Description

A comment is a textual annotation that can be attached to a set of elements.

See 7.3.9 Comment (from Kernel) from [2].

5.2.7.2 Example

This example shows a comment, as a rectangle with a "bent corner" in the upper right corner. It contains text. It appears on a particular diagram and may be attached to zero or more modelling elements by dashed lines.

Figure 5.2.7.2-1: Comment notation

5.2.7.3 Name style

It has no name so there is no name style.

5.2.8 Multiplicity, a.k.a. cardinality in relationships

5.2.8.1 Description

"A multiplicity is a definition of an inclusive interval of non-negative integers beginning with a lower bound and ending with a (possibly infinite) upper bound. A multiplicity element embeds this information to specify the allowable cardinalities for an instantiation of this element…", an extract from 7.3.32 MultiplicityElement of [2].

Table 5.2.8.1-1: Multiplicity-string definitions

Multiplicity	Explanation
1	Attribute has one attribute value.
m	Attribute has m attribute values.
0..1	Attribute has zero or one attribute value.
0..*	Attribute has zero or more attribute values.
*	Attribute has zero or more attribute values.
1..*	Attribute has at least one attribute value.
m..n	Attribute has at least m but no more than n attribute values.

The use of "0..n" is not recommended although it has the same meaning as " 0..* " and " *".

The use of a standalone symbol zero (0) is not allowed.

5.2.8.2 Example

This example shows a multiplicity attached to the end of an association path. The meaning of this multiplicity is one to many. One Class1 instance is associated with zero or more Class2 instances. Other valid examples can show the “many to many” relationship.

Figure 5.2.8.2-1: Cardinality notation

The cardinality zero is not used to indicate the IOC’s so-called “transient state” characteristic. For example, it is not used to indicate that the instance is not yet created but it is in the process of being created. The cardinality zero will not be used to indicate this characteristic since such characteristic is considered inherent in all IOCs. All IOCs defined are considered to have such inherent “transient state” characteristics.

The following table shows some valid examples of multiplicity.

Table 5.2.8.2-1: Multiplicity-string examples

Multiplicity	Explanation
1	Attribute has exactly one attribute value.
5	Attribute has exactly 5 attribute values.
0..1	Attribute has zero or one attribute value.
0..*	Attribute has zero or more attribute values.
1..*	Attribute has at least one attribute value.
4..12	Attribute has at least 4 but no more than 12 attribute values.

5.2.8.3 Name style

It has no name so there is no name style.

5.2.9 Role

5.2.9.1 Description

It indicates navigation, from one class to another class, involved in an association relationship. A role is named. The direction of navigation is to the class attached to the end of the association relationship with (or near) the role name.

The use of role name in the graphical representation is optional for bidirectional and unidirectional association relationship notations (see Figure 5.2.2.2-1: Bidirectional association relationship notation and Figure 5.2.2.2-2: Unidirectional association relationship notation). Role name shall not be used in non-navigable association relationship notation (see Figure 5.2.2.2-3: Non-navigable association relationship notation).

A role at the navigable end of a relationship becomes (or is mapped into) an attribute (called role-attribute) in the source class of the relationship. Therefore, roles have the same behaviour (or properties) as attributes. See Table 5.2.1.1-1: Attribute properties.

To avoid clutter in UML diagram, the role names can be removed.

The role-attribute shall have all properties defined for attributes in subclause 5.2.1 Attribute and in addition the following property

Table 5.2.9.1-1: passedById property

Property name

Description

Legal values

passedById

If True, the role-attribute (navigable association source end) contains a DN of the navigable association target end instance.

If False, the role-attribute contains (a copy of) the whole target end instance (e.g. X). If X has a role-attribute whose “passedById==False”, then the subject role-attribute contains (a copy of) X’s target end instance as well.

The above rule is applied repeatedly for all occurrences of “passedById==False”. This application can result in a collection of instances where no ordering can be implied and no instances are duplicated.

Use of “passedById==False” supports the efficient access of target end instances from a source end instance. The mechanism by which such access is achieved is operation model design specific (e.g. not related to resource model design).

True (default), False

5.2.9.2 Example

This example shows that a Person (say instance John) is associated with a Company (say whose DN is “Company=XYZ”). We navigate the association by using the opposite association-end such that John’s Person.company would hold the DN, i.e. "Company=XYZ".

Figure 5.2.9.2-1: Role notation

5.2.9.3 Name style

A role has a name. Use a noun for the name. The name style follows the attribute name style; see subclause 5.2.1.3.

5.2.10 Xor constraint

5.2.10.1 Description

“A Constraint represents additional semantic information attached to the constrained elements. A constraint is an assertion that indicates a restriction that must be satisfied by a correct design of the system. The constrained elements are those elements required to evaluate the constraint specification…“, an extract from 7.3.10 Constraint (from Kernel) of [2].

For a constraint that applies to two elements such as two associations, the constraint shall be shown as a dashed line between the elements labeled by the constraint string (in braces). The constraint string, in this case, is xor.

5.2.10.2 Example

The figure below shows a ServerObjectClass instance that has relation(s) to multiple instances of a class from the choice of ClientObjectCLass_Alternative1, ClientObjectClass_Alternative2 or ClientObjectCLass_Alternative3.

Figure 5.2.10.2-1: {xor} notation

5.2.10.3 Name style

It has no name so there is no name style.

5.3 Stereotype

5.3.0 Description

Subclause 5.1 listed the UML defined basic model elements. UML defined a stereotype concept allowing the specification of simple or complex user-defined model elements.

This subclause lists all allowable stereotypes for this repertoire.

The names of stereotypes shall be chosen such that they do not clash.

For each stereotype model element listed, there are three parts. The first part contains its description. The second part contains its graphical notation examples and the third part contains the rule, if any, recommended for labelling or naming it.

5.3.1 <<ProxyClass>>

5.3.1.1 Description

It is a form or template representing a number of <<InformationObjectClass>>. It encapsulates attributes, links, methods (or operations), and interactions that are present in the represented <<InformationObjectClass>>.

The semantics of a <<ProxyClass>> is that all behaviour of the <<ProxyClass>> is present in the represented <<InformationObjectClass>>. Since this class is simply a representation of other classes, this class cannot define its own behaviour other than those already defined by the represented <<InformationObjectClass>>.

A particular <<InformationObjectClass>> can be represented by zero, one or more <<ProxyClass>>. For example, the ManagedElement <<InformationObjectClass>> can have MonitoredEntity <<ProxyClass>> and ManagedEntity <<ProxyClass>>.

The attributes of the <<ProxyClass>> are accessible by the source entity that has an association with the <<ProxyClass>>.

5.3.1.2 Example

This shows a <<ProxyClass>> named MonitoredEntity. It represents (or its constraints is that it represents) all NRM <<InformationObjectClass>> (e.g. GgsnFunction <<InformationObjectClass>>) whose instances are being monitored for alarm conditions. It is mandatory to use a Note to capture the constraint.

Figure 5.3.1.2-1: <<ProxyClass>> notation

See Annex A for more examples that use <<ProxyClass>>.

5.3.1.3 Name style

For <<ProxyClass>> name, use the same style as <<InformationObjectClass>> (see 5.3.2).

5.3.2 <<InformationObjectClass>>

5.3.2.1 Description

The <<InformationObjectClass>> is identical to UML class except that it does not include/define methods or operations.

A UML class represents a capability or concept within the system being modelled. Classes have data structure and behaviour and relationships to other elements.

This class can inherit from zero, one or multiple classes (multiple inheritances).

See more on UML class in 10.2.1 of [1].

5.3.2.2 Example

This example shows an AbcFunction <<InformationObjectClass>>.

Figure 5.3.2.2-1: <<InformationObjectClass>> notation

The following table captures the properties of this modelled element.

Table 5.3.2.2-1: <<InformationObjectClass>> properties

Property name	Description	Legal values
documentation	Contains a textual description of this modelled element. Should refer (to enable traceability) to a specific requirement.	Any
isAbstract	Indicates if the class can be instantiated or is just used for inheritance.	True, False (default)
isNotifyable	Identifies the list of the supported notifications.	List of names of notification
supportQualifier	Identifies the required support of the class. See also subclause 6.	M, O (default), CM, CO, C

5.3.2.3 Name style

The name shall use UCC style. The name shall end with an underscore if it is an abstract class in the UIM. The name must not end with an underscore if it is a concrete class.

WKA is treated as a word if used in a name. However, WKA shall be used as is (its letter case cannot be changed) except when it is the first word of the name; and if so, its first letter must be in upper case.

Embedded underscore is not allowed except the name is for an Association class (see 5.4.1.)

5.3.3 <<names>>

5.3.3.1 Description

The <<names>> is modelled by a composite association where both ends are non-navigable. The source class is the composite and the target class is the component. The target instance is uniquely identifiable, within the namespace of the source entity, among all other targeted instances of the same target class and among other targeted instances of other classes that have the same <<names>> composition with the source.

The source class and target class shall each has its own naming attribute.

The composite aggregation association relationship is used as the act of name containment providing a semantic of a whole-part relationship between the domain and the named elements that are contained, even if only by name. From the management perspective access to the part is through the whole. Multiplicity shall be indicated at both ends of the relationship.

A target instance cannot have multiple <<names>> with multiple source instances s, i.e. a target instance can not participate in or belong to multiple namespaces.

5.3.3.2 Example

This shows that all instances of Class4 are uniquely identifiable within a Class3 instance’s namespace.

Figure 5.3.3.2-1: <<names>> notation

5.3.3.3 Name style

It has no name so there is no name style.

5.3.4 <<dataType>>

5.3.4.1 Description

It represents an attribute property type (see Table 5.2.1.1-1: Attribute properties).

This repertoire uses two kinds of data types: predefined data types and user-defined data types. The former is defined in subclause 5.4.3. The latter is defined by the specifications authors using this <<dataType>> model element.

The names of predefined data types and user-defined data types must be chosen such that they do not clash.

The user-defined data types support the modelling of structured data types (see <<dataType>> PLMNId in 5.3.4.2).

When a user-defined or predefined data type is used to apply type (see property named type in Table 5.2.1.1‑1: Attribute properties) information to a class attribute, the data type name is shown along with the class attribute. See Example below.

5.3.4.2 Example

The following examples are two user-defined data types.

The left-most user-defined data type is named PLMNId . It has two attributes. One is the Mobile Country Code (MCC) of predefined data type String. The other is the Mobile Network Code (MNC) of predefined data type String as well.

The right-most user-defined data type is named Xyz. It has three attributes. The attribute1 uses predefined data type String. The attribute2 uses predefined data type Integer. The attribute3 uses user-defined data type PLMNId.

Figure 5.3.4.2-1: <<dataType>> notations

The following example shows a ZClass which has four attributes. Two attributes (i.e. attribute1, attribute4) use the user-defined data types (i.e. PLMNId, Xyz) and the other two attributes use the predefined data types.

Figure 5.3.4.2-2: Usage example of <<dataType>>

The third column of the following shows some of the properties of an attribute attribute1 of ZClass. It shows the attribute1 attribute property type is PLMNId, a user-defined data type.

attribute1

It is a PLMN identifiers.

type: PLMNId

multiplicity: 1

isOrdered: N/A

isUnique: N/A

defaultValue: None

isNullable: False

5.3.4.3 Name style

For <<dataType>> name, use the same style as <<InformationObjectClass>> (see 5.3.2).

For <<dataType>> attribute, use the same style as Attribute (see 5.2.1).

5.3.5 <<enumeration>>

5.3.5.1 Description

An enumeration is a data type. It contains sets of named literals that represent the values of the enumeration. An enumeration has a name.

See 10.3.2 Enumeration of [1].

5.3.5.2 Example

This example shows an enumeration model element whose name is Account and it has four enumeration literals. The upper compartment contains the keyword <<enumeration>> and the name of the enumeration. The lower compartment contains a list of enumeration literals.

Note that the symbol to the right of <<enumeration>> Account in the figure below is a feature specific to a particular modelling tool. It is recommended that modelling tool features should be used when appropriate.

Figure 5.3.5.2-1: <<enumeration>> notation

5.3.5.3 Name style

For <<enumeration>> name, use the same style as <<InformationObjectClass>> (see 5.3.2).

For <<enumeration>> attribute (the enumeration literal), use the following rules:

 Enumeration literal is composed of one or more words of upper case characters. Words are separated by the underscore character.

5.3.6 <<choice>>

5.3.6.1 Description

The «choice» stereotype represents one of a set of classes (when used as an information model element) or one of a set of data types (when used as an operation model element).

This stereotype property, e.g., one out of a set of possible alternatives, is identical to the {xor} constraint (see 5.2.10).

5.3.6.2 Example

Sometimes the specific kind of class cannot be determined at model specification time. In order to support such scenario, the specification is done by listing all possible classes.

The following diagram lists 3 possible classes. It also shows a «choice» named SubstituteObjectClass. This scenario indicates that only one of the three related «InformationObjectClass» named Alternative1ObjectClass, Alternative2ObjectClass, Alternative3ObjectClass shall be realised.

The «choice» stereotype represents one of a set of classes when used as an information model element.

Figure 5.3.6.2-1: Information model element example using «choice» notation

Sometimes the specific kind of data type cannot be determined at model specification time. In order to support such scenario, the specification is done by listing all possible data types.

The following diagram lists 2 possible data types. It also shows a «choice» named ProbableCause. This scenario indicates that only one of the two «dataType» named IntegerProbableCause, StringProbableCause shall be realised.

The «choice» stereotype represents one of a set of data types when used as an operations model element.

Figure 5.3.6.2-2: Operations model element example using «choice» notation

5.3.6.3 Name style

For <<choice>> name, use the same style as <<InformationObjectClass>> (see 5.3.2).

5.4 Others

5.4.1 Association class

5.4.1.1 Description

An association class is an association that also has class properties (or a class that has association properties).
Even though it is drawn as an association and a class, it is really just a single model element.

See 7.3.4 AssociationClass of [2].

Association classes are appropriate for use when an «InformationObjectClass» needs to maintain associations to several other instances of «InformationObjectClass» and there are relationships between the members of the associations within the scope of the "containing" «InformationObjectClass». For example, a namespace maintains a set of bindings, a binding ties a name to an identifier. A NameBinding «InformationObjectClass» can be modelled as an Association Class that provides the binding semantics to the relationship between an identifier and some other «InformationObjectClass» such as Object in the figure. This is depicted in the following figure.

5.4.1.2 Example

Figure 5.4.1.2-1: Association class notation

5.4.1.3 Name style

The name shall use the same style as in <<InformationObjectClass>> (see 5.3.2.3).

5.4.2 Abstract class

5.4.2.1 Description

It specifies a special kind of <<InformationObjectClass>> as the general model element involved in a generalization relationship (see 5.2.5). An abstract class cannot be instantiated.

This modelled element has the same properties as class. See 5.3.2.

5.4.2.2 Example

This shows that Class5_ is an abstract class. It is the base class for SpecializedClass5.

Figure 5.4.2.2-1: Abstract class notation

5.4.2.3 Name style

For abstract class name, use the same style as <<InformationObjectClass>> (see 5.3.2) . The name shall be in italics. In the UOM, its last character shall be an underscore

5.4.3 Predefined data types

5.4.3.1 Description

It represents the general notion of being a data type (i.e. a type whose instances are identified only by their values) whose definition is defined by this specification and not by the user (e.g. specification authors).

This repertoire uses two kinds of data types: predefined data types and user-defined data types. The latter is defined in 5.3.4 <<dataType>> and 5.3.5 <<enumeration>>.

The following table lists the UML data types selected for use as predefined data type.

Table 5.4.3.1-1: UML defined data types

Name	Description and reference
Boolean	See Boolean type of [7].
Integer	See Integer type of [7].
String	See PrintableString type of [7].

The following table lists data types that are defined by this repertoire.

Table 5.4.3.1-2: Non-UML defined data types

Name	Description and reference
AttributeValuePair	This data type defines an attribute name and the attribute’s value.
BitString	This data type is defined by Bit string of subclause 3 and subclause G.2.5 of [7].
DateTime	This data type is defined by GeneralizedTime of [7].
DN	This data type defines the DN (see Distinguished Name of ) of an object. It contains a sequence of one or more name components. The “initial sub-sequence” (note 1) of a DN is also a DN of an object. Note 1: Suppose an object’s DN is composed of a sequence of 4 name components, i.e. 1^st, 2^nd, 3^rd and 4^th components. The “initial sub-sequence” of this DN is composed of the 1^st, 2^nd and 3^rd components.
External	This data type is defined by another organization.
Real	This data type is defined by Real type of [7]

5.4.3.2 Example

Figure 5.4.3.2-1: Predefined data types usage

Note: Use of this is optional. Uses of other means, to specify Predefined data types, are allowed.

5.4.3.3 Name style

It shall use the UCC style.