${taskforce.name} Avatar
  1. OMG Task Force

UML Profile for DDS (UML4DDS) FTF 2 — Open Issues

Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
UML4DDS-32 UML Profile for DDS does not refer to WaitSet element UML4DDS 1.0b1 open
UML4DDS-31 format file url for qos_profile should be specified in more detail UML4DDS 1.0b1 open
UML4DDS-30 Problematic type library specification UML4DDS 1.0b1 open
UML4DDS-33 Figure 15-5: UML4DDS 1.0b1 open
UML4DDS-29 Figure 46: "manages" and "class" have not been defined previously. UML4DDS 1.0b1 open
UML4DDS-28 Section 7.3.2.2: what is the "field" stereotype? UML4DDS 1.0b1 open
UML4DDS-21 domainParticipant needs to be considered as a Component *and* a ddsProperty UML4DDS 1.0b1 open
UML4DDS-20 Section 7.2.5 figure 46 UML4DDS 1.0b1 open
UML4DDS-25 the name "relation" is syntactically too poor and too common UML4DDS 1.0b1 open
UML4DDS-24 Section 7.2.7 associations UML4DDS 1.0b1 open
UML4DDS-27 Section 7.3.2.1: UML2 conformance UML4DDS 1.0b1 open
UML4DDS-26 Paragraph 7.3 is non normative and, thus, should be moved in an annex UML4DDS 1.0b1 open
UML4DDS-23 missing link UML4DDS 1.0b1 open
UML4DDS-22 a domain needs to be considered as a ddsSpecification *and* a ddsProperty UML4DDS 1.0b1 open
UML4DDS-19 Section 7.2.4 How are complememts of types designed? UML4DDS 1.0b1 open
UML4DDS-18 Section 7.2.3: TopicStruct and TopicField UML4DDS 1.0b1 open
UML4DDS-17 Section 7.2.3: constraint should be specified UML4DDS 1.0b1 open
UML4DDS-12 Section 7.1.10: SharedKey is not specified anywhere UML4DDS 1.0b1 open
UML4DDS-11 Section 7.1.9: semantics behind dashed line "reads and writes" is unclear UML4DDS 1.0b1 open
UML4DDS-15 Section 7.2.2 UML4DDS 1.0b1 open
UML4DDS-14 Section 7.2.1: wrong UML2 notation UML4DDS 1.0b1 open
UML4DDS-13 which field is actually the key? UML4DDS 1.0b1 open
UML4DDS-16 Section 7.2.3association "type" UML4DDS 1.0b1 open
UML4DDS-7 Section 7.1.5 "TopicField" UML4DDS 1.0b1 open
UML4DDS-6 TopicField should be under Core::Specification UML4DDS 1.0b1 open
UML4DDS-5 Section 7.1 UML4DDS 1.0b1 open
UML4DDS-9 Figure 9: the names of the fields of a structure are not designed UML4DDS 1.0b1 open
UML4DDS-8 Figure 9 and following paragraphs: subset constraints are not designed UML4DDS 1.0b1 open
UML4DDS-4 "type" of a TopicDescription UML4DDS 1.0b1 open
UML4DDS-3 Section 7.1.4 UML4DDS 1.0b1 open
UML4DDS-10 Section 7.1.9 UML4DDS 1.0b1 open
UML4DDS-2 Fig 6:qosPolicy subsets property and not ownedEntity as stated in § 7.1.3.1 UML4DDS 1.0b1 open
UML4DDS-1 The document does not specify how the compliance levels are layered UML4DDS 1.0b1 open

Issues Descriptions

UML Profile for DDS does not refer to WaitSet element

  • Key: UML4DDS-32
  • Legacy Issue Number: 16343
  • Status: open  
  • Source: International Business Machines ( Gidi Gal)
  • Summary:

    UML Profile for DDS does not refer to WaitSet element, though it is part of
    DCPS package in DDS specification.

  • Reported: UML4DDS 1.0b1 — Wed, 22 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

format file url for qos_profile should be specified in more detail

  • Key: UML4DDS-31
  • Legacy Issue Number: 15289
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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?

  • Reported: UML4DDS 1.0b1 — Mon, 14 Jun 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problematic type library specification

  • Key: UML4DDS-30
  • Legacy Issue Number: 15084
  • Status: open  
  • Source: DECA ( Rick Warren)
  • Summary:

    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.

  • Reported: UML4DDS 1.0b1 — Wed, 24 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 15-5:

  • Key: UML4DDS-33
  • Legacy Issue Number: 16353
  • Status: open  
  • Source: International Business Machines ( Gidi Gal)
  • Summary:

    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

  • Reported: UML4DDS 1.0b1 — Thu, 30 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 46: "manages" and "class" have not been defined previously.

  • Key: UML4DDS-29
  • Legacy Issue Number: 12832
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Figure 46: "manages" and "class" have not been defined previously.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.2.2: what is the "field" stereotype?

  • Key: UML4DDS-28
  • Legacy Issue Number: 12831
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    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.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

domainParticipant needs to be considered as a Component *and* a ddsProperty

  • Key: UML4DDS-21
  • Legacy Issue Number: 12824
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Looking at Figure 46 and following, it seems that domainParticipant needs to be considered as a Component and a ddsProperty.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.5 figure 46

  • Key: UML4DDS-20
  • Legacy Issue Number: 12823
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    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

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

the name "relation" is syntactically too poor and too common

  • Key: UML4DDS-25
  • Legacy Issue Number: 12828
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    the name "relation" is syntactically too poor and too common to be used here. Please find something more specific (such as dlrlRelation for instance).

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.7 associations

  • Key: UML4DDS-24
  • Legacy Issue Number: 12827
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    it should be stated that the associations "homes", "topicmanages" and "criterion" subset the UML2 association between UML2::Class and UML2::Property

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.2.1: UML2 conformance

  • Key: UML4DDS-27
  • Legacy Issue Number: 12830
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    UML2 conformance: ActiveUser should be change with "active_user:UserType" and the "type" tag should be removed (as well as with ChatMessage and MessageType).

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Paragraph 7.3 is non normative and, thus, should be moved in an annex

  • Key: UML4DDS-26
  • Legacy Issue Number: 12829
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Paragraph 7.3 is non normative and, thus, should be moved in an annex

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

missing link

  • Key: UML4DDS-23
  • Legacy Issue Number: 12826
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    There is no link between, on the one hand, publisher, subscriber, domainparticipant, datareader, datawriter and, on the other hand, qosProperty (I guess it should).

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

a domain needs to be considered as a ddsSpecification *and* a ddsProperty

  • Key: UML4DDS-22
  • Legacy Issue Number: 12825
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Looking at Figure 46 and following, it seems that a domain needs to be considered as a ddsSpecification and a ddsProperty.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.4 How are complememts of types designed?

  • Key: UML4DDS-19
  • Legacy Issue Number: 12822
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    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.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.3: TopicStruct and TopicField

  • Key: UML4DDS-18
  • Legacy Issue Number: 12821
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    TopicStruct and TopicField should specialize ddsSpecification and ddsProperty

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.3: constraint should be specified

  • Key: UML4DDS-17
  • Legacy Issue Number: 12820
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    A constraint should be specified to subset the UML2 associations "attribute" between TopicStruct and TopicField.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1.10: SharedKey is not specified anywhere

  • Key: UML4DDS-12
  • Legacy Issue Number: 12815
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    SharedKey is not specified anywhere (used elsewhere but never defined).

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1.9: semantics behind dashed line "reads and writes" is unclear

  • Key: UML4DDS-11
  • Legacy Issue Number: 12814
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    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

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.2

  • Key: UML4DDS-15
  • Legacy Issue Number: 12818
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    it should be stated that an association between qosProperty and qosPolicy subsets the UML2 association between UML2::Class and UML2::Property

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.1: wrong UML2 notation

  • Key: UML4DDS-14
  • Legacy Issue Number: 12817
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    wrong UML2 notation for an extension association between a stereotype and its metaclass

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

which field is actually the key?

  • Key: UML4DDS-13
  • Legacy Issue Number: 12816
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    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.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2.3association "type"

  • Key: UML4DDS-16
  • Legacy Issue Number: 12819
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    it should be stated that the association "type" subsets the UML2 association between UML2::Class and UML2::Property.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1.5 "TopicField"

  • Key: UML4DDS-7
  • Legacy Issue Number: 12810
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    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.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

TopicField should be under Core::Specification

  • Key: UML4DDS-6
  • Legacy Issue Number: 12809
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    TopicField should be under Core::Specification (target of the association "type") instead of the too general Core::Entity.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1

  • Key: UML4DDS-5
  • Legacy Issue Number: 12808
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    §§ 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?

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 9: the names of the fields of a structure are not designed

  • Key: UML4DDS-9
  • Legacy Issue Number: 12812
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    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.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 9 and following paragraphs: subset constraints are not designed

  • Key: UML4DDS-8
  • Legacy Issue Number: 12811
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Figure 9 and following paragraphs: subset constraints are not designed (most of associations seems to subset at least ownEntity).

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

"type" of a TopicDescription

  • Key: UML4DDS-4
  • Legacy Issue Number: 12807
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    The "type" of a TopicDescription should be Types::TopicStruct instead of Types::TopicField.

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1.4

  • Key: UML4DDS-3
  • Legacy Issue Number: 12806
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Either TopicDescription is-a Core::TypedEntity or the association "type" subsets "property"

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.1.9

  • Key: UML4DDS-10
  • Legacy Issue Number: 12813
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    The semantics behind the dashed line named "is mapped to" is not specified (no class in the metamodel for instance).

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fig 6:qosPolicy subsets property and not ownedEntity as stated in § 7.1.3.1

  • Key: UML4DDS-2
  • Legacy Issue Number: 12805
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Figure 6: qosPolicy subsets property and not ownedEntity as stated in § 7.1.3.1

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The document does not specify how the compliance levels are layered

  • Key: UML4DDS-1
  • Legacy Issue Number: 12804
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    The document does not specify how the compliance levels are layered. More precisely, does L3 include L2?

  • Reported: UML4DDS 1.0b1 — Thu, 4 Sep 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT