Extensions to the CCM specification

While implementing and using the CCM metamodel library we encountered a few errors, typos, and shortcomings in the specification. This section lists these difficulties and describes our attempts to solve them for our project.

Our work with the library so far has only taken place in the context of implementing a series of code generators, so we have been approaching the library and CCM metamodel specification from only a few angles (IDL3 parsing and C++ code generation). These problems reflect our singular points of view only and are mentioned here in the spirit of making the CCM metamodel specification a solid, practical, complete standard. This is not intended to be a complete bug list for the CCM metamodel specification, but rather a simple list of some points that have come up during our work.

Fields and union fields

The CCM metamodel specification provides classes for representing fields in structures and unions; these Field and UnionField classes are insufficient for model navigation. The CCM Tools implemented these classes as MFieldDef and MUnionFieldDef, respectively. Along with this change, we needed to add DK_FIELD and DK_UNIONFIELD to the DefinitionKind enumeration. The reasoning in these two cases basically involves the following two points:

1. MField and MUnionField objects have an identifier member parameter and associated getIdentifier and setIdentifier methods. Thus, they should be locatable objects just like MParameterDef, MOperationDef, or MInterfaceDef (all of which have an identifier parameter and associated access functions). Without an associated DefinitionKind, it would be impossible to use the limitToType parameter of the lookupName functions to find field and union field objects.
2. Fields and union fields occupy roles similar to that of parameters. Parameter objects have an associated entry in the DefinitionKind enumeration, so all three objects should be treated in the same manner.

Homes and components

As implemented in the CCM Tools, a 1-to-many correspondence exists between components and homes. That is, each component might have 1 or more homes, and a home must have exactly one component. However, navigation in the CCM MOF specification is only possible from homes to their corresponding components (via the getComponent and setComponent functions).

For this 1-to-many correspondence to make more practical sense, the CCM Tools add a series of functions to MComponentDef to allow direct navigation to associated home(s). These functions are similar to the set of component supports functions already in a component (but see section 2.4.4 for notes about component supports).

Definition kinds

The DefinitionKind enumeration makes little sense in the context of the rest of the CCM metamodel specification. There are two major points of interest here:

• There is no way to associate a DefinitionKind value with each class type in the CCM metamodel specification (i.e. there is no static, constant definitionKind variable in each of the metamodel classes). This makes the lookupName and getFilteredContents functions impossible to implement properly.
• The enumeration for DefinitionKind is incomplete.

These two issues are addressed below.

Lack of association between classes and definition kinds

To solve the first item, the CCM Tools introduced a definitionKind class variable into the following classes:

• those whose names end with `DefImpl' (i.e. MModuleDefImpl, MParameterDefImpl, MPrimitiveDefImpl, MWstringDefImpl, etc.)
• MContainer and MContained

The definitionKind variable is declared private final static because it is not variable for a given class. Each class has an associated getDefinitionKind function that returns the definitionKind constant.

Incomplete definition kind enumeration

The second point was easy enough to fix, but any solution will cause a small disturbance in the force, given the separation between the Base IDL and Component IDL metamodels. The DefinitionKind enumeration as specified has many inconsistencies:

• The enumeration has values for StringDef, ParameterDef, and PrimitiveDef, for example, but no values for FieldDef or UnionFieldDef (see section 2.4.1).

  All of these classes inherit only from the Typed or IDLType classes (which have no identifier member variables). So, for example, MParameterDef has an identifier variable and an associated DefinitionKind value. FieldDef and UnionFieldDef also have identifier member variables (indicating that a library user might be able to use the lookupName functions to look for instances of these classes), but there are no corresponding DefinitionKind values.

• The enumeration has values for InterfaceDef, ExceptionDef, TypedefDef, and OperationDef, for example, but no values for ValueDef, ValueBoxDef, or ValueMemberDef.

  This seems to have been a simple oversight, as all of these types should be treated equally in this regard.

• The enumeration lacks values for classes in the Component IDL library, even though many Component IDL classes inherit from, for example, InterfaceDef. This has caused us some discomfort, as it should clearly be possible to call, for example,

  someContainer.lookup("someHome")
  

  But it is not clear where to put the DefinitionKind values in this case.

Our solution to the first two problems was to add the missing values to the MDefinitionKind enumeration implementation (see the tables below). Our solution to the third problem was also to add the missing values to the MDefinitionKind enumeration class in the Base IDL library. However, this removes the strict subset/superset relationship between the two parts of the library: the Base IDL is no longer a logical proper subset of the Component IDL.

Nonetheless, we felt this was the best solution: the best alternative is to create an empty MDefinitionKind interface in the Base IDL, and then implement that interface with an MDefinitionKindImpl class in the Base IDL and a second MDefinitionKindImpl class in the Component IDL. The alternative requires excessive typecasting (for a Java, C, or C++ implementation) and would be difficult to maintain. The maintenance difficulty is especially true in the sense of coordinating integer values between the two implementations. As further justification for our solution, this maintenance requirement for the two-implementation solution also removes the proper subset relationship between the two metamodels, so the solution we chose follows the path of least disturbance.

Table 2.1: Definition kind enumeration elements, as defined in the CCM metamodel specification and as used by the CCM Tools.

Component supports

The CCM metamodel specification includes an insufficient method for modeling supported interfaces of components. MComponentDef class instances contain a set of functions for getting, setting, adding, and removing supported interfaces. However, the CCM specification provides no way of representing the fact that these interfaces are supported by the component. This is particularly problematic during code generation, since a component's supported interfaces look to a code generator just like normal interfaces; that is, they have no special semantics in a metamodel.

To remedy this, the CCM Tools introduced an MSupportsDef interface and associated MSupportsDefImpl class implementation. This class functions almost exactly like the MUsesDef and MProvidesDef classes; it simply provides a thin wrapper around the supported interface. This wrapper signals the fact that the associated interface is supported by a component. This is hopefully analogous to the MUsesDef and MProvidesDef classes, which indicate that the associated interface is a receptacle or facet.

One further difficulty exists, though: both homes and components can have supported interfaces. The CCM Tools contain a simple workaround for this problem by including both getHome/setHome and getComponent/setComponent access functions. If the supports node is the child of a home class, the getComponent function will return null, and vice versa.

Primitive kinds

The MWstringDefImpl and MStringDefImpl classes need to have a kind data member, just like the MPrimitiveDefImpl class. The MPrimitiveKind enumeration class contains values for wide and normal strings (PK_WSTRING and PK_STRING, respectively), so it seems like these types should behave similarly to the other primitive kind data types.

Language mappings

This section describes some difficulties or inconsistencies encountered with the language mappings.

IDL 2 language mapping

Publishes

The language mapping template for event publishers in the OMG document is difficult to read. In addition, the template appears to contain the same text two times, with different indentation.