Issue 11621: Section: 10/3
Issue 11706: use the stereotype <<allocated>> alone
Issue 11767: [Time: Examples]
Issue 11845: Runtimes may have multiple stacks
Issue 11856: MARTE Profile : Synchronisation between SRM, GRM, HRM and analysis part
Issue 12223: Introduce new chapter in section 6.4
Issue 12234: associations between Instance and ModelElement (subclasses)
Issue 12286: align the notation section of 11.3.2.7 to the profile diagram.
Issue 12403: ConcurrentAccessProtocolKind
Issue 12411: Example in Figure 10.21 makes use of directed arrows
Issue 13086: MARTE/section 7.2.1/ "No Metamodel root" bug
Issue 13088: MARTE/section 7.2.1/ "several labels for the same classifiers in the Metamodel" bug
Issue 13654: Having icons and symbols for stereotypes improves models comprehesibility
Issue 13655: stereotype GRM::SchedulableResource should have an attribute describing its activation parameters
Issue 13668: Section: 14.2 HRM Add an attribute isInterleaved : NFP_Boolean to the MemoryOrganization tuple type
Issue 13842: Cannot precisely allocate an application to an execution platform described as a series of composite structures.
Issue 14221: Semantics description of TimedObserver
Issue 14348: MARTE domain model: defintion of Trigger
Issue 14427: NFP_Constraint metaclass syncho with its underlying stereotype
Issue 14428: NfpConstraint stereotype: rename property mode to modes
Issue 14435: Meta class BehaviorScenario not synchronized with its representation
Issue 14610: Missing constraint between scheduler and scheduling parameters
Issue 14808: GQAM::RequestedService metaclass has no definition
Issue 14821: Example of RtFeature update required
Issue 14841: Nature and Kind of Allocation and Assignment
Issue 14842: Implied NFP constraint on stereotypes Assign and Allocate
Issue 14864: MARTE AADL annexe
Issue 14865: FLOW : MARTE and AADL alignment
Issue 14866: Feature group
Issue 14867: DATA : MARTE AADL mapping
Issue 14868: Annexe introduction
Issue 14870: MARTE-AADL connectors modeling
Issue 14871: MARTE-AADL component implmentation modeling
Issue 14872: MARTE-AADL summeray table upgrade
Issue 14873: MARTE-AADL software concept upgrades
Issue 14874: MARTE-AADL software concept upgrades
Issue 14891: Relationship between AnalysisContext, WorkloadBehavior and ResourcePlatform
Issue 14892: Different multiplicities in the GQAM meta-model and profile
Issue 14893: Align the NFP profile and domain model with the QUVD meta-model
Issue 14894: AssigmentKind/AssignmentNature are redundant with AllocationKind/AllocationNature
Issue 14895: Remove the TimedObservation stereotype
Issue 14896: Update the GCM ClientServerPort to take into account evolutions in UML 2.3
Issue 14897: SecondaryScheduler should be an association of the Scheduler instead of a specialized class
Issue 14899: Missing mappings between analysis duration, arrival patterns and clock constraints
Issue 14900: PortGroup concept used in Annex A.2 is not defined in the MARTE profile
Issue 14901: The concept of System in Annex A.2 maps to a SysML concept
Issue 14902: Inconsistent definition of CommunicationChannel properties
Issue 14903: Inconsistency between the Time domain model and related profile
Issue 14904: TimedElement.on default value should refer to the ideal clock
Issue 14905: SAM Workload Figure defines a new property for GQAM::WorkloadBehavior
Issue 14906: Figure 16.3 inconsistent with Figure 15.3
Issue 14907: Typo in Figure 10.13: enery property
Issue 14908: ResourceUsage.requiredAmount aggregation kind should be composite
Issue 14909: In Figure 15.3, Step.concurRes property should be typed by ConcurencyResource instead of SchedulableResource
Issue 14910: NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -).
Issue 14911: Clarify the additional semantics brought by the GRM::TimingResource stereotype
Issue 14912: Align notions of duration in NFP, Time and GQAM
Issue 14913: Clarify the semantics of GQAM::BehaviorScenario duration attribute w.r.t. execTime, respTime and hostDemand
Issue 14914: The Step.host attribute is redundant,
Issue 14915: Relationship between MARTE allocations, UML deployment and analysis profiles need to be clarified
Issue 14916: Typo in Figure 10.13: multiplicity of event property
Issue 14917: Clarify the relationship between GQAM::WorkloadEvent and GRM::UsageDemand
Issue 15032: Figure 8.5 UML profile diagram for NFPs modeling
Issue 15033: <<StereoType>> "SchedulableResource" has a tag of schedParams which is made up of a Class (this is not allowed in UML)
Issue 15034: Diagram shows {ordered usedResouces}, it should be {ordered usedResources}.
Issue 15035: • polling: PollingParameters [0..1]
Issue 15036: 13.3 UML Representation
Issue 15039: MARTE AADL Annexe
Issue 15048: Timing observer naming
Issue 15057: Inconsitencies in MARTE::GCM
Issue 15073: MARTE Issue: Overloaded relationship Scenario to Step in Analysis
Issue 15081: GCM behavioral representation
Issue 15096: VSL - B3.3.9 - Typos in rule <interval-bounds>
Issue 15097: VSL - B.3.3.11 and B.3.3.12 - Introducing optional keywords ‘Tuple’ and ‘Choice’
Issue 15098: VSL - B.3.3.17 - In conditional expressions, <if-false-exp> should not be optional
Issue 15099: VSL - B.3.3.15 - typos in <namespace> rule in the context of Property Call Expression
Issue 15100: VSL - Absence of rule for calling behaviors
Issue 15106: MARTE Beta 3: Invalid stereotype label in figure 11.8
Issue 15116: Domain concept (definingEvent) not implemented in the UML representation
Issue 11621: Section: 10/3 (marte-rtf)
Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Enhancement
Severity: Significant
Summary:
The GRM::Resource stereotype (and its specializations in GRM, SRM, HRM, such as HRM::HwProcessor) extends the following UML metaclasses: Classifier, Property, InstanceSpecification, Lifeline, ConnectableElement. When modeling resources within a composite structure, one has the choice to : 1) apply the stereotype on a UML::Classifier, and then type the parts by this classifier 2) directly apply the stereotype on parts (UML::Property) 3) both 1) and 2) In the case of 3), the relationships between the stereotype attributes defined on the classifer and those defined on the parts need to be clarified. A possible answer would be to formulate the following: "a stereotype applied to an instance (part, instance specification, lifeline, connectable element) allows one to assign values that are instance-specific and which overrive the default values of the stereotype applied to the class".
ApplicationAllocationEnd and ExecutionPlatformAllocationEnd differentiate the client and the supplier of the allocation. In case where a model element is both the source of an allocation and the target of another allocation it would be practical to be able to use the stereotype <<allocated>> alone instead of applying the two stereotypes <<app_allocated,ep_allocated>>.
[Time: Examples] One important specification feature in the embedded system domain is the Timing diagram. I propose to include examples to illustrate the use of the MARTE observation concepts and time expressions with Timing Diagrams
Discussion: There are ongoing discussions about the introduction of Timing Diagrams in SysML. MARTE is equipped to annotate UML Timing Diagrams. Giving a precise example in the MARTE specification might anticipate the SysML decision. So I suggest to postpone this issue for the FTF and wait for the evolution of SysML. Disposition: Deferred
Runtimes may have multiple stacks. How to reference a specific stack size (e.g., primary or secondary) in SRM? It seems to miss a concept.
Discussion: This is already possible to describe multiple stacke because the multiplicty of the staskSizeElement attribute is unlimited (concurrentResource stereotype). It seems that there is a need to describe more precisely several stacks : primiary stack, secondary stack ... One solution leads to describe an explicit "Stack" stereotype. Such solution deeply modifies the SRM chapter. Disposition: Deferred
A simplification of GRM should be envisaged. GRM defines too many detailled concepts (for instance the Scheduler which seems more appropriate in the SRM package), these concepts could be defined in SRM or HRM package or even in SAM package. The way to define different types of services need to be aligned between GRM, SRM and HRM.
Discussion: There are two different opinions regarding the proposed re-structuring the concepts in the profile. In the opinion of ESEO: As mentioned for instance in issues 11411 and 11412, regarding GRM and SRM in particular, redundancy emerges between GRM concepts and packages depending on it (SRM, HRM but also SAM and GQAM). The same concept could be redefined twice, and this redefinition will let the designer express the same idea in different MARTE meta-classes (or stereotypes). In addition to a problem of consistency, there is a problem of readability and understanding for the designer. Behind this issue, it is the central role given to GRM and the way Analysis models (GQAM and SAM) and XRM (GRM, SRM and HRM) elements are related which could be discussed. It's not certain that a clear consensus or agreement is reached on this central role of GRM. A broader discussion is needed in order to reach a consensus. Different approaches for resolving this issue are possible. More time is needed to make a better analysis of the advantages/default and change impacts of each one. For theses reasons, this issue is deferred. In the opinion of UC: As mentioned in Issues 11411 and 11412 regarding GRM and SRM in particular, they may get significant "synchronization" by simply including in the SRM stereotypes the inheritance from the corresponding in GRM, but they do not have to be forced to stay totally "synchronized" since they are meant for different purposes, and use and promote very different modeling styles. GRM goes for architectural models that can provide and be extended to lead easily to analysis of the basic NFPs, while the main concern in the current flavor of SRM is to enable easier platform independence through model transformations. Even considering these different modeling intents in the two subprofiles, avoiding inheritance at the profile level seems to indicate that it is due to a matter of purism more than to a technical reason. In response to the issue : (a) GRM is not that complex considering that it must provide the minimum additional elements to UML to deal with design at the architectural level, as well as foundations for design and analysis, design for platform and application oriented models, and finally the hardware and software aspects of the platform. The suggestion to reduce it means probably not comprehension of this multifaceted role, or the implicit assumption that all these different aspects have totally nothing in common, which is wrong. They share the absolute necessity to have at the minimum the capability of being able to do evaluations of a system feasibility even at the very basic level against its non functional properties, and at least its timing properties. (b) For this reason, there must be aspects like scheduling in GRM. The concept of scheduler is crucial for almost all of the mentioned chapters (exception made of HRM probably). The attributes on it are the very basic ones to get the minimal capabilities to say something of the system feasibility in the context of the large majority of applications. Even particular techniques that model explicitly the behavior of the scheduler require this concept at this level of description. Along this discussion, one week before the start of the voting period, this issue has been pushed to create a polemic enough to deserve further attention. More even considering that making such a coarse change in the structure of the standard may require a very deep reformulation. In the opinion of UC this issue should be closed. A better alignment between the different models inside MARTE may be gotten, but restructuring it in the way it seems to be proposed will require a significant number of methodological choices, which may be good for one application or modeling style but not for others. This is a different alternative for standardization, and may lead to a new RFP, in which a concrete number of industrial applications, with their corresponding development styles, analysis techniques, and certification requirements, find precise modeling methodologies and tool support. This may require a per-domain response. Anyway in order to give the community the possibility to elaborate on all these, it has been deferred at this time. Resolution: Defer the issue so that a wider discussion may lead to consensus. Revised Text: Disposition: Deferred
It would be interested to introduce in the section 6.4 a chapter to explain the diferent design patterns adopted within the specification to use the UML extenssion mechanisms.
Due to lack of time we defer this issue to next RTF. Disposition: Deferred
On fig. 7.6 three association between Instance and ModelElement (subclasses) have properties subsetted "type", but the "type" property only appear between Instance and Classifier (not ModelElement) fig. 7.3.
Defered due toi lack of time and was not considered as major issue. Disposition: Deferred
The notation section of 11.3.2.7 makes use of stereotypes that are inconsistent with the profile diagram. Proposed resolution: align the notation section of 11.3.2.7 to the profile diagram.
"ConcurrentAccessProtocolKind" contains several enumeration literals, one of them is "Other." With this representation, it is possible to represent ONE implicit user define protocol acces but impossible to make the distinction between various protocols defined by the end user like for exemple (ex: .Interrupt_Masking, Maximum_Priority).
This issue is more generally related to the usage of Enumerations for typing attributes of stereotypes, and the way to extend them. This is a recurrent problem when designing a profile: The enumeration literals of an Enumeration are used to capture the most representative interpretations of the aspect under study (e.g., for ConcurrentAccessProtocolKind, each enumeration literal represents a usual protocol for concurrent accesses) but one would let the possibility for users to define their own interpretations (e.g., for ConcurrentAccessProtocolKind, the literal “Other” is intended to capture such an alternative interpretation). As this problem is recurrent, it is worth taking time to have deeper discussions and propose a systematic modeling pattern to address this profiling issue. We therefore propose to defer issue 12403. Disposition: Deferred
The example in Figure 10.21 makes use of directed arrows to represent connectors in a composite structure. Moreover, it seems that the element inside the composite structure look more like classes than parts.
Deferred to RTF due to lack of time. Disposition: Deferred
The metamodel can not be executed/implemented since their is no root element in the metamodel. It would be useful to introduce the packageableElement, Model (A model owns * PackageableElements). This addition has several consequences on other parts of the metamodel in order for this latter to be used for instance to create MARTE model conforms to the MARTE metamodel.
Using the profile, an element can have several stereotypes. However, in the metamodel, an element can not have several labels traducing these stereotypes. A traduction in the metamodel of this kind of element (stereotyped several times) can not be made.
Having icons and symbols for stereotypes improves models comprehesibility. For instance, HRM and SRM chapters provide graphical representations for most of the stereotypes. However, the GRM subprofile, which is shared by other chapters (analysis modeling parts of MARTE), has not such graphical representation. We propose to add icons and symbols (likely similar to SRM and HRM's ones) to GRM stereotypes.
The stereotype GRM::SchedulableResource should have an attribute describing its activation parameters (arrival pattern and parameters). This is useful in multi-rate systems, where, in addition to the activations defined at application level (activation events triggering action/event chains), OS tasks/threads can be defined with a given activation rate. For instance, almost all automotive systems are multi-rate systems. Even if the functional application appears as a single rate system, multiplexing mechanisms both in the communication or in data sampling mechanisms can induce to more complicated timing behaviors, which are a characteristics of multi-rate systems.
Add an attribute isInterleaved : NFP_Boolean to the MemoryOrganization tuple type do allow to discriminate between interleaved and non interleaved multi-bank memories
Title: Cannot precisely allocate an application to an execution platform described as a series of composite structures. Description : Consider an execution platform : a rack composed of 3 boards, each boards has a general-purpose processor and an accelerator. The rack and the board are structured classes defined with composite structure diagrams. The pseudo-code below provides an informal description of the platform: Rack { board: Board [3] } Board { gpp: GPP accelerator: FPGA } GPP {...} FPGA {...} How to precisely address the accelerator on the second board of the rack and allocate application elements on it ? The current allocation mechanism allows one to allocate an application on gpp property of the Board class but does not express that the second board is specifically designated.
The description of the semantics of TimedObserver in section F10.18 has to be aligned with its description denoted in the diagram shown in figure 15.4. TimedObserver can refer to several start and end events.
The defintnion of the Trigger concept says: "A Trigger specifies the event and conditions that may trigger a behavior execution.". However, there is nothing in its features (associations or attributes) that will support the concept of condition mentioned in the defintion of Trigger.
The stereotype NFPConstraint owns a property to denotes in which modes the constaint is attached. The metaclass NFP_Constraint defined in the domain model of MARTE should be updated to reflect that property.
The property mode of the stereotype NfpCinstaint has a multiplicity [0 ..*]. To reflect that I propose to rename this latter mode to modes.
The description of the Meta class BehaviorScenario is not synchronized with its representation in diagramm shown in FIgure 15.3. As for example, associations called steps in the diagram and called Actions in section F.10.13 (idem issue with assoc labelled inputstream in the section F.10.3 and called cause in diagram 15.3).
In the GRM domain model (Figure 10.11) and GRM profile (Figure 10.16), there should be a constraint that enforce consistency between scheduling parameters and the related scheduler (e.g. a task brokered by an HPF scheduler cannot have anything else than a priority - integer - as a scheduling parameter).
GQAM::RequestedService metaclass has no definition in Annex F.
All examples related to RtFeature in section 13.4.1 are out of date with respect to the definition of RtFeature stereotype that is in Beta 3 associated to a RtSpecification. They have to be updated accordingly.
Both Allocation and Assigne stereotype use their onw enumerations for defining their nature and kind. For simplification, they should use the same enumerations.
Both stereotypes Assign and Allocate have a properties called impliedConstraint. Do we need this additional attribute because indeed a NfpConstraint being a extension of the UML constraint can be apply on any elements. Or if we need, could these properties be derived?
The notion of assembly/delegation connectors between ports and subcomponents has to be clarified in the MARTE AADL annexe.
The AADL flow path implementation semantics is not in line with MARTE mapping proposition. The AADL flow path declaration and implementation mapping need to be rethink
The whole AADL features group concepts can't be represented in MARTE Precise the mapping perimeter and semantics of "inverse of"
Two ways of modeling Data existe in AADL: the one using the AADL Data annexe modeling features, the other one relying on a pure structural view. The first solution is currently addressed by the MARTE AADL annexe. The annexe has to be upgraded to take into account the second way of doing.
AADL v2 has be voted. Upgrade introduction texte to position MARTE according the new version of the AADL standard
The notion of assembly/delegation connectors between ports and subcomponents has to be clarified in the MARTE AADL annexe.
Upgrade AADL component declaration relationship to a AADL component implementation (UML Realization -> UML Component Realization)
Upgrade MARTE AADL summery table upgrade according resolved issues
The provide a full MARTE AADL alignment, upgrade software concepts with AADL 1) abstract component, 2) prototype, 3) threadgroup, 4)subprogram group concepts
The provide a full MARTE AADL alignment, upgrade platform concepts with AADL 1) virtual bus 2) virtual processor concepts
AnalysisContext is the root of the GQAM model. In the first paragraph of the domain model, it is mentioned that an analysis context contains two parts: workload behavior and resource platform. AnalysisContext should specify composition relationships with WorkloadBehavior and ResourcePlatform (Figure 15.2)
In the GQAM domain model, the multiplicity of the AnalysisContext.workloadBehavior is 1. In the profile, the multiplicity of the stereotype attribute is *. Proposed resolution: align on the profile and make it *.
Previous discussions between the SysML and MARTE communities have allowed relationships between both languages. An important convergence area relates to the notions of quantities, unit and dimensions. The SysML 1.2 RTF and the MARTE FTF work resulted in the definition of the QUVD meta-model (SysML Annex C.5). The MARTE NFP profile has not been yet entirely aligned on the QUVD meta-model. It would need aligned stereotyped when applicable (e.g. dimension vs. quantity type)
Notions of kind and nature are shared between allocation and assignment. Related enumerations AssignmentKind and AssignmentNature describe the same concepts and are redundant. Proposed resolution: remove assignment enumerations and relate the Assign stereotype attributes to AllocationKind and AllocationNature
TimedObservation is an abstract stereotype that extends TimedElement without adding new features. It is sublassed by the concrete TimedDurationObservation and TimedInstantObservation. Given that it cannot be directly used, and for the sake of smplicity, removing the stereotype may be considered
Update the GCM ClientServerPort to take into account evolutions in UML 2.3 (introduction of conjugated port)
For the sake of simplicity, SecondaryScheduler should be an association of the Scheduler instead of a specialized class. Making this concept relative would provide means to support more than two-level schedulers. Requires changes in the meta-model and the profile
The mappings between the analysis arrival patterns (periodic, sporatic, …) and Time durations, and clock constraints in CCSL should be defined in the specification.
PortGroup concept used in Annex A.2 is not defined in the MARTE profile
The concept of System in Annex A.2 maps to a concept not defined in the MARTE specification (a SysML concept). However the MARTE profile does not import the SysML profile.
Annex F defines a CommunicationChannel.msgSize property while the meta-model and the profile defines a packetSize property. Note that the term 'packet' may not generic enough for the concept of CommunicationChannel
In the domain model, TimeProcessing.duration is a simple association, typed by CVS::DurationValueSpecification while in the profile the association is a composition, typed by ValueSpecification. Inconsistency should be corrected
TimedElement.on default value should refer to the ideal clock, by the mean of a default property (e.g. instance value)
Figure 16.3 located in the SAM chapter defines a new property (typed by EndToEndFlow) for a meta-class WorkloadBehavior defined in GQAM. Either move EndToEndFlow to GQAM or create a class that specializes WorkloadBehavior and introduce this new property. Additionally, the 'workload' property name can be renamed into 'flow' to avoid creating confusion.
Figure 15.3 defines a cause-effect association between WorkloadEvent and WorkloadBehavior, while Figure 16.3 defines an inputSteam-effect association
ResouceUsageAmount has a 'enery' property. Rename into 'energy'
ResourceUsage.requiredAmount aggregation kind should be composite
In Figure 15.3, Step.concurRes property should be typed by ConcurencyResource instead of SchedulableResource. SchedulableResource limits the domain of possible analysis that are possible with GQAM
NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). This currently does not exist, as a consequence two NFP_Duration cannot be compared one another. For instance, the VSL grammar does allow expressions such "(end - start) < (value=10.0, unit=ms)" (where start and stop are TimeObservation
GRM::TimingResource inherits from Resource and is then specialized into ClockResource and TimerResource but it does not add any new property. A clarification of the additional semantics of this intermediate stereotype would be needed
The Time profile is suposed to provide a fundational timing model for MARTE. Time stereotypes are specialized in several of profiles, such as GRM and GQAM. However, while time-related notions in the analysis profiles are typed by NFP_Duration, the Time::TimedProcesssing.duration stereotype attribute is typed by a ValueSpecification. This type inconsitency makes between general and specialized concepts creates usability issues. Indepently of that, note that the TimedProcessing meta-class and stereotype attribute are not consistently typed, as the (normative) TimedProcessing.duration meta-class attribute is typed by the (non-normative) CVS::DurationValueSpecification.
Clarify the semantics of GQAM::BehaviorScenario duration attribute w.r.t. execTime, respTime and hostDemand, and harmonize their use across analysis chapters of the specification. On-going discussion with Dorina and Murray on this topic.
The Step.host attribute is redundant, given that a schedulable resource need to be related to a processor (execution host) for the analysis model to be complete and practically usable. Three alternatives for this stereotype attribute may be discussed: a) remove it, b) make it derived, c) keep it as a duplicate shortcut information. On-going discussion with Dorina and Murray on this topic
UML introduce deployment concepts. MARTE introduces a notion of allocation that seem to encompass deployment-related notions (as stated in the specification). How these concepts relate to analysis attributes is left undefined in the specification at the moment. Depending on the examples one can have a look at, MARTE allocations and UML deployments seem to be used in a similar way (see Section 16.3.3 and Section 17.4). However, nothing is formally stated. Clarify whether MARTE allocations / UML deployment have the same semantics w.r.t. analysis, or not. And, if possible, make the connection with the related issue on host stereotype properties.
* symbol in front of the event property in Figure 10.13, which multiplicity is 0..1
GQAM::BehaviorScenario specializes GRM::ResourceUsage. It seems that GRM::UsageDemand generalizes GQAM::WorkloadEvent. If so, make explicit this generalization relationship and consider the WorkloadEvent.timeEvent, WorkloadEvent.effect and BehaviorScenario.cause as redefined attributes
Figure 8.5 UML profile diagram for NFPs modeling StereoType "Unit" has a Tag of convOffset but the xmi import has named it offsetFactor
<<StereoType>> "SchedulableResource" has a tag of schedParams which is made up of a Class (this is not allowed in UML)
Diagram shows {ordered usedResouces}, it should be {ordered usedResources}.but is called D.4.6 PoolingParameters (PollingParameters definition does not exist in the spec)
CallConcurrencyKind is an Enumeration but is not marked as such on the Diagram
Precise component type and implementation relationship. "Component realization" concept seems more inline with the AADL semantics than "UML realization" concept.
The GQAM chapter defines the stereotype GaTimedObs in both domain and profile figures, however there are inconsistencies elsewhere ... GQAM sec 15.3.2.12 refers to GaTimingObserver ... SAM chapter refers to it as GaTimingObserver, in the domain figure 16.5 ... and also just before Fig 16.8 ... and as TimingObs, in the profile figure 16.8 ...PA chapter refers to it as GaTimingObserver in profile Fig 17.7 These are due to a last minute effort to shorten the names. THey all need to be standardized on GaTimedObs.
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."
In the analysis subprofiles a step has two relationships to scenarios: 1 Containment... a step is always contained in a scenario 2 Refinement: a step may be optionally be refined by a lower-level scenario The GQAM chapter defines one association behavior/steps which is defined as containment from the scenario point of view, and as refinement from the step point of view. This is navigable and usable, but formally incorrect. Suggested resolution: To be formally correct it requires two associations. One defines a collection of steps as the steps of the scenario, the other defines a scenario as a refinement of a step. Suggestion: Containment: Scenario has association steps, Step has association scenario Refinement: Scenario has association parentStep, Step has association childScenario Alternatively we could explain the overloading in the text and leave the profile as it is. Needs discussion.
The current version of the MARTE::GCM specification presents a mechanism to model data received and sent via ports. However, receptions are modelled in the higher level as GCMTriggers which extends UML Trigger, applicable in State Machine diagrams; while invocations are modelled using GCMInvocationActions, which extends UML InvocationAction, applicable in Activity diagrams. For the sake of applicability I would propose to extend the GCM metamodel with extra stereotypes so that invocations can be modelled in STM and receptions can be modelled in Activity diagrams. I this wouldn't be possible I would propose to include some examples showing how this can be modelled in the later cases.
There are some typos and mistakes in the rule <interval-bounds>, concerning the following alternatives: | <choiceinterval-bound> '..' <tuple-interval-bound> | <expression-interval-bound> '..' <tuple-interval-bound> Proposed resolution: - Replace: | <choiceinterval-bound> '..' <tuple-interval-bound> by | <choice-interval-bound> '..' <choice-interval-bound> - Replace: | <expression-interval-bound> '..' <tuple-interval-bound> by | <expression-interval-bound> '..' <expression-interval-bound>
Adding an optional keyword ‘Tuple’ may improve readability of tuple expressions, since, depending on the context, an expression of the form ‘(‘ValueSpecification’)’ can resolve to a tuple value or a choice value. Of course, the context is enough to disambiguate the rule. The optional keyword ‘Tuple’ would only provide a mean for making the expressions more readable from a user standpoint (note that the ‘Tuple’ keyword is also used in OCL). For the same reason, an optional keyword ‘Choice’ could also be added in choice expressions.
In rule <conditional-expression>, <if-false-exp> should not be optional. Otherwise, it is not clear what is the result of a ConditionalExpression in the case where <condition-expr> evaluates to false, and there is no specified <if-false-exp> Proposed resolution: - Replace: <conditional-expression> ::= <condition-expr> '?' <if-true-expr> [':' <if-false-exp>] By <conditional-expression> ::= <condition-expr> '?' <if-true-expr> ':' <if-false-exp>
In rule <namespace>, the element [‘.’ <namespace>] is useless and should be removed. Proposed resolution: - Replace: <namespace> ::= <body-text> ['.' <namespace>] By <namespace> ::= <body-text>
VSL doest not provide a rule for expressing behavior calls (i.e., it only supports call of operations). Since Behaviors are first class citizen of UML2, there is no fundamental reason for preventing this kind of expressions. Integrating a rule for calling behaviors does not require much effort (cf. following proposed resolution).
Proposed resolution:
- Modify text of B2.4 p.431 (p.443 of the pdf)
Between paragraph starting with “An Operation Call Expression…” and paragraph starting with “This metamodel does not define…”, insert the following paragraph:
A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters.
- Modify figure B.4 p.432 (p.444 of the pdf) as follows:
. Add a class BehaviorCallExpression, and a generalization relationship between this class and Expression
. Add a composition relationship between BehaviorCallExpression and ValueSpecification, identical to the composition relationship between OperationCallExpression and ValueSpecification (this is to capture the arguments of the call)
. On the diagram, add an abstract class Behavior, with a grey background like classes Property and Operation.
. Add an association between BehaviorCallExpression and Behavior, identical to the association between PropertyCallExpression and Property, except that the name of the role should : definingBehavior
. Add the following derived property to BehaviorCallExpression: /behavior:String
- In section B.3.3.13:
Replace:
<expression> ::= <variable-call-expr> | <variable-declaration> | <property-callexpr>
| <operation-call-expr> | <conditional-expr>
By:
<expression> ::= <variable-call-expr> | <variable-declaration> | <property-callexpr>
| <operation-call-expr> | <behavior-call-expr> | <conditional-expr>
- p.453 (p.465 of the pdf), insert the following section (and increment the number of remaining sections):
// Beginning of section
B.3.3.17 Behavior Call Expressions
Behavior calls are particularly used in the MARTE context to call behaviors taking data type values as parameters.
<behavior-call-expr> ::= <behavior-name> '('[ <argument-value> [','<argument-value>]* ]')’
<behavior-name> ::= [<namespace> '.'] <body-text>
<namespace> ::= <body-text>
Expression typing
• The <behavior-call-expr> production rule should be evaluated to the type of the UML::Behavior that is called.
• The <argument-value> production rule must be evaluated to the corresponding to UML::Parameter's type of an existing UML::Parameter owned by the UML::Behavior.
Abstract syntax mapping
• The <behavior-call-expr> production rule maps to the BehaviorCallExpression domain element described in Annex F (Section F.13.XX).
Disambiguating rules
• <behavior-name> should correspond to an existing UML::Behavior name.
//end of section
- In annex F, insert a section F.13.1 as follows (and increment of remaining sections):
// beginning of section
F.13.1 BehaviorCallExpression (from Expressions)
Generalizations
• Expression (from Expressions) on page 560
Associations
• definingBehavior: Causality::CommonBehavior::Behavior [1]
Called Behavior.
• argument: VSL::ValueSpecification [*] {ordered}
Arguments of the Operation Call.
Attributes
• /behavior: String [1]
String with the qualified name of the called Behavior. This is a derived value obtained from the definingBehavior.
Semantics
A Behavior Call Expression refers to a behavior defined in a UML Namespace. The expression may contain a list of argument expressions if the behavior is defined to have parameters. In this case, the number and types of the arguments must match the parameters.
// end of sectionFigure 11.8 has an element called Memory inside an element named "p:Process[256]" that is labeled as 'app_allocated'. Unfortunately, there is no such stereotype defined in MARTE (this is probably a leftover from an earlier version)
The domain view of the Time Chapter provides clocks to achieve two goals. First, Clocks give an explicit time referential for various kinds of elements. Second, Clocks give an orthogonal mechanism to put temporal information on any events, whereas UML consider TimeEvent as a special case of events. In the domain view, the second position was made concrete by the attribute "definingEvent" that was denoting the event from which a clock was built (occurrences of the events, where the instants of the clock). All the stereotypes provided in the UML representation address the first objective. None address the second one. Suggested resolution, the stereotype "Clock" could extend the metaclass "Event" as well. That would allow clock constraints to constrain/specify the occurrences of events.