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.

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.

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.

class Interface already inherits from IAnnotable through IConcreteTypeDeclaration

Interfaces are already annotable.

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

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”

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

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

Update the XML, IDL and C++ code.

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

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.

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.

Rewrite the references section

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

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; 
  }
  

Align annotations with the existing IDL annotations

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

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

Create a section for the IDL equivalent syntax

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

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

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.

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

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.

the definition of UCM is the one of UML

fix the symbol typo

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

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.

add a section for IPrimitiveDataType

Add a section to document the IPrimitiveDataType class

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

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.

This is a typo

change the title of section 9.2.7.1

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

UCM introduced two extra integer kinds: byte and ubyte, which do not exist in IDL. On the other side, IDL has a type named octet, which does not exist in UCM. Also, wchar in IDL is char32 in UCM.
UCM should be consistent with IDL.

Align UCM primitive types with IDL

Remove BYTE and UBYTE primitive integers. Introduce OCTET. Rename CHAR32 into WCHAR.

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.

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.

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.

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...*]

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.

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.

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

Create a section for the graphical guidelines

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

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

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.

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

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

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

change cardinality of field part in class IAssembly

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

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.

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)

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

replace IStandardTypeBase by IStandardDataType and put more precision in the text

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

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

add inheritance in section 9.5.5.6

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

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

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

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

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.

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.

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.

this section is normative, and should not contain examples

remove example text from section 9

remove the examples

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

add a section for ConnectorPortConfiguration

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

field actualType of class AbstractTypeBinding should be IConcreteTypeDeclaration.

replace ITypeDeclaration by IConcreteTypeDeclaration

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.