DDSXTY12 — UML Model is not consistent with document and missing types

This changes are needed to align the XTYPES model with IDL4. Specifically with regards to annotations.

In IDL4 it is possible to annotate type declarations, members, and elements in a collection as in:

@MyAnnotation(3)
struct MyStruct {
    @MemberAnnotation  long l_member;
    sequence< @ElementAnnotation long, 55>   seq_member;
};

Union discriminators can also be annotated and so can members, but not the case literals:

@MyAnnotation(3)
union MyUnion switch ( DiscriminatorAnnotation(44)  long)  {
    case 1:
       @MemberAnnotation  long  l_member;
    default:
        sequence< @ElementAnnotation long, 55>   seq_member;
};

It is also possible to annotate enumeration, bitmask and bitset members.

@MyAnnotation(3)
bitmask MyBitmask{
    @position(2)  flag1;
};

Annotation are also permitted in the “related type” for a typedef:

typedef  @max(23) long  MyLong;
typedef  sequence<@external long>  LongPtrSeq;

Another issue is that in the new XTYPES we are no longer requiring that all types are named. So that the inheritance of Type from NamedElement is not what we want.

Currently we use NamedElement model both the name of a type as well as the name of a member (structure, union), name of a bitflag, module, and enum literal.

Those are things we want to annotate. But we also want to annotate element of a collection as well as the discriminator of unions which have no name.

Update UML Model to align it with IDL4

This changes are needed to align the XTYPES model with IDL4. Specifically with regards to annotations.

In IDL4 it is possible to annotate type declarations, members, and elements in a collection as in:

@MyAnnotation(3)
struct MyStruct {
    @MemberAnnotation  long l_member;
    sequence< @ElementAnnotation long, 55>   seq_member;
};

Union discriminators can also be annotated and so can members, but not the case literals:

@MyAnnotation(3)
union MyUnion switch ( DiscriminatorAnnotation(44)  long)  {
    case 1:
       @MemberAnnotation  long  l_member;
    default:
        sequence< @ElementAnnotation long, 55>   seq_member;
};

It is also possible to annotate enumeration, bitmask and bitset members.

@MyAnnotation(3)
bitmask MyBitmask{
    @position(2)  flag1;
};

Annotation are also permitted in the “related type” for a typedef:

typedef  @max(23) long  MyLong;
typedef  sequence<@external long>  LongPtrSeq;

Another issue is that in the new XTYPES we are no longer requiring that all types are named. So that the inheritance of Type from NamedElement is not what we want.

Currently we use NamedElement model both the name of a type as well as the name of a member (structure, union), name of a bitflag, module, and enum literal.

Those are things we want to annotate. But we also want to annotate element of a collection as well as the discriminator of unions which have no name.

Modifications to the UML model

The UML model needs an AppliedAnnotation class that models the application of annotations to some other classifier.

Also NamedElement should not be modeled as a “base class” but rather as something that certain classifiers have. So it should be a “has-a” relationship. That would allow some types (e.g. anonymous types) to not have a name.

String should not inherit from Collection. There should be a StringType that is specialized by String8 and String16. StringType would be a direct child of Type, peer to PrimitiveType.

There should be a EnumeratedType peer of PrimitiveType. It should have Enumeration and Bitmask as specializations.

Bitset should be added as another specialization of Aggregation.

In addition:

• Create an association between Aggregation and NamedElement. This has cardinality “1”. Every Aggregation type has a name.
• Create an association between Collection and NamedElement. This has cardinality “0..1”. Collection types can be named or anonymous.
• Create an association between Alias and NamedElement. This has cardinality “1”. Alias types always have a name.
• Add an association between ConstructedType and NamedElement. It should have to be “0..1” to capture the possibility for anonymous collections.
• Module, EnumerationLiteral, Bitflag, Member, and Bitfield would also have a “has-a” relation to NamedElement with cardinality “1”.
• Model the annotations on collection element and union discriminator.
• Union Discriminator requires a separate class. Currently it is modeled as a “member” but that is odd (e.g. it is unnamed, has hard-coded memberID) better to model it separately.
• Change NamedElement to ScopedIdentifier.

Enhance model for Annotations
Currently Annotation specializes Aggregation type. This is wrong in several ways.
Al constructed types can be annotated. But Annotations cannot have annotations.
It does make sense to talk about the extensibility kind of an annotation. Nor about the type compatibility/assignability.

Many associations to type (e.g. a structure member has a type) do not make sense if the “type” is an annotation.

The only thing from Type is that they can have a type object.

Annotations should not be modeled as types. They should not specialize “Type” they should be their own thing. Basically we define a AnnotationDeclaration an AppliedAnnotation (and AnnotationParameter). This can follow the TypeObject model.

Then section 7.2.2.3.6 “Annotation Types” can be moved to a higher level. Say 7.2.2.6 after :”Try Construct Behavior”

Also in the XTYPES it says (in section 7.2.2.3.6) that annotations can inherit from other annotations. However the IDL grammar 7.4.15 does not support annotation inheritance so we should get rid of that in the XTYPES.