UML Profile for MARTE Avatar
  1. OMG Specification

UML Profile for MARTE — Closed Issues

  • Acronym: MARTE
  • Issues Count: 60
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
MARTE11-108 GRM:Support for Time table driven schedules MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-110 The concept of System in Annex A.2 maps to a SysML concept MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-109 RequestEventStream changed by WorkloadEvent MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-106 MARTE Beta 3: Invalid stereotype label in figure 11.8 MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-105 VSL - Absence of rule for calling behaviors MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-104 VSL - B.3.3.15 - typos in rule in the context of Property Call Expression MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-107 Domain concept (definingEvent) not implemented in the UML representation MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-103 VSL - B.3.3.17 - In conditional expressions, should not be optional MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-102 VSL - B.3.3.11 and B.3.3.12 - Introducing optional keywords ‘Tuple’ and ‘Choice’ MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-101 VSL - B3.3.9 - Typos in rule MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-100 GCM behavioral representation MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-99 MARTE Issue: Overloaded relationship Scenario to Step in Analysis MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-98 Inconsitencies in MARTE::GCM MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-97 Timing observer naming MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-96 MARTE AADL Annexe MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-95 13.3 UML Representation MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-94 • polling: PollingParameters [0..1] MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-93 Diagram shows {ordered usedResouces}, it should be {ordered usedResources}. MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-92 <> "SchedulableResource" has a tag of schedParams which is made up of a Class (this is not allowed in UML) MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-90 Clarify the relationship between GQAM::WorkloadEvent and GRM::UsageDemand MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-91 Figure 8.5 UML profile diagram for NFPs modeling MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-86 Align notions of duration in NFP, Time and GQAM MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-85 Clarify the additional semantics brought by the GRM::TimingResource stereotype MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-88 The Step.host attribute is redundant, MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-87 Clarify the semantics of GQAM::BehaviorScenario duration attribute w.r.t. execTime, respTime and hostDemand MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-89 Typo in Figure 10.13: multiplicity of event property MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-84 NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -). MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-81 Typo in Figure 10.13: enery property MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-83 In Figure 15.3, Step.concurRes property should be typed by ConcurencyResource instead of SchedulableResource MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-82 ResourceUsage.requiredAmount aggregation kind should be composite MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-77 Inconsistency between the Time domain model and related profile MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-76 Inconsistent definition of CommunicationChannel properties MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-79 SAM Workload Figure defines a new property for GQAM::WorkloadBehavior MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-78 TimedElement.on default value should refer to the ideal clock MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-80 Figure 16.3 inconsistent with Figure 15.3 MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-74 SecondaryScheduler should be an association of the Scheduler instead of a specialized class MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-73 Update the GCM ClientServerPort to take into account evolutions in UML 2.3 MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-72 Remove the TimedObservation stereotype MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-71 AssigmentKind/AssignmentNature are redundant with AllocationKind/AllocationNature MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-75 PortGroup concept used in Annex A.2 is not defined in the MARTE profile MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-70 Different multiplicities in the GQAM meta-model and profile MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-69 Relationship between AnalysisContext, WorkloadBehavior and ResourcePlatform MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-68 MARTE-AADL software concept upgrades MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-67 MARTE-AADL software concept upgrades MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-65 MARTE-AADL component implmentation modeling MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-64 MARTE-AADL connectors modeling MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-63 Annexe introduction MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-66 MARTE-AADL summeray table upgrade MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-62 DATA : MARTE AADL mapping MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-61 Feature group MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-60 FLOW : MARTE and AADL alignment MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-59 MARTE AADL annexe MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-58 Implied NFP constraint on stereotypes Assign and Allocate MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-57 Nature and Kind of Allocation and Assignment MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-56 Example of RtFeature update required MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-55 GQAM::RequestedService metaclass has no definition MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-54 Meta class BehaviorScenario not synchronized with its representation MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-53 NFP_Constraint metaclass syncho with its underlying stereotype MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-52 MARTE domain model: defintion of Trigger MARTE 1.0 MARTE 1.1 Resolved closed
MARTE11-51 Semantics description of TimedObserver MARTE 1.0 MARTE 1.1 Resolved closed

Issues Descriptions

GRM:Support for Time table driven schedules

  • Legacy Issue Number: 15292
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    MARTE, formal/2009-11-02, GRM chapter, pag 96-97, enhancement

    GRM:Support for Time table driven schedules.

    Having the opaque expression attribute "schedule" in the Scheduler in GRM lead to a very open way of expressing fixed schedules or non-traditional scheduling policies. This is the case of time triggered sets of tasks in particular, but also of any form of table driven schedule. Following a general approach but formalizing the way of expressing schedules as a set of labeled timed windows would make the exchange of information between strict time triggered platforms design intent and its corresponding analysis models easier and in a standardized way.

    An alternative to study may be formalizing the attribute “schedule” of a scheduler to include at least the frame_cycle_time, and the list of “windows” or “time_slots” to be managed as schedulable resources. To do this the easiest way may be to make them part of a list inside the schedule indexed by a key that match the scheduling parameters field of the schedulable resources that are attached to the scheduler.

  • Reported: MARTE 1.0 — Sun, 27 Jun 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The current structure grants the designer the capacity of describing the schedule to use
    by means of an opaque expression, and the scheduling parameters for the table driven
    policy in the way of an open format string. In order to facilitate the description of more
    precise and standardized schedules, a concrete format for these types has been
    proposed.
    The necessary attributes are presented. For the scheduler the attribute “schedule” will
    be formalized to include at least the frame_cycle_time, and the list of “windows” or
    “time_slots” for the partitions, for doing this there are two alternatives (a) make them part
    of a list inside the schedule indexed by a key that match the scheduling parameters field
    of the schedulable resources that are attached to the scheduler, or (b) compose the list
    by considering the allocated schedulable resources with their corresponding
    schedulingParameters, changing the current type string used for the TableEntry field into
    the necessary time_slot data type tuple.
    Alternative (a) is easier to set into the standard and the models are easier to check for
    consistency, hence is the one proposed. It comprises the formalization of the opaque
    expression used for the attribute “schedule” into a structure like the one shown in the
    next figure:

  • Updated: Wed, 14 Oct 2015 04:55 GMT

The concept of System in Annex A.2 maps to a SysML concept

  • Legacy Issue Number: 14901
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    An AADL system represents an assembly of interacting application software,
    execution platform, and system components.
    The chosen mapping shall not only be semantically correct, but shall also have
    an intuitive name.
    MARTE doesn’t address such a generic aspect, and it would not make sense to
    add such a concept to MARTE.
    UML generic concept “StructuredClasses class” could be use, but this concept
    has already been used to represent AADL data. As mappings have always to be
    bijectiv, another representation has to be found.
    UML “subsystem” concept could be used to represent an “AADL system”, this
    mapping is semantically correct, but the name is confusing.
    The best solution is to use the SysML “block” concept: the mapping is
    semantically correct and the name is sufficiently different to avoid confusion.
    This solution needs to import the SysML profile. A prerequisite will be added in
    the introduction précising that the SysML profile needs to be importing when
    using MARTE to design AADL applications in order to fully address the MARTE
    to AADL mapping.

  • Updated: Sun, 8 Mar 2015 17:59 GMT

RequestEventStream changed by WorkloadEvent

  • Legacy Issue Number: 15377
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    The term RequestEventStream is still used in GQAM, and in Annexes F and H while the concept has been refurbished as WorkloadEvent and others. Make all of them consistent.

  • Reported: MARTE 1.0 — Tue, 20 Jul 2010 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The change from RequestEventStream to WorkloadEvent needs to be completed.
    The sections where it appears still in the text are:
    annex H, some texts in GQAM and PAM and many sections in Annex F: 10.19, 10.14,
    10.21, 11.1, 12.1, 12.3, 12.4

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE Beta 3: Invalid stereotype label in figure 11.8

  • Legacy Issue Number: 15106
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Figure 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)

  • Reported: MARTE 1.0 — Tue, 15 Sep 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Replace “app_allocated” by “allocated” as suggested. The kind “application”
    already has the information about the role (“app_”).

  • Updated: Fri, 6 Mar 2015 23:15 GMT

VSL - Absence of rule for calling behaviors

  • Legacy Issue Number: 15100
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    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 section

  • Reported: MARTE 1.0 — Mon, 1 Mar 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The absence of rules for calling behaviors indeed introduces an artificial limitation to the
    applicability of VSL. Concretely, all the available behavior signatures are currently defined
    following the object-oriented paradigm, in the form of operations (e.g., String.concat(String)),
    belonging to data types of the standard MARTE libraries. These behavior signatures could
    alternatively be defined following a procedural style (e.g. concat(String,String)). Designers who
    are familiar with procedural languages would probably feel more comfortable with this approach.
    Since UML natively offers support for describing behavior signatures in the procedural style, VSL
    should not prevent the usage of this kind of behaviors, and a rule should be added to support call
    of behaviors. The following figure illustrates the differences between the two paradigms, from
    both the perspective of libraries definitions (left hand side of the figure) and the perspective of
    usage in VSL (right hand side of the figure).

  • Updated: Fri, 6 Mar 2015 23:15 GMT

VSL - B.3.3.15 - typos in rule in the context of Property Call Expression

  • Legacy Issue Number: 15099
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    In rule <namespace>, the element [‘.’ <namespace>] is useless and should be removed.

    Proposed resolution:

    • Replace:
      <namespace> ::= <body-text> ['.' <namespace>]
      By
      <namespace> ::= <body-text>
  • Reported: MARTE 1.0 — Mon, 1 Mar 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Domain concept (definingEvent) not implemented in the UML representation

  • Legacy Issue Number: 15116
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Wed, 3 Mar 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

VSL - B.3.3.17 - In conditional expressions, should not be optional

  • Legacy Issue Number: 15098
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    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>
  • Reported: MARTE 1.0 — Mon, 1 Mar 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The proposed resolution, described in the summary, would indeed avoid ambiguities, and make
    the usage of operators ‘?’ ‘:’ more conventional.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

VSL - B.3.3.11 and B.3.3.12 - Introducing optional keywords ‘Tuple’ and ‘Choice’

  • Legacy Issue Number: 15097
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Mon, 1 Mar 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    This issue concerns two aspects of VSL: Introduction of optional keyword for
    clarifying the syntax, and alignment with OCL. These two points are interesting,
    but only focus on some very specific aspects on the relationship between VSL
    and OCL. It would not make sense to address this relationship by only focusing
    on the keyword Tuple. That’s why this issue must be closed without changes,
    and a new issue, more generally related to the clarification of the links between
    VSL and OCL (what parts are shared, how VSL is both a short-hand notation for
    some OCL statements / an extension of OCL) and the adjustments that may be
    needed by the VSL syntax should be raised.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

VSL - B3.3.9 - Typos in rule

  • Legacy Issue Number: 15096
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    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>
  • Reported: MARTE 1.0 — Mon, 1 Mar 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Follow the proposed resolution

  • Updated: Fri, 6 Mar 2015 23:15 GMT

GCM behavioral representation

  • Legacy Issue Number: 15081
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Adrian Noguero)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Tue, 23 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The issue addresses two different problems. The first one regarding receptions in
    Activity diagrams and the second one regarding invocations in state machine
    diagrams.
    The first part of the issue can be closed, since it is possible to model this kind of
    receptions using UML AcceptEventActions; which can be associated with a
    GCMTrigger. Example 3, on Figure 12.23, illustrates this.
    The second part of the issue; however it is not currently covered by MARTE or
    UML. The proposed resolution is to add a new stereotype,
    GCMInvocatingBehavior, which models the invocations taking place inside a
    behavior without having to look at its internals (particularly interesting in the case
    of OpaqueBehaviors). This stereotype will allow specifying communications in
    the scope of a single component and independently from other components (in
    opposition with Interactions, which specify communications between different
    components, with a system wide scope).

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE Issue: Overloaded relationship Scenario to Step in Analysis

  • Key: MARTE11-99
  • Legacy Issue Number: 15073
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Sat, 20 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    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
    These changes are needed both in the domain model sec 15.2 and the profile
    sec 15.3, and in Appendix F.10 for the encoding of the domain model
    Also, some changes in sec. F.10.3 to synchronize it with sec 15.2 were
    transferred from issue 14435,
    • association Actions renamed steps (consistent with Fig 15.3)
    • association usedResources dropped (not in Fig. 15.3)
    • association inputStream renamed cause (consistent with fig 15.3)
    • association connectors added (consistent with Fig 15.3)
    • attribute priority dropped (it occurs on Step)(consistent with chapter 15) (A) Figure 15.3:
    • add association parentStep - childScenario
    • rename association behavior - steps to scenario - steps
    (B) Section 15.2, Text p 290 para 5:
    Before:
    Steps and BehaviorScenarios have quantitative attributes as shown in Figure 15.3. A Step
    can be optional (with a probability less than one of being executed), or repeated (with a
    repetition count). It can be refined as another BehaviorScenario (its “behavior”
    association). The “isAtomic” property specifies atomicity of execution (default is false).
    Revised Text (the one new sentence is in red)
    Steps and BehaviorScenarios have quantitative attributes as shown in Figure 15.3. A Step
    can be optional (with a probability less than one of being executed), or repeated (with a
    repetition count). A BehaviorScenario is a collection of Steps, but also a Step can also be
    the parent of a refinement as a more detailed BehaviorScenario (its childScenario). The
    “isAtomic” property specifies atomicity of execution (default is false).
    (C) Fig 15.7 (the profile) also needs to be updated for the second association
    between Step and Scenario:
    • add association parentStep - childScenario
    • modify association behavior - steps to scenario - steps
    (D) Appendix F.10.3 for BehaviorScenario
    The five changes transferred from issue 14435 are included, plus the association
    change between Step and BehaviorScenario. For clarity the new text is in red.
    Original text: Associations
    • root: Step [0..1] Root Step to begin the BehaviorScenario.
    • Actions: Step [0..1] Set of Steps making up the BehaviorScenario.
    • inputStream: RequestEventStream [1..*] RequestEventStream that initiates it.
    • usedResources: Resource [0..*]

    {ordered}

    Set of resources used by the scenario UML
    Profile for MARTE, V1.0
    Attributes
    • hostDemand: NFP_Duration [0..1] CPU demand in time units.
    • hostDemandOps: NFP_Real [0..1] CPU demand in operations.
    • priority: NFP_Integer [0..1]
    • respTime: NFP_Duration [0..1] End-to-end delay of a part of an operation.
    • interOccTime: NFP_Duration [0..1] Interval between successive initiations of an
    operation.
    • throughput: NFP_Rate [0..1] Frequency of initiations of an operation.
    • utilization: NFP_Real [0..1] Fraction of time an operation is busy (throughput times
    delay). For a resource, the fraction of time each unit is busy, times the number of units.
    • utilizationOnHost: NFP_Real [0..1] Fraction of time the host is busy executing this
    operation.
    Revised text:
    Associations
    • root: Step [0..1] Root Step to begin the BehaviorScenario.
    • steps: Step [0..1] Set of Steps making up the BehaviorScenario.
    • cause: RequestEventStream [1..*] RequestEventStream that initiates it.
    • parentStep: Step [0..1] Step of which this BehaviorScenario is a refinement (nested
    behavior)
    • connectors: PrecedenceRelation [*] The set of precedence relationships between the
    steps of the scenario
    Attributes
    • hostDemand: NFP_Duration [0..1] CPU demand in time units.
    • hostDemandOps: NFP_Real [0..1] CPU demand in operations.
    • respTime: NFP_Duration [0..1] End-to-end delay of a part of an operation.
    • interOccTime: NFP_Duration [0..1] Interval between successive initiations of an
    operation.
    • throughput: NFP_Rate [0..1] Frequency of initiations of an operation.
    • utilization: NFP_Real [0..1] Fraction of time an operation is busy (throughput times
    delay). For a resource, the fraction of time each unit is busy, times the number of units.
    • utilizationOnHost: NFP_Real [0..1] Fraction of time the host is busy executing this
    operation.
    (E) Section F10.17 for Step
    Add the new association between Step and BehaviorScenario Old text:
    Associations
    • outputRel: PrecedenceRelation [*] Successor relation.
    • inputRel: Step[*]:PrecedenceRelation [*] Predecessor relation.
    Attributes
    • isAtomic: NFP_Boolean [0..1] If true, the step cannot be decomposed any further.
    • blockingTime: NFP_Duration [0..1] Delay inserted into the execution of the Step.
    • repetitions: NFP_Real [0..1] Actual or average number of repetitions of an operation or
    loop.
    • probability: NFP_Real [0..1] Probability of the step to be executed (useful for
    conditional execution).
    • priority: NFP_Interval [0..1] Step priority.
    Revised text:
    Associations
    • outputRel: PrecedenceRelation [*] Successor relation.
    • inputRel: Step[*]:PrecedenceRelation [*] Predecessor relation.
    • childScenario: Scenario [0..1] An optional refinement of the behavior of this Step
    Attributes
    • isAtomic: NFP_Boolean [0..1] If true, the step cannot be decomposed any further.
    • blockingTime: NFP_Duration [0..1] Delay inserted into the execution of the Step.
    • repetitions: NFP_Real [0..1] Actual or average number of repetitions of an operation or
    loop.
    • probability: NFP_Real [0..1] Probability of the step to be executed (useful for
    conditional execution).
    • priority: NFP_Interval [0..1] Step priority.
    (F) Sec 15.3.2.12, giving the UML definition of GaScenario
    Old text:
    Associations
    • steps: Step [1..*]
    The set of steps that make up the Scenario.
    New text:
    Associations
    • steps: GaStep [1..*]
    The set of steps that make up the Scenario.
    • parentStep: GaStep [1..*]
    A GaStep, of which this scenario is a refinement.
    (G) Sec 15.3.2.13, giving the UML definition of GaStep
    Old text: Associations
    • behavior: GaScenario [0..1]
    A GaScenario that refines a composite Step.
    New text:
    Associations
    • scenario: GaScenario [0..1]
    The GaScenario that that contains this Step.
    • childScenario: GaScenario [0..1]
    A GaScenario that refines this Step, making it a composite Step.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Inconsitencies in MARTE::GCM

  • Key: MARTE11-98
  • Legacy Issue Number: 15057
  • Status: closed  
  • Source: CEA, LIST, Laboratory of model driven engineering for embedded systems, Point Courrier 94, Gif-sur-Yvette, 91191, France ; ( Florian Noyrit)
  • Summary:

    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."
  • Reported: MARTE 1.0 — Mon, 15 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Timing observer naming

  • Key: MARTE11-97
  • Legacy Issue Number: 15048
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Thu, 11 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The domain term in chapters 15 16 17 and appendix F should be
    TimedObserver, the profile term in chapters 15 16 17 should be TimedObs

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE AADL Annexe

  • Key: MARTE11-96
  • Legacy Issue Number: 15039
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    Precise component type and implementation relationship.
    "Component realization" concept seems more inline with the AADL semantics than "UML realization" concept.

  • Reported: MARTE 1.0 — Fri, 5 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Disposition: See issue 14871 for disposition

  • Updated: Fri, 6 Mar 2015 23:15 GMT

13.3 UML Representation

  • Key: MARTE11-95
  • Legacy Issue Number: 15036
  • Status: closed  
  • Source: Atego ( Marty Stolz)
  • Summary:

    CallConcurrencyKind is an Enumeration but is not marked as such on the Diagram

  • Reported: MARTE 1.0 — Thu, 4 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The issue actually refers to figure 13.8. Indeed, the keyword “enumeration” is missing on
    CallConcurrencyKind. The proposed resolution consists in adding the missing keyword.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

• polling: PollingParameters [0..1]

  • Key: MARTE11-94
  • Legacy Issue Number: 15035
  • Status: closed  
  • Source: Atego ( Marty Stolz)
  • Summary:

    but is called D.4.6 PoolingParameters (PollingParameters definition does not exist in the spec)

  • Reported: MARTE 1.0 — Thu, 4 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    It is indeed a typo: change PoolingParameters into PollingParameters for the
    label of section D4.6.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Diagram shows {ordered usedResouces}, it should be {ordered usedResources}.

  • Key: MARTE11-93
  • Legacy Issue Number: 15034
  • Status: closed  
  • Source: Atego ( Marty Stolz)
  • Summary:

    Diagram shows

    {ordered usedResouces}

    , it should be

    {ordered usedResources}

    .

  • Reported: MARTE 1.0 — Thu, 4 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    New figure 10.18.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

<> "SchedulableResource" has a tag of schedParams which is made up of a Class (this is not allowed in UML)

  • Key: MARTE11-92
  • Legacy Issue Number: 15033
  • Status: closed  
  • Source: Atego ( Marty Stolz)
  • Summary:

    <<StereoType>> "SchedulableResource" has a tag of schedParams which is made up of a Class (this is not allowed in UML)

  • Reported: MARTE 1.0 — Thu, 4 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Clarify the relationship between GQAM::WorkloadEvent and GRM::UsageDemand

  • Key: MARTE11-90
  • Legacy Issue Number: 14917
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    This is actuially a very good observation. It does not seem dangerous. A
    resolution with it is provided.
    Note for the editor: Please observe that this resolution must be edited in after
    issue 14906, since this add the “redefined” constraint.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Figure 8.5 UML profile diagram for NFPs modeling

  • Key: MARTE11-91
  • Legacy Issue Number: 15032
  • Status: closed  
  • Source: Atego ( Marty Stolz)
  • Summary:

    Figure 8.5 UML profile diagram for NFPs modeling

    StereoType "Unit" has a Tag of convOffset but the xmi import has named it offsetFactor

  • Reported: MARTE 1.0 — Thu, 4 Feb 2010 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The right name is convOffset. The xmi must be fixed..

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Align notions of duration in NFP, Time and GQAM

  • Key: MARTE11-86
  • Legacy Issue Number: 14912
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Disposition: See issue 14903 for disposition

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Clarify the additional semantics brought by the GRM::TimingResource stereotype

  • Key: MARTE11-85
  • Legacy Issue Number: 14911
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    This is already explained in its definition in page 93.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

The Step.host attribute is redundant,

  • Key: MARTE11-88
  • Legacy Issue Number: 14914
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The host relationship is very important when we need to model an abstract
    application without an explicit Task Model. The Step should be rich enough to
    model a piece of code subject to scheduling. For this reason a step has a Host, a
    Priority (among others). This kind of assumptions is necessary for early
    scheduling analysis. We propose then to close with no change this resolution.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Clarify the semantics of GQAM::BehaviorScenario duration attribute w.r.t. execTime, respTime and hostDemand

  • Key: MARTE11-87
  • Legacy Issue Number: 14913
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Clarified, using a reference to the definitions in Table 15.1. Some of the attributes
    like execTime occur in the Table but are not used in the domain model, this is
    also clarified

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Typo in Figure 10.13: multiplicity of event property

  • Key: MARTE11-89
  • Legacy Issue Number: 14916
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:
    • symbol in front of the event property in Figure 10.13, which multiplicity is 0..1
  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Separate the * from the +event role label, and locate them correctly in figure
    10.13.
    The figure here shown is the very same as the resolution for issue 14908.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

NFP_CommonType shall define comparison operators (eg. =, >, <, *, +, -).

  • Key: MARTE11-84
  • Legacy Issue Number: 14910
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The issue addresses the absence of operations for the datatype
    NFP_CommonType (and its children types such as NFP_Duration) capturing
    predefined operators applying on these types. One of the consequences of this
    absence is that it is not possible to manipulate values of these in datatypes in
    VSL infix expressions (such as “"(end - start) < (value=10.0, unit=ms)", which
    would imply that operator ‘<’ is available for NFP_Duration).
    As suggested by the issue description, one possible solution would be to modify
    the existing MARTE libraries, by adding required operations to
    NFP_CommonType or its children datatypes. The main drawback of this
    approach is that, each time a user identifies a need for an operator which is not
    supported by a datatype from the MARTE libraries, the library needs to be
    modified, by adding the corresponding operation to the datatype. This solution is
    not flexible.
    The idea of the resolution described in the section “revised text” is to provide
    users with a flexible mechanism for stating that a given predefined operator can
    be used on a particular type (in the context of infix VSL expressions). The core
    idea behind this resolution is to rely on the new features introduced in the
    resolution to issue 15100. The resolution to this issue introduces additional
    syntactic rules to VSL for expressing behavior calls (i.e.,
    BehaviorCallExpression). As described in the resolution to this issue, defining
    behavior signatures following a procedural style (i.e., capturing signatures by
    behaviors instead of operations on DataTypes) can help to limit the coupling
    between type definitions and behavior signature definitions (since signatures are
    no longer captured as operations of data types). Relying on Behaviors instead of Operations for capturing new operators (e.g., adding predefined operators for
    NFP_CommonType) would therefore avoid modifications of existing libraries.
    In order to capture the fact that a given behavior actually represents an operator,
    a new stereotype, « Operator », is introduced in this resolution. Some text is also
    provided regarding how this information can be automatically exploited by a VSL
    parser, regarding type inference and scoping.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Typo in Figure 10.13: enery property

  • Key: MARTE11-81
  • Legacy Issue Number: 14907
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    ResouceUsageAmount has a 'enery' property. Rename into 'energy'

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

In Figure 15.3, Step.concurRes property should be typed by ConcurencyResource instead of SchedulableResource

  • Key: MARTE11-83
  • Legacy Issue Number: 14909
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

ResourceUsage.requiredAmount aggregation kind should be composite

  • Key: MARTE11-82
  • Legacy Issue Number: 14908
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    ResourceUsage.requiredAmount aggregation kind should be composite

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Add the diamond in ResourceUsage.requiredAmount depicted in figure 10.13.
    Here it is to be solved also the typo reported in Issue 14916

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Inconsistency between the Time domain model and related profile

  • Key: MARTE11-77
  • Legacy Issue Number: 14903
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    In the domain view, the intent was to refer to a value (a duration value) and a
    value exists independently of its specification and therefore cannot be owned. In
    the UML representation, in practice, we use a specification to denote the value
    and there is no reason for the specification not to be owned by another element.
    The resolution proposes to keep the association in the domain view but refer to
    the metaclass DurationValue instead of CVS::DurationValueSpecification. This
    partly addresses also the issue 14912, stating that
    CVS::DurationValueSpecification being non normative should not be used in a
    normative part. The composition with a ValueSpecification is maintained in the
    profile. This is consistent with the different roles played by a value and one of its
    possible specifications.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Inconsistent definition of CommunicationChannel properties

  • Key: MARTE11-76
  • Legacy Issue Number: 14902
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    For consistency, change the attributes of a CommunicationChannel in Annex F
    section F.10.4, and the GaCommChannel stereotype description in section
    15.3.2.3 so that they appear as packetSize and utilization, like in Fig 15.5.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

SAM Workload Figure defines a new property for GQAM::WorkloadBehavior

  • Key: MARTE11-79
  • Legacy Issue Number: 14905
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    To avoid this new association for WorkloadBehavior, this resolution proposes to remove the
    association itself. It is not really needed since WorkloadBehavior already has the composite
    association with the two concepts that are part of an EndToEndFlow (WorkloadEvent and
    BehaviorScenario).

  • Updated: Fri, 6 Mar 2015 23:15 GMT

TimedElement.on default value should refer to the ideal clock

  • Key: MARTE11-78
  • Legacy Issue Number: 14904
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    TimedElement.on default value should refer to the ideal clock, by the mean of a default property (e.g. instance value)

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The intent was actually to do so. When attribute "on" is not used, then it implicitly
    refers to idealClk. However, "idealClk" is defined in "TimeLibrary", which actually
    applies the "Time" profile. So what is requested in the issue would actually create
    a cyclic dependency.
    The resolution proposes to add a sentence to make the intent clear as suggested
    by the issue.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Figure 16.3 inconsistent with Figure 15.3

  • Key: MARTE11-80
  • Legacy Issue Number: 14906
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Figure 15.3 defines a cause-effect association between WorkloadEvent and WorkloadBehavior, while Figure 16.3 defines an inputSteam-effect association

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Change “inputStream” by “cause” in the association between WorkloadEvent and
    WorkloadBehavior in Figure 16.3. This implies changing also the description of
    the concept in Annex F section F10.3.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

SecondaryScheduler should be an association of the Scheduler instead of a specialized class

  • Key: MARTE11-74
  • Legacy Issue Number: 14897
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    This simplification is not possible since the mechanisms to share the capacity
    that will be rendered by the primary scheduler to the secondary in order to be
    brokered by the secondary needs to be expressed, and this is done by the
    utilization of the intermediate schedulable resource.
    Simpler models may be made at user model level, so that the association
    between them can be stereotyped as Schedulable resource, but that is not
    feasible at the profile or domain view level.
    Resolution:
    Closed the issue with no change to the specification.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Update the GCM ClientServerPort to take into account evolutions in UML 2.3

  • Key: MARTE11-73
  • Legacy Issue Number: 14896
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Update the GCM ClientServerPort to take into account evolutions in UML 2.3 (introduction of conjugated port)

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The issue refers to the introduction in UML 2.3 of the property “isConjugated” on the metaclass
    Port. It means that the property “isConjugated” is no longer needed on the stereotype
    “ClientServerPort” from MARTE since ClientServerPort extends Port.
    The revised text describes required modifications to the MARTE specification. Note that, even
    though the issue does not mention it, FlowPort are also concerned by this evolution of UML ports.
    The “revised text” section also describes modifications required by the stereotype FlowPort.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Remove the TimedObservation stereotype

  • Key: MARTE11-72
  • Legacy Issue Number: 14895
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Stereotype TimedObservation was created for consistency with the UML
    Specification and considering that TimeExpression would refer to
    TimedObservation directly without deciding on the actual specialization.
    The stereotype can be removed with no harm. TimeExpression will refer to
    (untimed) Observation instead. Even though the semantics is weakened, there is
    no actual impact since the association between TimeExpression and Observation
    is not actually serialized by any tool.
    Though, it should be noted that TimedObservation cannot be removed from the
    Domain View since it is actually used by DurationPredicate and TimePredicate.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

AssigmentKind/AssignmentNature are redundant with AllocationKind/AllocationNature

  • Key: MARTE11-71
  • Legacy Issue Number: 14894
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Disposition: See issue 14841 for disposition

  • Updated: Fri, 6 Mar 2015 23:15 GMT

PortGroup concept used in Annex A.2 is not defined in the MARTE profile

  • Key: MARTE11-75
  • Legacy Issue Number: 14900
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    PortGroup concept used in Annex A.2 is not defined in the MARTE profile

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Port Group concept has been removed in AADL v2 and a more generic concept
    (feature group) has been introduced. The mapping towards MARTE is defined in
    issue 14866.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Different multiplicities in the GQAM meta-model and profile

  • Key: MARTE11-70
  • Legacy Issue Number: 14892
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

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

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Make it * in Fig 15.2 and Sec F10.2. Also there is a dangling phrase in Sec F10.2

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Relationship between AnalysisContext, WorkloadBehavior and ResourcePlatform

  • Key: MARTE11-69
  • Legacy Issue Number: 14891
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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)

  • Reported: MARTE 1.0 — Thu, 31 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary: {…This issue misreads the text, which is: “The top-level GQAM package shown in Figure 15.2, is organized around the concept of AnalysisContext, which represents the root of the domain model. It contains two parts that address different concerns: “It” refers to the top-level package, not to AnalysisContext. The relationship to WorkloadBehavior and ResourcesPlatform is consistently an association, in chapters 15 16 17. AnalysisContext is the root of a tree of associations. I suggest this be closed with no change. To convert the relationship to a composition would be a major rewrite of all three chapters, with no benefit to the profile. }

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE-AADL software concept upgrades

  • Key: MARTE11-68
  • Legacy Issue Number: 14874
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The provide a full MARTE AADL alignment, upgrade platform concepts with AADL 1) virtual bus 2) virtual processor concepts

  • Reported: MARTE 1.0 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Renumber section 2.4.4 in 2.4.6 Device
    Add section 2.4.2 Virtual Processor
    A virtual processor represents a logical resource that is capable of scheduling and
    executing threads and other virtual processors bound to them. It will be represented as a
    MARTE “swSchedulingResource” AND “ProcessingResource” stereotyped UML
    Classifier
    Add section 2.4.4 Virtual Bus
    A virtual bus component represents logical bus abstraction such as a virtual channel or
    communication protocol. It will be represented at resource level as a MARTE
    “CommunicationMedia” stereotyped UML connection or classifier allocated to the
    physical HWBus.
    • If the communication media represents a bus, and the clock is the bus speed, "element size" would be the width of the bus, in bits.
    • If the communication media represents a layering of protocols, "element size"
    would be the frame size of the uppermost protocol.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE-AADL software concept upgrades

  • Key: MARTE11-67
  • Legacy Issue Number: 14873
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The provide a full MARTE AADL alignment, upgrade software concepts with AADL 1) abstract component, 2) prototype, 3) threadgroup, 4)subprogram group concepts

  • Reported: MARTE 1.0 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    In AADL v2, the concepts of abstract component, prototype, thread group and
    subprogram group have been added and have be taken into account by MARTE
    to ensure a full AADL v2/MARTE alignment.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE-AADL component implmentation modeling

  • Key: MARTE11-65
  • Legacy Issue Number: 14871
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    Upgrade AADL component declaration relationship to a AADL component implementation (UML Realization -> UML Component Realization)

  • Reported: MARTE 1.0 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    An AADL component type specifies the external interface of a component that its
    implementations satisfy. It contains declarations that represent features of a
    component and property associations. An AADL component implementation
    represents the realization of a component in terms of subcomponents, their
    connections, flow sequences, properties, component modes and mode
    transitions. UML 2 “Realization” semantics makes references to a specialized
    abstraction relationship between two sets of model elements, one representing a
    specification and the other representing an implementation of the latter. The UML
    2 “ComponentRealization” concepts refine the “Realization” concepts, reducing
    the subset of linked elements to UML Components and Classifiers. This concepts
    suits better the the AADL component type/implementation relationship.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE-AADL connectors modeling

  • Key: MARTE11-64
  • Legacy Issue Number: 14870
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The notion of assembly/delegation connectors between ports and subcomponents has to be clarified in the MARTE AADL annexe.

  • Reported: MARTE 1.0 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Same issue as 14864
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Annexe introduction

  • Key: MARTE11-63
  • Legacy Issue Number: 14868
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    AADL v2 has be voted.
    Upgrade introduction texte to position MARTE according the new version of the AADL standard

  • Reported: MARTE 1.0 — Tue, 15 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Replace first sentence with

    AADL is a RTES design and analysis language and standard referenced at the
    SAE (standard number XXX). Version 2 has been voted in XXX. This section
    presents the correspondence between MARTE 1.0 and AADL 2.0 concepts, with
    the aim to clarify which subset of MARTE concepts shall be used to explicit
    AADL concepts. The MARTE profile has be adopted as the UML profile for
    AADL, so this section presents the MARTE2AADL concepts correspondence.
    The section is not a methodology to design AADL applications in UML. “

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE-AADL summeray table upgrade

  • Key: MARTE11-66
  • Legacy Issue Number: 14872
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    Upgrade MARTE AADL summery table upgrade according resolved issues

  • Reported: MARTE 1.0 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    see pages 59 - 62 of ptc/2010-08-30 for resolutoion

  • Updated: Fri, 6 Mar 2015 23:15 GMT

DATA : MARTE AADL mapping

  • Key: MARTE11-62
  • Legacy Issue Number: 14867
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Tue, 15 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Replace section A.2.3.4 with
    There are two ways of modeling AADL components, the first one addressing a
    pure architectural design, the second one, based on the Data Annex [SAE
    AS5506 A, Annex Document B: Data Modeling] , will be more dedicated to data
    modeling.
    AADL data component are used to represents different concepts
    • Data component classifier (type and implementation) staying for “data type
    in the source text”. This source text data type can be modeled by a data
    component type declaration with relevant properties without providing
    internal details that will be specified in a data component implementation.
    • Data subcomponents staying for “static data in the source text”. Data
    subcomponents are instances of data classifiers.
    According data classifier features and subcomponent features, the data
    component can represent:
    • A simple type (not necessary primitive) • A structured type (when sub component declared)
    • A class (when subcomponent present and provide subprograms declared)
    • A shared resource (if data access connection specified)
    AADL Primitive Types
    Each AADL primitive type from the AADL data_types packages (i.e. aadlboolean,
    aadlinteger, aadlreal, aadlstring) will have an UML/MARTE primitive type
    equivalent, defined in MARTE Model Library for Primitive Types (Annexe D from
    MARTE).
    These primitive types are commonly used in properties specification. Do
    represent them in an architectural view, the data annex based representation
    style must imperatively be followed. <<< see pages 51 - 53 of ptc/2010-08-30 for images>>>

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Feature group

  • Key: MARTE11-61
  • Legacy Issue Number: 14866
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The whole AADL features group concepts can't be represented in MARTE

    Precise the mapping perimeter and semantics of "inverse of"

  • Reported: MARTE 1.0 — Tue, 15 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Feature Group is a new aadl v2 concept.
    An AADL feature is part of a component type definition that specifies how that
    component interfaces with other components of the system. Features represent
    ports, subprogram and subprogram group accesses, parameters, and data and
    bus accesses.
    Feature group represents groups of component features, features group can
    contain feature group, and can be use anywhere features can be used. Inside a
    component, each feature can be connected individually, outside a component a
    feature groups can be connected as a single unit.
    A feature group type can be declared to be the inverse of another feature group
    type, which specifies that the feature types will remain the same but that the
    “direction” will be the opposite: so service provided/ required qualifier, flow
    direction, the parameter passing mode will be automatically deduced.
    In UML concept, the notion of port group, as group of ports, doesn’t exist. We
    use a symmetrical solution, meaning the possibility to refine and compose
    interfaces typing ports as alternative to physical connection point assembly.
    The MARTE AADL mapping perimeter will be restricted to data access and
    subprogram access.
    In order to provide a homogeneous representation for designers, align with data
    access and subprogram access, feature group will be represented as an UML
    interface composed by at least two attributes (representing more than one data
    access) or two subprogram access (representing more than one subprogram
    access). By default, the interface is provided.
    UML delegation/assembly connection represents AADL feature group access. In Threads and Processes subcomponents, constituting the system
    subcomponents, internal ports will be typed by interfaces representing the
    FeatureGroup subtypes, like unitary or composed data/subprogram access

  • Updated: Fri, 6 Mar 2015 23:15 GMT

FLOW : MARTE and AADL alignment

  • Key: MARTE11-60
  • Legacy Issue Number: 14865
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    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

  • Reported: MARTE 1.0 — Tue, 15 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    AADL flow semantics has been introduced to specify information transmission
    (data/event) over connection and subcomponent, covering the whole component
    and subcomponent hierarchy. This aspect is complementary to the structural
    one.
    Declaration flow paths links flow sources to flow sinks of components in a black
    boxes approach.
    Implementation flow paths specify the way this information is convey over
    connections and flow paths.
    End-to-end flows represent a logical flow of data and control from a source to a
    destination through the system instance, meaning a sequence of threads that
    process and possibly transform the data. The corresponding end-to-end flow
    instance is determined by expanding the flow specifications through their flow
    implementations.
    As UML/MARTE concepts makes a full distinction between logical and structural
    aspects, and while AADL manipulates them jointly, different and not full satisfying
    solutions can be provided to represent AADL flows and end-to-end-flows.
    • UML sequence diagrams, using message exchanges between instances
    and associated ports
    • UML activity diagrams, more focusing on actions and their associated
    control flow. Flow path declaration representation will stay unmodified, using the UML
    “InformationFlow” concept.
    Flow path implementation will be represented in a sequence diagram, using UML
    “GeneralOrdering” elements to keep order preservation between messages
    received and sent over the ports, UML “Messages” will be used to represent
    communication between instances. The Name of the GeneralOrdering element
    will make reference to the FlowPath declaration; the name of the message will
    make reference to the connection conveying it.
    To provide a representative distinction and to avoid code generation ambiguity
    between end-to-end flow and flow implementation representations, both
    represented as sequence diagrams, the first one will be stereotyped “end-to-end
    flow”, the second one, will have the suffix: Flowname_flow_impl.
    AADL flow sinks and flow sources can’t be represented in UML/MARTE.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE AADL annexe

  • Key: MARTE11-59
  • Legacy Issue Number: 14864
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The notion of assembly/delegation connectors between ports and subcomponents has to be clarified in the MARTE AADL annexe.

  • Reported: MARTE 1.0 — Tue, 15 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Implied NFP constraint on stereotypes Assign and Allocate

  • Key: MARTE11-58
  • Legacy Issue Number: 14842
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    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?

  • Reported: MARTE 1.0 — Tue, 8 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The intent is to emphasize that allocations and assignments always come at
    price and the costs should be made explicit by some NFP constraints. These
    NFP constraints will then guide the architecture exploration, for instance. Of
    course, constraints can be applied to anything but having an explicit association
    is useful for traceability purpose.
    If you allocation one element to two execution platforms, the costs may be
    different and you need to know which constraint is imposed by which allocation.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Nature and Kind of Allocation and Assignment

  • Key: MARTE11-57
  • Legacy Issue Number: 14841
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Both Allocation and Assigne stereotype use their onw enumerations for defining their nature and kind. For simplification, they should use the same enumerations.

  • Reported: MARTE 1.0 — Tue, 8 Dec 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    Replace AssignmentNature by AllocationNature and remove the definition of
    AssignmentNature.
    Replace AssignmentKind by AllocationKind and remove the definition of
    AssignmentKind

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Example of RtFeature update required

  • Key: MARTE11-56
  • Legacy Issue Number: 14821
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The issue actually refers to figures 13.14, 13.15, 13.16, 13.17, 13.18, 13.19 and 13.20. Most of
    the resolution consists in adding stereotype « rtSpecification » to comments associated with
    «rtfeatures». See details in the revised text.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

GQAM::RequestedService metaclass has no definition

  • Key: MARTE11-55
  • Legacy Issue Number: 14808
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    GQAM::RequestedService metaclass has no definition in Annex F.

  • Reported: MARTE 1.0 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    A subsection must be inserted after F.10.13 with the definition. Also, Fig 15.3 is
    missing the attributes of Step which define the requests, and these should be
    added.

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Meta class BehaviorScenario not synchronized with its representation

  • Key: MARTE11-54
  • Legacy Issue Number: 14435
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    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).

  • Reported: MARTE 1.0 — Mon, 28 Sep 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 23:15 GMT

NFP_Constraint metaclass syncho with its underlying stereotype

  • Key: MARTE11-53
  • Legacy Issue Number: 14427
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Mon, 21 Sep 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    The domain model already showed the Nfp_Constraint’s relationship to a Mode (Fig. 8.3)
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MARTE domain model: defintion of Trigger

  • Key: MARTE11-52
  • Legacy Issue Number: 14348
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Thu, 3 Sep 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    This is a conceptual entity, there is no stereotype associated. The semantically closer
    element that have a stereotype is the …. GQAM::GaWorkloadEvent plus its
    GaWorkloadGenerator. They do have the necessary attributes. I suggest Close No
    Change.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Semantics description of TimedObserver

  • Key: MARTE11-51
  • Legacy Issue Number: 14221
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    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.

  • Reported: MARTE 1.0 — Wed, 26 Aug 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.1
  • Disposition Summary:

    {Fig 15.4 shows multiplicity * for both start and end events. Sec F10.18 shows
    multiplicity 0..1 for both... this should be changed to *. Since there may be
    several pairs of events, the associations must be ordered to express the
    correspondence. Since the is also an attribute laxity for each pair, it must also be
    multiple and ordered.
    Also there is confusion in the naming of the associations: startObs and endObs
    in the text in F10.18 and of Ch 15 for domain and UML, and startEvent and
    endEvent in the formal definition of F10.18 and in Fig. 15.4, and in the profile
    definition (sec 15.3.2.14). One or the other should be used consistently. Since
    startEvent/endEvent is rather generic, and indeed is also used in the Core
    domain model in another sense, it is preferred to standardize on startObs and
    endObs.

  • Updated: Fri, 6 Mar 2015 23:15 GMT