UML4DDS — Problematic type library specification

The Types model included in the UML Profile for Data Distribution has 3 significant high-level problems that the FTF should address. These are:

P-1. It does not describe any normative DDS type system.

The DDS specification does not define the range of data types that may be used with DDS implementations. Although it implies an IDL-based type system by its specification of an IDL-based PSM, it does not articulate (a) which portions of IDL are normative with respect to DDS and (b) what extensions to the IDL 2 (or 3, or 3+) type system may be necessary to support DDS-specific concepts.

For example, with respect to (a), some DDS implementations support valuetypes while others do not. And at least some DDS implementations omit support for "any" and "fixed." With respect to (b), different DDS implementations indicate keys in different ways and treat keys differently when they occur within nested objects.

The purpose of the UML Profile for Data Distribution is to facilitate the modeling of DDS-based applications such that those models may be transformed into executable code that compiles and links against existing DDS implementations. It defines conformance for a UML-based model and consequently for a tool capable of viewing and editing such a model. It does not define conformance for a DDS middleware implementation itself. It is therefore incorrect to consider it to define a normative DDS system that would constrain DDS implementations; it must either describe a type system that is specified elsewhere, or it must be considered non-normative:

P-2. It is not clear whether it is intended to be normative itself.

Level-1 conformance with the profile is defined to include the Topics package, and Types is a sub-package of Topics, so in some sense it is implied that Level-1 conformance includes the Types package. The Types package is also a common library between DCPS and DLRL, which implies it is a part of Level-2 conformance as well.

However, a type-modeling facility was not called for in the RFP, and the Types package is really just a supporting package for Topics, so it is not required to be normative. Indeed, given (1) above, it may not actually be appropriate to consider it normative. There is a precedent for this kind of situation: UPDM uses a UML profile for BPMN in a supporting and non-normative role.

P-3. It does not meet the needs of complex DDS-based systems.

Complex DDS-based systems – especially systems of systems – require support for type substitution and evolution. (For example, if the type Bar extends the type Foo, I should be able to publish Bar to you if you subscribe to Foo. This is completely analogous to typical object-oriented type substitution rules. Furthermore, I should be able to extend our shared type definition in a future version of my component, and you should be able to consume instances of that evolved type with well-defined semantics without rebuilding and redeploying yourself.) The Types model does not address these use cases.

POSSIBLE RESOLUTION:

The proposed resolution consists of two parts:

R-1. Declare unambiguously that the current Types package is non-normative. This declaration in itself would be enough to resolve this issue. Even though it only addresses P-2 directly, P-1 immediately becomes moot. P-3 may be considered out of scope of the UML Profile, as indeed it is out of scope of the DDS 1.2 specification itself.

This degree of resolution is sufficient, strictly speaking, but not wholly satisfactory. Therefore:

R-2. The "Extensible and Dynamic Topics Types for DDS" ("X-Topics") RFP was issued specifically to address (a) the ambiguities in the DDS type system pointed out in P-1 and (b) the lack of flexibility noted in P-3. Therefore, once a response to this RFP is available (the joint revised submission will be up for a vote in the Jacksonville 2010 meeting), the UML Profile could allow implementers to use that specification to describe their types in a fully normative way. This use of X-Topics by the UML Profile could either be declared non-normative, like the current lightweight Types model, or could be declared to be an additional normative-but-optional conformance point within the UML Profile specification (as X-Topics support will be optional for DDS implementations themselves).

Depending on the relative timeline for X-Topics adoption and availability and the conclusion of the UML Profile FTF, R-2 could be implemented either during the current FTF or, if desired, during a subsequent RTF.