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

Open Issues

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

Issues Descriptions

allow extension relationship between Annotation Definitions

  • Key: UCM11-7
  • Status: open  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Subclasses of IConfigurable (ConnectorDefinition, TechnicalPolicyDefinition, etc.) have an extension relationship. This should be applied to AnnotationDefinition too, to bring the same level of flexibility.

  • Reported: UCM 1.0b2 — Mon, 13 Nov 2017 10:29 GMT
  • Updated: Mon, 13 Nov 2017 10:29 GMT

Add cardinalities (i.e. min and max) for configuration parameters

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

    It is impossible to declare optional configuration parameters or to specify that a configuration parameter can accept several values. See for example the following declaration of the standard technical policy for periodic component execution:

    <policyDef applicability="on_component_only" aspect="::core::comp_exec::comp_trig_asp" extends="::core::comp_exec::self_exec_comp" name="prdc_self_exec_comp">
      <comment>periodic self-executing component. It will invoke method run every period.</comment>
      <configParam name="psec_period" type="::core::basic_svc::clock::api::ucm_timeval_t"/>
      <configParam name="psec_priority" type="contracts::priority_t"/>
      <configParam name="psec_offset" type="::core::basic_svc::clock::api::ucm_timeval_t"/>
    </policyDef>
    

    It has 3 mandatory parameters:

    • period
    • offset
    • priority

    While the period is obviously mandatory, the offset information might be optional. It would be nice to be able to specify that offset is not mandatory (min="0"):

    <policyDef applicability="on_component_only" aspect="::core::comp_exec::comp_trig_asp" extends="::core::comp_exec::self_exec_comp" name="prdc_self_exec_comp2">
      <configParam name="psec_period" type="::core::basic_svc::clock::api::ucm_timeval_t"/>
      <configParam name="psec_priority" type="contracts::priority_t"/>
      <configParam min="0" name="psec_offset" type="::core::basic_svc::clock::api::ucm_timeval_t"/>
    </policyDef>
    

    Also, one could imagine some kind of complex policy with several different execution periods in order to create a complex execution pattern.

  • Reported: UCM 1.0b2 — Mon, 23 Oct 2017 12:33 GMT
  • Updated: Mon, 23 Oct 2017 15:42 GMT

Add support for 8-bit integers

  • Key: UCM11-2
  • Status: open  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    IDL42-6 recently introduced support for 8-bit integers in IDL. UCM should follow this enhancement and support 8-bit integers.

  • Reported: UCM 1.0b2 — Mon, 23 Oct 2017 09:55 GMT
  • Updated: Mon, 23 Oct 2017 15:42 GMT

remove class ProgrammingLanguages from the meta-model, as it is useless

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

    Class ProgrammingLanguages had been created to gather programming language declarations and avoid having them scattered in NonfunctionalAspectModule. In the actuality, it creates unnecessary complexity when creating tools without bringing real advantage. It is better to simply remove it and have its contents (class Language) directly linked with class NonfunctionalAspectModule, as illustrated in the attached diagram.

  • Reported: UCM 1.0b2 — Mon, 9 Oct 2017 15:37 GMT
  • Updated: Mon, 23 Oct 2017 15:41 GMT
  • Attachments:

Create a DTD for the XML syntax

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

    UCM 1.0 defines an XML schema, which is sufficient to validate file structures.
    However, XML provides a nice feature: entities. Entities allow automatic string substitution. Some of them are standard. For example: &nbsp;, &quot;, &gt;

    As UCM relies on absolute names to reference elements, XML files can become verbose:

      <policyDef applicability="on_component_only" aspect="::core::comp_exec::comp_trig_asp" extends="::core::comp_exec::self_exec_comp" name="prdc_self_exec_comp">
        <configParam name="psec_period" type="::core::basic_svc::clock::api::ucm_timeval_t"/>
        <configParam name="psec_priority" type="contracts::priority_t"/>
        <configParam name="psec_offset" type="::core::basic_svc::clock::api::ucm_timeval_t"/>
      </policyDef>
    

    It would be nice to be able to write instead:

      <policyDef applicability="on_component_only" aspect="&ce;::comp_trig_asp" extends="&ce;::self_exec_comp" name="prdc_self_exec_comp">
        <configParam name="psec_period" type="&ucm_timeval_t;"/>
        <configParam name="psec_priority" type="contracts::priority_t"/>
        <configParam name="psec_offset" type="&ucm_timeval_t;"/>
      </policyDef>
    

    XML entities require the specification of a DTD.

  • Reported: UCM 1.0b2 — Mon, 23 Oct 2017 15:39 GMT
  • Updated: Mon, 23 Oct 2017 15:40 GMT

Improve component port declaration

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

    Component ports in UCM are specified by 3 parameters:

    • a name
    • a définition
    • bindings to actual types if need be

    UCM defines a set of nested classes in the meta-model, which makes the XML syntax verbose. See for example:

    <compType name="Compare">
      <port name="in1">
        <typeSpec type="::core::messages::msg_rcvr_pt">
          <binding abstract="::core::messages::api::message_type_t" actual="::complex_types::image_t"/>
        </typeSpec>
      </port>
      <port name="in2">
        <typeSpec type="::core::messages::msg_rcvr_pt">
          <binding abstract="::core::messages::api::message_type_t" actual="::complex_types::image_t"/>
        </typeSpec>
      </port>
    </compType>
    

    Three nested XML tags are necessary: port, typeSpec and binding.

    The specification of data binding is nested in the port declaration. Although it is a clean way to specify bindings, it brings two issues:

    • users have to write the binding specification for each port; a binding cannot be written once and used for several ports, which would be simpler
    • it is difficult to implement efficient code generators: a naive generator will generate specific code for each port instead of for each unique binding; this leads to redundant code.

    It would be better to write something like this:

    <bindingSet name="binding1">
      <binding abstract="::core::messages::api::message_type_t" actual="::complex_types::image_t"/>
    </bindingSet>
    
    <compType name="Compare">
      <port name="in1" def="::core::messages::msg_rcvr_pt" binding="binding1"/>
      <port name="in2" def="::core::messages::msg_rcvr_pt" binding="binding1"/></compType>
    

    Also, when refining a component type, ports can be refined. By “refined”, one must understand “redefined”: UCM actually allows a complete port redefinition; no shared data or semantics is required between the original port and its refinement.

  • Reported: UCM 1.0b2 — Mon, 23 Oct 2017 13:53 GMT
  • Updated: Mon, 23 Oct 2017 15:39 GMT

Bring more flexibility in composite component extensions

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

    Composite component implementations can extend other composite implementations. Parts and connections can be refined, with some limitations to guarantee consistency:

    • refined parts must be of the same component type
    • refined connections must be of the same connector definition or an extended connector definition

    This is actually too restrictive. The following should be allowed:

    • refined parts should be of the same component type OR a component type that refines the initial component type
    • refined connections should simply be consistent with the connected ports
  • Reported: UCM 1.0b2 — Mon, 23 Oct 2017 10:14 GMT
  • Updated: Mon, 23 Oct 2017 10:14 GMT