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.

remove class ProgrammingLanguages

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

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

add extension relationship for AnnotationDefinition

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

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

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.

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

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.

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:  , ", >

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.

provide a new XML schema and DTD

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

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.

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.

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.

add lower and upper cardinalities to configuration parameters

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