Issue 12804: The document does not specify how the compliance levels are layered
Issue 12805: Fig 6:qosPolicy subsets property and not ownedEntity as stated in § 7.1.3.1
Issue 12806: Section 7.1.4
Issue 12807: "type" of a TopicDescription
Issue 12808: Section 7.1
Issue 12809: TopicField should be under Core::Specification
Issue 12810: Section 7.1.5 "TopicField"
Issue 12811: Figure 9 and following paragraphs: subset constraints are not designed
Issue 12812: Figure 9: the names of the fields of a structure are not designed
Issue 12813: Section 7.1.9
Issue 12814: Section 7.1.9: semantics behind dashed line "reads and writes" is unclear
Issue 12815: Section 7.1.10: SharedKey is not specified anywhere
Issue 12816: which field is actually the key?
Issue 12817: Section 7.2.1: wrong UML2 notation
Issue 12818: Section 7.2.2
Issue 12819: Section 7.2.3association "type"
Issue 12820: Section 7.2.3: constraint should be specified
Issue 12821: Section 7.2.3: TopicStruct and TopicField
Issue 12822: Section 7.2.4 How are complememts of types designed?
Issue 12823: Section 7.2.5 figure 46
Issue 12824: domainParticipant needs to be considered as a Component *and* a ddsProperty
Issue 12825: a domain needs to be considered as a ddsSpecification *and* a ddsProperty
Issue 12826: missing link
Issue 12827: Section 7.2.7 associations
Issue 12828: the name "relation" is syntactically too poor and too common
Issue 12829: Paragraph 7.3 is non normative and, thus, should be moved in an annex
Issue 12830: Section 7.3.2.1: UML2 conformance
Issue 12831: Section 7.3.2.2: what is the "field" stereotype?
Issue 12832: Figure 46: "manages" and "class" have not been defined previously.
Issue 15084: Problematic type library specification
Issue 15289: format file url for qos_profile should be specified in more detail
Issue 16343: UML Profile for DDS does not refer to WaitSet element
Issue 16353: Figure 15-5:
Issue 12804: The document does not specify how the compliance levels are layered (uml4dds-ftf)
Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Clarification
Severity: Significant
Summary:
The document does not specify how the compliance levels are layered. More precisely, does L3 include L2?
Figure 6: qosPolicy subsets property and not ownedEntity as stated in § 7.1.3.1
Either TopicDescription is-a Core::TypedEntity or the association "type" subsets "property"
The "type" of a TopicDescription should be Types::TopicStruct instead of Types::TopicField.
§§ 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?
TopicField should be under Core::Specification (target of the association "type") instead of the too general Core::Entity.
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.
Figure 9 and following paragraphs: subset constraints are not designed (most of associations seems to subset at least ownEntity).
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.
The semantics behind the dashed line named "is mapped to" is not specified (no class in the metamodel for instance).
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
SharedKey is not specified anywhere (used elsewhere but never defined).
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.
wrong UML2 notation for an extension association between a stereotype and its metaclass
it should be stated that an association between qosProperty and qosPolicy subsets the UML2 association between UML2::Class and UML2::Property
it should be stated that the association "type" subsets the UML2 association between UML2::Class and UML2::Property.
A constraint should be specified to subset the UML2 associations "attribute" between TopicStruct and TopicField.
TopicStruct and TopicField should specialize ddsSpecification and 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.
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
Looking at Figure 46 and following, it seems that domainParticipant needs to be considered as a Component *and* a ddsProperty.
Looking at Figure 46 and following, it seems that a domain needs to be considered as a ddsSpecification *and* a ddsProperty.
a domain needs to be considered as a ddsSpecification *and* a ddsProperty.
There is no link between, on the one hand, publisher, subscriber, domainparticipant, datareader, datawriter and, on the other hand, qosProperty (I guess it should).
it should be stated that the associations "homes", "topicmanages" and "criterion" subset the UML2 association between UML2::Class and UML2::Property
the name "relation" is syntactically too poor and too common to be used here. Please find something more specific (such as dlrlRelation for instance).
Paragraph 7.3 is non normative and, thus, should be moved in an annex
UML2 conformance: ActiveUser should be change with "active_user:UserType" and the "type" tag should be removed (as well as with ChatMessage and MessageType).
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.
Figure 46: "manages" and "class" have not been defined previously.
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.
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?
UML Profile for DDS does not refer to WaitSet element, though it is part of DCPS package in DDS specification.
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