Unified Component Model for Distributed, Real-Time and Embedded Systems Avatar
  1. OMG Specification

Unified Component Model for Distributed, Real-Time and Embedded Systems — All Issues

  • Acronym: UCM
  • Issues Count: 49
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
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-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-5 Improve component port declaration 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-4 Add cardinalities (i.e. min and max) for configuration parameters UCM 1.0b2 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-1 remove class ProgrammingLanguages from the meta-model, as it is useless 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
UCM-51 the UCM standard platform should reorganized UCM 1.0b1 UCM 1.0 Resolved closed
UCM-48 Improve technical policies for ports UCM 1.0b1 UCM 1.0 Resolved closed
UCM-69 update the IDL and C++ sections to match the new metamodel, programming model and xml names UCM 1.0b1 UCM 1.0 Resolved closed
UCM-67 improve the class diagram of reziable data type UCM 1.0b1 UCM 1.0 Resolved closed
UCM-71 use the RFC 2119 vocabulary UCM 1.0b1 UCM 1.0 Resolved closed
UCM-65 Rewrite the references section UCM 1.0b1 UCM 1.0 Resolved closed
UCM-61 Harmonization with IDL4.1 and XTYPES1.2 UCM 1.0b1 UCM 1.0 Resolved closed
UCM-56 Create a section for the IDL equivalent syntax UCM 1.0b1 UCM 1.0 Resolved closed
UCM-18 wrong definition in section "symbols" UCM 1.0b1 UCM 1.0 Resolved closed
UCM-16 Interfaces should be able to have annotation UCM 1.0b1 UCM 1.0 Closed; No Change closed
UCM-14 The annotation system is too flexible UCM 1.0b1 UCM 1.0 Closed; No Change closed
UCM-47 Align UCM primitive types with IDL UCM 1.0b1 UCM 1.0 Resolved closed
UCM-46 enable multiple refinement for component types and composite component implementations UCM 1.0b1 UCM 1.0 Resolved closed
UCM-50 The connection registration API may lead to portability issues UCM 1.0b1 UCM 1.0 Resolved closed
UCM-44 Create a section for the graphical guidelines UCM 1.0b1 UCM 1.0 Resolved closed
UCM-45 update the xml syntax and diagrams and put shorter names UCM 1.0b1 UCM 1.0 Resolved closed
UCM-43 Create a section for the XML syntax of UCM UCM 1.0b1 UCM 1.0 Resolved closed
UCM-37 remove sections that explain the graphical representation from section 9 UCM 1.0b1 UCM 1.0 Resolved closed
UCM-34 IAssembly may have no part UCM 1.0b1 UCM 1.0 Resolved closed
UCM-29 class IPrimitiveDataType is missing UCM 1.0b1 UCM 1.0 Resolved closed
UCM-17 AssemblyParts should inherit from IAnnotable UCM 1.0b1 UCM 1.0 Resolved closed
UCM-15 class IinterfaceBase is now named IInterface UCM 1.0b1 UCM 1.0 Resolved closed
UCM-28 there is no distinction between compositions and aggregations in the descriptions of classes UCM 1.0b1 UCM 1.0 Resolved closed
UCM-12 remove sections that explain the xml representation from section 9 UCM 1.0b1 UCM 1.0 Resolved closed
UCM-13 remove sections that explain the IDL representation from section 9 UCM 1.0b1 UCM 1.0 Resolved closed
UCM-11 remove the examples from section 9 UCM 1.0b1 UCM 1.0 Resolved closed
UCM-10 use UML for class diagrams UCM 1.0b1 UCM 1.0 Resolved closed
UCM-6 section for ConnectorPortConfiguration is missing UCM 1.0b1 UCM 1.0 Resolved closed
UCM-5 wrong field type in AbstractTypeBinding UCM 1.0b1 UCM 1.0 Resolved closed
UCM-4 wrong inheritance for sequences and text not assertive enough UCM 1.0b1 UCM 1.0 Resolved closed
UCM-2 change field identifier of class INamed UCM 1.0b1 UCM 1.0 Resolved closed
UCM-3 missing inheritance for port delegation UCM 1.0b1 UCM 1.0 Resolved closed
UCM-1 add attribute delegations in composite component implementations UCM 1.0b1 UCM 1.0 Resolved closed
UCM-7 make classes Connection and ConnectionEnd inherit from IConfigured UCM 1.0b1 UCM 1.0 Resolved closed
UCM-9 create an abstract class IItemBinding UCM 1.0b1 UCM 1.0 Resolved closed
UCM-8 enable extension for composite component implementation UCM 1.0b1 UCM 1.0 Resolved closed

Issues Descriptions

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:

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:

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

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:

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:

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:

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:

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

the UCM standard platform should reorganized

  • Key: UCM-51
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    There should be only 3 standard component execution policies: unprotected_passive, protected_passive and protected_active (they more or less correspond to <nothing>, ppUnit and rtUnit in MARTE). protected_self-executing is actually not an execution policy, but a triggering policy, and should therefore be regrouped with the timers in the additional execution policies

  • Reported: UCM 1.0b1 — Tue, 21 Mar 2017 17:35 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    separate self-execution policy from component execution policy

    Associate the self-executing component policy to a component execution trigger aspect rather than a component execution aspect. Also associate the timer policies to the execution trigger aspect.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

Improve technical policies for ports

  • Key: UCM-48
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Technical policy definitions specify to what kind of element they apply: only components, ports of components, or either case. There is then two metaclasses ComponentTechnicalPolicy and ComponentPortTechnicalPolicy to distinguish between the two situations. This approach creates two problems:
    1- it is impossible to specify that a technical policy is meant to apply to all the interaction points of a component (both ports and policies that have port elements)
    2- it is impossible to make a ComponentPortTechnicalPolicy manage the interactions between the component and one of its policies

  • Reported: UCM 1.0b1 — Fri, 17 Mar 2017 15:58 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    Merge component technical policy and component port technical policy

    Define three values for policy applicability: on_component_only (for services), on_some_ports (for interceptors) and on_all_ports (for interceptors that have to intercept all ports). The later value is useful for policies that control the component execution and thus have to intercept all communications. Classes ComponentTechnicalPolicy and ComponentPortTechnicalPolicy can be merged into a unique class TechnicalPolicy, which is simpler.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

update the IDL and C++ sections to match the new metamodel, programming model and xml names

  • Key: UCM-69
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Some XML sample codes are obsolete in the IDL and C++ section because some names changed. Some mapping explanations must be updated as well.

  • Reported: UCM 1.0b1 — Thu, 20 Apr 2017 16:52 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    update the IDL and C++ sections to match the new metamodel, programming model and xml names

    Update the XML, IDL and C++ code.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

improve the class diagram of reziable data type

  • Key: UCM-67
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    This diagram illustrates the definitions of NativeType, Sequence and StringType. It is difficult to read. It may be better to have several diagrams instead.

  • Reported: UCM 1.0b1 — Thu, 20 Apr 2017 15:17 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    replace the standard data type diagram by dedicated diagrams for string type, native type and sequence

    Instead of having a unique and complex class diagram for resizable data types, create three diagrams for string type, native type and sequence.

  • Updated: Mon, 16 Oct 2017 15:14 GMT
  • Attachments:

use the RFC 2119 vocabulary

  • Key: UCM-71
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Many sentences are not assertive enough: they use words like "can". The document should use "shall", "shall not", "may", "should" and "should not".

  • Reported: UCM 1.0b1 — Sat, 22 Apr 2017 20:32 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    use the RFC 2119 vocabulary and be more specific

    many occurrences of “can”, “will”, “could”, etc. are used in the normative specification and are thus too vague. They must be replaced by accurate words like “may”, “shall”, “shall not”, “should”, “should not”

  • Updated: Mon, 16 Oct 2017 15:14 GMT

Rewrite the references section

  • Key: UCM-65
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The “References” section mentions too many documents that only inspired UCM, and are not required for its application. The section should therefore be simplified to only mention relevant documents.

  • Reported: UCM 1.0b1 — Thu, 20 Apr 2017 13:54 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    Rewrite the references section

    only mention IDL, XML, IDL to C++ and C++ as normative references.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

Harmonization with IDL4.1 and XTYPES1.2

  • Key: UCM-61
  • Status: closed  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    To the extent possible it is desirable to harmonize the type annotations and use between IDL4, XTYPES and UCM.
    The general concept is that IDL4 defines the general syntax and common annotations, and other specifications like XTYPES and UCM will "refer" to IDL4 and add annotations as needed for concepts not present in IDL4.

    The latest revision of XTYPES (version 1.2) ptc/17-03-06 already follows this approach.

    So it would be desirable that IDL4 does the same. In the cases where the annotation is not present in IDL4 but is present in XTYPES it is also desirable that UCM "reuses/references" the annotation defined in XTYPES. That way if this annotation is eventually moved to IDL4 we do not have a conflict.

    This means several annotations currently used in UCM should be changed as listed below:

    • @IndexType should be removed. Instead refer to @bit_bound (see IDL41 section 8.3.4.1)
    • @DefaultValue should be removed. Instead refer to @value (see IDL 41 section 8.3.1.5).
    • IDL4 annotations are all lower case. So @Range (used in UCM) should be @range.
    • IDL4 uses snake_case for builtin annotations names. So does XTYPES for the new annotations it introduces. It would be good if UCM follows the same convention instead of using CamelCase. For example @MemoryFootprint should be @memory_footprint and so on.
    • The syntax to define new annotations in IDL4 uses the "@annotation" keyword in lower case. It also does not use the "attribute" keyword anymore. UCM should do the same. So the declaration of MemoryFootprint in 14.4.1.1 should be changed to:
      @annotation memory_footprint {
          unsigned long max; 
      }
      
  • Reported: UCM 1.0b1 — Wed, 29 Mar 2017 17:21 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    Align annotations with the existing IDL annotations

    use snake_case instead of CamelCase. Reuse IDL standard annotation instead of inventing new, redundant ones.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

Create a section for the IDL equivalent syntax

  • Key: UCM-56
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Some UCM aspects (e.g. component types) have an IDL equivalent. There should be a section describing how to use IDL to specify UCM.

  • Reported: UCM 1.0b1 — Tue, 28 Mar 2017 14:10 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    Create a section for the IDL equivalent syntax

    Add the content of file ucm_idl_syntax.odt before chapter 10.

  • Updated: Mon, 16 Oct 2017 15:14 GMT
  • Attachments:

wrong definition in section "symbols"

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

    the definition of UCM is the one of UML

  • Reported: UCM 1.0b1 — Tue, 6 Sep 2016 09:08 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    fix the symbol typo

    replace "UCM: unified modeling language"
    by "UML: unified modeling language"

  • Updated: Mon, 16 Oct 2017 15:14 GMT

Interfaces should be able to have annotation

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

    Concrete data types can have annotations. Interface cannot: only methods and attributes can. It would be interesting to enable annotations in interfaces, just in case.

  • Reported: UCM 1.0b1 — Mon, 5 Sep 2016 15:36 GMT
  • Disposition: Closed; No Change — UCM 1.0
  • Disposition Summary:

    class Interface already inherits from IAnnotable through IConcreteTypeDeclaration

    Interfaces are already annotable.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

The annotation system is too flexible

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

    Annotations can be associated with several kinds of entity: component types, methods, attributes, data types, ports, atomic component implementations, composite component implementations. It is impossible, when declaring an annotation definition, to specify which kind of entity it must be associated with. Consequently, annotations might be associated in an irrelevant manner.

  • Reported: UCM 1.0b1 — Mon, 5 Sep 2016 12:42 GMT
  • Disposition: Closed; No Change — UCM 1.0
  • Disposition Summary:

    won't fix annotations

    There is no simple way to specify which entity an annotation definition can apply to. Therefore, it is wise not to change the current situation: UCM tools may define extensions to the annotation system.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

Align UCM primitive types with IDL


enable multiple refinement for component types and composite component implementations

  • Key: UCM-46
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    A given component type can refine only a single another component type. Same thing for composite component implementations. Enabling the refinement of several component types (or composite implementations) would help component definition reuse.

  • Reported: UCM 1.0b1 — Thu, 19 Jan 2017 16:41 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    allow multiple refinements for component types and composite component implementations

    allow multiple refinements for component types and composite component implementations by setting "refines" field cardinalities to [0...*]

  • Updated: Mon, 16 Oct 2017 15:14 GMT
  • Attachments:

The connection registration API may lead to portability issues

  • Key: UCM-50
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    UCM component bodies are supposed to have a method named on_startup() that takes a list of ports to connect as parameter. When creating a statically typed API (with an explicit list of PortElement), one has to decide which order to follow for the ports. For example, for a component C that has two port elements peA and peB, should we have on_startup(peA a, peB b) or on_startup(peB b, peA a) ?
    The standard cannot leaves this choice implementation-dependent, as it would prevent code portability.
    Also, port elements have two relationships named "executor", which is confusing.

  • Reported: UCM 1.0b1 — Tue, 21 Mar 2017 17:21 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    Connect port elements using on_connect instead of on_startup

    Simplify the programming model by manking the Connectable interface mandatory, and remove parameters of method on_startup().
    This makes implementation work more portable.
    Also update the programming model diagrams to use SVG instead of PNG images.

  • Updated: Mon, 16 Oct 2017 15:14 GMT
  • Attachments:

Create a section for the graphical guidelines

  • Key: UCM-44
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    In document Beta 1, section 9 contains several small sections that describe the graphical guidelines for the creation of graphical, informal representation of UCM models. These sections have been removed during by issue #37. A new section should be added at the end of the document to explain the non-normative graphical guidelines

  • Reported: UCM 1.0b1 — Tue, 29 Nov 2016 17:36 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    Create a section for the graphical guidelines

    Create a new section describing the graphical guidelines and update diagrams according to these guidelines.

  • Updated: Mon, 16 Oct 2017 15:14 GMT
  • Attachments:

update the xml syntax and diagrams and put shorter names

  • Key: UCM-45
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    As the UCM metamodel has been updated, the UCM XML schema must be updated, and consequently the XML code shown in section 10 must be updated as well.
    Also, the names used for the platform definitions are a bit long, and it would be better to have shorter names, in case users would like to write them by hand, and also because it would fit better in the pages.
    As a consequence, diagrams shall be updated accordingly.

  • Reported: UCM 1.0b1 — Tue, 29 Nov 2016 17:40 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    Update the syntax and the names for the standard library

    Update the XML code blocks, with shorter names. Also remove the diagrams. Add the IDL equivalent syntax.
    This task also resolves issue UCM-51 by associating the self-executing component policy to the component trigger technical aspect instead of the component execution technical aspect.

  • Updated: Mon, 16 Oct 2017 15:14 GMT
  • Attachments:

Create a section for the XML syntax of UCM

  • Key: UCM-43
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    There should be a section that shows the UCM XML syntax. This should be a new section.

  • Reported: UCM 1.0b1 — Tue, 29 Nov 2016 17:29 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    New sections for the XML syntax

    A new small section that introduces the UCM XML schema, and a non-normative section with examples to help understand the syntax.

  • Updated: Mon, 16 Oct 2017 15:14 GMT
  • Attachments:

remove sections that explain the graphical representation from section 9

  • Key: UCM-37
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Section 9 describes the meta-model, not concrete syntax.
    Remove sections 9.3.3.5, 9.3.4.5, 9.3.5.3, 9.4.3.3, 9.5.3.8, 9.5.4.4, 9.5.5.7

  • Reported: UCM 1.0b1 — Thu, 29 Sep 2016 16:14 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    remove sections that explain the graphical representation

    Remove sections 9.3.3.5, 9.3.4.5, 9.3.5.3, 9.4.3.3, 9.5.3.8, 9.5.4.4, 9.5.5.7

  • Updated: Mon, 16 Oct 2017 15:14 GMT

IAssembly may have no part

  • Key: UCM-34
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    current cardinality of field part for IAssembly is 1.... It would be better to allow empty IAssembly objects: set cardinality to 0....

  • Reported: UCM 1.0b1 — Wed, 21 Sep 2016 15:40 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    change cardinality of field part in class IAssembly

    change the cardinality of field part from [1...*] to [0...*]

  • Updated: Mon, 16 Oct 2017 15:14 GMT

class IPrimitiveDataType is missing

  • Key: UCM-29
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Although it is shown in figure 8 p.19, class IPrimitiveDataType is not described in the document. A subsection in section 9.2.3 must be added for it.

  • Reported: UCM 1.0b1 — Mon, 19 Sep 2016 11:44 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    add a section for IPrimitiveDataType

    Add a section to document the IPrimitiveDataType class

  • Updated: Mon, 16 Oct 2017 15:14 GMT

AssemblyParts should inherit from IAnnotable

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

    Assembly parts should be able to have annotations, just in case.

  • Reported: UCM 1.0b1 — Mon, 5 Sep 2016 15:52 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    add inheritance to AssemblyPart

    Make class AssemblyPart inherit from both IAnnotable and INamed.
    The meta-model must be edited. The main document must be edited as well.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

class IinterfaceBase is now named IInterface

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

    This is a typo

  • Reported: UCM 1.0b1 — Mon, 5 Sep 2016 12:44 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    change the title of section 9.2.7.1

    The meta-model is correct. This is a typo in the text.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

there is no distinction between compositions and aggregations in the descriptions of classes

  • Key: UCM-28
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    In the text that describes the meta-model classes, compositions and aggregations are not clearly identified: the reader must refer to the class diagrams. It would be better to have the information in the diagrams and in the text.

  • Reported: UCM 1.0b1 — Fri, 9 Sep 2016 14:31 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    append "(owned)" to items that correspond to compositions

    For the moment, the only way to distinguish between agregations and composititions is to have a look at the class diagrams: the text itself does provide information.
    Append "(owned)" to items that correspond to compositions to help make the distinction between agregations and compositions.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

remove sections that explain the xml representation from section 9

  • Key: UCM-12
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Section 9 deals with the UCM meta-model, not with concrete syntax. The description of the XML schema must be put in a separate section, at the end of the document. Sections 9.3.2.2, 9.3.3.6, 9.3.4.6, 9.3.5.4, 9.4.3.4, 9.5.3.9, 9.5.4.5, 9.5.5.8 must be removed.

  • Reported: UCM 1.0b1 — Mon, 29 Aug 2016 15:25 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    remove sections that explain the xml representation from section 9

    Remove sections 9.3.2.2, 9.3.3.6, 9.3.4.6, 9.3.5.4, 9.4.3.4, 9.5.3.9, 9.5.4.5, 9.5.5.8.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

remove sections that explain the IDL representation from section 9

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

    Section 9 deals with the UCM meta-model, not with concrete syntax. The description of the IDL equivalent syntax must be put in a separate section, at the end of the document. Sections 9.3.2.3, 9.3.3.7, 9.3.4.7, 9.3.5.5, 9.4.3.5, 9.5.3.10, 9.5.4.6, 9.5.5.9 must be removed.

  • Reported: UCM 1.0b1 — Mon, 29 Aug 2016 15:30 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    remove IDL sections from section 9

    Remove sections 9.3.2.3, 9.3.3.7, 9.3.4.7, 9.3.5.5, 9.4.3.5, 9.5.3.10, 9.5.4.6, 9.5.5.9.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

remove the examples from section 9

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

    this section is normative, and should not contain examples

  • Reported: UCM 1.0b1 — Fri, 26 Aug 2016 14:09 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    remove example text from section 9

    remove the examples

  • Updated: Mon, 16 Oct 2017 15:14 GMT

use UML for class diagrams

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

    Class diagrams in section 9 do not exactly conform to the UML syntax. They should be recreated with the UML syntax.

  • Reported: UCM 1.0b1 — Fri, 26 Aug 2016 13:34 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    replace ecore diagrams of section 9 with UML class diagrams

    replace diagrams of figures 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 16, 17, 18, 19, 21, 24, 25, 26, 27, 28, 29 by UML class diagrams made with Papyrus. See attached file.

  • Updated: Mon, 16 Oct 2017 15:14 GMT
  • Attachments:

section for ConnectorPortConfiguration is missing

  • Key: UCM-6
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    The UCM meta-model contains a class named ConnectorPortConfiguration, which has no documentation. A section for it should be added.

  • Reported: UCM 1.0b1 — Thu, 25 Aug 2016 15:58 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    add a section for ConnectorPortConfiguration

    This section is simply missing: the meta-model is up to date.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

wrong field type in AbstractTypeBinding

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

    field actualType of class AbstractTypeBinding should be IConcreteTypeDeclaration.

  • Reported: UCM 1.0b1 — Thu, 25 Aug 2016 15:26 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    replace ITypeDeclaration by IConcreteTypeDeclaration

    The meta-model is correct. This is only a typo in the document.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

wrong inheritance for sequences and text not assertive enough

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

    Class sequence inherits from IStandardDataType, not IStandardTypeBase (which does not exist)

  • Reported: UCM 1.0b1 — Thu, 25 Aug 2016 15:07 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    replace IStandardTypeBase by IStandardDataType and put more precision in the text

    Fix the typo.
    Also be more assertive in the specification.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

change field identifier of class INamed

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

    Field identifier of class INamed should be renamed into name, which is more logical

  • Reported: UCM 1.0b1 — Thu, 25 Aug 2016 14:41 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    change the name of field identifier of class INamed to name

    Edit the meta-model to rename field identifier of class INamed to name
    Update section 9.1.4.1

  • Updated: Mon, 16 Oct 2017 15:14 GMT

missing inheritance for port delegation

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

    According to the meta-model, class PortDelegation inherits from INamed. This does not appear in the document

  • Reported: UCM 1.0b1 — Thu, 25 Aug 2016 15:01 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    add inheritance in section 9.5.5.6

    The meta-model is correct. This is a typo.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

add attribute delegations in composite component implementations

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

    Composite component implementations have port delegations between their ports and ports of assembly parts. For consistency, there should be attribute delegations as well. The semantics of attribute delegation would be the following: when deploying a composite component, the initial values set for its attributes shall actually be set for the delegated attributes of its subcomponents. As composite component implementations have no existence at runtime, attribute delegation shall have no existence at runtime either.

  • Reported: UCM 1.0b1 — Thu, 25 Aug 2016 14:37 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    create a new class for attribute delegation

    Create a class named AttributeDelegation in package ucm_components. This new class has three fields:

    • externalAttribute: Attribute [1]
    • part: AssemblyPart [1]
    • attribute: Attribute [1]

    Update class PortDelegation to follow the same structure. That is, replace field internalEndPoint by the two following fields:

    • part: AssemblyPart [1]
    • port: Port [1]

    Update class CompositeComponentImplementation to add a new field:

    • attributeDelegation: AttributeDelegation [0...*] (owned)
  • Updated: Mon, 16 Oct 2017 15:14 GMT

make classes Connection and ConnectionEnd inherit from IConfigured

  • Key: UCM-7
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    class ComponentTechnicalPolicy inherits from IConfigured, which allows the specification of values for configuration parameters. Connections and ConnectionEnd should also inherit from IConfigured, to enable the specification of configuration values as well.

  • Reported: UCM 1.0b1 — Fri, 26 Aug 2016 09:38 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    make classes Connection and ConnectionEnd inherit from IConfigured

    The meta-model must be edited to add inheritance to class IConfigured for classes Connection and ConnectionEnd.
    The main document must be updated in sections 9.5.5.4 and 9.5.5.5.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

create an abstract class IItemBinding

  • Key: UCM-9
  • Status: closed  
  • Source: THALES ( Thomas Vergnaud)
  • Summary:

    Ports of component types contain an IPortSpec, which is an abstract class that contains nothing, thus allowing future meta-model extensions without any restriction regarding the way ports are specified.
    On the other hand, class ConnectorDefinition contains ItemBinding, which explicitly associates an InteractionItem with an ITypeDeclaration. Although this will cover most situations, it is not as general as for component ports, since it implies that connector definitions depend on the notion of data type.
    There should be an intermediate abstract class IItemBinding that only contains InteractionItem, and that is extended by class ItemBinding.

  • Reported: UCM 1.0b1 — Fri, 26 Aug 2016 12:14 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    create class IItemBinding

    Create an abstract class named IItemBinding with the following field:

    • interactionItem: InteractionItem [1]

    Class ItemBinding will inherit class IItemBinding. Field itemBinding of class ConnectorDefinition will now reference IItemBinding.

  • Updated: Mon, 16 Oct 2017 15:14 GMT

enable extension for composite component implementation

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

    It would be nice to allow a composite component implementation to extend another one. This can be achieved by adding a field extends to the existing CompositeComponentImplementation class. Composite extensions would allow the declaration of additional assembly parts, port delegations, attribute delegations and connections without altering the elements declared in ancestor components.

  • Reported: UCM 1.0b1 — Fri, 26 Aug 2016 10:02 GMT
  • Disposition: Resolved — UCM 1.0
  • Disposition Summary:

    add composite component implementation refinement and update field names for extension mechanisms

    Add a field extends in class CompositeComponentImplementation. Also add a field refines in classes AssemblyPart and Connection. Rename fiels instanceOf of class AssemblyPart into componentDefinition, as an assembly part is not an instance.
    Fix inconsistencies in field names

  • Updated: Mon, 16 Oct 2017 15:14 GMT