1. OMG Mailing List
  2. Unified Component Model 1.3 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: ucm-rtf
  • Issues Count: 7

Issues Descriptions

fix problems in the XMI file of the UCM metamodel

  • Key: UCM12-13
  • Status: open  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    This issue corresponds to remarks from Pete Rivett regarding the XMI file of the UML metamodel.

    The namespace for UML is wrong xmlns:uml="http://www.eclipse.org/uml2/5.0.0/UML"

    Remove xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
    And all eAnnotations (8)

    The package URI should conform to OMG’s standard URI="http://org.omg.ucm/1.0/metamodels/base/commons".
    It should be https://www.omg.org/spec/UCM/20190501/ucm_base.uml

    Since it’s a metamodel the topmost element should be the Package not the uml:Model

    The primitive types do not reference the standard ones:
    For example
    <type xmi:type="uml:PrimitiveType" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#String"/>

    The URI should be
    https://www.omg.org/spec/UCM/20190501/ucm_base.uml

    There should be no xmi:type or reference elements such as the above.
    There should be no xmi:version.

  • Reported: UCM 1.1 — Mon, 24 Jun 2019 14:30 GMT
  • Updated: Sat, 29 Jun 2019 00:02 GMT
  • Attachments:

change the character base of the string type in the standard annotations

  • Key: UCM12-6
  • Status: open  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The standard annotations (module ucm_std_ann) defines a set of properties, the type of which is a string (prop_str_t). The base character of this string is “char8”. As these properties are likely to contain text in natural language, it would be better to use wide characters (wchar) instead.

  • Reported: UCM 1.1 — Tue, 26 Feb 2019 13:11 GMT
  • Updated: Sun, 19 May 2019 00:41 GMT
  • Attachments:

typos

  • Key: UCM12-11
  • Status: open  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The document contains some typos.

    In section 9.2.8 (Abstract type declarations), the end of the first paragraph contains an error: “(§ Error: Reference source not found)”.

    In section 10 (XML syntax for UCM declarations), in the sentence that starts with “Basically, every UCM concept described in the meta-model (see section [9]) corresponds…”, the section number (9) is plain text while it should be a link to section 9.

    In section 13 (Specification of UCM platform capabilities), a reference to a document is missing in the second paragraph.

    In section 13.1.2.1 (From connectors to fragments), there are several typos.

    • in the first paragraph, “As states by the UCM metamodel"
    • in the second paragraph, “Ex: the fragments of DDS based connector implementation…”

    In section 14.1.2.2 (From technical policies to fragments), “As for the connector PortElements…” should be replaced by “Like for the connector PortElements…”.

    In section 14.2.1.4 (Connectable), in the first line of the first paragraph, “shallt” should be “shall”.

    In section 15.7 (UCM module mapping), the IDL code block is colored, while all code blocks in the document are written in black. Same thing in sections 15.8.2 (Atomic Component Implementation mapping), 15.8.4 (Port mapping), 15.8.5 (Technical Policy Mapping).

    In section 15.11 (Component Programming Model), in the second paragraph, “programing” should be spelled “programming”.

    In section 16.10.2 (Enumeration mapping), the C++ code block is colored while all code blocks in the document are written in black.

  • Reported: UCM 1.1 — Mon, 29 Apr 2019 10:11 GMT
  • Updated: Sun, 19 May 2019 00:41 GMT

Introduce name spaces to split declarations across several files

  • Key: UCM12-1
  • Status: open  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Although it is not explicitly specified in the standard, UCM modules cannot be
    declared in several parts. Hence, a UCM module and all its submodules must be
    gathered in a single file; such a file may be difficult to read if there are
    many submodules.

    It would be nice to introduce the notion of name space in UCM. A UCM name space
    would be a specific kind of module that can contain any type of module. A UCM
    name space could be declared several times (each declaration in a separate
    file).

    Example:
    In file sys--components.xml

    <namespace name="sys">
      <componentModule name="components">
      […]
      </componentModule>
    </namespace>
    

    In file sys--contracts.xml

    <namespace name="sys">
      <contractModule name="contracts">
      […]
      </contractModule>
    </namespace>
    

    Currently, only the following declarations are allowed:

    <applicationModule name="sys">
      <componentModule name="components">
      […]
      </componentModule>
      <contractModule name="contracts">
      […]
      </contractModule>
    </applicationModule>
    

    This would enable split a large UCM model in several files while keeping a
    common naming scheme.

  • Reported: UCM 1.1 — Tue, 9 Oct 2018 15:55 GMT
  • Updated: Sun, 19 May 2019 00:41 GMT
  • Attachments:

enable the use of message send port type in the shared data connector

  • Key: UCM12-5
  • Status: open  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The shared data connector defined in the standard UCM library involves two port types: sd_writer_pt and sd_reader_pt. In particular, sd_writer_pt is based on an interface that defines three methods: “write_data”, “publish_data” and “cancel_data”. The standard message connector (section 13.1.7) involves a simpler port type msg_emtr_pt, with a single method “push”.
    The shared data connector should support port type msg_emtr_pt, as its API (a single method “push”) is simpler. The shared data connector would then offer to alternative port types to publish data: sd_writer_pt and msg_emtr_pt.

  • Reported: UCM 1.1 — Tue, 26 Feb 2019 11:43 GMT
  • Updated: Sun, 19 May 2019 00:41 GMT
  • Attachments:

clarify the UCM programming model and C++ mapping w.r.t. port element connection

  • Key: UCM12-4
  • Status: open  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The programming model described in section 14.2 shows a set of methods to be implemented by programming language mappings. In particular, the signatures of connection methods are explicitly described (see figure 14.5 on page 77 for on_disconnect and on_connect). These methods are restrictive, as they force some "dynamic" programming: port elements are accessed from their names.
    Section 16.7 indicates the corresponding mapping to C++11, with the same method signatures.
    However, section 16.9 indicates there could actually be two approaches for a C++ mapping: one based on strongly typed methods, and the other based on generic methods. Section 16.7 describes the later one.

    Section 16.9 is so small it might be completely overlooked, while it states a very important point: both generic and strongly typed mappings are necessary. Generic API is nice as it provides flexibility when creating applications, but it prevents addressing real-time critical systems, as it manipulates strings (which cannot guarantee execution time). On the opposite, a strongly typed API completely suits cricital systems as it enables far more predictable execution time, but it also prevent flexibility in the implementation, and is almost always coupled with code generation.

    Section 16.9 shows that the UCM standard identified the two mapping approaches, and decided to allow both. But it is not explicit enough. The definition of the programming model in section 14.2 should explicitly address the two possibilities (generic and strongly typed). Section 16 should explicitly explain that UCM actually defines TWO standard mappings for C++11: one with generic API and the other with a strongly typed API.

  • Reported: UCM 1.1 — Mon, 25 Feb 2019 17:36 GMT
  • Updated: Sun, 19 May 2019 00:41 GMT
  • Attachments:

wrong constraint in technical aspect comp_exec_asp

  • Key: UCM12-3
  • Status: open  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    In the UCM specification document, contraint of technical aspect “comp_exec_asp” is “exactly_one”, which means a given atomic component implementation must have one and only one technical policy that specifies its execution. For example, either passive unprotected, passive protected or active protected
    However, in the XML file of the core library, technical aspect “comp_exec_asp” is specified with constraint “any_number”. This is inconsistent with the specification document

  • Reported: UCM 1.1 — Tue, 20 Nov 2018 17:35 GMT
  • Updated: Sun, 19 May 2019 00:41 GMT
  • Attachments: