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

Closed Issues

  • Issues resolved by a task force and approved by Board
  • Name: ucm-rtf
  • Issues Count: 33

Issues Summary

Key Issue Reported Fixed Disposition Status
UCM13-16 Introduce structured configuration parameters UCM 1.2 UCM 1.3 Resolved closed
UCM13-17 Unexpected mention of “monolithic” component implementation UCM 1.2 UCM 1.3 Resolved closed
UCM13-5 problems in the XML schema and the DTD UCM 1.2b1 UCM 1.3 Resolved closed
UCM13-23 List XML tags names and clarify the rules for name references UCM 1.2 UCM 1.3 Resolved closed
UCM13-13 broken link in the document UCM 1.2 UCM 1.3 Resolved closed
UCM13-21 Rephrase some explanations UCM 1.2 UCM 1.3 Resolved closed
UCM13-11 define port types for “pull-pull” interactions UCM 1.2 UCM 1.3 Resolved closed
UCM13-4 Add a method in the comp_trace policy to log messages with a default severity UCM 1.2 UCM 1.3 Closed; No Change closed
UCM13-3 Allow specific configuration for the ports and policies managed by a given technical policy UCM 1.2 UCM 1.3 Resolved closed
UCM13-2 Attribute values of parts cannot be set in composite component implementation, while configuration parameter values of connections can UCM 1.2 UCM 1.3 Resolved closed
UCM13-1 Named entities have no ID in the meta-model UCM 1.2 UCM 1.3 Resolved closed
UCM13-8 Inconsistency in number of bindings for technical policies UCM 1.2 UCM 1.3 Resolved closed
UCM13-10 rename “executor” into “context” in the container model UCM 1.2 UCM 1.3 Resolved closed
UCM12-13 fix problems in the XMI file of the UCM metamodel UCM 1.1 UCM 1.2 Resolved closed
UCM12-6 change the character base of the string type in the standard annotations UCM 1.1 UCM 1.2 Resolved closed
UCM12-5 enable the use of message send port type in the shared data connector UCM 1.1 UCM 1.2 Resolved closed
UCM12-4 clarify the UCM programming model and C++ mapping w.r.t. port element connection UCM 1.1 UCM 1.2 Resolved closed
UCM12-11 typos UCM 1.1 UCM 1.2 Resolved closed
UCM12-3 wrong constraint in technical aspect comp_exec_asp UCM 1.1 UCM 1.2 Resolved closed
UCM12-1 Introduce name spaces to split declarations across several files UCM 1.1 UCM 1.2 Resolved closed
UCM11-19 value ranges are wrong for 8-bit integers UCM 1.0 UCM 1.1 Resolved closed
UCM11-18 there should be no returned error code for data consumers in the standard library UCM 1.0 UCM 1.1 Resolved closed
UCM11-17 names of standard library files should be consistent with module names UCM 1.0 UCM 1.1 Resolved closed
UCM11-1 remove class ProgrammingLanguages from the meta-model, as it is useless UCM 1.0b2 UCM 1.1 Resolved closed
UCM11-15 improve the specification of task periods UCM 1.0 UCM 1.1 Resolved closed
UCM11-14 remove parameter "methods_to_trace" from port_trace technical policy UCM 1.0 UCM 1.1 Resolved closed
UCM11-7 allow extension relationship between Annotation Definitions UCM 1.0b2 UCM 1.1 Resolved closed
UCM11-16 Connectable interfaces does not support more that one portelement per port-type UCM 1.0 UCM 1.1 Resolved closed
UCM11-3 Bring more flexibility in composite component extensions UCM 1.0b2 UCM 1.1 Resolved closed
UCM11-2 Add support for 8-bit integers UCM 1.0b2 UCM 1.1 Resolved closed
UCM11-6 Create a DTD for the XML syntax UCM 1.0b2 UCM 1.1 Resolved closed
UCM11-5 Improve component port declaration UCM 1.0b2 UCM 1.1 Resolved closed
UCM11-4 Add cardinalities (i.e. min and max) for configuration parameters UCM 1.0b2 UCM 1.1 Resolved closed

Issues Descriptions

Introduce structured configuration parameters

  • Key: UCM13-16
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    It is currently not possible to gather several configuration parameters together.

    For example, let us suppose we want to design a message connector that handles channels with different FIFO priorities.
    Such a connector would allow the specification of a channel number for each emission port.
    It would also allow the specification of a FIFO priority for each channel number in each reception port.

    See the following example of what would be needed:

    <interactionModule name="enhanced_fifo_connector">
      <contractModule name="data_types">
        <integer kind="int32" name="channel_id_t"/>
        <integer kind="uint8" name="fifo_priority_t"/>
      </contractModule>
      <connectorDef name="enh_fifo_msg_cnt" pattern="::ucm_core::messages::msg_intr_pat">
        <extends ref="::ucm_core::messages::simple_msg_cnt"/>
        <portConf port="emitter">
          <configParam max="1" min="1" name="channel_id" type="data_types::channel_id_t"/>
        </portConf>
        <portConf port="receiver">
          <structParam max="-1" min="0" name="fifo_priorities">
            <comment>the default fifo priority is 0</comment>
            <configParam max="-1" min="1" name="emitter_channel_id" type="data_types::channel_id_t"/>
            <configParam max="1" min="1" name="fifo_priority" type="data_types::fifo_priority_t"/>
          </structParam>
        </portConf>
      </connectorDef>
    </interactionModule>
    

    Sets made of several channels and one priority can be specified for each port “receiver”.

    Such a connector could be used as follows:

    <componentModule name="components">
      <contractModule name="contracts">
        <integer kind="int16" name="payload_t"/>
      </contractModule>
      
      <bindingSet name="payload_binding">
        <binding abstract="::ucm_core::messages::api::transm_data_t" actual="contracts::payload_t"/>
      </bindingSet>
      
      <compType name="C_sender">
        <port bindings="payload_binding" name="snd" type="::ucm_core::messages::msg_emtr_pt"/>
      </compType>
      
      <compType name="C_receiver">
        <port bindings="payload_binding" name="rcv" type="::ucm_core::messages::msg_rcvr_pt"/>
      </compType>
      
      <compType name="C_appli">
      </compType>
      
      <atomic lang="::ucm_lang::cpp::CPP11_typed" name="CI_sender" type="C_sender"/>
      <atomic lang="::ucm_lang::cpp::CPP11_typed" name="CI_receiver" type="C_receiver"/>
      
      <composite name="appli" type="C_appli">
        <part name="c1" ref="CI_sender"/>
        <part name="c2" ref="CI_sender"/>
        <part name="c3" ref="CI_sender"/>
        <part name="c4" ref="CI_receiver"/>
        <part name="c5" ref="CI_receiver"/>
        <connection name="cnx1" ref="::enhanced_fifo_connector::enh_fifo_msg_cnt">
          <end name="c1_snd" part="c1" port="snd">
            <config def="channel_id" value="1"/>
          </end>
          <end name="c2_snd" part="c2" port="snd">
            <config def="channel_id" value="2"/>
          </end>
          <end name="c3_snd" part="c3" port="snd">
            <config def="channel_id" value="3"/>
          </end>
          <end name="c4_rcv" part="c4" port="rcv">
            <structConfig def="fifo_priorities">
              <config def="emitter_channel_id" value="1"/>
              <config def="fifo_priority" value="2"/>
            </structConfig>
            <structConfig def="fifo_priorities">
              <config def="emitter_channel_id" value="2"/>
              <config def="emitter_channel_id" value="3"/>
              <config def="fifo_priority" value="9"/>
            </structConfig>
          </end>
          <end name="c5_rcv" part="c5" port="rcv">
            <structConfig def="fifo_priorities">
              <config def="emitter_channel_id" value="1"/>
              <config def="fifo_priority" value="5"/>
            </structConfig>
            <structConfig def="fifo_priorities">
              <config def="emitter_channel_id" value="2"/>
              <config def="fifo_priority" value="2"/>
            </structConfig>
            <structConfig def="fifo_priorities">
              <config def="emitter_channel_id" value="3"/>
              <config def="fifo_priority" value="1"/>
            </structConfig>
          </end>
        </connection>
      </appAssembly>
    </componentModule>
    

    Composite component 'C_appli' contains 5 subcomponents: c1, c2 and c3 send messages to c4 and c5.
    Subcomponent c1 sends on channel 1, c2 sends on channel 2, c3 sends on channel 3.

    Subcomponents c4 and c5 receive all messages, with different priorities.
    Thus, c4 receives data from c1 (channel 1) with priority 2, data from c2 and c3 (channels 2 and 3) with priority 9.
    And c5 receives data from c1 (channel 1) with priority 5, data from c2 (channel 2) with priority 2, data from c3 (channels 3) with priority 1.

  • Reported: UCM 1.2 — Thu, 15 Oct 2020 13:16 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    create structured configuration parameters

    Add two new concepts in the meta-model: StructuredConfigurationParameter and StructuredConfigurationParameterValue.
    Update the XML schema and DTD accordingly.

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

Unexpected mention of “monolithic” component implementation

  • Key: UCM13-17
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    In section 14.1.2.2 (From technical policies to fragments), diagram 35 shows a “monolithic” component implementation. Monolithic component implementations are mentionned nowhere else in the document; this “monolithic” component is should be renamed “atomic” instead.

  • Reported: UCM 1.2 — Thu, 15 Oct 2020 13:39 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    rename “monolithic” into “atomic”

    In the early stages of the UCM standard, atomic component implementation were called monolithic. Update diagram 35 to use word “atomic”.

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

problems in the XML schema and the DTD

  • Key: UCM13-5
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    In the DTD, tag "comment" is missing in the declaration of element componentModule, line 283.

    In the XML schema, elements "componentModule" and "contractModule" are inverted with respect to the DTD, lines 672 and 673.

  • Reported: UCM 1.2b1 — Tue, 3 Mar 2020 13:49 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    Fix the problems in the DTD and the XML schema

    Fix the problems

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

List XML tags names and clarify the rules for name references

  • Key: UCM13-23
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Although the XML syntax of UCM is specified by a DTD and an XML schema, it would be nice to have at least a list of the XML tags in the main document, to help read the DTD and the schema.
    Also, the way of referencing entities is not completely clear for relative names.

  • Reported: UCM 1.2 — Tue, 2 Mar 2021 17:31 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    List XML tags names and clarify the rules for name references

    List the main tag names of the XML syntax. Clarify relative name references.

  • Updated: Mon, 4 Oct 2021 17:10 GMT

broken link in the document

  • Key: UCM13-13
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The content of section 17.4 “Components” is “The examples of this section correspond to the example illustrated in sectionError: Reference source not found”.
    This is obviously a broken link.

    The link should be updated to point to section 11.3 “Example”.

  • Reported: UCM 1.2 — Tue, 29 Sep 2020 11:57 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    fix the broken link

    Update the link to section 11.3 (Example)

  • Updated: Mon, 4 Oct 2021 17:10 GMT

Rephrase some explanations

  • Key: UCM13-21
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    There are some inconsistencies in the first sections of the document.
    For example, section 1.4 is entitled “Programming model” while section 14 is entitled “UCM container model”.
    Also, section 9.1.2 mentions “properties”, which do not seem to be defined in the rest of the document.

  • Reported: UCM 1.2 — Tue, 9 Feb 2021 17:54 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    Rephrase some explanations

    Some terms (e.g. “properties” or “programming model”) had been used in the early stages of the standard, but are have not been used in the final version of the document. Replace these obsolete terms with the correct ones.

  • Updated: Mon, 4 Oct 2021 17:10 GMT

define port types for “pull-pull” interactions

  • Key: UCM13-11
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The UCM core library defines the message connector in which the data producer pushes data to the connector, and the connector pushes data to the consumer. This more or less corresponds to the event interactions of CCM.

    Yet, in some situations, pulling data from the producer is a good architectural choice. For example, if we want to ensure a piece of data is sent periodically, it is best to let the connector manage this, instead of the component: even if there are bugs in the component business code, that connector shall periodically fetch the data.

    It might be difficult to standardize a “pull-pull” connector because there could be many different situations: periodic fetching, fetching upon request from the consumer, etc. The UCM standard should simply define port types in order to have standard APIs.

  • Reported: UCM 1.2 — Wed, 23 Sep 2020 16:54 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    define a data pull connector

    Define a data pull connector in the extended interactions. This connector involves one supplier and one or more consumers. Whenever a consumer pulls a piece of data, the piece of data is fetched from the supplier.

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

Add a method in the comp_trace policy to log messages with a default severity

  • Key: UCM13-4
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The invocation of the standard technical policy for traces consists of a method
    log that takes two parameters:

    • the severity (trace, debug, warning, etc.)
    • the log message (a wide character string)

    It can be tedious to always have to specify the severity. There should be an
    additional log method with a default severity.

  • Reported: UCM 1.2 — Tue, 7 Jan 2020 17:13 GMT
  • Disposition: Closed; No Change — UCM 1.3
  • Disposition Summary:

    Do not change the comp_trace policy

    No commonly used logging API (e.g. log4cpp) supports a default severity level. Therefore, such a mechanism does not correspond to current pratice, and may be difficult to understand.

    Platform providers that really want to deal with a default severity loggin level can define their own, non standard, technical policy.

  • Updated: Mon, 4 Oct 2021 17:10 GMT

Allow specific configuration for the ports and policies managed by a given technical policy

  • Key: UCM13-3
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Technical policies can have configuration parameters, and can manage component
    features (i.e. they can intercept them). However, it is not possible to
    associate a specific configuration with a given component feature.

    Current state

    Technical policy definitions can specify configuration parameters. In the
    following example, technical policy definition watchdog specifies a
    configuration parameter for the timeout. It also declares an interface named
    watchdog_intf that must be provided by components. The policy calls method
    timeout if no activity has been detected on the intercepted component
    features for some time.

    <policyModule name="example">
     <contractModule name="api">
       <interface name="watchdog_intf">
        <method name="timeout"/>
       </interface>
     </contractModule>
    
     <technicalAspect constraint="any_number" name="asp"/>
    
     <policyDef applicability="on_some_ports" aspect="asp" name="watchdog">
      <comment>This policy intercepts some component ports and policies. It invokes method timeout if no activity is detected on one of these ports and policies after max_delay.  </comment>
      <portElement interface="api::watchdog_intf" kind="provided" name="wdg"/>
      <configParam name="max_delay" type="::ucm_ext_exec::contracts::ucm_duration_t"/>
     </policyDef>
    </policyModule>
    

    One can set the value max_delay when declaring such a policy. In the
    following, we declare an atomic component named calculation_impl that has
    two input ports input1 and input2. It is associated with technical
    policy watcher that monitors both ports. Policy watcher triggers an
    alert after 2 seconds of inactivity on both ports.

    <componentModule name="comp">
     <contractModule name="data_types">
      <integer name="int32_t" kind="int32"/> 
     </contractModule>
    
     <bindingSet name="bindings">
      <binding abstract="::ucm_core::messages::api::transm_data_t" actual="data_types::int32_t"/>
     </bindingSet>
    
     <compType name="calculation">
      <port name="input1" type="::ucm_core::message::msg_recv_pt" bindings="bindings"/>
      <port name="input2" type="::ucm_core::message::msg_recv_pt" bindings="bindings"/>
     </compType>
    
     <policy name="watcher" def="::example::watchdog">
      <componentRef ref="calculation_impl"/>
      <managedPort ref="input1"/>
      <managedPort ref="input2"/>
      <configValue name="max_delay" value="{2, s}"/>
     </policy>
    
     <atomic name="calculation_impl" lang="::ucm_lang::cpp::cpp11_typed">
      <policyRef ref="watcher"/>
     </atomic>
    </componentModule>
    

    Limitation

    The problem is, it is impossible to set a specific timeout value for each
    intercepted port. Thus, one cannot specify that policy watcher shall
    trigger an alert after 2 seconds of inactivity on port input1, or 3 seconds
    of inactivity on port input2.

    Having two separate policies (one for each intercepted port) is not convenient
    because the component business code would then have to implement two different
    methods timeout (one for each policy).

    What should be added

    Technical policy definition should be extended to declare configuration
    parameters that apply to particular managed component features. Thus, the
    declaration of watchdog may be something like this:

    <policyDef applicability="on_some_ports" aspect="asp" name="watchdog">
     <comment>This policy intercepts some component ports and policies. It invokes method timeout if no activity is detected on one of these ports and policies after max_delay.  </comment>
     <portElement interface="api::watchdog_intf" kind="provided" name="wdg"/>
     <configParam name="default_max_delay" type="::ucm_ext_exec::contracts::ucm_duration_t"/>
     <specificConf name="specific_delays">
      <configParam name="max_delay" type="::ucm_ext_exec::contracts::ucm_duration_t"/>
     </specificConf>
    </policyDef>
    

    An additional section named featureConf allows the declaration of per-feature configuration parameters.

    Technical policy watcher may then be declared as follows:

    <policy name="watcher" def="::example::watchdog">
     <componentRef ref="calculation_impl"/>
     <managedPort ref="input1"/>
     <managedPort ref="input2"/>
     <configValue name="default_max_delay" value="{2, s}"/>
     <featureConf name="input2_config">
      <managedPort ref="input2"/>
      <configValue name="max_delay" value="{3, s}"/>
     </featureConf>
    </policy>
    

    Here, the policy triggers an alert after 2 seconds of inactivity on input1
    (default policy configuration) or after 3 seconds of inactivity on input2
    (specific configuration).

  • Reported: UCM 1.2 — Tue, 7 Jan 2020 15:17 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    Allow the specification of configuration parameters that are associated to particular ports or policies

    Create two new meta-classes:

    • SpecificPolicyParameter enables the declaration of configuration parameters that may be associated to some managed ports or policies
    • SpecificPolicyConfigurationValue actually associates configuration parameter values to managed ports or policies

    Provide an example for a better understanding.

    Update the XML schema and DTD with the new syntactic elements.

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

Attribute values of parts cannot be set in composite component implementation, while configuration parameter values of connections can

  • Key: UCM13-2
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    In CompositeComponentImplementation, the ucm_base meta-model allows the specification of configuration parameter values in Connection and ConnectionEnd, but it does not allow the specification of attribute values in AssemblyPart. The meta-model would be more consistent if it supported the specification of attribute values in AssemblyPart.
    For example, if we have the following component declaration:

    <componentModule name="comp">
      <compType name="C1">
        <attribute mode="read" name="attr1" type="::dataTypes::Int32_t"/>
      </compType>
    
      <atomic name="C1_i1" lang="::ucm_lang::cpp::CPP11_typed" type="C1"/>
    </componentModule>
    

    We should be able to write something like this:

    <componentModule name="comp2">
      <compType name="C2"/>
    
      <composite name="C2_i1" type="C2">
        <part name="c1a" ref="::comp::C1_i1">
          <attrVal ref="attr1" value="23"/>
        </part>
        <part name="c1b" ref="::comp::C1_i1">
          <attrVal ref="attr1" value="12"/>
        </part>
      </composite>
    </componentModule>
    

    Attribute attr1 shall be initialized to 23 for part c1a and to 12 for c1b.

  • Reported: UCM 1.2 — Thu, 5 Dec 2019 12:26 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    Set attribute values in assembly parts

    Add a new metaclass AttributeValue that allows the specification of a value for an attribute. This metaclass is referenced by metaclass AssemblyPart.

    Also update the DTD and XML schema.

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

Named entities have no ID in the meta-model

  • Key: UCM13-1
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The UCM DTD and XML schema specify an ID field for each named entity. Yet, such ID do not exist in the INamed metaclass of the ucm_base metamodel. Adding IDs in INamed entities would ease the importation of XML files into existing UCM models by enabling model mergers.

  • Reported: UCM 1.2 — Thu, 5 Dec 2019 10:37 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    Add an ID field in class INamed

    add a field “id” to class INamed

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

Inconsistency in number of bindings for technical policies

  • Key: UCM13-8
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Field “bindings” of technical policies is specified with cardinality [0…*] in the text, while it is displayed with cardinality [0…1] in diagram 31.

  • Reported: UCM 1.2 — Mon, 7 Sep 2020 10:08 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    change cardinality of field “bindings” of class TechnicalPolicy

    The correct cardinality is [0…1]. Change the text accordingly.

  • Updated: Mon, 4 Oct 2021 17:10 GMT

rename “executor” into “context” in the container model

  • Key: UCM13-10
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The UCM container model specifies that a PortElementObject uses the name “executor” to refer to the ComponentObject it belongs to. The name “context” may be a better choice for this.
    Indeed, the methods of a PortElementObject use the ComponentObject to retrieve the references to the other PortElementObjects of the component. So, the ComponentObject can be seen as a context for the execution of PortElementObject methods.
    Using “context” would make UCM more consistent with CCM.

  • Reported: UCM 1.2 — Wed, 23 Sep 2020 16:34 GMT
  • Disposition: Resolved — UCM 1.3
  • Disposition Summary:

    replace “executor” by “context”

    In section 13, replace “executor” by “body” (1 replacement).
    In the rest of the document, replace all occurrences of “executor” by “context” (4 replacements).
    Update two diagrams that describe the UCM container model.

  • Updated: Mon, 4 Oct 2021 17:10 GMT
  • Attachments:

fix problems in the XMI file of the UCM metamodel

  • Key: UCM12-13
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.2
  • Disposition Summary:

    fix conformity issues in the XMI metamodel file

    Fixed the problems the issue points out.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

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

  • Key: UCM12-6
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.2
  • Disposition Summary:

    set the character base to wchar in the standard annotations

    Issue UCM12-6 is addressed by changing the base character type of string prop_str_t from “char8” to “wchar”.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

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

  • Key: UCM12-5
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.2
  • Disposition Summary:

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

    Add a new connector port sd_simple_writer with port type msg_emtr_pt in the declaration of the shared data connector. Change the XML and IDL declarations accordingly.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

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

  • Key: UCM12-4
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.2
  • Disposition Summary:

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

    Rename the “programming model” into “container model”, as the name was not approriate. Rewrite the container model section to focus on its structure and explain that most parts of the API depend on the programming language mappings.
    Be more explicit about the two C++ mapping strategies: generic and strongly typed.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

typos

  • Key: UCM12-11
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.2
  • Disposition Summary:

    fix the typos found in the document

    Fix the typos.

  • Updated: Tue, 8 Oct 2019 17:58 GMT

wrong constraint in technical aspect comp_exec_asp

  • Key: UCM12-3
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.2
  • Disposition Summary:

    set the constraint of technical aspect comp_exec_asp to “exactly_one” in file ucm_core.xml

    Replace file ucm_core.xml by its new version that fixes the declaration of technical aspect comp_exec_asp.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

Introduce name spaces to split declarations across several files

  • Key: UCM12-1
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.2
  • Disposition Summary:

    add the notion of namespace

    Issue UCM12-1 is addressed by creating a new class named “Namespace” in the metamodel. This class derives from class “IModule”.
    The meta-model and the XML representation (DTD and schema) are updated.

  • Updated: Tue, 8 Oct 2019 17:58 GMT
  • Attachments:

value ranges are wrong for 8-bit integers

  • Key: UCM11-19
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The resolution of issue UCM11-2 introduced some typo in section 9.2.3.3.
    The table should contain

    INT8 -2 7 2 7 - 1 int8 (in IDL 4.2)

    instead of

    INT8 -2 8 2 8 - 1 int8 (in IDL 4.2)

    and

    UINT8 0 2 8 - 1 uint8 (in IDL 4.2)

    instead of

    UINT8 0 2 8 uint8 (in IDL 4.2)
  • Reported: UCM 1.0 — Mon, 9 Apr 2018 14:18 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    fix the value ranges for 8-bit integers

    The edition must come after UCM11-2.
    Write the correct value ranges: -2 7 .. 2 7 - 1 for int8 and 0 .. 2 8 - 1 for uint8.

  • Updated: Wed, 3 Oct 2018 14:18 GMT

there should be no returned error code for data consumers in the standard library

  • Key: UCM11-18
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Standard library model core.xml contains the following declaration:

    <interface name="message_intf">
    <method name="push">
    <param dir="in" name="message" type="message_type_t"/>
    <param dir="return" name="ecode" type="::core::return_codes::comm_ecode"/>
    </method>
    </interface>
    

    and

    <portType name="msg_emtr_pt">
    <portElement interface="api::message_intf" kind="required" name="emtr_pe"/>
    </portType>
    <portType name="msg_rcvr_pt">
    <portElement interface="api::message_intf" kind="provided" name="rcvr_pe"/>
    </portType>
    

    This indicates that message emitter and message receiver port types rely on the same interface message_intf. This interface has a unique method push with a return type for error codes. The error code makes sense for the emitter, as it let it know wether the communication has been successful or not. But it makes no sense for the receiver: the value of the error code must be set by the connector, not the receiving component.

    There is a similar problem with the request-reponse connector.

  • Reported: UCM 1.0 — Mon, 9 Apr 2018 13:58 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    remove return codes for data reception interfaces

    create separate interfaces for data emitter and data receiver for message and request-response interactions

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

names of standard library files should be consistent with module names

  • Key: UCM11-17
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The UCM standard defines a set of standard libraries stored in 5 files (core.xml, execution.xml, interactions.xml, properties.xml and timer.xml). Inside these files, the names of the top level modules do not always match the file names (core, ext_comp_exec, interactions, std_ann, timer).
    Although the standard does not states that UCM files should be named after the module they contain, it would make more sense to do so.

    In addition, module names should be less generic, as UCM is designed to encourage the use of additional libraries.

    Hence the standard library files may be renamed as follows:

    • ucm_core.xml
    • ucm_ext_exec.xml
    • ucm_ext_interac.xml
    • ucm_std_ann.xml
    • ucm_timer.xml
  • Reported: UCM 1.0 — Mon, 9 Apr 2018 12:29 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    update library and example declarations

    Rename the modules of the standard library models:

    • core becomes ucm_core
    • ext_comp_exec becomes ucm_ext_exec
    • interactions becomes ucm_ext_interac
    • std_ann becomes ucm_std_ann
    • timer becomes ucm_timer

    Also add a new subsection to describe the standard port roles, introduced by UCM 1.1

    Update XML and IDL code blocks to match the new module names of the standard library models

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

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

  • Key: UCM11-1
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    remove class ProgrammingLanguages

    The change consists of having programming language declarations directly in Nonfunctional modules, instead of nesting them in the intermediate class ProgrammingLanguages.

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

improve the specification of task periods

  • Key: UCM11-15
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Configuration of component execution policies relies on type ucm_timeval_t, which is a structure with two fields: seconds and nanoseconds. It is thus not convenient to specify task periods in milliseconds: too many zeroes to write, which may lead to mistakes. It should be nice to have a more adequate data structure.

  • Reported: UCM 1.0 — Tue, 27 Mar 2018 15:56 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    new specification for task periods

    The new definitions are provided in the attached file ucm_ext_exec.xml

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

remove parameter "methods_to_trace" from port_trace technical policy

  • Key: UCM11-14
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Technical policy port_trace has a parameter named methods_to_trace to indicate which method calls should be logged. It is not very convenient to use, as it leads to list all method names in a single string. It would be better to simply remove it and have port_trace log the invocations of all port methods.

  • Reported: UCM 1.0 — Tue, 27 Mar 2018 15:32 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    remove parameter "methods_to_trace"

    Simply removed the parameter declaration from the XML and IDL codes. Also remove the associated data types.

  • Updated: Wed, 3 Oct 2018 14:18 GMT

allow extension relationship between Annotation Definitions

  • Key: UCM11-7
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    add extension relationship for AnnotationDefinition

    Most UCM entities have an extension relationship. By adding it to AnnotationDefinition we ensure consistency.

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

Connectable interfaces does not support more that one portelement per port-type

  • Key: UCM11-16
  • Status: closed  
  • Source: MBDA Italia ( marco di ferrante)
  • Summary:

    Port-type can have 1..* PortElements, as clearly shown in Figure 9.22.
    So a component can provide and require a set of PortElementObjects as instances of couple PortName/PortElementName and this is correctly mapped in the component Port Mapping getter for provided portelement “get_<port_name>_<provided_port_element_name>".

    When looking for REQUIRED port elements and the interface to connect them to the related provided port element object, this Port/PortElement coupling seems lost.

    Infact:

    • ComponentObject::get_portElement (in string provided)
    • Connectable::on_connect (in string port_name, in PortElementObject required);
    • Connectable::on_disconnect (in string port_name);
    • Container::get_port_element (in componentId comp_instance, in string port_name)
    • Container::connect (in componentId instance, in string port_name, in PortElementObject to_port)
      support only one PortElementObject for Port.

    If the understanding of the UCM is correct they should be updated as

    • ComponentObject::get_portElement (in string port_name, in string port_element_name);
    • Connectable::on_connect (in string port_name, in string port_element_name, in PortElementObject required);
    • Connectable::on_disconnect (in string port_name, in string port_element_name);
    • Container::get_port_element (in componentId comp_instance, in string port_name, in string port_element_name);
    • Container::connect (in componentId instance, in string port_name, in string port_element_name, in PortElementObject to_port);
  • Reported: UCM 1.0 — Mon, 19 Feb 2018 14:09 GMT
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    update the programming model to explicitly manipulate port elements

    In the programming model APIs, replace parameter “port_name” by two parameters “port_or_policy” and “port_elem”.

    Document ptc/17-05-05 shall be replaced by file ucm.idl.

  • Updated: Wed, 3 Oct 2018 14:18 GMT

Bring more flexibility in composite component extensions

  • Key: UCM11-3
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    bring more flexibility in composite component extensions

    In component types, restrict port refinements: instead of allowing any refinement, refining ports must now reference the same port role.
    In composite component implementations, allow a part to reference any refinement of the component referenced by the inherited part, instead of restricting to the same component type. Also, allow connection refinement to reference any connector definition as long as it gives a consistent architecture.

  • Updated: Wed, 3 Oct 2018 14:18 GMT

Add support for 8-bit integers

  • Key: UCM11-2
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    Add support for 8-bit integers

    add literals INT8 and UINT8 in enumeration PrimitiveIntegerKind, and replace literals SHORT, LONG, etc. by INT16, INT32, INT64, UINT16, UINT32 and UINT64 for consistency.

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

Create a DTD for the XML syntax

  • Key: UCM11-6
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    provide a new XML schema and DTD

    replace ptc/17-05-07 with ucm_base.dtd and ucm_base.xsd

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments:

Improve component port declaration

  • Key: UCM11-5
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    Improve component port declaration

    introduce the notion of PortRole to restrict component port refinement: a component port can only be refined by a component port the port type of which references the same port role. For example, a message emitter port can refine a data producer port, but not a service client port.
    Also remove the notion of IPortSpec, PortTypeSpec and PortRoleSpec, and instead have a reference to the port type and binding in the port declaration.

  • Updated: Wed, 3 Oct 2018 14:18 GMT

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

  • Key: UCM11-4
  • Status: closed  
  • 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
  • Disposition: Resolved — UCM 1.1
  • Disposition Summary:

    add lower and upper cardinalities to configuration parameters

    Add fields “lower” and “upper” to configuration parameters, just like UML does for properties.

  • Updated: Wed, 3 Oct 2018 14:18 GMT
  • Attachments: