MARTE11 — Inconsitencies in MARTE::GCM

In the context of our work for the ADAMS project (http://www.adams-project.org/) we try to align MARTE and AUTOSAR with specific focus on MARTE::GCM and AR::SWC. To do so, we produced the domain models in UML. Unfortunately, we found the following inconsistencies, unclarities or typography issues in the MARTE specifications:

• Issue1:
  AssemblyConnector (F.6.1) in annex F is not used in the domain of MARTE.
  -Resolution1:
  Remove F.6.1 and F6.13 subsections.

• Issue2:
  SendFlowAction (F6.13) in annex F is not used in the domain of MARTE.
  -Resolution2:
  Remove F6.13 subsection.

• Issue3:
  In Figure 12.2 (The bulk of the MARTE GenericComponentModel package), BehavioredClassifer qualified name is wrong.
  -Resolution3:
  Marte::CoreElements::Foundations::BehavioredClassifier should become MARTE::CoreElements::Causality::CommonBehavior::BehavioredClassifier

• Issue4:
  In second paragraph of subsubsection 12.2.1 (The GenericComponentModel Package), "AssemblyConnector" is not appropriate
  -Resolution4:
  … "An interaction port defines an explicit interaction point through which components may be connected (linked) through an AssemblyConnector, and through which they can communicate via message passing."… should be changed to : "An interaction port defines an explicit interaction point through which components may be connected (linked) through an assembly connector, and through which they can communicate via message passing."…

• Issue5:
  BFeatureKind (F.6.3) shouldn't be used anymore and it is replaced by ClientServerKind
  -Resolution5:
  Remove F.6.3. In subsection ClientServerPort (F.6.8) the type for "kind" attribute should be ClientServerKind.

• Issue6:
  DirectionKind (F.6.12 ) shouldn't be used anymore and it is replaced by FlowDirectionKind
  -Resolution6:
  Remove F.6.12. In subsection FlowPort (F.6.15) and FlowProperty (F.6.16) the type for "direction" attribute should be FlowDirectionKind. Update Index.

• Issue7:
  Mutliplicity and defalut value of "direction" attribute in FlowPort (F.6.15) should be respectively [1] and "= inout" in annex F
  -Resolution7:
  In F.6.15, [0..1] multiplicity for direction should be changed to [1] and default value set to "= inout"

• Issue8:
  Default value of "direction" attribute in FlowProperty (F.6.16) should be "= inout" in annex F
  -Resolution8:
  In F.6.15, default value for direction should be set to "= inout"

• Issue9:
  Multiplicity specification association of FlowPort (F.6.15) should be [0..*]. Furthermore this association is not represented in Figure 12.3
  -Resolution9:
  In F.6.15, multiplicity for specification should be changed to [0..*], name should be updated to "specifications" and Figure 12.3 should be updated consequently.

• Issue10:
  In annex F, Attributes paragraph title for InvocationAction (F.6.19) should actually be "Associations"
  -Resolution10:
  In F.6.19, change paragraph title to "Associations" and add a "Attributes" pragraph title with "None" as body.

• Issue11:
  In annex F, generalization to ClientServerFeature is missing for Operation (F.6.21)
  -Resolution11:
  In F.6.21, add ClientServerFeature to Generalizations paragraph

• Issue12:
  In annex F, association to Flowproperty is missing for SendDataAction (F.6.22)
  -Resolution12:
  In F.6.22, add " + targetProperty: FlowProperty [0..1]" to Associations paragraph

• Issue13:
  In annex F, Associations paragraph title (the one containing kind attribute) for ClientServerFeauture (F.6.6) should actually be "Attributes"
  -Resolution13:
  In F6.6 change paragraph title to "Attributes"

• Issue14:
  In Figure 12.3 and Figure 12.4, default values are not represented
  -Resolution14:
  To clarify the specification, default values should be represented too (i.e. "=false" for isAtomic and "=inout" for direction

• Issue15:
  SendSignalAction introduced in Figure 12.5 is not mentioned in annex F
  -Resolution15:
  Add annex F the concept with generalization to InvocationAction and change BoradcastSignalAction (F.6.4) generalization to SendSignalAction

• Issue16:
  In annex F, multiplicity for onPort association of InvocationAction (F.6.19) and the multiplicity represented in Figure 12.5 are inconsistent : [1] and [0..1] respectively.
  -Resolution16:
  Should be set to [1] for both.

• Issue17:
  ClientServerSpeification concept should be added to align with what is done for FlowPort
  -Resolution17:
  In annex F Add ClientServerSpecification concept in annex F. It has " + ownedFeatures: ClientServerFeature [*]" association. Add an association " + specifications: ClientServerSpecification [0..*]" to ClientServerPort (F.6.8)

• Issue18:
  In annex F, isAtomic attribute of ClientServerPort (F.6.8) should be defined as derived
  -Resolution18:
  In F.6.8, add a "/" in front of isAtomic attribut of ClientServerPort

• Issue19:
  Constraints on direction attribute for FlowPort
  -Resolution19:
  Add this constraint in Annex F to FlowPort (F.6.15) : If the FlowPort is not atomic then if direction attribute of all the FlowProperty of all its FlowSpecification are set to in (respectively out) then direction is in (respectively out) otherwise direction is inout.
  If the FlowPort is atomic then direction attribute must be set by designer.

• Issue20:
  Constraints on kind attribute for ClientServerPort
  -Resolution20:
  Add this constraint in Annex F to ClientServerPort (F.6.8) : If the ClientServer is not atomic then if kind attribute of all the ClientServerFeature of all its ClientServerSpecification are set to provided (respectively required) then direction is provided (respectively required) otherwise kind is proreq.
  If the ClientServerPort is atomic then kind attribute must be set by designer.

• Issue21:
  In annex F.6.7, required enum literal paragraph of ClientServerKind is inconsistent
  -Resolution21:
  … "The behavioral feature is provided by the port of the owning entity."… should changed to "The behavioral feature is required by the port of the owning entity."

This issue actually consists of sub-issues, which concerns minor synchronization problems
between diagrams of the domain model, and associated descriptions in Annex F. For each subissue,
the submitter has proposed resolutions. All the resolution (as the described in the section
“summary” above) are reproduced in the section “revised text” below, with complementary
information when needed.