${taskforce.name} Avatar
  1. OMG Task Force

2nd UML Profile for MARTE FTF — Closed Issues

  • Key: MARTE_
  • Issues Count: 66
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
MARTE_-66 stereotype GRM::SchedulableResource should have an attribute describing its activation parameters MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-65 MARTE/section 7.2.1/ "No Metamodel root" bug MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-64 Example in Figure 10.21 makes use of directed arrows MARTE 1.0b1 MARTE 1.0 Resolved closed
MARTE_-63 align the notation section of 11.3.2.7 to the profile diagram. MARTE 1.0b1 MARTE 1.0 Resolved closed
MARTE_-62 associations between Instance and ModelElement (subclasses) MARTE 1.0b1 MARTE 1.0 Resolved closed
MARTE_-61 MARTE Profile : Synchronisation between SRM, GRM, HRM and analysis part MARTE 1.0b1 MARTE 1.0 Resolved closed
MARTE_-60 Section: 10/3 MARTE 1.0b1 MARTE 1.0 Resolved closed
MARTE_-59 There should be a section to describe the different possible notations for the allocation MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-58 Marte: more complete definition of contextParams in GaAnalysisContext (ch 15) MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-57 Marte: consistent capitalization of stereotypes in Sec 17.4 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-56 Typos in example Figures 17.15/16/17/27 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-55 In HRM, the structure of the subprofile is ill formed MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-54 Missing attributes MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-53 In B.3.3.16, jitter(t1,t2) should be clarified (description of the t2 term). Should be jitter(t2-t1)?? MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-52 In B.3.3.16, namespace must be replaced by namespace ::= ['.' namespace] MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-51 In B.3.3.15, if-false-expr should be optional. Also, the metamodel in page 402: must be updated. MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-50 In B.3.3.15, the parentheses in the rules: if-true-expr and if-false-expr are not required. MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-49 In B.3.3.13, namespace must be replaced MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-48 In B.3.3.14, first rule, parentheses are not optional MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-47 Variable call expression and property call expression are ambiguous MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-46 In Section B.3.3.12, second rule, it is missing the ":' symbol in variable declaration. MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-45 In Section B.3.3.12, in the last line, the examples should refer to variable call expr, and not property call expr. MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-44 Properties of TupleType and ChoiceType should be constrained to be DataType only. MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-43 In Section B.3.3.8, remove the 'unlimited-natural' term (not longer valid). MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-42 In B.3.3.7, the first rule allows defining bounds of different type, This should be forbidden MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-41 In B.3.3.7, literal-interval-bound should be separated in two interval bounds MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-40 In Section B.3.3.4., the DateTimeLiteral rule can be optimized MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-39 Section B.3.3.3 is duplicated. MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-38 In Section B.3.3.12 (Variables, p 416), the text is not aligned with the grammar MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-37 Literals terminal rule has not been defined for its elements, in Section B.3.3.1 in p. 412 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-36 FlowPort stereotype MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-35 The notion of value is missing the NFP_Declaration domain model Description MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-34 ARINC 653 Annex of MARTE MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-33 The dependency between NFP and VSL is not necessary MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-32 using a simple Dependency to model an allocation relationship doesn't match with the allocation concept MARTE defines MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-31 In GCM, domain model and profile do not match in ways that are not fully documented MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-30 GCM Classes Description in Annex should be revised: MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-29 MARTE/section 12.2/ "No assemblyConnectorEnd in the Metamodel" bug MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-28 MARTE/annexe E/ "No MultiplicityElement owner in the metamodel" bug MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-27 MARTE/RSM/repetition index port missing MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-26 MARTE/RSM/generalization of the reshape stereotype MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-25 inconsistencies in the HLAM subprofile MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-24 Figure 13.1 (pg 149) MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-23 Section: Annex D MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-22 Figure12.4 is wrong MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-21 Section: GQAM-SAM-PAM MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-20 Figure 16.6: multiplicity MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-19 definition of ResourceUsage (F.4.27) in annex F MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-18 NFP_Type MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-17 concrete syntax MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-16 clarify the semantical difference between an UML "Port" and a MARTE "Messag MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-15 Clarification in chapter "General Component Model" needed MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-14 MARTE aligment with SYSML 1.1 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-13 check UML 2.2 modifications impacts on MARTE Metamodel and definitions MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-12 What about a System Configuration concept having a set of OperationalModes? MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-11 rteConnector concept MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-10 Fig 15-7 shows that GaCommStep has the property MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-9 ordered association "subUsages" MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-8 property 'msgSize' in figure 15-7 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-7 MARTE profile-library interdependency should be revised and enhanced MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-6 HRM, fig 14-70, the stereotype HwMedia extends UML::Connector MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-5 typos in section E.3.2 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-4 Missing illustration for "Shape" and "reshape" stereotype MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-3 MARTE Beta: 12.3.2.4 FlowBFeature issue # 2 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-2 MARTE Beta: 12.3.2.4 FlowBFeature issue # 1 MARTE 1.0b2 MARTE 1.0 Resolved closed
MARTE_-1 Annex 3 MARTE 1.0b2 MARTE 1.0 Resolved closed

Issues Descriptions

stereotype GRM::SchedulableResource should have an attribute describing its activation parameters

  • Key: MARTE_-66
  • Legacy Issue Number: 13655
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    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.

  • Reported: MARTE 1.0b2 — Tue, 3 Mar 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The activation pattern is a characteristic of the application, not of the platform. In
    fact it is usually different in each execution scenario. The concept of task, as
    used in languages and formalisms is for all of them a way to create an
    application, not a description of the platform. A modeling element that may serve
    for this purpose would be much closer in meaning to an RTUnit than to a
    SchedulableReource. So the extension requested is not in the scope of GRM. A
    task is clearly a design modeling element and if not in HLAM it may probably fit in
    SRM.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

MARTE/section 7.2.1/ "No Metamodel root" bug

  • Key: MARTE_-65
  • Legacy Issue Number: 13086
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    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.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Actually there is a root element it is “ModeElement”, and it has the “ownedElement”
    reflective relationship so all elements in MARTE may be (hopefully) derived from and
    contained in it. I suggest Close No Change.
    Disposition: Closed, no change

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Example in Figure 10.21 makes use of directed arrows

  • Key: MARTE_-64
  • Legacy Issue Number: 12411
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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.

  • Reported: MARTE 1.0b1 — Thu, 24 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The example is not a composite structure; the caption text of the figure may have
    mislead the reader. It shows just a class diagram with dependencies among
    them.
    Resolution:
    Closed the issue with no change to the specification

  • Updated: Wed, 11 Mar 2015 01:53 GMT

align the notation section of 11.3.2.7 to the profile diagram.

  • Key: MARTE_-63
  • Legacy Issue Number: 12286
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    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.

  • Reported: MARTE 1.0b1 — Wed, 19 Mar 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This issue was related to MARTE beta 1 and is no longer relevant to MARTE v1.
    Disposition: Closed, no change

  • Updated: Wed, 11 Mar 2015 01:53 GMT

associations between Instance and ModelElement (subclasses)

  • Key: MARTE_-62
  • Legacy Issue Number: 12234
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Yann Tanguy)
  • Summary:

    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.

  • Reported: MARTE 1.0b1 — Mon, 18 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    THIS IS A slightly OLD ISSUE, THE FIGURE NUMBERS HAD CHANGE SINCE
    LAST VERSIONS. AND THIS HAS BEEN ALREADY SOLVED BY SUBTYPING
    THE ROLE IN ONE OF THE LAST VERSIONS. SEE FIGURE 7.7 We can close with
    no change the issue.
    Disposition: Closed, no change

  • Updated: Wed, 11 Mar 2015 01:53 GMT

MARTE Profile : Synchronisation between SRM, GRM, HRM and analysis part

  • Key: MARTE_-61
  • Legacy Issue Number: 11856
  • Status: closed  
  • Source: ESEO ( Jerome Delatour)
  • Summary:

    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.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    With respect to the status of the FTF, the resolution of this issue would need too
    much time to be resolved in an efficient and satisfying form. So, I (Sébastien
    Gérard from CEA LIST) propose to defer it.
    Disposition: Deferred This issue has been resolved by resolutions to issues 11411 and 11412. A brief
    modification is necessary in the introduction of GRM to comprise it as generic for
    also analysis and design. A brief text is to be added to the Introduction of GRM to emphasize its a role of
    foundation for the analysis packages (GQAM, SAM and PAM) and the DRM
    (SRM and HRM).

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Section: 10/3

  • Key: MARTE_-60
  • Legacy Issue Number: 11621
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • 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".

  • Reported: MARTE 1.0b1 — Wed, 17 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

There should be a section to describe the different possible notations for the allocation

  • Key: MARTE_-59
  • Legacy Issue Number: 13821
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    There should be a section to describe the different possible notations for the allocation

  • Reported: MARTE 1.0b2 — Mon, 30 Mar 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13126 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Marte: more complete definition of contextParams in GaAnalysisContext (ch 15)

  • Key: MARTE_-58
  • Legacy Issue Number: 13724
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    The attribute contextParams in the domain model (Fig 15.2) is a collection of VSL::Expression::Variable (Variable as defined in Sec B.3.3.12). However in the profile definition of Sec 15.3.2.2 it is just defined as a set of strings.

    To make it consistent with the domain model, and useful for defining parameters of contexts, the strings should be defined to conform to the concrete syntax for variable calls or declarations of Sec B.3.3.12.

    Three of the examples of Sec 17.4 use these attributes, in a form that is no longer in the document, and need to be updated (see Figs 17.16, 17.17, 17.21, 17.27)

  • Reported: MARTE 1.0b2 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    To make it consistent with the domain model, and useful for defining parameters
    of contexts, the strings should be defined to conform to the concrete syntax for
    variable calls or declarations of Sec B.3.3.12.
    Three of the examples of Sec 17.4 use these attributes, in a form that is no
    longer in the document, and need to be updated (see Figs 17.16, 17.17, 17.21,
    17.27)

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Marte: consistent capitalization of stereotypes in Sec 17.4

  • Key: MARTE_-57
  • Legacy Issue Number: 13723
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    The capitalization of stereotypes in the example in Sec 17.4 needs to be made consistent with the definitions in Sec 17.3. this afffects mostly figures, a few instances in the text also.

  • Reported: MARTE 1.0b2 — Mon, 16 Mar 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The correct prefix is Pa or Ga, instead of pa or ga.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Typos in example Figures 17.15/16/17/27

  • Key: MARTE_-56
  • Legacy Issue Number: 13714
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    These example figures contain a few stereotypes and attributes that were defined in earlier drafts of the profile and need to be updated. These are similar to typos. Examples:

    (a) Fig 17.15 the stereotype paRequestEventStream has been replaced by gaWorkloadEvent, and attributes closedPopulation and closedExeternalDelay are replaced by a closed pattern,

    (b) respTime should be respT, probability should be prob, repetition shold be rep

    (c) In Figure 17.16 the contextValues attribute must be upgraded

    (d) In 17.17 the contextValues attribute must be upgraded, and gaReleaseStep is replaced by gaRelStep, gaAcquireStep by gaAcqStep, repetition by rep.

    (e) in 17.27 there are three instances of probability --> prob

  • Reported: MARTE 1.0b2 — Wed, 11 Mar 2009 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    AnalysisContext changes are part of issue 13724.
    (a) Fig 17.15 the stereotype paRequestEventStream has been replaced by
    gaWorkloadEvent, and attributes closedPopulation and closedExeternalDelay
    are replaced by a closed pattern,
    (b) respTime should be respT, probability should be prob, repetition should be
    rep
    (c) In 17.17 gaReleaseStep is replaced by GaRelStep, gaAcquireStep by
    GaAcqStep, repetition by rep.
    (d) in Fig 17.24, PaProcess is replaced by PaRunTInstance
    (e) in Fig 17.26, remove $ signs on variable names
    (f) in 17.27 there are three instances of probability --> prob

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In HRM, the structure of the subprofile is ill formed

  • Key: MARTE_-55
  • Legacy Issue Number: 13534
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    In HRM, the structure of the subprofile is ill formed. The HwGeneral package should be direct sub package of the HRM profile and it shold be imported by both HwLogical and HwPhysical sub packages of HRM. And all sub packages of the HRM profile should be sub profiles in order to improve its scalability.

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

    The profile architecture of the HRM profile has been updated to factorize the
    HwGeneral sub profile in order it can be shared by both HwLogical and
    HwPhysical subprofiles.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Missing attributes

  • Key: MARTE_-54
  • Legacy Issue Number: 13445
  • Status: closed  
  • Source: university of cantabria ( pablo peñil del campo)
  • Summary:

    In page 91 (GRM chapter) of MARTE profile (beta_2)a figure appear with the <<CommunicationMedia>> attributes. But in the corresponding annex those attributes don't appear (just elementSize appears). Those "disappeared" attributtes are included in <<CommunicationEndPoint>> attributes.

  • Reported: MARTE 1.0b2 — Thu, 5 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Move from section F.4.6 to F.4.7 the additional attributes stated in resolution to 11835.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.16, jitter(t1,t2) should be clarified (description of the t2 term). Should be jitter(t2-t1)??

  • Key: MARTE_-53
  • Legacy Issue Number: 13424
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In B.3.3.16, jitter(t1,t2) should be clarified (description of the t2 term). Should be jitter(t2-t1)??

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.16, namespace must be replaced by namespace ::= ['.' namespace]

  • Key: MARTE_-52
  • Legacy Issue Number: 13423
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In B.3.3.16, namespace must be replaced by (or removed because the rule already exists): namespace ::= <body-text> ['.' namespace]

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.15, if-false-expr should be optional. Also, the metamodel in page 402: must be updated.

  • Key: MARTE_-51
  • Legacy Issue Number: 13422
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In B.3.3.15, if-false-expr should be optional. Also, the metamodel in page 402: must be updated.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.15, the parentheses in the rules: if-true-expr and if-false-expr are not required.

  • Key: MARTE_-50
  • Legacy Issue Number: 13421
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In B.3.3.15, the parentheses in the rules: if-true-expr and if-false-expr are not required.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.13, namespace must be replaced

  • Key: MARTE_-49
  • Legacy Issue Number: 13420
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In B.3.3.13, namespace must be replaced by: <namespace> ::= <body-text> ['.' <namespace>]

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.14, first rule, parentheses are not optional

  • Key: MARTE_-48
  • Legacy Issue Number: 13419
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In B.3.3.14, first rule, parentheses are not optional… (already solved in other Issue number!).

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Variable call expression and property call expression are ambiguous

  • Key: MARTE_-47
  • Legacy Issue Number: 13418
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    We should define a context for property call expression, or define some keywords for making difference.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In Section B.3.3.12, second rule, it is missing the ":' symbol in variable declaration.

  • Key: MARTE_-46
  • Legacy Issue Number: 13417
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In Section B.3.3.12, second rule, it is missing the ":' symbol in variable declaration.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In Section B.3.3.12, in the last line, the examples should refer to variable call expr, and not property call expr.

  • Key: MARTE_-45
  • Legacy Issue Number: 13416
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In Section B.3.3.12, in the last line, the examples should refer to variable call expr, and not property call expr.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Properties of TupleType and ChoiceType should be constrained to be DataType only.

  • Key: MARTE_-44
  • Legacy Issue Number: 13415
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    Properties of TupleType and ChoiceType should be constrained to be DataType only.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In Section B.3.3.8, remove the 'unlimited-natural' term (not longer valid).

  • Key: MARTE_-43
  • Legacy Issue Number: 13414
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In Section B.3.3.8, remove the 'unlimited-natural' term (not longer valid).

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.7, the first rule allows defining bounds of different type, This should be forbidden

  • Key: MARTE_-42
  • Legacy Issue Number: 13413
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In B.3.3.7, the first rule allows defining bounds of different type. This should be forbidden. The first two rules must be changed by: <interval> ::= ('[' | ']') <interval-bounds> ('[' | ']') <interval-bounds> ::= <number-interval-bound> '..' <number-interval-bound> | <datetime-interval-bound> '..' < datetime -interval-bound> | <tuple-interval-bound> '..' <tuple-interval-bound> | <choiceinterval-bound> '..' <tuple-interval-bound> | <expression-interval-bound> '..' <tuple-interval-bound>

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In B.3.3.7, literal-interval-bound should be separated in two interval bounds

  • Key: MARTE_-41
  • Legacy Issue Number: 13412
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In B.3.3.7, literal-interval-bound should be separated in two interval bounds: number-interval-bound and a datetime-interval-bound.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In Section B.3.3.4., the DateTimeLiteral rule can be optimized

  • Key: MARTE_-40
  • Legacy Issue Number: 13411
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In Section B.3.3.4., the DateTimeLiteral rule can be optimized by removing the first alternative and letting optional date-string in the third alternative.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Section B.3.3.3 is duplicated.

  • Key: MARTE_-39
  • Legacy Issue Number: 13410
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    Section B.3.3.3 is duplicated.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In Section B.3.3.12 (Variables, p 416), the text is not aligned with the grammar

  • Key: MARTE_-38
  • Legacy Issue Number: 13409
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    A variables begins by a "direction" and not by a "$" symbol. Yet, the direction is optional, and so a default value must be defined.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13408 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Literals terminal rule has not been defined for its elements, in Section B.3.3.1 in p. 412

  • Key: MARTE_-37
  • Legacy Issue Number: 13408
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    Literals terminal rule has not been defined for its elements, in Section B.3.3.1 in p. 412

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Since Issues 13408 to 13424 are all related to mistakes in the grammar of VSL
    (Annex B), we merge them all in this issue resolution. For convenience, we copy
    below the formulation of each issue.
    This resolution proposes to fix all these issues as proposed by the Issue source.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

FlowPort stereotype

  • Key: MARTE_-36
  • Legacy Issue Number: 13407
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Arnaud Cuccuru)
  • Summary:

    Concerning the FlowPort stereotype, there are some differences between the definition given in SysML and the definition given in MARTE. The differences are: - isConjugated : In MARTE, the multiplicity of this property is [1], whereas in SysML it is [0..1] - direction : In MARTE, the multiplicity of this property is [0..1], whereas in SysML it is [1]. Moreover, a difference also appear concerning the FlowSpecification stereotype: - In MARTE, FlowSpecification has a direction:DirectionKind[0..1] property, whereas in SysML, this property does not exist. Is it just an alignment issue, or is there any fundamental reason motivating these differences?

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    see ptc/2009-05-12 pages 348 - 351

  • Updated: Sat, 7 Mar 2015 21:28 GMT

The notion of value is missing the NFP_Declaration domain model Description

  • Key: MARTE_-35
  • Legacy Issue Number: 13400
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The current NFP_Declaration package of the NFP domain model introduces the notion of NFP and NFPType. However, it is missing a relation between these concepts of non-functional property and the concepts of physical quantity and value (expressed in SysML by Value Property / Value Type). One can consider a non-functional property as a kind of physical quantity. These links need to be explicitly stated, which will foster a future alignment with SysML concepts. Proposed resolution: Introduce the meta-classes: ValuePropery and ValueType in NFP_Declaration package and create inheritance links from ValueProperty to NFP and ValueType to NFPType. No impact on the current UML profile.

  • Reported: MARTE 1.0b2 — Mon, 2 Feb 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Proceed as suggested in the issue summary:
    • Introduce two meta-classes ValuePropery and ValueType in the NFP_Declaration
    package,
    • Create an inheritance link from ValueProperty to NFP and ValueType to
    NFP_Type,
    • Document the meta-classes in Annex F.
    The introduction of the ValueProperty and ValueType metaclasses will provide
    intermediate definitions that bridge the notions of non-functional property (NFP)
    and more general definitions of value and quantity. It is also an opportunity to
    reference SysML notions of ValueProperty / ValueType as related concepts.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

ARINC 653 Annex of MARTE

  • Key: MARTE_-34
  • Legacy Issue Number: 13349
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    The ARINC 653 Annex of MARTE is not strictly compliant with the ARINC 653 resolution: Update the API with the ARINC 653 Ada API

  • Reported: MARTE 1.0b2 — Tue, 27 Jan 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    New ARINC 653 API model has been provided and complementary text to
    explain ARINC 653 Service API

  • Updated: Sat, 7 Mar 2015 21:28 GMT

The dependency between NFP and VSL is not necessary

  • Key: MARTE_-33
  • Legacy Issue Number: 13341
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Currently the domain view and the UML representation of NFP rely on VSL constructs which specialize UML ones (ValueSpecification, Datatype). This dependency is a limitation to the modularity of MARTE (e.g. one might be willing to use NFP with another expression language). Proposed resolution: 1) In the domain model, replace references to MARTE::VSL::ValueSpecification by UML::ValueSpecification (starting by page 35). 2) In the domain model, replace references to MARTE::VSL::TupleType by UML::DataType (starting by page 38) 3) In the UML representation, remove the generalization link between TupleType and NFPType (starting by page 38) 4) In the chapter overview, remove the dependency link between NFP and VSL

  • Reported: MARTE 1.0b2 — Mon, 26 Jan 2009 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The dependency of Domain Models on the VSL Domain Model does not affect
    the modularity of MARTE. On contrast, having a cohesive integration of Value
    Specification concepts from VSL with the other chapters is a must regarding the
    comprehensibility of MARTE. The only design constraint in MARTE was to do
    VSL independent of other MARTE specific chapter, because we had in mind to
    use VSL together with other profiles (e.g., SysML). This level of dependency has
    been achieved as VSL doesn’t import other MARTE packages.
    Note that there are many MARTE chapters that reuse VSL concepts:
    CoreElements, Time, RSM, and having also NFP importing VSL is not a real
    problem.
    For these reasons, we propose to close this issue without change.
    Disposition: Closed No Change

  • Updated: Sat, 7 Mar 2015 21:28 GMT

using a simple Dependency to model an allocation relationship doesn't match with the allocation concept MARTE defines

  • Key: MARTE_-32
  • Legacy Issue Number: 13126
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    From my point of view using a simple Dependency to model an allocation relationship doesn't match with the allocation concept MARTE defines in its "Domain view", §11.2, p117. According to this domain view, it's clear that creating an allocation doesn't create any dependency between allocation ends, what is actually what we need in MDA like approaches where applications and plateforms are considered to be independant. However, the official definition of the UML "Dependency" metaclass states that : "A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. " (formal/2007-11-02 , §7.3.12, p62, unchanged in v2.2 beta 1) Then, I suggest to change the UML representation of the allocation concept so that it really complies to the domain view, that is : if an element of one end of the allocation is modified only the allocation itself should be impacted and not the elements(s) on the other end. It's can be achieved, for instance, by the specialization of the Classifier metaclass, instead of the Dependency metaclass

  • Reported: MARTE 1.0b2 — Wed, 26 Nov 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Allocation is meant to be very general. Application elements are allocated to an
    execution platform (software or hardware), functionality is allocated to processes,
    processes are allocated to a virtual machine, and resources may be allocated to
    resource pools, just for some examples. What allocation is doing in these cases
    is imposing structure on a less structured system.
    For generality, alternative allocations should be possible. If only a single
    allocation is possible then the potential of MDE is thrown away. In particular,
    allocation does not always imply a dependency. Moreover, when a dependency
    is created, the client of this dependency is modified to refer to the dependency.
    This can be a problem when allocating read_only elements.
    The metaclasses Relationship or DirectedRelationship fit better. However,
    these metaclasses are abstract and there is currently no concrete specialization
    in UML that would not induced a specific semantics compatible with the broad
    acception of allocation intended in MARTE. Consequently, the issue should be solved in UML by introducing a new metaclass. It should be discussed with the
    SysML community given the relationship explicitly stated in the MARTE
    specification between the MARTE allocation and its SysML counterpart.
    However, to have an short term solution, we have decided to propose something
    that is not entirely satisfactory but would work with read_only elements, be
    usable in very general cases, require few tool adaptations and would have a
    minimal impact on SysML, with which we want to maintain compatibilities.
    This is done by adding the stereotype Assign that extends the metaclass
    Comment, while preserving the stereotype Allocate to maintain compatibility with
    the current SysML approach. The Assign stereotype is an alternative UML
    representation of the Allocation metaclass, defined in the domain model, but
    without the underlying semantics of the Abstraction metaclass. Note that the
    optional body property of the Comment meta-class can be used to provide the
    justification of the assignment

  • Updated: Sat, 7 Mar 2015 21:28 GMT

In GCM, domain model and profile do not match in ways that are not fully documented

  • Key: MARTE_-31
  • Legacy Issue Number: 13125
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In GCM, domain model and profile does not match in ways that are not fully documented. Although this may be acceptable when domain concepts map directly to UML concepts (no stereotype assigned), or when some syntactic sugar are added at UML profile level. However, it is not clear why the attributes: "direction: DirectionKind" and "kind: BFeatureKind" appear in some domain entities (FlowProperty) and in others not (FlowSpecification, ServiceSpecification, ServiceFeature, SignalSpecificatio, SignalFeature), while in the Profile they are used in all these entities.

  • Reported: MARTE 1.0b2 — Tue, 25 Nov 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This issue is related to alignment problems between the UML view and the domain view
    of the GCM (as well as issues 12867 and 13124, which are set to duplicate/merge
    because they are treated here).
    Issues 11820 and 13407 are related to problems with the UML view of the GCM, and
    they have been treated before this issue 13125. So, the revised text of this resolution is
    made to be consistent with resolutions 11820 and 13407.
    However, note that the revised text proposed here does not result in a “one to one”
    alignment. Indeed, let's remain that the domain view is intended to describe the
    specification of the specific modeling language, whereas the UML view (the UML
    profile itself) is a real design model of the domain model. They are not to be considered
    at the level of abstraction, and then their concepts do not have to map one-per-one. The
    intend of the GCM domain model, and in fact of all other domain models denoted in the
    AMRTE specification, are proposed to depict what is essential for the understanding of
    the GCM, and its underlying causality model (described in section 12.2.2 of the revised
    text).

  • Updated: Sat, 7 Mar 2015 21:28 GMT

GCM Classes Description in Annex should be revised:

  • Key: MARTE_-30
  • Legacy Issue Number: 13124
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    GCM Classes Description in Annex should be revised: 1) BFeatureSpecification has not been included, although it exists in the Metamodel. 2) The "BfeatureAction" name is used in place of "BFeatureKind". 3) Descriptions of MessagePort attributes are not sufficiently detailed. While the Stereotype description section provides some key semantic description, it is not provided in Domain Class description. Particularly, this is the case for the attribute: "isConjugated". 4)SignalPort does not exist anymore in the domain model, but it is included in the Class Description.

  • Reported: MARTE 1.0b2 — Tue, 25 Nov 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13125 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE/section 12.2/ "No assemblyConnectorEnd in the Metamodel" bug

  • Key: MARTE_-29
  • Legacy Issue Number: 13089
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    Assembly connector End can not be manipulated in the metamodel. Wheras
    it is important to have the relashionship between the Assembly connector
    end and the port and from the Assembly Connector to the Port.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The resolution to this issue implies to introduce a ConnectorEnd class in the domain model (cf.
    #1). To mimic the structure of the UML2 metamodel, the ConnectorEnd domain class must have
    a generalization relationship with the MultiplicityElement domain class. MultiplicityElement is only
    defined in the Marte::RSM::Shape (which is basically a uml MultiplicityElement with a Shape). So,
    issue 13089 hides other fundamental issues: MultiplicityElement should be defined in
    Marte::CoreElements::Foundations #2 (and extended through package merge in
    Marte::RSM::Shape #3. Note that in the foundations, Property should also have a generalization
    relationship with MultiplicityElement #4

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE/annexe E/ "No MultiplicityElement owner in the metamodel" bug

  • Key: MARTE_-28
  • Legacy Issue Number: 13087
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    With the MARTE metamodel it can not be specified to which element a
    MultiplicityElement refers. In this context, the multiplicityElement can
    not be attached to any element and thus cannot be used.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    MultiplicityElement has been modified in the context of the issue 13089.
    Consequently, this issue becomes no more valid.
    Disposition: See issue 13089 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE/RSM/repetition index port missing

  • Key: MARTE_-27
  • Legacy Issue Number: 13085
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    In the RSM chapter, the repetition index should be visible by a shaped
    component so that its behavior can depend on this index. A possible
    solution could be a tagged value referencing a port of this component.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE/RSM/generalization of the reshape stereotype

  • Key: MARTE_-26
  • Legacy Issue Number: 13084
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    To be conform to the metamodel and extend the applicability of the
    reshape stereotype, it should be possible to apply it to other kinds or
    links than just allocations or connectors.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    It is not clear if that would be really useful. If some need appears in the future, reraise
    the issue.
    Disposition: Closed, no change

  • Updated: Sat, 7 Mar 2015 21:28 GMT

inconsistencies in the HLAM subprofile

  • Key: MARTE_-25
  • Legacy Issue Number: 12954
  • Status: closed  
  • Source: European Software Institute ( Adrián Noguero)
  • Summary:

    Several inconsistencies in the HLAM subprofile: 1- In figure 3.10 the stereotype <<RtFeature>> is displayed as <<Rtf>>. Later in section 13.3.2.8 is shown again as <<RtFeature>> 2- In section 13.3.2.8 the stereotype <<RtFeature>> is said to extend the UML Behavior element; however in section 3.10 this extension is not shown. 3- Figure 3.11 does not show all the attributes of the <<RtAction>> stereotype. 4- The use of the stereotype <<RtBehavior>> is not clear. An example in 13.4 would be of great help.

  • Reported: MARTE 1.0b2 — Mon, 13 Oct 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 11838 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Figure 13.1 (pg 149)

  • Key: MARTE_-24
  • Legacy Issue Number: 12869
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    Figure 13.1 (pg 149) the dependency of CoreElements is repeated twice. Revise the text: “the HLAM package of MARTE is depending of both GRM and CoreElements packages, but also on the CoreElements package” - figure 13.13 should be removed(since RTConnector has been eliminated) - The references to figures in the example seem wrong.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    One of the related dependencies in Figure 13.1 should be to the package
    MARTE::GeneralComponentModel. However, when referring to the HLAM
    element that depends on this package, we realized that the concrete domain
    model element from MARTE::GeneralComponentModel used in MARTE::HLAM,
    “ComponentService”, it doesn’t exist anymore (see Fig. 13.5, page 152,).
    Hence, this resolution proposes to remove one of the dependencies with
    MARTE::CoreElements in Figure 13.1, and remove all the references to the
    ComponentService domain model element in HLAM.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Section: Annex D

  • Key: MARTE_-23
  • Legacy Issue Number: 12868
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    D.2.2 (ArrivalPattern), it says sporadic: Aperiodic, should it be sporadic:Sporadic (pg 452). - In BurstPattern (D.2.6)minEventInterval is repeted twice. The difinitions in this class should be more explicit to better understand it. Shouldnt it be minEventInterval: NFP_Duration [0..1] the minimum interval between two occurrences OF a burst? it says within a burst. Isn't it what it is said by minInterarrival ?

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This issue points two mistakes and additionally requests for some description
    enhancements. This resolution proposes to revise the text as described below

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Figure12.4 is wrong

  • Key: MARTE_-22
  • Legacy Issue Number: 12867
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    Editorial Issues: - Figure12.4 is wrong, association signal in the SignalSpecification should be of type SignalFeature instead of ServiceFeature. - In annex F there are many incomplete definitions, see F.6.16, F.6.18, F.6.19). F.6.15 and F.6.20 are not mapped, is this correct? - Pg 137 it should say Figure 12.7 (it says 12.17) - Pg 144 it should say Figure 12.15 (it says 12.5), in pg 145 the same for Figure 12.6

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 13125 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Section: GQAM-SAM-PAM

  • Key: MARTE_-21
  • Legacy Issue Number: 12865
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    The attributes CommTxOvh and CommRcvOvh in a GQAM:ExecutionHost (F.10.8) limit comunication of a host to only one network/protocol. In fact the overhead due to communication maight be very dificultly expressed by simply a duration...

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Figure 16.6: multiplicity

  • Key: MARTE_-20
  • Legacy Issue Number: 12864
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    Figure 16.6: multiplicity for the host of a SchedulableResource shoudnt it be 1 - In the example (Figure 16.13), the SchedulableResources associated to SaCommHost, Shouldnt they be CommunicationChannels? - The constraints in 10.3.2.16 (SecondaryScheduler) should be also in its domin concept defined in annex F. - It is not clear the relationship between the clockOverhead of a SaExecutionHost and the TimingResources associated

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Figure 10.11, “The Scheduling Package” expresses that a
    SchedulableResource has at most one host. While a resource could be
    scheduled by two or hosts, management of such distributed scheduling is beyond
    the original intent. Figure 16.6 should be corrected to show the host role to be of
    multiplicity 0..1.

    • We agree that the schedulable entities allocated to the SaCommHost CAN Bus
      should be CommunicationChannels.
    • The SecondaryScheduler is described in F.4.33. The mentioned constraint
      should be added.
    • clockOverhead is only cited as an Attribute of an ExecutionHost and no
      explanation is provided. The purpose of the Attribute should be described.
  • Updated: Sat, 7 Mar 2015 21:28 GMT

definition of ResourceUsage (F.4.27) in annex F

  • Key: MARTE_-19
  • Legacy Issue Number: 12863
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    Editorial Issues: - The definition of ResourceUsage (F.4.27) in annex F is apparently confused (copy/paste) with the one of UsageDemand. - The definition of timingRes in F.11.5 is not the correct one - Shouldnt it be SourceKind in Anex F. - In F.4.7 the new attributes of CommunicationMedia have been inserted in CommunicationEndpoint - F.10.3 the generalizations are missing.

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Ok for items 1, 2, 4 and 5. Item 3 has no meaning. See following revised text.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

NFP_Type

  • Key: MARTE_-18
  • Legacy Issue Number: 12862
  • Status: closed  
  • Source: Universidad de Cantabria ( Patricia López)
  • Summary:

    The priority of a FixedPriorityParameter to attach to a SchedulableResource must be of an NFP_Priority type in order to handle it from tools that deal with VSL and parametric descriptions. This is also the case of the priorityCeiling of a MutualExclusionResource. It is convenient to clarified or indicated how to specify the preemption level of the SchedulableResources by means of its scheduling parameters when the StackBasedProtocol is used. If the priority is used for that it should be stated, If an additional parameter is included, then its type should be also an NFP_Type

  • Reported: MARTE 1.0b2 — Fri, 26 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    In order to handle them from tools that deal with VSL and parametric descriptions the
    most useful type for priority and ceiling is clearly NFP_Integer, it seems that the use of
    Integer instead has been just a typo, and it is easy to solve with no harmful implications.
    For simplicity on the one hand, and for the co-existence of both protocols in a combined
    EDF-FP platform on the other hand, it is convenient to use the Ceiling attribute to hold
    both, the priorityCeiling and the preemptionLevel of a mutualExclusionResource under
    the priorityCeiling and StackBased protection protocols respectively. Since both may be
    handled with an NFP_Integer type, the restriction already stated in the explanation of the
    ceiling attribute (section 10.3.2.9 page 104) is applicable also.
    This is the case for some other values using integer types in GRM, so a consistent
    modification of them is worth doing.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

concrete syntax

  • Key: MARTE_-17
  • Legacy Issue Number: 12861
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    Section 9 proposes some stereotypes to identify clocks and clock constraints. Annex C proposes a non-normative language (CCSL) to describe clock constraints. Even though CCSL is non normative (to give more freedom to tool vendors for implementation), such a constraint language must have some specific characteristics. For instance, it MUST allows description of both synchronous and asynchronous constraints. Hence, the normative part (Section 9) should provide a mechanism to identify the nature (synchronous, asynchronous, mixted) of the constraint even if the concrete syntax remains non-normative and described in Annex C. This would give some kind of consistency between different implementations.

  • Reported: MARTE 1.0b2 — Thu, 25 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The resolution proposes to add three meta-attributes to the stereotype
    ClockConstraint to reflect the domain view (CoincidenceRelation and
    PrecedenceRelation described in Figure 9.5) and identify the nature of the
    constraint.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

clarify the semantical difference between an UML "Port" and a MARTE "Messag

  • Key: MARTE_-16
  • Legacy Issue Number: 12802
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    In chapter "Generic Component Model", please clarify the semantical difference between an UML "Port" and a MARTE "MessagePort".

  • Reported: MARTE 1.0b2 — Wed, 3 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 11820 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Clarification in chapter "General Component Model" needed

  • Key: MARTE_-15
  • Legacy Issue Number: 12801
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    In chapter "General Component Model", please clarify the semantical difference between an atomic flow port typed by a Signal and an atomic MessagePort typed by a signal

  • Reported: MARTE 1.0b2 — Wed, 3 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 11820 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE aligment with SYSML 1.1

  • Key: MARTE_-14
  • Legacy Issue Number: 12799
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    MARTE aligment with SYSML 1.1 SysML has been evolved since the MARTE adoption. MARTE metamodel needs to be align with the SysML metamodel To solve it: check the SysML 1.1 metamodel and MARTE metamodel and align Metamodel / definition according to SysML evolutions

  • Reported: MARTE 1.0b2 — Tue, 2 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This proposal is too general. Moreover, let's notice that there are issues related
    this subject but focus on specific points (e.g., both issues 11871 and 11872) that
    have been resolved and that enable to align MARTE and SysML.
    Disposition: Closed, no change

  • Updated: Sat, 7 Mar 2015 21:28 GMT

check UML 2.2 modifications impacts on MARTE Metamodel and definitions

  • Key: MARTE_-13
  • Legacy Issue Number: 12798
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    Aligment of MARTE to UML 2.2 metamodel to solve it: check UML 2.2 modifications impacts on MARTE Metamodel and definitions

  • Reported: MARTE 1.0b2 — Tue, 2 Sep 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This is a too much general issue!
    However, I (Sébastien Gérard) am thinking that a priori everything is ok w.r.t. that
    alignment issue, i.e. every MARTE construct should be compatible with the
    UML2.2 metamodel.
    Disposition: Closed, no change

  • Updated: Sat, 7 Mar 2015 21:28 GMT

What about a System Configuration concept having a set of OperationalModes?

  • Key: MARTE_-12
  • Legacy Issue Number: 12797
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    The operationalModes association end from rtUnit to rtBehavior has a multiplicity 0..1. This is not enough to model the OperationalMode as understood by fault-tolerance theory. An rtUnit should be capable to have many operationalModes. In addition, an OperationlMode would be need to be defined at system level too (not rtUnit level only). It seems that a separated stereotype (not rtBehavior as currently) would be necessary for OperationalMode. What about a System Configuration concept having a set of OperationalModes?

  • Reported: MARTE 1.0b2 — Thu, 28 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    The concept of Mode (or Operational Mode) is central in embedded systems and
    in dependable embedded systems in particular. Having this concept only as an
    attribute of the RtUnit concept is indeed insufficient to model the behavioural and
    structural aspects of mode sensitive architectures. An operational mode can
    represent different things:

    • An operational system (or subsystem) state that is managed by reconfiguration
      mechanisms (e.g., fault-tolerance management middleware) according to fault
      conditions.
    • A state of system operation with a given level of QoS that can be handled by
      resource management infrastructures (e.g., middleware that assign resources at
      run time according to load demand, timing constraints, or resource usage).
    • A phase of a system operation e.g., starting, stopping, reconfiguring switchers,
      in a supervisory control system of an electric grid.
      We propose to adopt a number of minimum concepts to describe operational
      modes and their dynamics with UML state machines. Please notice that a UML
      state machine may be used “as is” to model operational modes and their
      dynamics. However, the need to unambiguously distinguish modal state
      machines, specifying the kind of above-mentioned macro-states, from other
      standard state machines, motivated us for explicitly describing these concepts in
      the MARTE specification. Furthermore, it seems necessary to characterize
      certain MARTE concepts with “modal” information. For instance, defining which entities are active in a given mode, specifying how entities behave in a mode
      transition, or determining what NFP values are valid in a given mode, all require
      means to refer to the entities proposed in this resolution.
      This resolution proposes to define this set of concepts related to operational
      modes in the “Core Elements” chapter. A number of updates are also proposed
      in other MARTE chapters to refer to the concepts added in “Core Elements”.
  • Updated: Sat, 7 Mar 2015 21:28 GMT

rteConnector concept

  • Key: MARTE_-11
  • Legacy Issue Number: 12796
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    Issue 11835 in the MARTE FTF 1 removed the rteConnector concept from the domain model of HLAM. However, the element (rteConnector) was not removed from the Profile (UML View) part.

  • Reported: MARTE 1.0b2 — Thu, 28 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This resolution proposes to remove Figure 13.13, page 156. The RteConnector
    stereotype doesn’t exist anymore.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Fig 15-7 shows that GaCommStep has the property

  • Key: MARTE_-10
  • Legacy Issue Number: 12780
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    Fig 15-7 shows that GaCommStep has the property "concurRes: SchedulableResource". However; it is not necessary, as far as its parent GaStep already has the same property

  • Reported: MARTE 1.0b2 — Mon, 18 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This has already been resolved during the resolution of issue 12778 in a previous
    ballot (the attribute msgSize was also defined unnecessarily) .
    Disposition: Closed, no change

  • Updated: Sat, 7 Mar 2015 21:28 GMT

ordered association "subUsages"

  • Key: MARTE_-9
  • Legacy Issue Number: 12779
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In page 107, ResourceUsage has an ordered association "subUsages", but Fig 10-18 doesn't reflect this feature (ordered). As far as I understand the semantics of the association, the isOrdered meta-attribute is not relevant here.

  • Reported: MARTE 1.0b2 — Mon, 18 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Add the

    {ordered}

    quality to the subUsages association depicted in Figure 10.18

  • Updated: Sat, 7 Mar 2015 21:28 GMT

property 'msgSize' in figure 15-7

  • Key: MARTE_-8
  • Legacy Issue Number: 12778
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In Fig 15-7, we notice that GaCommStep has the property 'msgSize'. However, this property already exist in its parent Stereotype 'ResourceUsage'. Hence, the property exists twice in GaCommStep. One of them should be removed.

  • Reported: MARTE 1.0b2 — Mon, 18 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    I t should be removed from CommStep. The property concurRes is also inherited
    from Step and can be removed from CommStep in fig 15.7

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE profile-library interdependency should be revised and enhanced

  • Key: MARTE_-7
  • Legacy Issue Number: 12777
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    MARTE profile-library interdependency should be revised and enhanced to ease implementation. Particularly, the MARTE primitive types packages should be used (imported) by the whole MARTE profile and MARTE Libraries. Currently, this aspect is not clear enough, and some parts use UML primitive types while others MARTE primitive types. In addition, establishing well-defined high level packages would help avoiding circular dependencies. For example, MARTE data types library use NFPs and VSL profiles, but MARTE defines NFPs profile in a high level package called Foundations, which has other internal packages that import the MARTE data types libraries. A better grouping criteria should remove interdependencies when implementing MARTE.

  • Reported: MARTE 1.0b2 — Mon, 18 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This issue requires an important restructuring of MARTE. We propose to defer it
    to the RTF
    Disposition: Deferred

  • Updated: Sat, 7 Mar 2015 21:28 GMT

HRM, fig 14-70, the stereotype HwMedia extends UML::Connector

  • Key: MARTE_-6
  • Legacy Issue Number: 12776
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    In HRM, fig 14-70, the stereotype HwMedia extends UML::Connector. This extension is not needed as long as its parent GRM::CommunicationMedia already extends UML::Connector.

  • Reported: MARTE 1.0b2 — Mon, 18 Aug 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Modifications should be done to delete this redundancy (see next proposition of revised text).

  • Updated: Sat, 7 Mar 2015 21:28 GMT

typos in section E.3.2

  • Key: MARTE_-5
  • Legacy Issue Number: 12588
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    Typo issues: the links to pages are not good for example: defaultlink is not defined in page 414 (as mentionned) but in page 475 (figure E3). it is the same for all definitions (distribute, inter -repetition ...) in this annexe, please check all pages refered in the text

  • Reported: MARTE 1.0b2 — Fri, 25 Jul 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Check all cross references. This editing work has to be done after no page
    number can change or all the cross references have to be made active (preferred
    solution).

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Missing illustration for "Shape" and "reshape" stereotype

  • Key: MARTE_-4
  • Legacy Issue Number: 12585
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    Missing illustration for "Shape" and "reshape" stereotype Need clarification inside the "Shape" and "Reshape" definition explanation

  • Reported: MARTE 1.0b2 — Wed, 23 Jul 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    Add an example of these two stereotypes in action at the end of the chapter.

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE Beta: 12.3.2.4 FlowBFeature issue # 2

  • Key: MARTE_-3
  • Legacy Issue Number: 12579
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    why is it called a “FlowBFeature” at all – what does it have to with Flows?

  • Reported: MARTE 1.0b2 — Thu, 17 Jul 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 11820 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

MARTE Beta: 12.3.2.4 FlowBFeature issue # 1

  • Key: MARTE_-2
  • Legacy Issue Number: 12578
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    the description says: “A FlowBFeature specifies the nature of a BehavioralFeature” and it lists BehavioralFeature in the Extensions section, yet in figure 12.6 it is shown extending Property

  • Reported: MARTE 1.0b2 — Thu, 17 Jul 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    See issue 11820 for disposition

  • Updated: Sat, 7 Mar 2015 21:28 GMT

Annex 3

  • Key: MARTE_-1
  • Legacy Issue Number: 12577
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    This annex is not complete. It needs to be finalized and updated according to the EAST-ADL2 language

  • Reported: MARTE 1.0b2 — Thu, 17 Jul 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0
  • Disposition Summary:

    This resolution provides a revised text that completes Annex 3.

  • Updated: Sat, 7 Mar 2015 21:28 GMT