UML Profile for DDS does not refer to WaitSet element, though it is part of
DCPS package in DDS specification.
in order to get real interoperability the spec should be more precise on the format of the qos_profile attribute. If it is a file url, how do we specify which qos_profile within that file to select? If it is a XML string, could that contain multiple qos_profiles or should it only contain one?
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.
Figure 15-5: The connecting lines between <<topic>> ActiveUser and
<<subscriber>> sub and <<publisher>> pub are not clear. If the intention is
to represent a connector, it is not possible in UML to connect a part
(topic) to a part (subscriber\publisher) of of another class
Figure 46: "manages" and "class" have not been defined previously.
what is the "field" stereotype? I didn't find any "field" execpt in the DLRL part. If my understanding of the previous pages is good, "filed" should be removed" and "userID: long" should be replaced with "<<Primitive>> userID: long" and so forth.
Looking at Figure 46 and following, it seems that domainParticipant needs to be considered as a Component and a ddsProperty.
looking at Figure 46, it seems that subscribers and publishers need to be considered as Properties (to be a part of a structured class) and as a Class (to be able to receive ports) as well. I thus propose to design publisher and subscriber as ddsProperty and ddsSpecification
the name "relation" is syntactically too poor and too common to be used here. Please find something more specific (such as dlrlRelation for instance).
it should be stated that the associations "homes", "topicmanages" and "criterion" subset the UML2 association between UML2::Class and UML2::Property
UML2 conformance: ActiveUser should be change with "active_user:UserType" and the "type" tag should be removed (as well as with ChatMessage and MessageType).
Paragraph 7.3 is non normative and, thus, should be moved in an annex
There is no link between, on the one hand, publisher, subscriber, domainparticipant, datareader, datawriter and, on the other hand, qosProperty (I guess it should).
Looking at Figure 46 and following, it seems that a domain needs to be considered as a ddsSpecification and a ddsProperty.
How are designed the complements of the types? For instance, a "sequence" does not mean anything by itself: another type is needed to precise it.
TopicStruct and TopicField should specialize ddsSpecification and ddsProperty
A constraint should be specified to subset the UML2 associations "attribute" between TopicStruct and TopicField.
SharedKey is not specified anywhere (used elsewhere but never defined).
The semantics behind the dashed line "reads and writes" is unclear. Moreover, DataReader should reads Topics::TopicDescription that is more general than Topics:Topic. The dashed line is thus confusing
it should be stated that an association between qosProperty and qosPolicy subsets the UML2 association between UML2::Class and UML2::Property
wrong UML2 notation for an extension association between a stereotype and its metaclass
If a key is designed as a subclass of TopicField, which field is actually the key? For instance, in the use case example shown in Figure 37, a PersonTopic has a key: taxNr (an int). Is this field designed as a DLRL::Key or as a Types::Integer? Anyway, the other information is lacking.
it should be stated that the association "type" subsets the UML2 association between UML2::Class and UML2::Property.
TopicField" is a strange name in this context because it results in having a "typedef", a "union" and so forth as a topic field! To my mind, "TopicType" should be better for the sake of comprehensibility.
TopicField should be under Core::Specification (target of the association "type") instead of the too general Core::Entity.
§§ 7.1.4.3.4, 7.1.6.1.4, 7.1.6.2.4, 7.1.6.7.4, 7.1.6.5.4: There is a mismatch between, in the one hand, the type of the associations (XXXQosPolicy) and, on the other hand, the comment (that speaks of QosProperty) and the subset constraint (it subsets "property" which goes from Core:Entity to Core::TypedEntity while QosPolicies are not TypeEnties). Moreover, what is the added value of these associations when all these classes (Topic, DataReader, DataWriter, PublisherSubscriber, DomainParticipant, Figures 7-14 to 7-17), are Core::DomainEntities and, so, have a "qosPolicy" associations?
Figure 9: the names of the fields of a structure are not designed? I.e., following the associations "members" allows to find the names of types of the fields of the structure but not the name of the fields themselves.
Figure 9 and following paragraphs: subset constraints are not designed (most of associations seems to subset at least ownEntity).
The "type" of a TopicDescription should be Types::TopicStruct instead of Types::TopicField.
Either TopicDescription is-a Core::TypedEntity or the association "type" subsets "property"
The semantics behind the dashed line named "is mapped to" is not specified (no class in the metamodel for instance).
Figure 6: qosPolicy subsets property and not ownedEntity as stated in § 7.1.3.1
The document does not specify how the compliance levels are layered. More precisely, does L3 include L2?