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

UML Profile for MARTE FTF — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
MARTE-187 TimedElements::TimedObservation (fig. 9.18) does not exist MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-186 Section: 13.3.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-185 first sentence of sub-section 6.4.2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-184 Base unit errors in Figure D.3 MARTE 1.0b1 MARTE 1.0b2 Duplicate or Merged closed
MARTE-183 SendFlowAction and FlowSendAction MARTE 1.0b1 MARTE 1.0b2 Duplicate or Merged closed
MARTE-182 Movement of some stereotypes and attributes from PA to GA MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-181 MARTE PAM Parameters for behaviour demanded by a Step MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-98 MARTE-AADL Issue 5 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-94 Section: Annex A: AADL-like models with MARTE MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-93 description of the Clock stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-97 MARTE-AADL Issue 4 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-96 MARTE-AADL Issue 3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-95 Section: Annex A: AADL-like models with MARTE -- issue 2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-92 Enhance the concept of Observer in GQAM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-91 How to model the size of code occupied in ROM? MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-100 MARTE-AADL Issue 7 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-99 MARTE-AADL Issue 6 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-107 Add short rationale in section 10.3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-106 Explanation in section 7.3 hard to read MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-105 In section 2.4.2, the list of extension units and table 7.2 are redundant MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-104 Table 2.1, I would suggest using the profile names MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-103 Table 2.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-102 Explain 'business management perspective" MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-101 MARTE-AADL Issue 8 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-128 Support for Views or sets of profile annotations MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-127 Missing Delay and Offset in SAM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-130 page 271, Fig.15.7 and in Annex D, page 437, Fig.D.5 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-129 Consistency between RTEMoCC, SAM, and SRM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-133 Missing attribute in figure MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-132 attribute “resMult” of Resource appears under its old name MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-131 use of stereotype names in UML model examples is inconsistent MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-138 RTF stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-137 Incorrect cross-reference to Figure numbers MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-126 HRM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-125 HRM::HwMemory MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-134 Typos: MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-136 Incorrect cross-reference to chapter number on Page 309, third paragraph MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-135 Unfinished sentence on Page 313, the sixth paragraph MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-124 HRM::HwMemory stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-86 the GCM chapter should define a causality model for flows MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-75 Giving an attribute a variable name and an expression value MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-74 ports in GCM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-85 What are semantics of real-time features on provided/required interfaces? MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-84 chapter 11 (GCM) should be moved in the Part II of the specification MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-83 Find a better name of the RTEMoCC profile MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-82 RTEConnector should be removed from RTEMoCC MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-81 Figure E.10 (p 468): MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-90 How to model the size the heap size of an Ada runtime with SRM? MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-89 HwMedia.bandwidth attribute may need to be generalized in GRM ancestor clas MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-79 Tiler stereotype (pp 465,466 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-78 Shaped stereotype (pp 464,465): MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-88 How to model the amount of memory occupied by an OS resource MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-87 Support for flows in activities MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-77 Reshape stereotype (pp 463,464) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-76 Figure E.6 (p 460) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-80 E.4 Examples (pp 467,468): MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-159 Section: Annex A3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-158 TimingObserver in GQAM should be renamed to TimedObserver MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-161 Specify a maximum number of period for periodic real-time constraints MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-160 MARTE-GQAM) Kinds of delay in a Step MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-155 MARTE name prefixes MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-167 Clock stereotype needs to extend UML::Property MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-166 BFeatureSpecification constraint MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-164 Type NFP_Weight does not exist MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-163 ConstraintKind not documented MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-169 MARTE needs naming conventions for stereotype names and tag values. MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-168 Clarify the nature of DRM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-157 no link between GRM::SchedulableResource and SRM::SwSchedulableResource MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-156 Section: 11.3.2.7 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-162 Dispatch protocols MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-165 "proreq" / "reqpro" literals do not exist in Beta 1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-70 SAM: General MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-69 GRM, GQAM, SAM: DomainModel & Profile MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-71 NFP: value syntax MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-73 Section: 1 MARTE spelling missing in the introduction MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-72 Section: HRM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-140 Section: 8.3.3.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-139 stereotype attribute "GaExecHost.throughput" that is not documented MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-142 Section Allocation: Wrong direction of the allocation MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-141 using $ in naming variables MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-146 Rename every instance of "SaEnd2EndFlow" to "SaEndToEndFlow". MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-145 expressing requirements MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-144 TimingResource of GRM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-143 Section: 15.3 and 17.3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-147 Correct the inconsistency between the diagram and the text MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-154 Section: Annex B (VSL) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-153 page 288: change explanation MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-149 picture 11.8, ports "loc" and "ftp" MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-148 page 64 ClockConstraintSpecification MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-152 Section 16.2.2 (SAM) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-151 GQAM-SAM cyclic dependency due to GQAM::WorkloadBehavior MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-150 VSL variable declaration (inconsistency between the BNF and the metamodel) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-171 GQAM Domain view inheritances MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-170 GQAM Observers: inconsistency between domain view and UML representation MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-173 TimedDomain stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-172 wrong multiplicity in sharedResources required for a SaStep MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-178 figure 10.18 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-177 Inconsistencies in GQAM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-180 Section: Annex D.2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-179 Errors in definition of GaEventTrace and GaWorkloadEvent MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-175 wrong numbering of figures MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-174 OCL rules for the Clock stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-176 The tiler stereotype should be applied on the UML::Port metaclass MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-123 Annex B: how VSL constructs shall be typed and evaluated MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-122 In Annex D, I would suggest make unit names (e.g. bits, bytes) singular MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-111 improve the usability of the RtBehavior stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-110 RtAction.isAtomic MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-109 Names should be identical MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-108 concept of refinement MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-117 VSL MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-119 GRM::SchedulableResource should have a period property MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-118 allocatedTo and allocatedFrom properties should not be derived MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-116 NFP does not introduce the concept of dimension MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-115 In section 6.1, I would suggest mentioning RTCORBA and CCM MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-121 MARTE primitive types MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-120 Relationship between Alloc::Allocation and SRM::EntryPoint MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-113 suggest removing the notion of feature in the conformance section MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-112 For the sake of consistency, the rtf stereotype should be renamed MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-114 Section 6: Remove the MSWord comment MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-63 [GQAM: General] MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-62 HRM: Examples MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-61 MoCC: Examples MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-60 [Alloc: Profile MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-59 GRM: Examples MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-58 GRM: Domain Model MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-65 GQAM: Domain Model & Profile (02) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-64 GQAM: Domain Model & Profile (01) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-68 [SAM: Profile] MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-67 GQAM: Domain Model & Profile (04) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-66 GQAM: Domain Model & Profile (03) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-57 [Time] Fig. 9.29 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-56 [NFP: Profile]. Fig 8.4 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-55 Section: NFP MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-54 Consider providing a tabular notation (as in SysML) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-50 HwTiming model of the HwLogical profile MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-49 Section: 14.2 add two stereotypes corresponding to HwSensor and HwActuator MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-45 Section: 11.3.1 figure 11.6 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-44 Section: 11.3.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-53 In 12.4, all references to figures are wrong MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-52 Editorial issue MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-51 Suggest to extend ClockConstraints to ClockTypes MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-48 Section: 14.2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-47 Section: 11.4.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-46 Section: 11.3.2.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-43 Section: 11.3.2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-37 Minor edits to MARTE Chapter 17 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-36 Section: Annex B.2.4 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-42 Section: 11.2.1 (data reception) MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-41 Section: 11.2.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-29 Class descriptions are missing MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-33 Section: 15.3.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-32 Section: 15/3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-8 Section: GRM / 10.3.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-7 concept of "resource" MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-20 grammar defined for conditional expressions MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-19 Annex D MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-23 Annex B VSL BNF MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-22 VSL meta-model MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-5 Section: Annex B3.3.3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-4 MARTE_Library::MeasurementUnits model library MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-10 rtf stereotype MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-9 Section: GRM / 10.3.1 - p 96 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-2 Consider adding a new attribute to «boundedSubtype» MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-1 UML Profile for MARTE acronym list MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-3 Naming conventions and typing errors MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-6 Section: Annex B3.3.3 p 397 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-17 Section 6/6.3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-16 Section 6/6/2/1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-11 Annex D3 MARTE model library for time MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-25 non-terminal symbol MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-24 The VSL grammar does not define the "( )" symbol MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-26 automotive example MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-13 Figure 14.70 - HwCommunication package details MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-12 the property named "isSynchronous" is misspelled MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-18 Section 6/6.4 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-35 Section: Annex B MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-34 Section: 14.2.3 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-31 Section: 14/2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-30 Class descriptions are missing in the MARTE model library for GRM (Annex D4 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-40 Section: 11.2.1 figure 11.4 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-39 Section: 11.2.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-27 GRM::SchedulableResource should not have a property "host:ExecutionHost" MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-28 no explicit dependency to QVT concepts MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-21 Wrong references in page 397 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-15 Section 2/2.2 MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-14 The type NFP_Price does not exist in the document. MARTE 1.0b1 MARTE 1.0b2 Resolved closed
MARTE-38 Section: 11.2.1 MARTE 1.0b1 MARTE 1.0b2 Resolved closed

Issues Descriptions

TimedElements::TimedObservation (fig. 9.18) does not exist

  • Key: MARTE-187
  • Legacy Issue Number: 12238
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Yann Tanguy)
  • Summary:

    TimedElements::TimedObservation (fig. 9.18) does not exist, the correct element is Time::TimeRelatedEntities::TimedObservations::TimedObservation

  • Reported: MARTE 1.0b1 — Tue, 19 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Substitution done.

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

Section: 13.3.1

  • Key: MARTE-186
  • Legacy Issue Number: 12221
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    Figure 13.12 needs to be updated to show all properties owned by the <<RtAction>> in order to complete the diagram according to the definition of the stereotype itself.

  • Reported: MARTE 1.0b1 — Thu, 14 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The mentioned attributes of <<RTAction>> are missing in Figure 13.11 (and not
    13.12. This resolution proposes to fix Figure 13.11 with the right RtAction
    attributes, according to the Stereotype description.

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

first sentence of sub-section 6.4.2

  • Key: MARTE-185
  • Legacy Issue Number: 11530
  • Status: closed  
  • Source: UFRGS - DELET ( WILSON PARDI JUNIOR)
  • Summary:

    The first sentence of sub-section 6.4.2 says: "Each extensions proposed by MARTE have been conflated around one main concerns and detailed in separate chapters: chapter 7 to chapter 18 and Annex E." I wonder if you mean "...chapter 7 to chapter 17 and Annex F." since there isn't a chapter 18, and Annex F is cited on the next paragraph.

  • Reported: MARTE 1.0b1 — Thu, 4 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Yes, the text should refer to chapter 7 to chapter 17 and Annex F. see next proposed resolution.

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

Base unit errors in Figure D.3

  • Key: MARTE-184
  • Legacy Issue Number: 12408
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Base unit errors in Figure D.3 The base unit for "KHz", "MHz", "GHz" and "rpm" is "W" while it is expected to be "Hz". The base unit for "mm" is "bits" while it is expected to be "m". The base unit for "um2" is "bits" while it is expected to be "mm2".

  • Reported: MARTE 1.0b1 — Thu, 24 Apr 2008 04:00 GMT
  • Disposition: Duplicate or Merged — MARTE 1.0b2
  • Disposition Summary:

    This issue is a duplicate of issue #11338.

  • Updated: Fri, 6 Mar 2015 22:56 GMT

SendFlowAction and FlowSendAction

  • Key: MARTE-183
  • Legacy Issue Number: 12401
  • Status: closed  
  • Source: European Software Institute ( Josetxo Vicedo)
  • Summary:

    Two different terms, SendFlowAction and FlowSendAction, are being used for describing the invocation action related to send a data flow to connected components. Example: see figure 11.5 and 11.6 on pages 120 and 121

  • Reported: MARTE 1.0b1 — Fri, 18 Apr 2008 04:00 GMT
  • Disposition: Duplicate or Merged — MARTE 1.0b2
  • Disposition Summary:

    duplicate of issue # 11664, closed issue

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Movement of some stereotypes and attributes from PA to GA

  • Key: MARTE-182
  • Legacy Issue Number: 11811
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    Some stereotypes were introduced in PA because they were identified by these authors as being useful... but they might be equally useful to someone in other analyses.

    An example is the <<noSync>> stereotype on a branch of a par, to say explicitly that this branch does not synchronize at the end of the par. This provides forks that do not join... a performance optimization in some cases.

  • Reported: MARTE 1.0b1 — Sun, 9 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 22:56 GMT

MARTE PAM Parameters for behaviour demanded by a Step

  • Key: MARTE-181
  • Legacy Issue Number: 11810
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    A PaStep can make a demand for a behaviour, much like a macro, to be included in the Step. An example of the use of this, is to include a complex handshake protocol for exchanging a message between objects on different nodes.

    The profile has

    behaviourDemands: list of Scenarios to be included
    behaviourCount: corresponding list of number of invocations during the step

    It also should support parameters to the Scenario, such as the message size. This requires a way of binding a value in the invocation to a value in the Scenario.

    Possible resolution:

    Add behaviorParm : a corresponding list of tuples. Each element of a tuple could be expressed as (variable=value), with the variable name corresponding to the variable used in the Scenario

    More complex and powerful resolution: Let the context variables decdlared for a Scenario be implicitly regarded as an ordered list of arguments, when the Scenario is invoked. The tuple could then give just the values for the list. A NUL value could be used to mean, do not override the value given within the Scenario.

    The same considerations apply to PAM::externalOpDemands. A similar concern applies to GQAM::servDemands, but the resolution may have to be different as Operations already have arguments and the defining scenario is attached indirectly.

    A broader version of this issue is parameterizing behaviours in general: it seems to be incomplete in MARTE.

  • Reported: MARTE 1.0b1 — Sun, 9 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 22:56 GMT

MARTE-AADL Issue 5

  • Key: MARTE-98
  • Legacy Issue Number: 11852
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The representation of AADL properties with UML Notes, does not provide the AADL capabilities of the Properties language. Annotations in notes are not formal, as users use a free-text zone without any constraints for the annotated elements, and syntax checking. Furthermore, most of the AADL Properties defined in the Predeclared Property Set annex (AADL spec.) are already existing in MARTE stereotype attributes. The more appropriate way is to use these attributes to model AADL properties. However, additional problems rise from this approach: a) Not all the AADL properties exist in MARTE. b) Some enumeration types existing in MARTE do not contain the options supported by AADL. c) Stereotype attributes are not always annotated in the same model elements (according to the mapping MARTE-AADL at the conceptual level). This aspect can be solved in at least two ways: 1) We add the required stereotype attributes in the MARTE spec. 2) New stereotypes are created in this annex only to support AADL. While the first option could not be in the scope of MARTE (we cannot align MARTE to all other language in the domain!), the second one requires to follow a set of formal rules to create the new stereotypes (naming, extended UML metaclasses, etc.) A third option is to create stereotypes for all the AADL concepts, but inheriting from MARTE concepts. An optimal solution should be evaluated with regard to criteria such as: tool reusability, automation of model transformations, timelines, etc. The third option goes along with the question of having an explicit profile for AADL, with AADL stereo type (or at least AADL profile label for MARTE stereo types that are identical to AADL). Do we need to introduce a new stereo type just because we have to add some properties to a MARTE stereo type? AADL allows users to introduce new properties through property sets. In MARTE terminology, users can introduce new stereo types that carry properties specific to an analysis framework. Those we need to be able to associate with the base concepts of describing an embedded architecture (what we call core language). What would be a good approach and guidance for doing so? In that sense there are two issues: 1) describe what mechanisms are available to allow users to extend the base modelling language of AADL/MARTE – in essence meta modelling capabilities). In AADL we have an explicit textual representation in addition to extending the meta model of AADL, while in MARTE it is solely done through meta modelling. 2) capture specific sets of standardized (and not yet standardized sets of properties).

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

    According to the implicit MARTE modeling process where modeling and analysis features are modeled by distinct features in separate diagrams, most (80%) of the AADL pre declared properties found their equivalent in MARTE. The complementary part will be explicitly modeled by the end user using the "Nfp" concept. The following table presents the mapping between the AADL pre-declared property set and their equivalent in MARTE.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex A: AADL-like models with MARTE

  • Key: MARTE-94
  • Legacy Issue Number: 11848
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    INTRODUCTION (to the following eigth issues) The section “AADL-like models with MARTE” in annex A: “Guidance example for use of MARTE” contains a mapping of UML concepts and stereotypes from MARTE and SysML to AADL metaclasses. The mapping is, in principle, a partial subset that was specified under the following considerations: 1. A UML native concept is used when it is considered expressive enough to represent an AADL concept (e.g., AADL Modes maps to UML State Machines). 2. Else, a MARTE concept is adopted (e.g., MARTE hwBus & hwDevice represents AADL Bus and Device). 3. If neither UML nor MARTE extensions have the corresponding AADL concept, SysML extensions are used (e.g., SysML Block represents AADL System). 4. Otherwise, new stereotypes are proposed in this annex (e.g., subprogram & port-group stereotypes to represents the corresponding AADL concepts). 5. Properties defined in the Predeclared Property Set of the AADL spec. are annotated in a UML Note stereotyped as “properties”. This section also provides some examples illustrating the use of UML (+MARTE+SysML) in order to specify AADL models. Some issues rise from this approach: [MARTE-AADL Issue 1] One general question is the scope of this annex. Either it will keep its “guidance” nature, providing a subset of mapping cases only, or it will provide a more formal mapping covering all AADL concepts and properties. Following a meeting with Peter Feiler (a core AADL author), the goal is to provide a full UML profile for AADL. If the approach turns towards the second option (full support), a more careful exploration of AADL concepts should be done. This means that this annex should guarantee that all the AADL metaclasses are mapped and that, at least, the predeclared AADL property set is supported. The SAE AADL committee supports a full UML profile of AADL. The committee would prefer to have it defined in the context of MARTE rather than a separate UML profile. A draft of a UML profile for AADL exclusively defined in terms of UML exists. This document can be harvested for the MARTE-based profile definition for AADL, e.g., for stereo type names and graphical symbol definitions

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

    In agreement with Peter Feiler from the SAE, MARTE will provide a full support to the AADL language, meaning that all AADL concepts and properties will be supported by MARTE. Annex A provides "guidelines" explaining and illustrating the use of MARTE for modeling and analysis of AADL applications.
    AADL-MARTE Concept alignment will be addressed by this issue; AADL pre-declared property set alignment will be addressed by issue #11582 and property language alignment with issue #11583.
    A proposed way of using MARTE with different abstraction levels is proposed in issue #11851, differencing design, software platform allocation, and hardware platform allocation phases and concepts. In addition to these refinement processes, analysis views providing specific and reusable analysis information are provided.
    The following table proposes a mapping between AADL and MARTE concepts, without introducing new MARTE concepts (stereotypes) in the annex.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

description of the Clock stereotype

  • Key: MARTE-93
  • Legacy Issue Number: 11847
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In the description of the Clock stereotype, UML::InstanceSpecification should appear as an extension and not a generalization

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    In the proposed way

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE-AADL Issue 4

  • Key: MARTE-97
  • Legacy Issue Number: 11851
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    MARTE is a profile with multiple abstraction levels. For instance, the concept of “Schedulable Resource” appears in the GRM as a high-level abstraction concept (SchedulableResource stereotype), in SRM as an RTOS API specific concept (swSchedulableResource stereotype). Also, some concepts used in GRM are refined with new attributes in the analysis chapters. The choice of MARTE stereotypes to model AADL concepts should be formalized with a set of rules, specifyingwhen to use GRM, SRM, GQAM, SAM stereotypes. This is not an easy task! This also depends on the required AADL Properties to attach in models. Managing the set of properties is indeed not easy. In AADL we have the property set mechanism through which we can introduce new properties that can be associated with existing AADL concepts. As such they enhance the semantics of those concepts and may introduce new concepts. For example, at the SEI we have defined a set of security related properties and associated them with components (system, process, thread, …), ports, and connections. In doing so we represent security related concepts of subjects, object, roles. To us these properties act as annotations to the base architecture model, and their mapping into a analysis-specific model (meta model for security models) understands the mapping of core AADL concepts into analysis-domain concepts. In some cases the existing core architecture concepts are not sufficient; then new concepts can be introduced through the annex mechanism. For example, the error model annex allows users to introduce additional concepts such as “error events” (faults), which exist as separate entities and are associated with core AADL entities. They themselves can have properties as defined through property sets. MARTE, by doing the same in the context of a meta model, e.g., through GQAM, SAM etc., have an explicit way of identifying these analysis specific concepts by name. At the same time when I have an architecture model and want to associate specific analysis interests, I would have to identify the collection of stereo types, some representing the base architecture model, and some the analysis specific abstractions and annotations to bee attached. When I look at the predeclared properties in the AADL standard, they deal with more than one analysis area. We are attempting to subcategorize them. If you have good insight on how to do some of this better, we are looking for input on doing this better on the AADL side as well.

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

    See issue 11850 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE-AADL Issue 3

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

    [MARTE-AADL Issue 3] The set of new stereotypes provided in the AADL annex of MARTE (e.g., port group, subprogram, data type) seems to show that MARTE (and UML) does not support some AADL concepts. However: a) AADL Subprogram clearly maps to an UML Operation. More refined Operations can be modelled by “Requested Service” (GQAM chapter, p.263). b) AADL Data concept clearly maps to MARTE MutualExclusionResource (GRM chapter) or SharedResource (SAM chapter). The latter includes additional stereotype attributes useful for schedulability analysis. It may be a combination of both. This brings up the question of what the overlap and difference is between MutualExclusionResource and SharedResource. One represents the mechanism to achieve mutual exclusion, while the second is the entity that may require mutual exclusion in the context of concurrent access.

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

    Summary table, most component and associated features representation and property
    table have been upgraded and aligned: a) on MARTE issues for ports, b) data
    representation, c) data and bus access representations, d) new reference on flow and
    mode sections. Non MARTE stereotypes have been removed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex A: AADL-like models with MARTE -- issue 2

  • Key: MARTE-95
  • Legacy Issue Number: 11849
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    The use of UML native concepts for some of the AADL constructs should be revised from a pragmatic viewpoint. For instance: a) The use of pure state machines to model AADL operational modes is sometimes insufficient. In the examples provided in MARTE (p.376; ptc/07-08-04), the relationship between a system configuration (modelled by a Collaboration) and a State specifying a Mode, is reflected by the “Name”. I.e., there is no an explicit association between both. It seems that providing a “Mode” stereotype in MARTE, with an appropriate relationship with other modelling elements could be very useful. This would facilitate model extraction/transformation when different kinds of state machines exist in a UML model. The relation between The AADL concepts of “mode transition” and “mode transition trigger” and UML state machines elements should be clarified. b) AADL Flows and EndToEndFlows are modelled by UML Activity diagrams. However, there is already the EndToEndFlow concept in MARTE (SAM chapter), which encloses the same semantics, and furthermore, provides a set of attributes (stereotype properties) that match with the AADL ones (e.g., end-to-end deadline, end to end time). The use of MARTE EndToEndFlows should be evaluated

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

    see ptc/2009-05-12 pages 89 - 94

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Enhance the concept of Observer in GQAM

  • Key: MARTE-92
  • Legacy Issue Number: 11846
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: Enhance the concept of Observer in GQAM. Details: The concept of observer is definitely useful although limited to timing and latency. There should be a way to support (at least) throughput and capacity observers. Maybe a more generic mechanism would be useful here?

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    After significant discussion it was agreed in a telecon that the existing stereotype has the desired generality. The necessary extensions should be applied to the existing observer by users, as they need them, rather than trying to define something that will satisfy all needs. All that is needed is to describe this process of extension, and to rename the TimingObserver to TimedObserver, signifying an observation over an interval of time.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How to model the size of code occupied in ROM?

  • Key: MARTE-91
  • Legacy Issue Number: 11844
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    How to model the size of code occupied in ROM? There seems to be a missing concept here.

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE-AADL Issue 7

  • Key: MARTE-100
  • Legacy Issue Number: 11854
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    Examples provided in the AADL annex of MARTE should be enriched: a) An example on how to model the AADL dispatch protocol with MARTE is missing. b) An example on how to model AADL flows with MARTE is missing c) An example on how to model AADL event-data port with queues and data ports without queues with MARTE is missing. If we go with doing a “real” profile for AADL, then we should probably have two part to that annex, one is the specification of the stereo types making up the AADL concepts (incl. their AADL labels and graphical symbol representation in addition to the UML-based box representation), the second a modelling guide to illustrate the use (like the examples mentioned above). We (the SEI) could work with you on additional examples to show.

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

    a) An example on how to model the AADL dispatch protocol with MARTE
    is missing.
    Two ways of representing dispatch protocol are possible, depending on
    the abstraction layer and end-user choice.
    A first representation allows mixing application elements and
    resources by attaching a Dispatch protocol attribute and applying the
    stereotype "SwSchedulableResource". For instance, a new property (named
    "dispatch_type") and stereotyped "rtf" can be created in the user model
    view. This dispatch property covers the different AADL dispatch
    protocols: periodic, sporadic, aperiodic, timed, hybrid, background.
    A second representation is to define a model library for AADL threads.
    One class can be defined for each dispatch protocol and the classes are
    used to type parts of a structured classifier. Subprograms can then be
    represented as actions within an Activity and are allocated to the
    parts of the structured classifier, which represent the software
    execution platform.
    b) An example on how to model AADL flows with MARTE is missing
    Flow path in component declaration and implementation have been
    modified. A Flow specification declaration indicates that information
    logically flows from one of the incoming ports, parameters, or port
    groups of a component to one of its outgoing ports, parameters, or port
    group flows.
    Component implementations must provide a flow implementation for each
    flow specification. A flow implementation declaration identifies the flow through its subcomponents. Flow sinks and flow sources are
    implicit, and deduced from flow path implementations. Flow path on
    parameters will not be processed in this version.
    Flow specifications are represented by "UML InformationFlows", which
    represents an abstraction of the communication of an information item
    from its sources to its targets.
    End to end flows are represented by interactions or activities.
    c) An example on how to model AADL event-data port with queues and
    data ports without queues with MARTE is missing
    Resolved in issue 11850, with data, event and data-event port
    semantic clarification and in end-to-end flow definition
    (activity diagram representation)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE-AADL Issue 6

  • Key: MARTE-99
  • Legacy Issue Number: 11853
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    MARTE provides a language for expressions (VSL), including mathematical, logical, and time expressions. AADL also provides the ability to specify expressions. A detailed mapping should be provided in order to transform VSL expressions into AADL expressions. AADL is more limited in terms of expressions. We tried to not grow the property expressions into a full constraint language but offer the constraint language through the annex mechanism (construct). In this case we may define an AADL annex that covers the constraint expression capabilities of VSL in MARTE. Also in MARTE properties carry meta information about the property values as attributes. At this time in AADL we do not support a general attribute mechanism on properties (properties on properties – although it turns out the meta model of AADL has that in). Here we need to make some decisions on the AADL side. Input on what we should do better on the AADL side is welcome

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

    AADL expression language and VSL language are not based on the same
    construction mechanism. These language alignments implies de definition of new
    features on the AADL side, action is not a priority at the moment in the AADL
    communauty.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add short rationale in section 10.3

  • Key: MARTE-107
  • Legacy Issue Number: 11862
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In introduction of section 10.3, a short rationale should be given to explain which meta-classes are extended (in relation with section 7.3 on classifiers and instances).

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

    Add a paragraph after the one in the introduction of section 10.3 explaining the application of the rule in section 7.3 to the extended metaclasses.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Explanation in section 7.3 hard to read

  • Key: MARTE-106
  • Legacy Issue Number: 11861
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Section 7.3 is very important to understand how to use of MARTE stereotypes in the following chapter. However, the explanation given here is hard to read. I would suggest rephrasing this specific paragraph.

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

    Rephrase the paragraph conveniently.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In section 2.4.2, the list of extension units and table 7.2 are redundant

  • Key: MARTE-105
  • Legacy Issue Number: 11860
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In section 2.4.2, the list of extension units and the table 7.2 are redundant. I would suggest removing the list of extension units

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

    I agree on the redundancy, but I propose to keep the table instead of the text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 2.1, I would suggest using the profile names

  • Key: MARTE-104
  • Legacy Issue Number: 11859
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In Table 2.1, I would suggest using the profile names (e.g. Alloc)in the acronym column instead of defining new ones (e.g. ALM). That would may facilitate reading the document.

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

    Agree on the suggestion, see proposed resolution

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Table 2.1

  • Key: MARTE-103
  • Legacy Issue Number: 11858
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In Table 2.1, I would suggest sorting the extensions units according to the table of content of this document.

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

    Agree on the suggestion, see proposed resolution

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Explain 'business management perspective"

  • Key: MARTE-102
  • Legacy Issue Number: 11857
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    I would suggest explaining what is the "business management perspective".

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

    Strike the phrase "Business Management Perspective" Change it by "system perspective"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE-AADL Issue 8

  • Key: MARTE-101
  • Legacy Issue Number: 11855
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    Modeling the AADL dequeue protocol AllItems seems impossible with UML (and therefore MARTE) because the selection of a behavior on an object node in UML takes only one token at once making it impossible to dequeue/read all the tokens from a queue. The OneItem, AllItems and in V2 also MultipleItems values try to abstractly specify three types of queue processing. It defines what happens to the queue content in terms of making it available to the application and having removed from system buffers. OneItem indicates that one element is removed from the system queue of the port. AllItems means all are removed. MultipleItems means that a detailed behaviour model describes (via the NextValue method how (many) are removed from the system queue.

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

    Disposition: See issue 11854 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Support for Views or sets of profile annotations

  • Key: MARTE-128
  • Legacy Issue Number: 11883
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    Schedulability analysis models are built for each real-time situation of interest, and due to the number of different modes of operation of the system or to the number of different worst case equivalent models used to analyze those situations for which there would be no analitical techniques available, the amount of SA models to be annotated over the same UML base model is significant. The profile mechanism in UML provides a way to apply and de-apply a profile to a UML model, but it does not allow to have different colections or groups of stereotype instances (annotations) in a common frame so that they can be store and retrive in the repository, treated as views or "profile applications" of the same profile. In the case of SAM this will be done with the purpose of having different RT Situations, but the same will be valid for a large number of modelling purposes: the phase in the development process, level of detail, different analysis tool or technique to use, or just to assist the modelling processing paradigm. This may be solved in an ad-hoc manner by tools, but a standard (hence interchangable among tools) mechanism is desireble. The NFP types in MARTE may include an additional tag (property) to tie them together, but this tagging should be extensible to any stereotype

  • Reported: MARTE 1.0b1 — Sat, 22 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This issue is duplicated of Issue 11764. Both propose a mechanism to annotate
    multiple value annotations for different situations in a model.
    Disposition: Duplicated

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing Delay and Offset in SAM

  • Key: MARTE-127
  • Legacy Issue Number: 11882
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    The name-definition of the attribute DelayTime leads to confusion, but if it remains, the profile require a mechanism to express the voluntary relinquish of the CPU during a time. This is what is normally called a delay, this is implemented with primitives like sleep, clock_nanosleep in POSIX, mdelay in linux, delay in ADA, etc. The usage of constraints/observers in this case is not desirable, since these are analysis models not specifications, and contraints will be used for verification against analysis results. A special kind of step that includes offsets and delays is suggested fdor inclusion, even at GQAM level.

  • Reported: MARTE 1.0b1 — Sat, 22 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Be explicit and conformant with existing practice: replace the attribute SaStep::delayTime with three new attributes, SaStep::nonpreemptionBlocking, SaStep::selfSuspensionBlocking, and SaStep::numberSelfSuspensions.
    If an additional specialization of GaStep is needed-and arguably it is-then that SHALL be addressed in a new and separate issue allocated to GQAM.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 271, Fig.15.7 and in Annex D, page 437, Fig.D.5

  • Key: MARTE-130
  • Legacy Issue Number: 11885
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:

    a) Inconsistent definition of dataType ArrivalPattern as follows:

    • on page 263, Fig.15.3 and on page 288, Fig.16.3 the definition contains 7 values (the last two are “open” and “close”)
    • on page 271, Fig.15.7 and in Annex D, page 437, Fig.D.5, the same definition contains only 6 values ("open" is missing and should be added).
      Example of use of different arrival patterns: “open” in Fig.17.17 and “closed” in 17.22.
  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    There was a mistake in Figures 15.7 (GQAM) and Fig. D.5 (Annex D). The OpenPattern was not included in the list of Arrival Patterns. These two figures will be corrected.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consistency between RTEMoCC, SAM, and SRM

  • Key: MARTE-129
  • Legacy Issue Number: 11884
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    As a complement to the explanation of the semantics of RTUnit and PPUnit in RTEMoCC it would be very useful to have a mapping to its corresponding SAM models, and if possible also to its platform independent implementation using SRM, this may be added in an annex specifically dedicated to semantic consistency among these chapters in MARTE.

  • Reported: MARTE 1.0b1 — Sat, 22 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This aspect is definitively out of the scope of the MARTE specification. It
    concerns methodological definitions. Since these model elements represent
    different levels of abstraction (HLAM, SAM, RSM), their mapping is complex and
    can derive in several choices.
    This could be covered by a further work providing some guidelines to help
    methodologists in defining their specific mappings, according to different models
    of computation, development phases, etc. However, this is out of the scope of
    MARTE standard document.
    We propose to close this issue with no change.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing attribute in figure

  • Key: MARTE-133
  • Legacy Issue Number: 11888
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:

    d) Missing attribute in figure. On Page 333, the second paragraph says:
    “The cycleInit Action has a hostDemand. Since it is not shown in a swimlane, its process (SchedulableResource) is given directly on the Step stereotype by the attribute "concur" (which determines its deployment and thus its host processor).”
    However, Fig 17.17 to which this text refers does not show any attribute “concur”.

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

    Add the attribute, which is called concurRes not concur.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

attribute “resMult” of Resource appears under its old name

  • Key: MARTE-132
  • Legacy Issue Number: 11887
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:

    The attribute “resMult” (resource multiplicity) of Resource appears under its old name “maxRI” in the following figures: 17.14, 17.16, 17.17, 17.24

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

    Replace the name in the affected Figures.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

use of stereotype names in UML model examples is inconsistent

  • Key: MARTE-131
  • Legacy Issue Number: 11886
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:

    b) The first letter of a stereotype applied to a UML model element should be lower-case or upper-case (e.g., <<gaScenario>> or <<GaScenario>>) ? The use of stereotype names in UML model examples is inconsistent in different chapters: starting with lower-case in chapters 8, 9, 11, 12, 13, 14, 16, etc. and with upper case in chapters 10 (Figures 10.20 to 10.22), 17.

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

    By convention, when a stereotype is applied to a model element, the first letter of the stereotype name must be lower-case. In the examples mentioned in the summary of the issue, the first letter of stereotype names must be set to lower-case.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RTF stereotype

  • Key: MARTE-138
  • Legacy Issue Number: 12185
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The RTF stereotype should also extend the Behavior Meta-class

  • Reported: MARTE 1.0b1 — Wed, 16 Jan 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect cross-reference to Figure numbers

  • Key: MARTE-137
  • Legacy Issue Number: 11892
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:
    • Page 325: “In Figure 17.8, the blockingTime ...” - should refer to Figure 17.9.
    • Page 326 the first paragraph: “In Figure 17.9 a simple sequence is annotated”- should refer to Figure 17.10
    • P331 “Figure 17.15 and Figure 17.16” - should refer to figures 17.16 and 17.17”
  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

HRM

  • Key: MARTE-126
  • Legacy Issue Number: 11881
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In HRM, it misses some explanation on how to model mono-port and multi-port memories.

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

    For modeling such construction, we do not think it requires additional concepts within
    MARTE::HRM. It can be solve using a composite structure with two ports, an in flow port and one
    out flow port for example and modeling a specifying behavior describing the user purpose. So we
    decided to close with no change this issue.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

HRM::HwMemory

  • Key: MARTE-125
  • Legacy Issue Number: 11880
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In HRM::HwMemory, I would suggest adding a throughput attribute (typed by a NFP_DataTxRate) to specificy the notion of throughput in a memory.

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

    A throughput:NFP_DataTxRate attribute is added to the HwMemory, in both domain view and uml representation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos:

  • Key: MARTE-134
  • Legacy Issue Number: 11889
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:
    • Page 265, the first paragraph: “between the two between”
    • Page 280, the second line from the bottom: “sorrespond”
    • Page 311, the first paragraph: “ypical performance”
    • Page 315, in the middle: “PProcesses”
    • Page 325, in the middle: “avalilable”
  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Corrections are described in the revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect cross-reference to chapter number on Page 309, third paragraph

  • Key: MARTE-136
  • Legacy Issue Number: 11891
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:

    g) Incorrect cross-reference to chapter number on Page 309, third paragraph:
    “The performance domain employs and extends the Generic Quantitative Analysis Modeling (GQAM) domain of Chapter 17.”
    GQAM is in chapter 15.

  • Reported: MARTE 1.0b1 — Fri, 21 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary: {Replace 17 by 15}
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unfinished sentence on Page 313, the sixth paragraph

  • Key: MARTE-135
  • Legacy Issue Number: 11890
  • Status: closed  
  • Source: Carleton University ( Dorina Petriu)
  • Summary:

    “Within a scenario these are lumped together as”

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

    Remove the partial sentence.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

HRM::HwMemory stereotype

  • Key: MARTE-124
  • Legacy Issue Number: 11879
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In the HRM::HwMemory stereotype, I would suggest removing the Timing datatype and directly pushing the attributes in the HwMemory stereotype, for the sake of usability

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

    cf. resolution of issue 11521.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

the GCM chapter should define a causality model for flows

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

    Subject: the GCM chapter should define a causality model for flows. Details: the GCM chapter introduces the notion of flow port as a structural feature of a structured class. However, the specification does not states what happens when a flow comes into / get out of a flow port. There should be a reference to behaviors owned by this structured class. Proposed resolution: enhance the GCM chapter.

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This issue concerns the semantics of FlowPorts and indeed its underlying causality model.
    Indeed, the issue 11840 is also clearly related to this issue. Issue 11840 summary is following:
    “Subject: Support for flows in activities. Details: The current specification provides a limited
    support for flow in activity diagrams. The GCM chapter introduces the FlowSendAction
    stereotype. However, there is no way to indicate the pins used to define the data to send. At the
    same time, there is no action (such as FlowReceiveAction) to indicate how to receive a flow. It
    seems that activity parameters are an interesing alternative to specify incoming and outgoing
    flows in activity diagrams (SysML follows this approach). Proposed resolution: Remove the
    FlowSendAction stereotype and provide a support for BOTH incoming and outgoing flows through
    activity parameters (maybe a stereotype would need to be defined here).” Both issues are treated
    in this document."
    As stated by Conrad Bock in [Conrad Bock: “UML 2 Activity and Action Models Part 4: Object
    Nodes”, Journal of Object Technology, vol.3, no.1, pp.27-41], there are traditionally two ways for
    considering dataflow communications:

    • a “pull” semantics with the following characteristics:
      o Passive: the arrival of data in the data store does not trigger behaviors per se. It
      is indeed additional actions, for example time-triggered actions, that when
      needed pull the data from the data store. o Non-depleting: the use of data in the store does not remove it from the store
    • a “push” form of data flow and storage, with the following characteristics:
      o Active: the arrival of data in the data store triggers execution of some behavior.
      o Depleting: the data arriving on the port is not store locally. Data is indeed
      conveyed to the triggered behavior.
      The objective of this resolution is to enable GCM's users to address both forms of data flow. For
      that purpose, we are making the following proposal:
    • Data sending:
      o The «SendFlowAction» stereotype is removed (NOTE: in this case, one resolves
      in the same time the issue 12286. This latter was then set to Duplicate/Merged
      and refer this resolution). Indeed, the standard UML SendObjectAction is already
      well suited to express a data emission. The execution of a SendObjectAction
      results in the emission of a message encapsulating the sent object (which can be
      an instance of any classifier). Note that, SendObjectAction inherits from
      InvocationAction and as defined in the composite structure package, this action
      already enables to specify a target port for the action (see, UML2 spec., section
      9.3.9 on p. 182).
      o In addition to specify the flowProperty on which a SendObjectAction is applied (or
      more generally to specify the feature of a non-atomic FlowPort or
      ClientServerPort on which an InvocationAction is applied), one introduces the
      «GCMInvocationAction» stereotype which extends InvocationAction (from
      InvocationActions). In this case, the stereotyped invocation action targets a nonatomic
      flow FlowPort or a featureBased ClientServerPort (i.e. a ClientServerPort
      which have been specified using a ClientServerSpecification. Cf resolution 11820
      for a precise definition of these concepts), and one of its features. For example, if
      a non-atomic output flowport has two flow properties (i.e. it is typed by a
      FlowSpecification with two out flow properties), the ‘onPort’ property of
      SendObjectAction enables to specify that this flow port is used as a target of the
      send. In addition, the ‘onFeature’ property of «GCMInvocationAction» enables to
      specify which of the two flow properties the target of the send is.
    • Data reception events: Once we have dealt with data sending, it is also required to be able to deal with
      data receipt. For that purpose, we introduce the «DataEvent» stereotype. This
      latter extends the UML's AnyReceiveEvent metaclass. This metaclass is the
      most generic kind of concrete MessageEvent. DataEvents are raised when data
      (which have been sent as a consequence of a SendObjectAction) are received
      on a behavioral FlowPort. In the case of a non-behavioral FlowPort, data are
      propagated along associated delegation connectors, and no event is raised at all
      (just as for standard UML Ports). DataEvents raised as a consequence of data
      receptions on behavioral ports are then stored in the event pool of the owning
      object just like any other kind of UML events would be. It implies that the UML
      semantic variation points related to event management also applies to
      «DataEvent» (and typically concerning the way events are ordered in and
      extracted from the event pool). This is however fully in line with the philosophy of
      the GCM which aims to be as generic as possible. Particular semantic
      interpretation on the way DataEvent are dispatched and consumed would thus
      require a specialization of the GCM, such as the one proposed in the HLAM subprofile
      of MARTE. The definition of «DataEvent» mimics the definition of the UML
      SignalEvent metaclass, in the sense that it is possible to attach a classifier to the
      event in order to characterize it (just as it is possible to attach a Signal to a
      SignalEvent). More precisely, the classifier that can be attached to the event
      must be a classifier that can be used to type flow ports or flow properties (i.e.,
      DataType and Class). In order to avoid confusion with SignalEvent, a constraint
      imposes that the classifier associated with the DataEvent cannot be a Signal.
      DataEvents can then be exploited by triggers of transitions within a
      StateMachine, or by triggers of AcceptEventActions within an Activity. Hence, it is
      possible to specify reactions to reception of data of a particular type (i.e., data
      which are typed by a classifier compatible with the classifier associated with the
      DataEvent). Note that such triggers can natively be related to particular ports i.e.,
      the ports from which the DataEvent have been raised.
      o UML Triggers can natively be related to a particular port. Additionally, in MARTE,
      we introduce the possibility to specify more precisely the origin of a trigger. The
      «GCMTrigger» stereotype is defined for that purpose. It extends the UML Trigger
      metaclass and it owns a property that enables to specify which feature of the
      FlowSpecification of a FlowPort or ClientServerSpecification of a
      ClientServerPort (cf. resolution 11820 for details on ClientServerPort) is the
      origin of the trigger. It is thus possible to specify reactions that are, for example,
      related to the occurrence of a given DataEvent on a non-atomic FlowPort, and for a particular FlowProperty. Of course this advanced mechanism is mainly
      interesting for non-atomic port, because in other cases, there are no possible
      ambiguities.
      The concepts denoted below were defined to support the “push” semantic of MARTE's ports
      (including flow and client-server ports), and they are well aligned with the standard event model.
      The “active” characteristic of the «push» semantics is covered because the reception of a data on
      a behavioral FlowPort raises a DataEvent, which can be used as a trigger in a behavior. The
      “depleting” characteristics of the "push" semantics is covered because, according to the standard
      UML semantics, once an event has been consumed by a behavior, it is no longer available in the
      event pool to trigger other behaviors.
      Concerning the “pull” semantics of MARTE's FlowPorts, no particular extensions are required. A
      simple modeling pattern (suggested by SysML and Conrad Bock’s article, respectively for the
      usage of delegation connectors and the usage of properties for persistent data storage and nondepleting
      data use) is indeed sufficient as explained next.
      According to the UML 2 superstructure, a non-behavioral port should have delegation connectors,
      so that incoming requests can be propagated along these connectors to parts of the composite
      structure owning the port (in other case as said previously and as it is defined in the UML2
      specification, messages are lost). Then there are two possibilities for the parts connected to the
      ports: either they delegate also the requests to some of their parts, or they deal directly with the
      request triggering the execution of one of their behaviors. This case fits also with the MARTE's
      client-server port and it is thus reasonable to have a similar mechanism for MARTE's flow ports.
      At the end of the delegation chain, a non-behavioral input atomic flow port should have at least
      one delegation connector targeting a part which is type-compatible with the port (if there is no
      delegation connector, the data is simply lost). When a data is received on such a port and then
      delegated through the connector, no DataEvent is raised (which is in line with the “passive”
      aspect of the “pull” form of data flow). In this case, the semantics says that the data is written in
      the part targeted by the delegation connector, replacing any existing value. The data stored on
      the targeted properti can then be used when needed by the behavior of the component, typically
      via a ReadStructuralFeatureAction (which has no depleting effect on the value of the property).
      For more complex storage policies, we propose to introduce the « DataPool » stereotype. Two
      default storage and selection policies are defined: LIFO and FIFO. « DataPool » can also be
      associated with user-defined policies, via its ‘insertion’ and ‘selection’ properties. These
      properties explicitly reference UML Behaviors, respectively describing how a data is to be
      inserted in the property, and how a set of data is to be selected from the property. When a data is
      received on a FlowPort with a delegation connector targeting a property stereotyped with
      «DataPool», the semantics says that the data is inserted in the pool following the description provided by ‘insertion’ behavior (Concerning the usage of the ‘selection’ behavior, see the
      following description concerning the usage of connectors between properties and behavior
      parameters).
      This rule can be extended for non-atomic flow ports, where each flow property should be
      associated with a delegation connector (by convention, when one of the flow properties is not
      associated with a delegation connector, the FlowPort should be behavioral, and data received on
      this FlowPort and related to this FlowProperty will raise a DataEvent).
      Finally, issue 11840 proposes the possibility of an explicit “binding” between flow ports of a
      component and parameters of the component behaviors. This additional proposition is an
      alternative solution to the mechanisms described below. Moreover, let's notice that SysML is
      relying on this mechanism, but SysML is lacking two points: firstly, SysML does not define indeed
      clearly how that works (i.e., either by name matching between ports and parameters, or
      (probably) by using a BindingConnector), and secondly SysML does define also it’s the clear
      meaning of this mechanism. Hence, we provide next a clear semantics for this mechanism
      aligned (i.e., compatible) with the “pull” and “push” semantics we have considered until now:
    • “pull” semantics: A standard UML connector is expressed between a property (which
      used to be the target of a delegation connector, but does not need to be) of the
      component and an IN or INOUT parameter of a behavior or operation (which would
      typically belong to the owner of the port, but does not need to be). It means that the
      values passed to the parameters of the behavior (or operation) when the behavior is
      called are actually the values of the connected properties. The connectors just prevent
      from the usage of an explicit ReadStructuralFeatureAction to get the value associated
      with the properties. Note that this usage of connectors is compatible with the abstract
      syntax of UML, since both Property and Parameter are ConnectableElements. In the
      case where the connected property is stereotyped with « DataPool », its ‘selection’
      Behavior is used to compute the values to be selected (from the property) and to be
      passed to the parameter.
    • “push” semantics: Connectors are directly expressed between input non-behavioral flow
      ports (respectively the output flow ports) and input parameters (respectively the output
      flow ports) of the classifierBehavior Activity of the composite structure owning the ports.
      The idea is that each incoming data received on a flow port will be propagated to a
      parameter of the classifier behavior. The data associated with the input message will be
      handled as a token on an ActivityParameterNode corresponding to the parameter. The
      token will then enter the chain of computation described by the set of object flows and
      actions of the activity (with respect to the token propagation semantics of UML activities). At the end of the computation chain, tokens will be propagated to
      ActivityParameterNodes corresponding to output parameters of the Activity. If a
      delegation connector is modeled between such a parameter and an output flow port of
      the composite structure, a message containing the produced data will be emitted through
      the flow port (just as if SendObjectAction with this value would have been applied on the
      flow port). The standard semantics of UML activities implies that tokens related to
      required input parameters must be available for the called activity to start, and that token
      corresponding to output parameters will be made available on corresponding output pins
      once the activity is finished. Note that if one wants the activity modeling the classifierbehavior
      to be able to accept inputs (on its input parameters) and produce outputs (on its
      output parameters) while it is executing, input and output parameters of the activity
      should typically be specified as streaming parameters. Examples are provided in the
      revised text.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Giving an attribute a variable name and an expression value

  • Key: MARTE-75
  • Legacy Issue Number: 11822
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    I am not clear of the status of this, but it seems that to use the profile flexibly one needs to be able to assign a variable name to an NFP, and also a value. Then the variable name can be used to change the value in studies, in a traceable way. The value can be an expression too.

    A possible resolution would be to allow expressions to read as variable = expression.

  • Reported: MARTE 1.0b1 — Wed, 19 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Resolution:

    This is already supported by VSL: A 'variable declaration' expression can have assigned an "initialExpression". Concretely, the following syntax has been adopted in VSL (page 402):

    <variable-declaration> ::= <variable-direction> '$' <variable-name> [<type-name>] ['=' <init-expression>]

    This means that you can have NFP values such as (extended notation):

    myLatency = (value= 5.0, expr= $var1=var2+var3/3, unit=ms) or the short notation:
    myLatency = (5.0, $var1=var2+var3/3, ms)

    Hence, this issue is close with no change.

    Revised Text:
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ports in GCM

  • Key: MARTE-74
  • Legacy Issue Number: 11820
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    This issue is about ports in GCM. In UML if a port is typed with an interface, this interface is automatically considered as provided by the port (see port description section 9.3.11 in UML Superstructure). In GCM it is possible to type a MessagePort with an interface (BFeatureSpecification). Moreover if a MessagePort direction is specified to be "required", and if the port is typed with a BFeatureSpecification interface, this interface contents are considered to be provided by the port according to UML. This results in a confusing specification: a MessagePort specifying a required interface provides that interface at the same time.

  • Reported: MARTE 1.0b1 — Wed, 19 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Using message ports may create redundancy and inconsistency with the UML composite
    structures, as mentioned in the summary of this issue. Indeed, BFeatureSpecification can own
    FlowBFeatures, where some of the features may have their ‘’kind’’ set to ‘’provided’’, and some
    others set to ‘’required’’. According to UML interface derivation rules, this may lead to ambiguous
    cases where a BFeatureSpecifcation (used to type a message port) is considered to be provided
    by the port, even if some of the behavioral features of the BFeatureSpecification actually
    represent ‘’required’’ features. A similar problem appears when a message port, with direction set
    to Required, is typed by an interface (i.e. the default rule in UML is that this interface is supposed
    to be provided by the port). [Note: More generally, the issue described here also concerns
    non-atomic flow ports, i.e. flow ports that are typed by a FlowSpecification. According to
    UML interface derivation rule, the FlowSpecification used to type the port would also be
    considered as a provided interface.].
    The proposed resolution for issue 11820 is designed according to the following guidelines:
    • it provides a mechanism for specifying provided and required interfaces of standard UML
    ports, in a way that is more intuitive and direct that the standard UML mechanism (which
    relies on derivation rules based on the port type, and which is particularly tedious for defining
    interfaces required by a port. Indeed, it technically implies to define a Classifier with a « use » relationship that targets the set of Interfaces to be required). It was indeed the original
    motivation for the ClientServerPort stereotype.
    • it should avoid conflicts with default UML rules concerning interface derivation, based on port
    type.
    The general idea behind the proposal is that ClientServerPorts can be used in different ways. The
    current solution explicitly identifies two usages (c.f. definition of /isAtomic = true or false) whereas
    in the resolution we identify three potential usages according to designer intent:
    • atomic usage: the designer wants to directly associate a signal with the port (i.e. the port is
    typed by the signal), specifying that the component owning the port is either able to send (i.e.
    ClientServerPort::kind = required) or receive (i.e. ClientServerPort::kind = provided) the signal
    via this port.
    • interface-based usage: the designer wants to directly provide and/or require standard UML
    interfaces on a port.
    • feature-based usage: the designer wants to associate a ClientServerSpecificaion (i.e. a
    consistent set of behavioral features, some of which may be provided or required) with the
    port.
    Additionally, issues 12802 (difference UML Port and MessagePorts) and 12801 (semantic
    difference between an atomic FlowPort typed by a signal and a MessagePort typed by a signal)
    have been stated as duplicate/merge with this issue. We provide a resolution for these issues in
    the revised text of the GCM chapter, described in this document. For issue 12802: Some text is
    added to explain that ClientServerPort (formerly MessagePort) is just a kind of syntactic sugar for
    UML Ports. Concerning issue 12801: we explain that FlowPorts and ClientServerPorts are almost
    semantically equivalent when signals are used to characterize their potential interactions (i.e.
    atomic FlowPort typed by a signal S, atomic ClientServerPort typed a signal S, or non-atomic
    ClientServerPort exposing a Reception for a signal S).
    Additionally, issue 12579 (that has been stated as duplicate/merge with this issue) concerns the
    renaming of elements (i.e. FlowBFeature) that are involved in the definition of MessagePort itself.
    We start this ‘’merged resolution’’ with the resolution of issue 12579.
    The primary reason of this name was to have a name constructed in a similar way than to the one
    of the FlowPorperty but dedicated to BehavioralFeature. I (Me, Sébastien Gérard, the original
    author of that concept) agree that this name is may be not the best one…
    Moreover as similar concepts exist in AUTOSAR, a very important standard for automotive
    domain and with which it is expected that MARTE will have strong relationships in near future, I
    propose to do following renamings:
    • FlowBFeature => ClientServerBFeature • BFeatureSpecification => ClientServerSpecification
    • MessagePort => ClientServerPort
    PS: I propose not only to rename FlowBFeature, but also the other concepts related to
    MessagePort, for global consistency of the specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What are semantics of real-time features on provided/required interfaces?

  • Key: MARTE-85
  • Legacy Issue Number: 11838
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:
  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This resolution proposes general clarifications on the usage of the stereotype
    «RtFeature» (including its usage and underlying semantics in the context of
    provided/required interfaces).
    The stereotype «RtFeature» can be applied to multiple elements Additionnaly, issue 12954 also requires some clarifications. These clarifications
    require modifications to figures that are modified in this resolution. We therefore
    propose to resolve problems identified in issue 12954 in this document, and we
    state resolution to issue 12954 as duplicate/merge with this resolution 11838.
    More specifically, issue 12954 has identified the following problems: 1- In figure
    3.10 the stereotype <<RtFeature>> is displayed as <<Rtf>>. : In the proposed
    modification of figure 3.10, this inconsistency is removed. 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. : In the proposed resolution,
    «RtFeature» does not apply anymore to behavior. 3- Figure 3.11 does not show
    all the attributes of the «RtAction» stereotype. The new version of figure 3.11
    proposed in this resolution includes all the attributes. 4- The use of the
    stereotype «RtBehavior» is not clear. An example in 13.4 would be of great help.
    This stereotype has been deleted. Its attributes are indeed only characterizations
    of the event pool of an active object. Its attributes have been added to
    «RtFeature», and prefixed with ‘sr’ (for Schedulable Resource).
    (InvocationAction, BehavioralFeature, Message, Signal). In order to clarify to
    meaning of these multiple extensions, some text is added in the section
    describing the stereotype «RtFeature» to explain that: the most basic element on
    which «RtFeature» can be applied is InvocationAction, and that any other places
    where this stereotype is applied enables to specify a kind of default value in the
    case where the stereotype «RtFeature» has not been applied on a particular
    InvocationAction.
    Additionnaly, the title of this issue suggests that real-time features could be
    contextual to the usage of interfaces (for example, one may want to specify that a
    real-time feature concerns an operation of an interface that is provided on a
    given port). Therefore, we propose the following modifications:
    The stereotype «RtFeature» is modified so that it now also extends the Port
    metaclass. The stereotype «RtSpecification» is introduced, and it extends the
    Comment metaclass.
    All the attributes of «RtFeature» are removed from «RtFeature», and they are
    added to «RtSpecification».
    An «RtFeature» can now own multiple «RtSpecification», and it is possible to
    specify the behavioral feature that is concerned by this «RtSpecification». For
    example, a port can be stereotyped with «RtFeature». It can then own multiple
    «RtSpecification», where each of these «RtSpecification» may concern a
    behavioral feature of a provided or required interface of this port.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

chapter 11 (GCM) should be moved in the Part II of the specification

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

    Subject: chapter 11 (GCM) should be moved in the Part II of the specification. Details: The argument to push GCM in Part I of MARTE was that it was used BOTH for modeling and analysis. After having read the whole document, I do not see any dependency from the GQAM to GCM therefore I suggest pushing back GCM in Part II of MARTE (the design part) to make the MARTE foundations thiner. Proposed resolution: move chapter 11 in Part II and update the chapter number accordingly.

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed according to the proposed resolution.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Find a better name of the RTEMoCC profile

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

    Subject: Find a better name of the RTEMoCC profile. This acronym is long and does not sound pretty fancy. I would suggest looking for a better alternative.

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Replace RTEMoCC with "High-level Application Modeling" and use the acronym of "HLAM"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RTEConnector should be removed from RTEMoCC

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

    Subject: RTEConnector should be removed from RTEMoCC The chapter 13 defines a model of computation for active objects and passive objects. It precisely defines the metaclasses involved in this model of computation, building upon the MARTE foundation packages (e.g. GRM). Additionally, chapter 13 introduces the concept of RteConnector, which is basically a specialization of a UML connector with additional NFP. While the definition of active/passive object provide useful features for RTES design. The concept of real-time connector is more discutable. This concept overlaps with GRM::CommunicationMedia. It seems that all that relates to NFP characterics of a communications between entities should be defined in GRM::CommunicationMedia (latency, jitter, bandwith) As a beneficial side effect, removing RTEConnector whould remove the depdendency from RTEMoCC to GCM, which is not usued anywhere else. Proposed resolution: remove RTEConnector metaclass and stereotype and push the related attributes (bandwith, blockT, packetT, transMode) into GRM (e.g., in CommunicationMedia).

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Remove RTEMoCC::RteConnector and refactor GRM::CommunicationsMedia to gain the attributes of the deleted RteConnector, and update the elements that use similar attributes in the rest of the spec so that they become consistent, that is at least in HwMedia.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure E.10 (p 468):

  • Key: MARTE-81
  • Legacy Issue Number: 11834
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    the fitting of the toTiler should be 0,0.

  • Reported: MARTE 1.0b1 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Change the fitting as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How to model the size the heap size of an Ada runtime with SRM?

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

    How to model the size the heap size of an Ada runtime with SRM?

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    An attribute must be added to the MARTE::SRM::SW_Concurrency::swConcurrentResource.
    heapSizeElements: UML::Kernel::Classes::TypedElement [0..*]

  • Updated: Fri, 6 Mar 2015 20:58 GMT

HwMedia.bandwidth attribute may need to be generalized in GRM ancestor clas

  • Key: MARTE-89
  • Legacy Issue Number: 11842
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: HwMedia.bandwidth attribute may need to be generalized in a GRM ancestor class. Details: According to another issue, the RTEConnector.bandwidth attribute could be pushed from RTEMoCC::RTEConnector to GRM. If so, it would make sense to factorize the HwMedia.bandwith with a common ancestor (the concept of "bandwith" being SW/HW agnostic). Proposed resolution: remove the bandwidth attribute from HwMedia and push it into a GRM ancestor class.

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The proposed resolution shall be followed and inserted in the resolution of issue 11835.

    The bandwidth attribute should be removed from HwMedia and placed in CommunicationMedia in GRM with a more general explanation. This solution unfortunately may impact terminology in future GQAM variations, where different names are used for the same concepts. Now the conflict is not present since there is not direct inheritance. Considering that issue 11835 is in the same ballot all changes should be consistently indicated to vote for them in that issue. Hence this is now in the scope of Issue 11835.

    Revised Text:
    See issue 11835, where explanation of attribute GRM:: CommunicationMedia should include a text like :

    bandwidth: NFP_DataTxRate [0..1]
    the capacity of the communication element when applicable

    Disposition: Duplicated

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tiler stereotype (pp 465,466

  • Key: MARTE-79
  • Legacy Issue Number: 11832
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    a default value should be specified for the various attributes as it is done for the TilerSpecification data type; the type of the tiler attribute should be TilerSpecification

  • Reported: MARTE 1.0b1 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Add various default values in the descriptions of the stereotypes as in the TilerSpecification and modify the type of the tiler attribute to TilerSpecification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Shaped stereotype (pp 464,465):

  • Key: MARTE-78
  • Legacy Issue Number: 11831
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    a notation to refer to a particular element of a shaped collection by index should be added. Proposal: use ElementName[index].

  • Reported: MARTE 1.0b1 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proposal: use ElementName[index].

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How to model the amount of memory occupied by an OS resource

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

    Subject: How to model the amount of memory occupied by an OS resource (eg. File, buffer, blackboard, ARINC ports). Details: We would need to know the memory used by OS objects (buffer, sem, blackboard…). This maybe needs further discussion but why not introducing a memorySizeElements attribute on SwResource? It might be also applicable on a GRM::Resource ?

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Support for flows in activities

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

    Subject: Support for flows in activities. Details: The current specification provides a limited support for flow in activity diagrams. The GCM chapter introduces the FlowSendAction stereotype. However, there is no way to indicate the pins used to define the data to send. At the same time, there is no action (such as FlowReceiveAction) to indicate how to receive a flow. It seems that activity parameters are an interesing alternative to specify incoming and outgoing flows in activity diagrams (SysML follows this approach). Proposed resolution: Remove the FlowSendAction stereotype and provide a support for BOTH incoming and outgoing flows through activity parameters (maybe a stereotype would need to be defined here).

  • Reported: MARTE 1.0b1 — Thu, 20 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    See issue 11839 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reshape stereotype (pp 463,464)

  • Key: MARTE-77
  • Legacy Issue Number: 11830
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    the default topology of a link connecting two shaped elements should be specified. Proposal: use a direct element-wise topology when the shapes of both ends are identical, undefined otherwise

  • Reported: MARTE 1.0b1 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proposal: use a direct element-wise topology when the shapes of both ends are identical, undefined otherwise.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure E.6 (p 460)

  • Key: MARTE-76
  • Legacy Issue Number: 11829
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    the two composition links from the Reshape stereotype to the Tiler Stereotype should be removed

  • Reported: MARTE 1.0b1 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Replace figure E.6 by removing the two composition links from Reshape to Tiler.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

E.4 Examples (pp 467,468):

  • Key: MARTE-80
  • Legacy Issue Number: 11833
  • Status: closed  
  • Source: INRIA ( Pierre Boulet)
  • Summary:

    put square brackets around the shapes on the diagrams

  • Reported: MARTE 1.0b1 — Mon, 17 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Correct all the diagrams of the examples to add the required brackets.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex A3

  • Key: MARTE-159
  • Legacy Issue Number: 12297
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    This section needs to be completed.

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

    See issue 12577 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimingObserver in GQAM should be renamed to TimedObserver

  • Key: MARTE-158
  • Legacy Issue Number: 12283
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    s discussed in the telecon today, the TimingObserver in GQAM should be renamed to TimedObserver, and the text should show that it can collect any measure, including time intyervals but also energy memory etc, over an interval bounded by two events.

    This is a separate issue from 11775 which suggests moving this concept to the Time chapter.

  • Reported: MARTE 1.0b1 — Tue, 18 Mar 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary: {The TimedObserver may be extended to return any statistical measure on any NFP over the interval from the startEvent to the EndEvent}
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specify a maximum number of period for periodic real-time constraints

  • Key: MARTE-161
  • Legacy Issue Number: 12402
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    It would be nice to be able to specify a maximum number of period for periodic real-time constraints. Proposed modification: add a property named max of type Integer (multiplicity 0..1) in PeriodicPattern tupleType on page 437.

  • Reported: MARTE 1.0b1 — Mon, 21 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Add a new parameter for the periodic arrival pattern indicating the number of occurrences. This parameter is optional: multiplicity 0..1. So, it doesn't need to be specified in the graphical view.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE-GQAM) Kinds of delay in a Step

  • Key: MARTE-160
  • Legacy Issue Number: 12371
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    Generated, based on extensive discussion, to deal with the issue raised in 11882, whose resolution is only for SAM.

    There are two kinds of delay in a step
    ... self-initiated delays like sleeping or thinking or some latency included in the step,
    ... blocked delay waiting for an event initiated by some other thread of behaviour

    The latter is represented by the domain concept Step.blockingTime, which is the profile property gaStep.blockT.

    The former is not represented. It should be added.

    Proposed resolution:

    1. In GQAM, add the domain property Step.selfDelayTime:NFP_Duration and the profile property gaStep.selfDelayT:NFP_Duration.

    Add text to the domain model to explain selfDelayTime

    Add the definition of selfDelayT to the UML representation.

    2. In PAM examples, many Steps have internal delay represented as a value of blockT, all of these should be changed to selfDelayT.

  • Reported: MARTE 1.0b1 — Tue, 1 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    1. In GQAM, add the domain property Step.selfDelay:NFP_Duration and the profile property gaStep.selfDelay:NFP_Duration.

    Add text to the domain model to explain selfDelayTime

    Add the definition of selfDelay to the UML representation.

    2. In PAM examples, many Steps have internal delay represented as a value of blockT, all of these should be changed to selfDelay.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE name prefixes

  • Key: MARTE-155
  • Legacy Issue Number: 12249
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    There is no consistent convention followed in the beta document for naming of stereotypes and their attributes, and this has been pointed out in other issues. Some chapters use a prefix for the chapter, such as Pa or pa for performance analysis, Grm or grm for General Resource Model, etc. MOst do not.

    From the point of view of precision, fully qualified names are sufficient, but from the point of view of usability, the prefixes are very helpful, especially as MARTE is such a big profile and realtime is a cross-cutting concern. THat is (unlike sysml) the profile does not redefine UML or restrict it to the domain of realtime, but adds realtime info to a functional design. MARTE may be used with other profiles, possibly several at once.

    The usability issues are to identify the realtime stereotypes and attributes, and also to avoid cluttering the namespace. A stereotype attribute may become a property of an object and its name might conflict with a functional property. Users might avoid MARTE just to avoid the risk of this happening.

    Issue: Consistency in prefixes is desirable, either all stereotypes with prefix, or none. Usability is affected. Realtime concerns are pervasive and crosscutting in software, so flooding of the namespace could be a problem, including conflict with other profiles and with functional property names.

    Proposed resolution:
    Apply two or three prefixes to all stereotypes and attributes:

    mm for MARTE Modeling
    ma for MARTE Analysis
    possibly mc for MARTE Core.

    Where a stereotype is specialized from another one, a third letter could be used.

    Alternative proposal:
    Apply prefixes only to the analysis chapters, because these are more likely to be used outside the embedded system domain (e.g. for enterprise system QoS) and thus to be used with other stereotypes. For instance to specify requirements on delay.

  • Reported: MARTE 1.0b1 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    In order to decide when we need to prefix the name of element, we propose to
    apply the following algorithm as much as possible:

    • When we define a stereotype which name may conflict with the UML2
      metaclass the stereotype is extending. In this case, we prefix with the
      name of the sub-profile wherein the stereotype is defined.
    • When we define a stereotype generalizing an already defined stereotype
      of MARTE. In this case, we should use the name of the profile wherein the
      stereotype is defined to prefix this latter.
    • Finally, we should not use "_" between the prefix and the name of the
      prefix. This rule should apply also for the name of the concepts of the
      domain model. However, there is an exception to this rule: we will not
      rename the predefined NFP type (the one define in the MARTE library
      such as NFP-Real) because they are used all along the specification and
      the change will need too much work w.r.t. to the global interest to do it.
      Let's note that, we consider that that as an editorial issue and we will not provide
      the complete revised text for the resolution because it would be too big. The
      editor of the specification (Sebastien Gerard) will do the required modifications
      directly in the specification when integrating all other resolutions voted within this
      FTF2
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clock stereotype needs to extend UML::Property

  • Key: MARTE-167
  • Legacy Issue Number: 12414
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The Clock stereotype would need to extend UML::Property along with UML::InstanceSpecification, in order to make use of clocks in composite structures and interactions. This way, the Time chapter would be compliant with the "instance/classifier" pattern defined for resources.

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

    Property is added as a base class for Clock

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BFeatureSpecification constraint

  • Key: MARTE-166
  • Legacy Issue Number: 12413
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In section 11.3.2.2, the constraint [1] is not applicate to BFeatureSpecification (it applies to FlowSpecification, defined in another section of the chapter). Proposed resolution: revise or delete the constraint.

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

    This issue actually refers to section 12.3.2.2 (11.3.2.2 refers to the numbering of an older
    version). This resolution does apply to FlowSpecification and not to ClientServerSpecification.
    The constraint has then to be moved. A new constraint is added ClientServerSpecification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type NFP_Weight does not exist

  • Key: MARTE-164
  • Legacy Issue Number: 12410
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    HwComponent stereotype has a property named "weight" typed by "NFP_Weight". The type NFP_Weight does not exist in the document.

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

    This NFP type was missing in the MARTE library.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ConstraintKind not documented

  • Key: MARTE-163
  • Legacy Issue Number: 12409
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The enumeration ConstraintKind defined in Figure 8.5 is not document in section 8.3.2

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

    The description of the Enumeration ConstraintKind is missing

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE needs naming conventions for stereotype names and tag values.

  • Key: MARTE-169
  • Legacy Issue Number: 12416
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    MARTE needs naming conventions for stereotype names and tag values. As discussed during the FTF meeting in DC, we need to define chapter-wide naming conventions for stereotype names and tag values. Consequently, we need to apply these conventions to the whole document.

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

    See issue 12249 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the nature of DRM

  • Key: MARTE-168
  • Legacy Issue Number: 12415
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    What is the nature of DRM in the MARTE specification? Details: There is no DRM profile in the description of the architecture of MARTE (Figure 6.4). On the other hand, looking at the first Figure (14.1) of Chapter 14, one can see a DRM package that includes the HRM and SRM packages. That may create confusion on the nature of DRM. We would need to clarify this at the begining of Chapter 14, or update Figure 14.1

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

    Delete the figure 14.1 and consequently modify the introduction of the chapter
    14. See revised text in the next section that intents to clarify this point.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

no link between GRM::SchedulableResource and SRM::SwSchedulableResource

  • Key: MARTE-157
  • Legacy Issue Number: 12282
  • Status: closed  
  • Source: THALES ( Eric Maes)
  • Summary:

    There is no link between GRM::SchedulableResource and SRM::SwSchedulableResource ! When modeling, much of SwSchedulableResource elements are also ScedulableResource elements and then, attributes such as host (GRM::SchedulableResource) and scheduler (SRM::SwSchedulableResource) are redundant. SRM::SwSchedulableResource should derive from GRM::SchedulableResource.

  • Reported: MARTE 1.0b1 — Mon, 17 Mar 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This is a duplicated issue, explained in Issue 11411.
    Revised Text:
    See resolution of Issues 11411, and 11856.
    Disposition: Duplicated

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.2.7

  • Key: MARTE-156
  • Legacy Issue Number: 12264
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    The stereotype FlowSendAction enable to define an action for sending a data via port. The given textual syntax defined for the label of the action does support that feature. However, the stereotype itself (for the abstract syntax point of view) does not have any property to model that point. Resolution => add an attribute to the stereotype: viaPort: Port [0..1]

  • Reported: MARTE 1.0b1 — Wed, 5 Mar 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Disposition: See issue 11839 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Dispatch protocols

  • Key: MARTE-162
  • Legacy Issue Number: 12404
  • Status: closed  
  • Source: THALES ( Madeleine Faugere)
  • Summary:

    Most common dispatch protocols can be modelized by the ArrivalPattern like (sporadic, aperiodcc,periodic, burst, irregular) ? The possibility to introduce other one is missing (exemple "Background).

  • Reported: MARTE 1.0b1 — Tue, 22 Apr 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    There is a misunderstanding here. “Background” is not an arrival pattern. The
    term background is related to task scheduling aspects. In MARTE, periodic
    server scheduling parameters are modeled with a set of parameters including
    background priority.
    In MARTE, we compiled all the arrival patterns used in real-time and embedded
    systems, including, periodic, aperiodic, sporadic, bursty, but also more general
    arrivals like irregular patterns for arbitrary distances between event occurrences,
    probability distributions, and other used in performance evaluation such as open
    and closed patterns. Additional patterns can be defined by extending the libraries
    of arrival patterns (Figure D.5)
    We propose to close this issue with no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"proreq" / "reqpro" literals do not exist in Beta 1

  • Key: MARTE-165
  • Legacy Issue Number: 12412
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    "proreq" / "reqpro" literals do not exist anymore in Beta 1. Details: The example in Figure 11.7 refers to a "reqpro" literal that does not exist anymore. In section 11.3.2.4, the constraint [3] refers to a "proreq" literal that does not exist anymore. Proposed resolution: remove references to these literals.

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

    See issue 11820 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

SAM: General

  • Key: MARTE-70
  • Legacy Issue Number: 11780
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    SAM: General] Time-triggered system modelling are supported in some way by the TimeTableDriven scheduling policy (fig 10-19). However, it is not clear how to specify a table (format) and where (e.g. Scheduler stereotype, schedule: OpaqueExpression attribute?). Some examples for time-triggered system modelling should be provided in MARTE.

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

    Schedulers of the other variants of SchedPolicyKind use configuration parameters which are expressed in the SchedulableResource::SchedParameters attributes. To be consistent, when modeling TimeTableDriven scheduling, the SchedParameters stereotype SHALL include a tag definition SchedParameters::tableEntry of type OpaqueExpression which SHALL store the information necessary to schedule the SchedulableResource according to the algorithm of the Scheduler's time-triggered, table-based scheduling.

    The algorithm of the time-triggered, table-based scheduler SHALL be expressed within the Scheduler::schedule's OpaqueExpression.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GRM, GQAM, SAM: DomainModel & Profile

  • Key: MARTE-69
  • Legacy Issue Number: 11779
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GRM, GQAM, SAM: DomainModel & Profile] A number of non-functional properties for scheduling analysis are specified by a worst-case and a best-case duration value. The MARTE library for NFP types defines a NFP_BoundedDuration data type. This type could be used to type ‘bounded’ durations in SAM. For instance: endToEndTime (fig. 16-7), execTime (fig. 10-18), latency (fig. 15-8), contextSwitchTime, ISRswithTime (fig. 16-9).

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

    This two attributes may be not sufficient, it is better to have all the statistical qualifiers over multiple values of NFP_Duration supported. To minimize editorial impact and a deep revision of side effects, the additional attributes provided in NFP_BoundedDuration will be added to NFP_Duration. With the variation that "min" will be represented as "best" and "max" as "worst", this keeps the dual dimension in the utilization of multiple values and the specification of variability in the context in which the value is used. This implies minimal changes to NFP_Duration, eliminating NFP_BoundedDuration, and change the only reference to it (in RealTimeFeature) to NFP_Duration.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NFP: value syntax

  • Key: MARTE-71
  • Legacy Issue Number: 11781
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [NFP: value syntax] It may be useful to have a shorter (graphical) notation for NFP types including the value and unit slots only, e.g., ‘(55, kHz)’, or still ’55 kHz’, instead of the notation ‘(55, -, kHz, max, -, est, -)’ with all the qualifiers. This will enhance the graphical models readability. While this feature may be only a tool-specific mechanism, which could propose a graphical view (short notation) of the repository notation (full notation), it would be useful to standardize this notation in the MARTE spec.

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

    We include this syntax (value-unit) only as a tool-specific feature to show NFP values in graphical models. This means that the syntax defined in VSL is still valid for NFP values (tuple notation). The reason is that the model repository needs to keep all the required NFP value information (value, unit, plus other qualifiers).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 1 MARTE spelling missing in the introduction

  • Key: MARTE-73
  • Legacy Issue Number: 11818
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    MARTE spelling missing in the introduction possible resolution: introduce the term MARTE in the introduction of the document MARTE: Modeling and Analysis of Real-Time and Embededd systems

  • Reported: MARTE 1.0b1 — Thu, 13 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Can be added as a subtitle on the cover page.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: HRM

  • Key: MARTE-72
  • Legacy Issue Number: 11817
  • Status: closed  
  • Source: THALES ( Laurent Rioux)
  • Summary:

    Some stereotype in the HRM profile do not have icons. And the icons proposed in the specification need to be improved to clarify the understanding of the model. possible solution: change icons on HRM and add icons on stereotype do not have yet

  • Reported: MARTE 1.0b1 — Thu, 13 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    I (Sébastien Gérard) have asked to the source of the issue what kind of
    improvement he was requiring or if he had some better proposition of
    iconographical representation, and he answered he had no proposals of
    improvement. I decided then without more feedback on graphical improvement to
    close with no change this issue.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.3.1

  • Key: MARTE-140
  • Legacy Issue Number: 12196
  • Status: closed  
  • Source: THALES ( Eric Maes)
  • Summary:

    Proposition to extend the probability distributions functions list with (used in AnyLogic) : - geometric (double p) The Geometric distribution is a discrete distribution bounded at 0 and unbounded on the high side. It is a special case of the Negative Binomial distribution. In particular, it is the direct discrete analog for the continuous Exponential distribution. The Geometric distribution has no history dependence, its probability at any value being independent of a shift along the axis. - laplace (double phi, double beta) The Laplace distribution, sometimes called the double exponential distribution, is an unbounded continuous distribution that has a very sharp central peak, located at theta. The distribution scales with phi. - chi squared (double nu, double min) The Chi Squared is a continuous distribution bounded on the lower side. Note that the Chi Squared distribution is a subset of the Gamma distribution with beta=2 and alpha=nµ/2. Like the Gamma distribution, it has three distinct regions. For nµ=2, the Chi Squared distribution reduces to the Exponential distribution, starting at a finite value at minimum x and decreasing monotonically thereafter. For nµ<2, the Chi Squared distribution tends to infinity at minimum x and decreases monotonically for increasing x. For nµ>2, the Chi Squared distribution is 0 at minimum x, peaks at a value that depends on nµ, decreasing monotonically thereafter. - rayleigh (double sigma) The Rayleigh distribution is a continuous distribution bounded on the lower side. It is a special case of the Weibull distribution with alpha =2 and beta/sqrt(2) =sigma. Because of the fixed shape parameter, the Rayleigh distribution does not change shape although it can be scaled. - weibull (double alpha, double beta, double min) The Weibull distribution is a continuous distribution bounded on the lower side. Because it provides one of the limiting distributions for extreme values, it is also referred to as the Frechet distribution and the Weibull-Gnedenko distribution. - logistic (double beta, double alpha) The Logistic distribution is an unbounded continuous distribution which is symmetrical about its mean [and shift parameter], alpha. The shape of the Logistic distribution is very much like the Normal distribution, except that the Logistic distribution has broader tails. - pareto (doubla alpha, double min) The Pareto distribution is a continuous distribution bounded on the lower side. It has a finite value at the minimum x and decreases monotonically for increasing x. A Pareto random variable is the exponential of an Exponential random variable, and possesses many of the same characteristics. - triangular (double min, double max, double mode) The Triangular distribution is often used when no or little data is available; it is rarely an accurate representation of a data set. However, it is employed as the functional form of regions for fuzzy logic due to its ease of use. - cauchy (doubla lambda, double theta) The Cauchy distribution is an unbounded continuous distribution that has a sharp central peak but significantly broad tails. The tails are much heavier than the tails of the Normal distribution. - beta (double p, double q, double min, double max) The Beta distribution is a continuous distribution that has both upper and lower finite bounds. Because many real situations can be bounded in this way, the Beta distribution can be used empirically to estimate the actual distribution before much data is available. Even when data is available, the Beta distribution should fit most data in a reasonable fashion, although it may not be the best fit. The Uniform distribution is a special case of the Beta distribution with p, q = 1. - lognormal (double mu, double sigma, double min) The Lognormal distribution is a continuous distribution bounded on the lower side. It is always 0 at minimum x, rising to a peak that depends on both mu and sigma, then decreasing monotonically for increasing x. - erlang (double beta, int m, double min) The Erlang distribution is a continuous distribution bounded on the lower side. It is a special case of the Gamma distribution where the parameter, m, is restricted to a positive integer. As such, the Erlang distribution has no region where F tends to infinity at the minimum value of x [m<1], but does have a special case at m=1, where it reduces to the Exponential distribution. - negativeBinomial (double p, double n) The Negative Binomial distribution is a discrete distribution bounded on the low side at 0 and unbounded on the high side. The Negative Binomial distribution reduces to the Geometric Distribution for k = 1. The Negative Binomial distribution gives the total number of trials, x, to get k events (failures...), each with the constant probability, p, of occurring. - logarithmic (double beta) The Logarithmic distribution is a discrete distribution bounded by [1,...]. Theta is related to the sample size and the mean. - hypergeometric (int ss, int dn, int ps) The Hypergeometric distribution is a discrete distribution bounded by [0,s]. It describes the number of defects, x, in a sample of size s from a population of size N which has m total defects. The ratio of m/N = p is sometimes used rather than m to describe the probability of a defect. Note that defects may be interpreted as successes, in which case x is the number of failures until (s-x) successes. The sample is taken without replacement.

  • Reported: MARTE 1.0b1 — Thu, 24 Jan 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We need to be sure that the new distributions functions are really necessary in
    MARTE. Note that we do not attempt in MARTE to define all the existing
    distribution functions but the required in common practice.
    After evaluating some performance analysis and simulation tools, we consider
    that the following one are highly decided, and propose to include them in the
    MARTE library. geometric (real p). The Geometric distribution is a discrete distribution
    bounded at 0 and unbounded on the high side.

    • triangular (real min, real max, real mode). The Triangular distribution is
      often used when no or little data is available; it is rarely an accurate
      representation of a data set.
    • logarithmic (real theta). The Logarithmic distribution is a discrete
      distribution bounded by [1,...]. Theta is related to the sample size and the
      mean.
      Further distribution functions can be added at library level.
      Issue Dependency Warning: Note that this issue affects Issue 12561, which
      clarifies the mechanism to specify probability distribution expressions. Issue
      12561 depends on this issue, but the reverse case is not true.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

stereotype attribute "GaExecHost.throughput" that is not documented

  • Key: MARTE-139
  • Legacy Issue Number: 12194
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In GQAM, the profile diagram (Figure 15.6) defines a stereotype attribute "GaExecHost.throughput" that is not documented in section 15.3.2 or introduced in the domain model (Figure 15.5)

  • Reported: MARTE 1.0b1 — Wed, 23 Jan 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Add to Domain model and document it. Add to Fig 15.5

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section Allocation: Wrong direction of the allocation

  • Key: MARTE-142
  • Legacy Issue Number: 12214
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    Wrong direction of the allocation: The MARTE allocation mechanism is directly inspired from SysML. SysML has chosen a convention contrary to UML and draws the arrow from the suppliers (usually a target) to the clients (usually a source). So as to be compatible MARTE has followed SysML with that convention. Now, the SysML RTF is considering that this triggers too many problems with tool vendors and thus considers using the same convention than UML. An alignment between SysML and MARTE is required as much as possible and MARTE FTF should then think through this issue and adopt the same convention than UML.

  • Reported: MARTE 1.0b1 — Thu, 7 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The only text that was wrong has been removed in the resolution for issue 11770. The new text in this resolution assumed that sources are referred as clients and targets are referred as suppliers.
    This resolution has no impact on any other section since the wrong "direction" was only in the vocabulary used (clients vs. suppliers) and the graphical notation was already correct.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

using $ in naming variables

  • Key: MARTE-141
  • Legacy Issue Number: 12209
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    This editing issue affects many chapters.

    In VSL sec B.3.3.12 p 402 the declaration of variables requires that $ precede the variable name. Thus the $ sign is not part of the variable name.

    Throughout the document there is inconsistent naming of variables where they are used in context, with and without the $ at the beginning.
    Examples are found in NFP (Fig 8.9) and many other chapters.

    These are not incorrect... a variable name may still begin with any character. However they give a confusing impression, and consistency within the doc might be an improvement.

    In reading examples, I have found it a great help to readability if names denoting quantities (variable names) DO have the $ sign. So I suggest that we use the $ sign on variable names in our examples

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

    There are two kinds of VSL expressions related to variables: 'variable declaration' and 'variable call'. In VSL, we use '$' as a prefix only in the declaration notation, and in the 'call' expression, we use only the name. We really need to make difference between both because VSL parsers need to distinguish them.

    a) Arguments to use 'let' as keyword in variable declarations:

    The use of '$' is not 'conventional' to declare variables. Other keywords like 'let [variable-name]' would be more appropriate. It is recommended to use 'let ' for variable declaration because having a keyword for declaration is the more natural choice in most of languages.

    b) Arguments to use '$' as part of the variable name in variable call expressions:

    The absence of the symbol '$' in variable call expressions ("variable use") would make hard to make the distinction with other 'names' in VSL expressions, such as enumeration literals or PropertyCallExpression. The goal of this symbol in the former SPT profile was to identify easily a variable within an expression. With the current notation, the latter is not possible.
    .
    c) Arguments against a modification of variable notation

    Some reasons would suggest avoiding such a modification:

    • VSL has an essential difference with other conventional languages: VSL is intended to be used in 'properties values', where compact annotations should be privileged. Also, its use in Constraints tries to mark a difference with OCL, and it's that annotations should be shorter and easier to understand. Having simple and short expressions is a main concern in VSL to embed them in graphical models without charging models, and for easy learning of the language.
    • The UML Time Observation notation works exactly like VSL variables. A symbol ('@' for time observation and '&' for duration observation) is used for declarations, and only the name (without the symbol) for expressions. Time observations could be considered as a sort of variables, but with a more specific semantics. So, having the notation of both VSL variables and Time Expression aligned is important for comprehensibility of Profile users.

    -In MARTE, most of VSL variable expressions are used at "declaration" level, because in a regular NFP tuple, the value resulting from the evaluation of an expression or variable is specified in a dedicated slot ("value"). This means that the variables will be easily identified in a model, because they will include the '$' symbol.

    • VariableCallExpressions are mainly used in Algebraic (math, logical, conditional) expressions, where having a transparent syntax in terms of "parameters" either coming from a UML Property or VSL Variable origin is desirable to avoid complexity in VSL expressions.

    d) Conclusions

    The argument for using 'let' is more to follow conventional languages, and not pragmatic concerns. Also, the argument that the current mechanism confuses comprehensibility between variable declaration and variable call expression is not sustainable. VSL variable notation works exactly as UML TimeObservation works, and there were not reported any issue related to confusing language users.

    For these reasons, we suggest to close this issue with no change.

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename every instance of "SaEnd2EndFlow" to "SaEndToEndFlow".

  • Key: MARTE-146
  • Legacy Issue Number: 12232
  • Status: closed  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    Rename every instance of "SaEnd2EndFlow" to "SaEndToEndFlow". While this issue is specific to the cited text, it SHOULD be applied throughout the specification whereever attributes are so named. The rationale for the change is that the substitution of numerals such as "1", "2", and "4" for the non-numeric concepts expressed by the truncated words "a", "to", and "for", respectively, lead to needless cognitive dissonance. CamelCase is acceptable but there is no longer any need for variable names which use substitutions and truncations to satisfy machine or language constraints.

  • Reported: MARTE 1.0b1 — Fri, 15 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with the suggested modification.
    The only place where a numeral is used as substitute of words is in the stereotype "SaEnd2EndFlow" and in two of their attributes.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

expressing requirements

  • Key: MARTE-145
  • Legacy Issue Number: 12231
  • Status: closed  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    When expressing requirements that implementations of the MARTE Profile MUST satisfy, the specification SHALL use Requirements Engineering statements which are de facto best current practices. For example, the phrase in the fourth paragraph, of 16.3.1, reads: BEGINQUOTE An "SaEnd2EndFlow" will make reference implicitly to one ore [sic] more GQAM "GaWorkloadEvent" and to one "GaScenario" commonly by means of a containment relationship (owned elements) or allocation stereotypes. ENDQUOTE This is expressing a Business (or Domain) Rule (as expressed in Figure 16.3) which implementations of the Profile must enforce. However, the sentence is too passive and is not sufficiently imperative to communicate this requirement. The recommendation is to replace such ambiguous and passive phrasing with the de facto standard SHOULD, MUST, SHALL phrasing now employed in RFCs and in Requirements Specifications. For example, replace the wording above with: BEGINQUOTE Every implementation of the MARTE Profile SHALL enforce that each 'SaEndToEndFlow' MUST refer to one or more GQAM_Workload::WorkloadEvent(s) and MUST refer to one and one only GQAM_Workload::BehaviorScenario. These references SHALL be achieved directly via Composition or indirectly via the <<allocation>> association. ENDQUOTE While this issue is written specifically for the cited text, the recommendation SHOULD be applied throughout the entire specification whereever the specification is expressing how the Profile MUST be implemented. There is no need for this formalism in the sections of the specification that provide rationale and explanation--that is, within the Domain Modeling sections. The rationales for this formalism are: it greatly reduces ambiguity, profiles are more than collections of individual decorations, domain rules "cut across" sets of domain elements, and a subset of tools extant can enforce such domain rules if those rules are known, expressed, and consistent.

  • Reported: MARTE 1.0b1 — Fri, 15 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimingResource of GRM

  • Key: MARTE-144
  • Legacy Issue Number: 12225
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    My concern is about the TimingResource of GRM. In the domain model (10.2.2, p.89-90 and figure 10.7), TimingResource both refers to a Clock (since it is a Resource) and specializes ChronometricClock. The specialization is not suitable since a TimingResource is not a clock (with the meaning given in the Time profile) but merely refers to a Clock. To make a TimingResource specific to chronometric clocks, it is largely sufficient to refine the association to a Clock by an association to a ChronometricClock. In the UML representation (Figure 10.15) and in 10.3.2.20 I would simply remove the specialization to ClockType. The reference to a Chronometric Clock (idealClock in this precise case) is already implicit by the use of the NFP_Duration type. If you really want to insist on the use of chronometric clock only, a comment in the text should do it.

  • Reported: MARTE 1.0b1 — Fri, 15 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We propose to remove the specialization from TimingResource to
    ChronometricClock in the domain view. In the UML representation, we remove
    the specialization from ClockType. This latter specialization is very problematic
    since Resource extends several metaclasses (Property, InstanceSpecification,
    Classifier, Lifeline, Connectableelement) and ClockType only extend Class.
    The specializations are not required since a TimingResource being a resource
    can already access to information of Clocks (including if required,
    ChronometricClocks).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3 and 17.3

  • Key: MARTE-143
  • Legacy Issue Number: 12220
  • Status: closed  
  • Source: THALES ( Eric Maes)
  • Summary:

    Inconsistencies concerning the <<GaStep>> prob stereotype attribute multiplicity: - In figure 15.7 "UML extensions for GQAM stereotypes related to behavior", p 271, it is [0..1], - In <<GaStep>> profile element description (§15.3.2.13), p280, it is [0..*], - In figure 17.7 "Profile diagram of performance extensions for workload, behavior and time observations", p 318, it is [0..1], - In <<PaStep>> profile element description (§17.3.2.15), p323, it is [0..1]. As a consequence, in PAPYRUS, it is [0..1] and in RSA, it is [0..*].

  • Reported: MARTE 1.0b1 — Wed, 13 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    [0..1] is correct, so it is changed in sec 15.3.2.13 where it is written [*]. Other
    attributes in that section:
    ... blockT
    ...selfDelay
    ...rep
    are also written [*] when they should be [0..1], and these are changed also. They
    are correct in Annex F.10.17.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Correct the inconsistency between the diagram and the text

  • Key: MARTE-147
  • Legacy Issue Number: 12233
  • Status: closed  
  • Source: InterCAX ( Mr. Lonnie VanZandt)
  • Summary:

    Sentence 1, paragraph 2, on page 295 begins: BEGINQUOTE "GaTimingObserver" specializes "NfpConstraint", and the latter extends UML Constraints... ENDQUOTE However, Figure 16.8, page 295, expresses that GQAM::GaTimingObs [sic] extends not specializes MARTE::NFPs::NfpConstraint. Several recommendations follow: 1. Correct the inconsistency between the diagram and the text. I suspect that the text should say "extends" rather than "specializes". 2. Consistently name the element GQAM::GaTimingObserver. 3. In text which refers to elements, always use a qualified name-it need not be fully qualified when there is a common parent scope in effect for the context of the text-and never use quoted "nicknames" or, worse, arbitrary alternate, similar names. 4. Replace the cited paragraph entirely with a paragraph which describes the Schedulability Analysis Module's profile and which isn't suspiciously similar to a cut-n-paste from the related GQAM material. 5. If Timing Observers move to a more common subprofile outside of GQAM, then refactor this section appropriately.

  • Reported: MARTE 1.0b1 — Fri, 15 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Revise figures and text according to the following considerations (each
    numbered point is related to the corresponding numbered item above):
    1. Update figures with the Specialization relationship instead of the Extension
    relationship between NfpConstraint and GaTimedObserver. This has to be done
    in both Chapters GQAM and SAM, and in both sections Domain View and UML Representation View. Also, in Figure 16.5, the association ends startObs and
    endObs are not valid anymore. In the FTF1, they have changed by startEvent
    and endEvent respectively.
    2. GQAM::GaTimingObserver is an old name that was changed in FTF1 by the
    name GQAM::GaTimedObserver. This has to be updated in all figures and text
    throughout Chapter SAM.
    3. Edit all incorrect aliases for GQAM::GaTimedObserver appropriately. Never
    use quoted "nicknames". The affected section is only Section 16.3.1.
    4. The cited paragraph doesn’t exist elsewhere in the MARTE specification.
    5. Timed Observers have not been moved to a more common sub-profile. So, no
    additional modifications are required.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex B (VSL)

  • Key: MARTE-154
  • Legacy Issue Number: 12248
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    There are the following mistakes in the VSL grammar: obsCallExpression (section B.3.3), instead of obs-call-expression value_specification (section B.3.3.10), instead of value-specification

  • Reported: MARTE 1.0b1 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Fix these typos:

    -Rename obsCallExpression (section B.3.3), by obs-call-expression

    -Rename value_specification (section B.3.3.10), by value-specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 288: change explanation

  • Key: MARTE-153
  • Legacy Issue Number: 12247
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    When explaining the semantics of the stereotype atributes 'EndToEndDeadline' and 'EndToEndTime' of an EndToEndFlow (page 289), it is clarified that these measures apply "only one input end-to-end stimuli exist". However, an end-to-end flow can have several execution end points (e.g., an activity diagram with more than 'one activity end' node). So, it is necessary to precise better the semantics of these two attributes. A resolution could be to add at the end of the first paragraph of page 289 something like: "...stimuli exist and only one finalization Step exists".

  • Reported: MARTE 1.0b1 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with the proposal to clarify semantics.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

picture 11.8, ports "loc" and "ftp"

  • Key: MARTE-149
  • Legacy Issue Number: 12240
  • Status: closed  
  • Source: AdaCore ( Matteo Bordin)
  • Summary:

    On picture 11.8, ports "loc" and "ftp" are typed with the type of the interface they require (instead of a classifier requiring the interfaces). Probably the names "loc" and "ftp" are for the ports, but the type is for the (required) interface.

  • Reported: MARTE 1.0b1 — Wed, 20 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The port "loc" and "fp" are defined in Figure 11.18 and not in Figure 11.8. Still, the issue is totally relevant and the Figure 11.18 is updated according to the proposed resolution.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 64 ClockConstraintSpecification

  • Key: MARTE-148
  • Legacy Issue Number: 12237
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Yann Tanguy)
  • Summary:

    On page 64 ClockConstraintSpecification is said to be specified in CCS, but if you take a look in CCS (p.420) it is referenced as an element from Time::TimeRelatedEnt ities::ClockConstraints.

  • Reported: MARTE 1.0b1 — Tue, 19 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Change in Figure C.2. ClockConstraintSpecification is now defined in CCS
    package and no longer refer to Time::TimeRelatedEntities

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 16.2.2 (SAM)

  • Key: MARTE-152
  • Legacy Issue Number: 12246
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    The first paragraph of page 289 makes reference to 'isSchedulability', which is wrong. The right name is 'isSchedulable'.

  • Reported: MARTE 1.0b1 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    revise this mistake

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM-SAM cyclic dependency due to GQAM::WorkloadBehavior

  • Key: MARTE-151
  • Legacy Issue Number: 12245
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [SAM] There is a cyclic dependency between packages GQAM and SAM at Domain Model level due to SAM adds an association (workload: EndToEndFlow) in GQAM::WorkloadBehavior. The model needs to be revised. A simple resolution could be to remove the association as far as the owning relationship already exist between WorkloadBehavior and the owned elements of EndToEndFlow (i.e., WorkloadEvent and BehaviorScenario)

  • Reported: MARTE 1.0b1 — Thu, 28 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We decided to proceed with the proposed resolution by the source

  • Updated: Fri, 6 Mar 2015 20:58 GMT

VSL variable declaration (inconsistency between the BNF and the metamodel)

  • Key: MARTE-150
  • Legacy Issue Number: 12242
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: VSL variable declaration (inconsistency between the BNF and the metamodel) Details: The direction of a VSL variable is refered as optional in the metamodel (multiplicity of 0..1) while it is presented as a mandatory term in the BNF. Proposed resolution: Change to BNF to turn variable declaration into an optional term.

  • Reported: MARTE 1.0b1 — Tue, 19 Feb 2008 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with proposal: change the BNF to do direction of variable declaration an optional term.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM Domain view inheritances

  • Key: MARTE-171
  • Legacy Issue Number: 12418
  • Status: closed  
  • Source: Universidad de Cantabria ( Dr. Julio Medina)
  • Summary:

    In the GQAM Domain view GQAM::GQAM_Resources::CommunicationHost should inherit from GRM::ResourceTypes::CommunicationMedia, and GQAM::GQAM_Resources::ExecutionHost should inherit from GRM::ResourceTypes::ComputingResource. This said from a conceptual point of view, seems to indicate that also the corresponding elements in the profile should keep this inheritance relationship with the corresponding elements in GRM. The names of attributes should be consistent or at least related semantically to those in GRM. This may required some minor structural changes since in GQAM platform elements include semantics form various elements in GRM like for example the scheduler as well as the processing resource.

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

    Include in GQAM::GQAM_Resources::CommunicationHost the inheritance from GRM::ResourceTypes::CommunicationMedia. And in GQAM::GQAM_Resources::ExecutionHost inheritance from GRM::ResourceTypes::ComputingResource. Correspondingly update the profile, making GQAM::GaExecHost inherit from GRM::ComputingResource, and GQAM::GaCommHost inherit from GRM::CommunicationMedia.

    According to issue 11835 already resolved in ballot 2, some attributes in GQAM::GaCommHost are now inherited from GRM::CommunicationMedia, these attributes are:
    o bandwidth: NFP_DataTxRate [0..1] capacity of the communication element when applicable.
    o packetT: NFP_Duration [0..1] time to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize.
    o blockT: NFP_Duration [0..1] time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum.
    o transmMode: MARTE_Library::MARTE_DataTypes::TransmModeKind [0..1] defines the transmission mode, one of the following values:

    {simplex, half-duplex, full-duplex}

    .
    The only difference is in the name of the attribute "bandwith" which is called "capacity" in GQAM. Since both of them represent the same concept one of the two should prevail; "capacity" is preferred as it is more general. As mentioned, this impact previous resolution of issue 11835, and as a duplicated also issue 11842.

    Attributes schedPolicy and isPreemptible in SaExecutionHost and SaExecHost are now redundant since they are inherited transitively from Scheduler.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM Observers: inconsistency between domain view and UML representation

  • Key: MARTE-170
  • Legacy Issue Number: 12417
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    GQAM Observers: inconsistency between domain view and UML representation Details: In the domain view (Figure 15.4), the Timing/TimedObserver has two properties startObs and endObs, typed by MARTE::Time::TimedInstantObservation. In the UML profile diagram (Figure 15.8), the related GaTiming/TimedObserver has two properties startObs and endObs, typed by UML::TimeObservation. In the UML profile description (p.281), the same GaTiming/TimedObserver has two properties startObs and endObs, typed by MARTE::Time::TimedInstantObservation. We need to choose whether a timed observer relates to a MARTE TimedInstantObservation or UML TimeObservation, and then to align the domain view, profile definition and profile description accordingly.

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

    In the conceptual domain model, we rely in MARTE "concepts", independently of
    whatever UML construct. For that reason we use the concept coming from the Time
    chapter.
    However, in the profile view, it is permissible to use the UML corresponding metaclass,
    because there is no reason to constraint such TimedObservers to Observations
    stereotyped with the MARTE Time concepts. (The time concepts add the notion of
    clocked Observation (attribute "clock"), which are not essential here). We agreed with
    Charles Andre that such a stereotype should not be mandatory when
    defining a TimedObserver.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TimedDomain stereotype

  • Key: MARTE-173
  • Legacy Issue Number: 12497
  • Status: closed  
  • Source: INRIA ( Charles Andre)
  • Summary:

    Resolution of issue 12414 introduced two base metaclasses for
    stereotype Clock (InstanceSpecification and Property).
    The TimedDomain stereotype has to be changed to support the case of
    Clock being a Property extension.
    The OCL rule number 1 has also to be updated.

  • Reported: MARTE 1.0b1 — Fri, 16 May 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Change the metaclass of TimedDomain from Package to Namespace in Figure
    9.26. Also change Extensions of TimedDomain (9.3.2.5). No need to change
    OCL rule for this issue because there is no ocl rule associated with
    TimedDomain, but see issue 12498 for indirect change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

wrong multiplicity in sharedResources required for a SaStep

  • Key: MARTE-172
  • Legacy Issue Number: 12428
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Julio Medina)
  • Summary:

    This might be an editorial issue since it is correct in section F but not in SAM. In the association sharedResource from SaStep to SAM_Resources::SharedResource (see Figure 16.4, page 289 in SAM)change multiplicity from 0..1 to * , This is correct and well explained in the Domain description in Annex F (Section F.11.3 page 609) but Figure 16.4 and the description in sections 16.3.2.3 and probably 16.3.2.8 must be adjusted.

  • Reported: MARTE 1.0b1 — Tue, 6 May 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The resolution of this issue makes consistent the domain and UML views of SAM in the aspect of sharedResources linked to steps. It complements resolution of Issue 11778 stating consistently that a SaStep may require multiple passive shared resources to be locked during its execution.
    First it is necessary to change from 0..1 to * the multiplicity in the association sharedResource that exists between SaStep and SAM_Resources::SharedResource in Figure 16.4, page 289 in the domain view of SAM. Then align the profile correspondingly by correcting the pictures in Figure 16.7 or Figure 16.9, and insert the description of the association as it is in Section F.11.3 page 609 in the description of the stereotype SaStep in page 298. In the GRM domain view it is necessary also to change to 0..* the multiplicity of MARTE::GRM::ResourceUsages::ResourceUsage.usedResources so that it may admit incomplete definitions of usages. For consistency it is convenient also to extend the multiplicity of requiredAmount to 0..*.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

figure 10.18

  • Key: MARTE-178
  • Legacy Issue Number: 12537
  • Status: closed  
  • Source: European Software Institute ( Adrián Noguero)
  • Summary:

    We have detected a difference between domain analysis "ResorceUsage" concept, the stereotype diagram in figure 10.18 and the stereotype description in 10.3.2.13. The association between ResourceUsage and Resource is unidirectional according to figure 10.13 and sections 10.3.2.12 and 10.3.2.13; however in figure 10.18 this association is shown as bidirectional.

  • Reported: MARTE 1.0b1 — Thu, 19 Jun 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The UML representation for resourceUsage maps the domain view in a more practical
    way. However, the navigability from resource to resourceUsage might be removed in
    Figure 10.18 to be consistent with the definition of resource (section 10.3.2.12) which is
    agnostic with respect to its usages.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistencies in GQAM

  • Key: MARTE-177
  • Legacy Issue Number: 12536
  • Status: closed  
  • Source: European Software Institute ( Adrián Noguero)
  • Summary:

    A number of inconsistencies have been detected in the GQAM subprofile description. The GaScenario stereotype description changes from the domain description section to the UML stereotype description sections (15.2.2.1, 15.3.1 and 15.3.2.12).

  • Reported: MARTE 1.0b1 — Thu, 19 Jun 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The differences are mostly in style of expression rather than substance,
    particularly in a property being expressed as an attribute in a diagram, because it
    is geometrically awkward to show an association. Attributes and associations are
    equivalent properties. There are two differences: (b3) timing is correctly represented in Fig 15.3 by an association
    (b4) timing is missing from the stereotype on p 283, and should be added.
    (a) GaWorkloadEvent has five properties:
    in Fig 15.3 in Fig 15.7 in stereotype p 286
    • pattern: attrib attrib attrib
    • generator: assoc attrib attrib
    • trace: assoc attrib attrib
    • timeEvent: assoc assoc attrib
    • effect assoc attrib assoc (proposed in resolution of
    issue 12538)
    The textual stereotype is consistent with the meaning of both diagrams, so no
    change is necessary.
    (b) The stereotype GaScenario in Figure 15.7 has attributes “cause” and “timing”
    which are not correctly represented in Fig 15.3 and in the stereotype on p 283.
    (b1) cause is represented in Fig 15.3 by the association inputStream. This should
    be changed to cause
    (b2) cause is not represented in the stereotype at all, it should be added.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex D.2

  • Key: MARTE-180
  • Legacy Issue Number: 12561
  • Status: closed  
  • Source: European Software Institute ( Adrián Noguero)
  • Summary:

    We have found that the current format for modelling probability distributions is not very good is some cases. For example, it is hard to model correctly the probability distribution related to a SporadicPattern. We propose that distributions are modelled as a ProbabilityDistribution <<choice_type>> element, with each probability distribution modelled as a <<tuple_type>> element each with the parameters needed (e.g. Uniform <<tuple_type>> should have 2 parameters: a min:NFP_Real and max:NFP_Real).

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

    There is a misunderstanding in the way MARTE deals with probability distribution
    expressions. This is, in any case, a weak aspect in the description of such
    specification mechanism in MARTE. This resolution proposes to clarify this
    aspect, by adding an example in the NFP chapter and by making explicit the list
    of distributions in Annex D.
    In addition, this issue proposes to complete the textual description of all the
    NfpTypes included in the library MARTE_NfpTypes.
    Issue Dependency Warning: Note that the texts and figures provided in this
    issue depend on Issue 12196, which proposes new probability distributions.
    Thus, if Issue 12196 is not accepted, these new probability distributions need to
    be removed from the texts and figures proposed in this issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors in definition of GaEventTrace and GaWorkloadEvent

  • Key: MARTE-179
  • Legacy Issue Number: 12538
  • Status: closed  
  • Source: European Software Institute ( Adrián Noguero)
  • Summary:

    Errors in definition of GaEventTrace and GaWorkloadEvent. In page 275, the stereotype <<GaEventTrace>> has an association defined as "stream" which does not appera in figure 15.7. Moreover no multipicity is defined for such association. In page 271, in figure 15.7 stereotype <<GaWorkloadEvent>> a property called "effect" can be read; however the semantics behind this property cannot be found anywhere, nor in page 282 nor in the domain description (section 15.2).

  • Reported: MARTE 1.0b1 — Fri, 20 Jun 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    (a) This association is handled differently in Fig 15.7: GaWorkloadEvent has an
    attribute trace of type GaEventTrace, with default multiplicity 1. Thus the stream
    association can be removed from GaEventTrace.
    (b) There are two problems identified here.
    (b1) GaWorkloadEvent has an association effect:GaScenario in Fig 15.3, and
    also in Figure 15.7, with default multiplicity 1. This should be represented in the
    stereotype on p 286. If it is stated as an association then the constraint among
    the other four attributes is still correct.
    (b2) in Figure 15.7, GaWorkloadEvent is lacking the attribute
    timeEvent:UML::timeEvent[0..1] which is shown in the stereotype on p 286, it
    should be added to the figure.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

wrong numbering of figures

  • Key: MARTE-175
  • Legacy Issue Number: 12513
  • Status: closed  
  • Source: CATS CO., LTD. ( Shuji Kawasaki)
  • Summary:

    p.316, l.13: "Figure 17.5" should be Figure 17.6 p.325, l.7: "Figure 17.8" should be Figure 17.9 p.326, l.1: "Figure 17.9" should be Figure 17.10 These are a part of my MARTE errata. Since I cannot write them all here, I will send the errata file by E-mail to pubs@omg.org.

  • Reported: MARTE 1.0b1 — Wed, 28 May 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OCL rules for the Clock stereotype

  • Key: MARTE-174
  • Legacy Issue Number: 12498
  • Status: closed  
  • Source: INRIA ( Charles Andre)
  • Summary:

    Resolution of issue 12414 introduced two base metaclasses for
    stereotype Clock (InstanceSpecification and Property).
    The OCL rules [2] has to be changed to deal with both base metaclasses
    (The present rule deals only with InstanceSpecification).

  • Reported: MARTE 1.0b1 — Fri, 16 May 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Distinction has been done in ocl rules according to the base metaclass of Clock.
    Rule 1 is no longer valid (because change in issue 12497)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The tiler stereotype should be applied on the UML::Port metaclass

  • Key: MARTE-176
  • Legacy Issue Number: 12514
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The tiler stereotype should be applied on the UML::Port metaclass. Tilers are currently applicable on connectors and connector ends, along with instances (parts) of a given class. It would be very useful to make use of the same stereotype at a classifier level, in order to define the expected and produced data format at a classifier level. The UML::Port metaclass is a good candidate to carry this stereotype.

  • Reported: MARTE 1.0b1 — Thu, 29 May 2008 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex B: how VSL constructs shall be typed and evaluated

  • Key: MARTE-123
  • Legacy Issue Number: 11878
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: Annex B doesn't clearly define how VSL constructs shall be typed and evaluated Details: Our problem: it seems to be missing some information in the current VSL specification that explains how language constructs shall be typed and evaluated. We had a look at other standard programming languages (ANSI C, Java) to see how such information is defined. In the ANSI C language reference, every section introducing a language element is organised with the same structure: a subsection that introduces the syntax, a subsection defining the constraints (including type constraints) and finally a subsection regarding the semantics (other type constraints plus explanations regarding the evaluation). For instance, we can have a look at an extract that introduces the function calls: > 6.5.2.2 Function calls > > Syntax > > primary-expression: > identifier > constant > string-literal > ( expression ) > > > Constraints > 1 The expression that denotes the called function shall have type pointer to function > returning void or returning an object type other than an array type. > > 2 If the expression that denotes the called function has a type that includes a prototype, the > number of arguments shall agree with the number of parameters. Each argument shall > have a type such that its value may be assigned to an object with the unqualified version > of the type of its corresponding parameter. > > Semantics > 3 A postfix expression followed by parentheses () containing a possibly empty, commaseparated > list of expressions is a function call. The postfix expression denotes the called > function. The list of expressions specifies the arguments to the function. > > 5 If the expression that denotes the called function has type pointer to function returning an > object type, the function call expression has the same type as that object type, and has the > value determined as specified in 6.8.6.4. Otherwise, the function call has type void. If > an attempt is made to modify the result of a function call or to access it after the next > sequence point, the behavior is undefined. In VSL, we have a definition of the abstract syntax (the meta-model) and the concrete syntax (the BNF) in the Annex B and we have a detailed description of the domain classes (abstract syntax elements) in the Annex F. It seems that the current "constraint" and "semantics" sections of the metaclass descriptions miss some detailed information on the way constructs shall be typed and evaluated. The information does not seem to be systematic and homogeneous. Examples: > F.13.6 ConditionalExpression (from Expressions) > Generalizations > • Expression (from Expressions) on page 560 > Associations > • conditionExpr: VSL::ValueSpecification [1] Boolean expression to be evaluated. > • ifTrueExpr: VSL::ValueSpecification [1] result expression if conditionExpr is evaluated to True. > • ifFalseExpr: VSL::ValueSpecification [1] result expression if conditionExpr is evaluated to false. > Semantics > Conditional Expressions define "if-then-else" statements, which can be used inside an expression. The result of evaluating > this expression will be the result of => Here it is not stated that the consequence (ifTrueExpr) and the alternative (ifFalseExpr) shall have the same type or that the type of such an expression if a boolean. OR > F.13.8 DurationExpression (from TimeExpressions) > Generalizations > • TimeExpression (from TimeExpressions) on page 567 > Semantics > DurationExpression is a time expression that denotes a duration value. => Again, here it may miss more detailed information on the type of the expression. This is the kind of information we missed when implementing the VSL editor and which we need to figure out by ourselves. Sometimes it's obvious but it happens to be definitely tricky. That's why we think that it would be beneficial for MARTE and VSL to complete the Annex F to add this information. In that context, we propose that: 1) every VSL domain class in Annex F shall provide information about its type. 2) if the type cannot be directly known, there shall be an explanation on how it can be computed (this is the case of all the subclasses of Expression and TimeExpression). 3) if information about the evaluation / execution semantics is provided then it shall be distinguished from the type information (because this is something really different). All this information would complete either the "constraint" and/or "semantics" section of Annex F.

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

    VSL complements MARTE for improving the UML data type system and the
    specification of expressions. The approach to define VSL was to balance both its
    precision and its level of formality in order to provide a very compact specification
    but still well-formed. MARTE Beta 1 and 2 have provided a good basis to develop
    a couple of tools supporting VSL parsing and type checking. There are, however,
    some aspects that need to be improved in the VSL specification to avoid
    ambiguity in tool implementations. Some of the ambiguity problems were
    described in the summary of this issue, but we can organize them more formally
    in the following categories:
    a) Some of the production rules are syntactically ambiguous because they are
    based on the UML model to which the VSL expression is attached (e.g., does a
    data type exist or not). This means that disambiguating rules have to be defined
    for those rules.
    b) In order to semantically evaluate VSL expressions, we need to define the type
    of each expression or value specification. The mapping of expressions to (data)
    types can be easily identified in many cases, but there are other cases that this
    requires making it explicit. Moreover, there are some expressions that cannot be
    evaluated to any existing data type defined in MARTE. For example, duration
    expressions have not a type counterpart in the library of MARTE primitive types. To solve item (a), we will add a section of “Disambiguating Rules” for each
    production rule. In addition, one of the suggestions proposed in the summary of
    this issue is to add a special section for a semantics description. It must be
    noted, however, that VSL is described in two main parts: abstract syntax and
    concrete syntax. The semantics of VSL construct is described in plain English as
    a part of the abstract syntax. More particularly, the semantics of VSL model
    elements is described in Annex F, section F.13. However, the mapping of
    abstract syntax constructs to concrete syntax constructs is not explicit. In this
    resolution, we propose to add this mapping by identifying the abstract syntax
    counterpart of each production rule explicitly in the concrete syntax section.
    To solve item (b), we will complete all the required primitive types and describe
    the types to which VSL expressions should be evaluated. For those expressions
    that cannot be directly mapped to a concrete type, we will provide rules to help
    evaluating them.
    In addition, we will add some clarifications to help VSL implementers to use this
    specification. The goal is that at the end of all processing every tool
    implementation should be able to produce the same well-formed instance of
    abstract syntax tree.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In Annex D, I would suggest make unit names (e.g. bits, bytes) singular

  • Key: MARTE-122
  • Legacy Issue Number: 11877
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In Annex D, I would suggest make unit names (e.g. bits, bytes) singular.

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

    Modify Figures D.3 with singular unit names.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

improve the usability of the RtBehavior stereotype

  • Key: MARTE-111
  • Legacy Issue Number: 11866
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    To improve the usability of the RtBehavior stereotype, it should also extend the UML::Operation metaclass.

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RtAction.isAtomic

  • Key: MARTE-110
  • Legacy Issue Number: 11865
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The meaning of the RtAction.isAtomic should be precisely state. In chapter 13, isAtomic is used in other contexts (e.g. flow ports) with other semantics.

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

    Provide a precise, non-recursive definition: here, isAtomic means indivisible.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Names should be identical

  • Key: MARTE-109
  • Legacy Issue Number: 11864
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The Refinement metaclass relates to the ClockRefinement stereotype. Names should be identical.

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

concept of refinement

  • Key: MARTE-108
  • Legacy Issue Number: 11863
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Does the concept of refinement only apply to clock refinement. My first impression is that this concepts may apply to other NFPs. In any case, this needs to be clarified

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

    There is agreement to extend the Refinement to any kind of NFP constraints. Issue 11864 required to use the same name in the domain model and in the UML representation so we chose NFPRefine for the name.
    The resolution replaces every occurrence of ClockRefine by NFPRefine. It also replaces the association to Time::ClockConstraint by an association to NFPs::NfpConstraint. In the domain model, the metaclass Refinement is associated to NFP_Constraint instead of ClockConstraint.
    The second constraint is removed since it was assuming all constraints were ClockConstraint.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

VSL

  • Key: MARTE-117
  • Legacy Issue Number: 11872
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: VSL should support definition and application of functions, derivatives, sequences and series. Details: In the early stage of a development process, it may be useful to model control laws of a RTES. VSL seems to be a very good fit for that purpose. However, it misses several mathematical concepts to provide a comprehensive support. VSL should support definitions of functions, derivatives, sequences and series.

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

    In VSL, functions are supported by means of:
    a) The definition of UML::Operations in DataTypes, for the declaration of
    functions in data type libraries.
    b) VSL::OperationCallExpression, for the specification of functions
    (reference/call to declared UML::Operations) in VSL expressions.
    We added a set of minimum operations/functions to MARTE primitive and data
    types (e.g., arithmetic and logic functions). The number of functions that could be
    added to VSL, and useful in the real-time and embedded system domain, is very
    large. In MARTE, we did not attempt to define all these functions. Instead, we
    proposed only a basic subset useful for general expressions. The initial intent
    was that further libraries could extend MARTE libraries to support domainspecific
    functions.
    However, we should assure that different kinds of functions can be declared with
    basis on the current VSL abstract and concrete syntaxes (e.g., the functions
    described in the summary of this issue). In this resolution, we describe how such
    functions (i.e., functions, derivatives, sequences and series) are added to the
    MARTE library of primitive types and supported by VSL.
    From a computer science viewpoint, every function declaration can be expressed
    as a tuple: <name, parameters/arguments, returning type>. For instance, all the
    functions supported by Matlab are defined in this way. In Matlab, functions are program routines, usually implemented in M-files that accept input arguments
    and return output arguments. Every mathematical (or not mathematical) function
    in Matlab is implemented with this basic principle2 (integrals, derivatives,
    matrices, potentials, optimization expressions, etc.). If we look at VSL, the
    “function” notion matches very well with the UML::Operation concept. Thus, VSL
    is supported in Operations for the declaration and specification (expression
    specifications) of functions. In VSL, however, our scope is just the language
    aspects. VSL does not support implementation support on those functions
    (although they could be implemented as methods –UML::Behavior- of such UML
    UML::Operations). Instead, VSL describes the semantic of functions in a
    declarative way.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GRM::SchedulableResource should have a period property

  • Key: MARTE-119
  • Legacy Issue Number: 11874
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: GRM::SchedulableResource should have a period property. Details: After some discussion with F. Thomas, it seems that the GRM::SchedulableResource misses a period property

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

    SchedulableResource in GRM represents the capabilities for obtaining processing capacity from a processing resource. The period is not a fundamental quality of the concurrent units represented. The fact that it may be periodically activated or not is a design choice. To annotate this behavior among other alternatives, a workloadEvent with the periodic arrival pattern may be used.

    Revised Text:

    Disposition: Close, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

allocatedTo and allocatedFrom properties should not be derived

  • Key: MARTE-118
  • Legacy Issue Number: 11873
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: In chapter 12, Details: The concept of allocation in MARTE is quite generic. Any UML::NamedElement can be used as allocation end. That enables the use of allocations in various kind of diagrams, for multiple purposes (e.g., structural, behavioural allocation.) In the current specification, allocations are supported by three stereotypes: Allocate, ApplicationAllocationEnd and ExecutionPlaformAllocationEnd. The allocatedTo and allocatedFrom properties of ApplicationAllocationEnd and ExecutionPlaformAllocationEnd are derived from the UML::Abstraction that is stereotyped as Allocate. However, creating an abstraction (i.e., a dependency) between two elements, implies that these elements belong to the same diagram, which is not always the case. Moreover, it limits the use of allocation to specific diagram types (e.g., not all the UML modeling tools allow the use of dependency on composite structures). Proposed correction: 1) Do not considerer allocatedTo and allocatedFrom as derived properties and allow end users to directly make use of the ApplicationAllocationEnd and ExecutionPlaformAllocationEnd stereoypes to express allocations. 2) Identify mechanisms to allow a characterisation of this allocation (allocation kind, allocation nature) the way its done in the Allocate stereotype.

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NFP does not introduce the concept of dimension

  • Key: MARTE-116
  • Legacy Issue Number: 11871
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Subject: NFP does not introduce the concept of dimension. Details: NFP defines the notion of unit attached to a type but it does explicitly express the dimension related to this unit. This should be fixed to provide a comprehensive support for modeling quantities in RTES.

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

    The Dimension concept, and its possible attributes such as the base dimensions,
    is required to do dimensional analysis and verify consistency of expressions with
    quantitative NFPs.
    The concept of Dimension is not explicitly formalized in the NFP domain model
    nor in the NFP profile. However, the enumeration which gather the literals that
    are stereotyped by Unit can be already seen as a Dimension. We make this
    concept explicit here. The design of the current profile support this clarification
    with minimal changes.
    Note that SysML also includes the concept of dimension. As a first result of
    discussions between SysML and MARTE communities and a first step towards
    an alignment between both profiles in this domain, we propose to also explicitly
    support this concept.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In section 6.1, I would suggest mentioning RTCORBA and CCM

  • Key: MARTE-115
  • Legacy Issue Number: 11870
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In section 6.1, I would suggest mentioning RTCORBA and CCM

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE primitive types

  • Key: MARTE-121
  • Legacy Issue Number: 11876
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    MARTE primitive types: Integer, String, UnlimitedNatural and Boolean are redefined in the MARTELib. To facilitate integration, I would suggest making them subclasses of their UML counterpart.

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

    There is no reason to have a syntactical link between MARTE primitive types and
    UML primitive types. The semantics of MARTE primitive types is clearly defined
    and a set of default operations are provided for each primitive type. Also, the
    meaning of the inheritance between primitive types is not fully defined, although
    not forbidden, in UML. Hence, this resolution proposes to close this issue with no
    change.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relationship between Alloc::Allocation and SRM::EntryPoint

  • Key: MARTE-120
  • Legacy Issue Number: 11875
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Relationship between Alloc::Allocation and SRM::EntryPoint should be clarified (maybe a generalization relationship?)

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

    SRM::EntryPoint shloud specialized the Alloc::Allocation stereotype.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

suggest removing the notion of feature in the conformance section

  • Key: MARTE-113
  • Legacy Issue Number: 11868
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    I whould suggest removing the notion of feature in the conformance section. As this notion is not used in other places of the document

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

    Agree on the proposal.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

For the sake of consistency, the rtf stereotype should be renamed

  • Key: MARTE-112
  • Legacy Issue Number: 11867
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    For the sake of consistency, the rtf stereotype should be renamed as rtFeature.

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

    Rename "rtf" to be "rtFeature".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 6: Remove the MSWord comment

  • Key: MARTE-114
  • Legacy Issue Number: 11869
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Remove the MSWord comment "[N.B. Clearly, this is something..." in the related standard section

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

    Ok, see revised text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[GQAM: General]

  • Key: MARTE-63
  • Legacy Issue Number: 11773
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GQAM: General] The references (publications) along the text should be moved to the annex.

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

    Replace each reference by suitable words which name the authors of documents, and insert the references in Annex G.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

HRM: Examples

  • Key: MARTE-62
  • Legacy Issue Number: 11772
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [HRM: Examples] Figure 14-78, 14-82, 14-83, 14-84 specify tagged values with a syntax that does not correspond to VSL (e.g., 166MHz, 64 MB). It should be clarified the syntax used, or align to VSL.

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

    Figures 14-78, 14-82, 14-83 and 14-84 are modified in order to be consistent with VSL syntax, and with the syntax which has been allowed in the resolution of issue 11781.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MoCC: Examples

  • Key: MARTE-61
  • Legacy Issue Number: 11771
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [MoCC: Examples] Fig. 13-22 misuse time observation declarations when using the occurrence index at declaration level. This should be specified in time expressions.

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

    Rather, time observation declarations should be specified in time expressions.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[Alloc: Profile

  • Key: MARTE-60
  • Legacy Issue Number: 11770
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [Alloc: Profile] The MARTE allocation concept aimed to refine the SysML allocation concept. Furthermore, it seems that the idea was to not be dependent on SysML by re-defining the same concepts in the MARTE context. For this reason, MARTE uses the same names for the generic stereotypes (<<allocated>> and <<allocate>>). However, there is a limitation in the MARTE <<allocated>> stereotype that does not allow modelers to have the same capabilities. More precisely, when using the <<allocated>> stereotype, we cannot refers to the target and source ends. We are forced to use the more specialized stereotypes: <<ApplicationAllocationEnd>> and <<ExecutionPlatformAllocationEnd>>, which is not always practical (the annotation process requires to pollute the target model) or is not always what modelers want to allocate (physical-logical allocation, or others support by SysML). So, I’d suggest to add properties: /allocatedFrom:NamedElement[*] and /allocatedTo:NamedElement[*] for the stereotype: <<Allocated>.

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

    Add the proposed property in the stereotype Allocated to maintain compatibility with SysML. Replace Figure 12.3 and the description text accordingly. If the property allocatedTo and allocatedFrom are already defined in the stereotype Allocated, they need not be redefined in the specialized stereotypes (ApplicationAllocationEnd and ExecutionPlatformExecutionEnd). Thus, these two stereotypes can be replaced by a mere attribute of type AllocationEndKind.
    All figures where either the stereotype ExecutionPlatformExecutionEnd or ApplicationAllocationEnd were displayed have been replaced by a new Figure with the new notation.
    No concept is introduced or removed. It is just a different lighter way to implement the domain model so as to be consistently compatible with the SysML allocation.
    The revised text assumes that resolution 12214 will be resolved by referring to sources of an allocation as clients and to targets as suppliers.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GRM: Examples

  • Key: MARTE-59
  • Legacy Issue Number: 11769
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GRM: Examples] Fig 10.21 shows a composite diagram, which is not conform to UML: parts are shown with attribute and operation compartments. This should be revised.

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

    Instead of using as an example a composite structure, it will be used a class diagram. There are no implications in the text, so the only change is in the diagram shown in Figure 10.21. The diagram is changed by the next one:

    The usage of the stereotype <<allocate>> in this diagram is simplified to the minimum to avoid cluttering the picture.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GRM: Domain Model

  • Key: MARTE-58
  • Legacy Issue Number: 11768
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GRM: Domain Model] A number of GRM domain concepts make it hard to understand and use. These mainly relate to its mapping with the UML profile and its refinement in the HRM, SRM and analysis profiles: a) Figures 10.3 and 10.4 illustrate the ‘resource’ concept as two kinds of entities: an instance (ResourceInstance) and a classifier (Resource). This separation is not explained and is not used along the remaining parts of the spec. I.e., all the associated or specialized concepts are related to ‘Resource’. Also, the profile only defines a ‘Resource’ stereotype. Furthermore, NFPs are only associated with ‘Resource’. What about NFPs related to ResourceInstances? ? I’d suggest to remove the ResourceInstance concept, as conceptually, has not any relevance, and create confussion. b) Fig. 10-13 introduces the concepts of ‘ResourceUsage’, ‘UsageTypedAmount’, which inherits from ‘ResourceAmount’. However, at UML profile definition level, only <<ResourceUsage>> is provided, by using the attributes of UsageTypedAmount (from the domain model). I’d suggest to harmonize both, domain model and profile. c) A double inheritance of ‘ComputingResource’ from ‘Resource’ has been defined (Fig. 10.6 and, Fig. 10.11 through ‘ProcessingResource’). I’d suggest to remove one of them. d) GRM attempts to be a generic framework for modelling resources. However, some of the attributes seems too specific and not useful when specializing this package (e.g., HRM & SRM). For instance, ‘packetSize’ in ‘CommunicationEndPoint’ (Fig. 10-8) is related to specific kinds of protocols. ‘speedFactor’ in ‘ProcessingResource’ is an analysis-specific parameters.

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

    a) Instances and Classifiers are consubstantial to UML and their role in
    MARTE are explained in the CoreElements Chapter. The instances are
    there to illustrate the finite nature of resources. No change.
    b) UML View is an utilitarian mapping of the domain model, and in this case
    the harmonization is already included in the constraints that describe the
    rules for the utilization of resourceUsage. No change.
    c) Double inheritance is neither conceptually nor practically a problem. No
    change.
    d) Very few attributes have been defined, but all of them are optional and do
    not jeopardize the conceptual and architectural role of the stereotypes in
    GRM. No change
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM: Domain Model & Profile (02)

  • Key: MARTE-65
  • Legacy Issue Number: 11775
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GQAM: Domain Model & Profile] The notions included in the GQAM Observer package (TimingObserver, LatencyObserver) may be used not only for analysis purposes . I’d suggest to move this concepts to a more general package.

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

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM: Domain Model & Profile (01)

  • Key: MARTE-64
  • Legacy Issue Number: 11774
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GQAM: Domain Model & Profile] The PrecedenceRelation concept (fig 15.3) could be used to specify delays due to e.g., queues. However, PrecedenceRelation only exists in the Domain Model. Its implementation is intended to be supported by existing UML concepts (e.g., forks, joints, etc.) I’d suggest to define the corresponding stereotype (<<PrecedenceRelation>>) in order to allow for modelling delays or other precedence patterns like event divisors: a number of event occurrences triggers an execution.

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

    This enhancement is not necessary, since everything it would provide can already be done using scenario Steps, and done better. However the method for showing an event divisor using steps should be added to the text.
    Since a precedence relation always leads to one or more steps, properties such as queueing etc can be attached to the step. The step is a better place for these properties because there may be multiple branches in a precedence relation (a branch or fork), each with its own properties. For example, a fork precedence would have a different waiting on each branch of the fork, which would be complex to describe or specify within the fork, but very easy on the following steps.
    An event divisor or multiplier can be provided using the CommStep stereotype. We assume that the event is a call invoking a Step. The call can be stereotyped as a CommStep, which has a repetition attribute. If this is set to N, it means the call is repeated N times, giving event multiplication. If it is set to 1/N, it means that every Nth execution of the sender gives a call... an event divisor. If the repetition attribute is specified as a deterministic NFP, it should be defined to be interpreted as 1/N for an integer N, determined by rounding to an integer if necessary. A stochastic division is also possible.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[SAM: Profile]

  • Key: MARTE-68
  • Legacy Issue Number: 11778
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [SAM: Profile] The SaStep domain concept (Fig. 16-4) has an association to a SharedResource. This is very useful to model execution steps that take a resource along all their execution (alternative to use the AcquireStep and ReleaseStep). However, this association has not been reflected in the UML profile. This should be added in Fig. 16-7.

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

    (FTF Group) Strike the phrase "Business Management Perspective" Change it by "system perspective"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM: Domain Model & Profile (04)

  • Key: MARTE-67
  • Legacy Issue Number: 11777
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [GQAM: Domain Model & Profile] A TimingObserver (Fig. 15-4) refers to 0 or 1 start event occurrence and 0 or 1 end event occurrences, which are modelled by TimedInstantObservation elements. However, more refined TimingObservers can define the synchronization between several events. I’d suggest to change the multiplicity of the start and end observation points to [*].

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

    Change the multiplicity of the start and end observation points to [*].

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GQAM: Domain Model & Profile (03)

  • Key: MARTE-66
  • Legacy Issue Number: 11776
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    GQAM: Domain Model & Profile] The notions included in the GQAM Observer package (TimingObserver, LatencyObserver) may be used not only for analysis purposes . I’d suggest to move this concepts to a more general package

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

    This is identical to issue 11775, it was submitted or entered twice
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[Time] Fig. 9.29

  • Key: MARTE-57
  • Legacy Issue Number: 11766
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [Time] Fig. 9.29 refers to the Enumeration type ‘EventKind’. The formal definition of EventKind is an annex (Annex D). I’d suggest to show this definition in Fig 9.29 for a faster comprehensibility of the provided stereotypes.

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

    This is easy to do, but I guess that this suggestion may apply to many diagrams. In the chapter time (for instance),
    · Fig. 9.26 refers to TimeStandardKind,
    · Fig. 9.27 refers to TimeInterpretationKind
    · Fig. 9.28 refers to TimeInterpretationKind
    · Fig. 2.29 refers to EventKind
    My question is: do we systematically include in UML extension diagrams the used enumerations and mention in the associated text that the enumeration is part of a library given in Annex D?

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[NFP: Profile]. Fig 8.4

  • Key: MARTE-56
  • Legacy Issue Number: 11765
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [NFP: Profile]. Fig 8.4 shows a domain model for NFP declaration. In this domain model, the NFP concept has to attributes (statisticalQualifier + direction). However, these two attributes do not appear in the corresponding Stereotype: <<Nfp>> (Fig. 8-5). Section 8.3.2.1 justifies this by saying: “the attributes of NFP, statistical qualifier and direction, are implemented in the library of NFP Types”. However, it could be useful to allow stereotype users to define these two parameters at the NFP declaration stage (and not only at the value specification stage). On the other hand, the current mechanism to define these two parameters at the NFP declaration stage (default values of NFPs), is not strict enough, as users can modify default values. So, I propose to put this two attributes (statisticalQualifier + direction) in the <<Nfp>> stereotype.

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

    If we adopt these two attributes for the 'Nfp' stereotype, there may exist some issues regarding to consistency and duplication of information. Indeed, statisticalQualifier and direction would be able to be specified in 'Nfp' and in the value specification too (e.g., maxLatency= (value=5, unit=ms, statQ=max)).
    Another question that rises is why other qualifiers would not able to be specified in 'Nfp' attributes (e.g., source) in the same way.
    In order to keep consistency and to avoid confusions between the domain model and profile definition, both 'statisticalQualifier' and 'direction' attributes of the 'NFP' metaclass are removed from the domain model.
    This means that the proposal to include these two attributes in the stereotype definition is not accepted. However, for comprehensibility, they are removed from the domain model.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: NFP

  • Key: MARTE-55
  • Legacy Issue Number: 11764
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Mr. Huascar Espinoza Ph.D.)
  • Summary:

    [NFP] A very useful concept for NFP annotations could be the notion of ‘NFP level’. For instance, a NFP level may identify a group of non-functional values that are valid for a specific system operation mode. More specifically, in a component-based architecture, components can support different working modes, and these working modes may provide different non-functional values or qualities for the same services. In infrastructures supporting dynamic resource management, the resources may offer different non-functional values depending on the system load. From a conceptual viewpoint, a NFP level can identify a level of model refinement. For example, one may define NFP values according to available estimates in early development phases, while further accurate measurement values may be annotated in the same models. A NFP level, in this case, can offer a mechanism to organize non-functional values according to successive refinement stages.

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

    In general, this is a problem than might need some especial mechanism in UML,
    or a trick/cheat annotation mechanism. We recognize that we need the ability to
    express differing configurations for modal analysis or tradeoff analysis. However,
    having multiple value annotations for arbitrary cases or situations is clearly
    beyond the scope of the MARTE Profile and is within the scope of the UML
    metamodel and modeling generally. For instance, this could be supported by
    allowing applying a given stereotype multiple times in the same UML model
    element. We need to raise the issue within the UML Revision Task Force.
    Also, MARTE offers AnalysisContext and VSL offers variables and the two are
    intended for multi-case analysis.
    Finally, modeling of NFP_Constraint annotations for specific operational model is
    treated in Issue 12797 (HLAM work group).
    Hence, we propose to close this issue with no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consider providing a tabular notation (as in SysML)

  • Key: MARTE-54
  • Legacy Issue Number: 11707
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    Consider providing a tabular notation (as in SysML) to easy the setting of allocations and their implied constraints when the source and the target are in diagrams too far apart.

  • Reported: MARTE 1.0b1 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Add an example of a possible table that contains NFP constraints relative to an allocation activity groups.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

HwTiming model of the HwLogical profile

  • Key: MARTE-50
  • Legacy Issue Number: 11694
  • Status: closed  
  • Source: CEA-LIST ( TAHA Safouan)
  • Summary:

    in the HwTiming model of the HwLogical profile, HwClock has a property named "frequency" that is already inherited from the HwResource stereotype. We should rename it or better remove it.

  • Reported: MARTE 1.0b1 — Wed, 28 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The HwResource stereotype actually owns a "frequency" property. As there is a (indirect) generalization relationship between HwClock and HwResource, the "frequency" property of HwClock must be removed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.2 add two stereotypes corresponding to HwSensor and HwActuator

  • Key: MARTE-49
  • Legacy Issue Number: 11693
  • Status: closed  
  • Source: CEA-LIST ( TAHA Safouan)
  • Summary:

    After many users feedbacks, we should add two stereotypes corresponding to HwSensor and HwActuator as specializations of the existing stereotype HwI_O from the HwDevice package. Even if we explained in the document that the HwDevice denotes both sensors and actuators, it is better to separate these concepts.

  • Reported: MARTE 1.0b1 — Wed, 28 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with the proposal.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.1 figure 11.6

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

    In figure 11.6, the [0..1] multiplicity of the direction tagged value is NOT displayed (whereas the [0..1] multiplicity of the kind tagged value of the MessagePort stereotype is displayed).

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Correct Figure 11.6 by adding a [0..1] multiplicity to the direction attribute on the FlowPort stereotype.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.1

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

    In figure 11.6, this stereotype is called SendFlowAction instead of FlowSendAction

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    There is indeed an inconsitency between the domain model where the action is named "FlowSendAction" and the profile definition where it is called "SendFlowAction".
    In UML, the action that sends an object is named SendObjectAction; the action that sends a signal is named SendSignalAction.
    The resolution for this issue is to align the the domain model on the profile definition terminology, which is consistent with UML related actions.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In 12.4, all references to figures are wrong

  • Key: MARTE-53
  • Legacy Issue Number: 11705
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    In 12.4, all references to figures are wrong (e.g., 12.12.8 instead of 12.8).

  • Reported: MARTE 1.0b1 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This is an editorial issue. All callouts of the form 12.12.x are replaced by 12.x.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial issue

  • Key: MARTE-52
  • Legacy Issue Number: 11704
  • Status: closed  
  • Source: INRIA ( Frederic Mallet)
  • Summary:

    First a typographical issue, there are some question marks appearing here and there. They should be replaced by slashes .

  • Reported: MARTE 1.0b1 — Fri, 30 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This editorial issue is resolved by removing the unexpected question marks.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Suggest to extend ClockConstraints to ClockTypes

  • Key: MARTE-51
  • Legacy Issue Number: 11696
  • Status: closed  
  • Source: INRIA ( Charles Andre)
  • Summary:

    in the Time model, ClockConstraint is defined by
    "A ClockConstraint is a Constraint that imposes dependency between clocks."

    I suggest to extend ClockConstraints to ClockTypes.
    => "A ClockConstraint is a Constraint that imposes dependency between clocks or between clock types."

    This will allow more general constraints indirectly applied to all the clocks of a given type.

  • Reported: MARTE 1.0b1 — Thu, 29 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    I suggest adopting the extension

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.2

  • Key: MARTE-48
  • Legacy Issue Number: 11692
  • Status: closed  
  • Source: CEA-LIST ( TAHA Safouan)
  • Summary:

    In the HwCommunication model of the HwLogical profile, HwMedia should extend UML::Connector inspite of Association. Association in UML is a Classifier and the parent stereotype HwResource already extend it. By extending Connector we will help to use this concept within composite structure diagrams

  • Reported: MARTE 1.0b1 — Wed, 28 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with proposal.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.4.1

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

    The Automative Example uses stereotypes that are not defined in the specification (namely SignalSpecification and ServiceSpecification

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Disposition: See issue 11551 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.2.1

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

    It would probably be clearer if the BFeatureKind enumeration only proposes REQUIRED and PROVIDED enumeration literals (that is to say “qualifiers” that are already used and widely accepted in the UML to denote “direction” of signals and operations in message-oriented communications). IN, OUT, INOUT should be reserved to FlowPorts and FlowProperties (that is to say for data-flow communication schemes).

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Disposition: See issue 11661 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.3.2

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

    FlowPort and MessagePort stereotypes have two common tagged values: isAtomic and isConjugated. These two properties could be inherited from a common ancestor stereotype (for example, an abstract InteractionPort stereotype).

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Disposition: See issue 11658 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor edits to MARTE Chapter 17

  • Key: MARTE-37
  • Legacy Issue Number: 11649
  • Status: closed  
  • Source: Carleton University ( Murray Woodside)
  • Summary:

    p 311 Fig 17.2 The name of the package should be PAM_Resources

    also on the left halfway down the Fig, troughput --> throughput

    p 312 line 2 resources).... end bracket is missing.

    p 314 line 2 Figure 17.4

    line 14 "a message transmission is defined within the UML model, but if no network is specified it is an external service". Wording clarified.

    p 317 Fig 7.6 CommunicationStep inherits from PAM_Workload::PAM_Step. The attributes are inherited and can be eliminated from this figure.

    p 322 line 10 "identity of the resource" spelling

    p 325 sec 17.4.1 para 2 line 1 "In Figure 17.9 the blockT attribute of the LAN" corrected fig number, attribute name, plus clarification.

    p 325 fig 17.10 stereotype on database should be <<PaRunTInstance>>, same as for web

    p 326 first line after Fig 17.10: "In Figure 17.10 a simple sequence diagram"...wrong number

    second para after Fig 17.10, delete the last sentence, it refers to something in the example that was changed.

    third para, replace ExecStep by Step (two occurrences, plus another on p 327 line 1)

    Figure 17.13, in the box labelled dbReq, under the label should be "12.4 ms"

    p 329 last line, complette the sentence: "The behavior is shown in figure 17.15".

    p 330, Fig 17.15, two annotations near the bottom have "$images" which should be just "images"

    p 331 first sentence "with that a set" --> with a set" and add at the end "(with 95% probability)"

    p 332 para 2 line 1, replace "Process stereotypes" by "RunTInstance stereotypes"

    p 332 Fig 17.17 in the attributes of the <<GaWorkloadEvent>> stereotype the cycleTime95 variable should be preceded by "out$" (it is declared here, and it is an analysis output)

    lower in Fig 17.17 the $ sign should be removed from variables acquireThreads, frameSize, blocks, storeThreads, DBThreads. (they are declared in the context)

    p 333 para 2 delete the paragraph (it refers to aspects of the example that have been changed)

    p 335 line 2 Figure 17.21, three instances in the para

    p 336 Fig 17.21, the two <<PaProcess>> --> <<RunTInstance>>

    also in the context at the top "contextParams=$messageSize"

    below the figure, Figure 17.21 --> 17.22 and 17.22 --> 17.23

    p 337 Figure 17.22 <<PaProcess>> --> <<RunTInstance>> twice,

    also in the attributes, "runTInstance = webserver" --> "instance = webserver" (was not adapted to a change in definitions during profile development)

    and similarly "runTInstance = App" --> "instance = application"

    below Figure 17.23, increase Fig numbers by 1 (twice)

    p 338 bottom ...Figure 17.25

    p 339 line 1 Figure 17.25

    line 2, add to end of sentence "Figure 17.26."

    Figure 17.26 legend ends with "hierarchy of Figure 17.25" (no (b))

    p 340 para 2, Figure 17.26 --> 17.27 and 17.14 --> 17.15

    p 341 Figure 17.27 top: two instances of @Nusers should be $Nusers the first time, then Nusers.

    p 342 para 1, add a sentence for clarification:

    "The Markov Chain is solved to provide the steady state probabilities of each state, and thus of each behavior in the combined workload."

  • Reported: MARTE 1.0b1 — Sun, 11 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Editorial changes as follows.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex B.2.4

  • Key: MARTE-36
  • Legacy Issue Number: 11644
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Inconsistency between the VSL BNF and metamodel (Variable declaration) In the VSL annex, Figure B.4 (VSL::Expressions package) indicates that a Variable has "direction" property: VariableDirectionKind [0..1]. On the other hand, in the BNF, the <variable-direction> term is not between brackets, which means that it is a mandatory term. Proposed resolution: either we update the BNF or we change the multiplicity of the direction property in the metamodel.

  • Reported: MARTE 1.0b1 — Tue, 6 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    As far as the variable direction is optional, as described in the metamodel, the grammar should be revised and modified with the brackets for the <variable-direction> term.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.1 (data reception)

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

    The FlowSendAction concept is introduced to enable sending of data via a FlowPort. It seems that there is no equivalent concept (action) for data reception. If a given behavior has to be expressed according to data arriving from an input port, how is the behavior “notified” that a data is available on this port (I mean: is there something equivalent to AcceptCallAction used for service oriented communication schemes)? Once that the notification has occurred in one way or another, do we access to this data with something like a ReadStructuralFeatureAction (because ports are structural features)?

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Disposition: See issue 11840 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.1

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

    In the UML, a “Provided or Required” direction is implicitly associated to Signals that are exposed on the ports of a structured class or component (via the provided or required interfaces of the port). For UML consistency purpose, the “direction” attributes of SignalFeature and MessagePort should be typed by an enumeration like BFeatureKind (which is defined in the UML representation section), only with PROVIDED and REQUIRED enumeration literals. In other words, the DirectionKind enumeration (with enumeration literals IN, OUT and INOUT) should be reserved to FlowPorts, and used only to type “direction” attributes of FlowPort and FlowProperties classes.

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with suggested resolution in the profile definition and the domain model.
    Related issues: 11666, 11551

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Class descriptions are missing

  • Key: MARTE-29
  • Legacy Issue Number: 11554
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Class descriptions are missing in the MARTE model library for extended datatypes (Annex D2).

  • Reported: MARTE 1.0b1 — Tue, 9 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We describe a subset that requires unambiguous definition. The remaining extended data types are self-explanatory.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15.3.1

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

    Inconsistency between GCAM profile definition and SAM example In Figure 16.14, the stereotype <<GaResourcesPlatform>> is applied on a part (i.e. a UML property) of the TeleoperatedRobotSAM composite class. Meanwhile, in Figure 15.6, it seems that this stereotype extends only UML::Classifier. Proposed resolution: either we remove the stereotype from the SAM example or we allow the stereotype <<GaResourcesPlatform>> to extend UML::Classifier and UML::Property. The second option would make sense to me.

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

    The stereotypes are to be removed from the example.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 15/3

  • Key: MARTE-32
  • Legacy Issue Number: 11620
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The stereotype <<gaEventTrace>> defines stereotype attributes: content, format, location that are not defined in the domain model (p. 263). I would suggest adding a definition of these attributes in the EventTrace domain class.

  • Reported: MARTE 1.0b1 — Tue, 16 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Add definitions to the text of the domain model

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: GRM / 10.3.1

  • Key: MARTE-8
  • Legacy Issue Number: 11411
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The GRM packages defines a <<SchedulableResource>> stereotype. The SRM package, which is presented as a specialization of GRM to model software resources, defines a stereotype with a similar name: <<SwSchedulableResource>>. However, there is no direct link between these two stereotypes. GRM::SchedulableResource directly specializes GRM::Resource, while SRM::SwSchedulableResource specializes SRM::SwConcurencyResource, which specializes SRM::SwResource, which specializes GRM::Resource. Stereotypes have quite similar name, which may think of related concepts. However, their use and their related stereotype attributes are quite different.

  • Reported: MARTE 1.0b1 — Fri, 14 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Make stereotype SwSchedulableResource inherit from SchedulableResource. Since this
    inheritance is already present in the domain view, the sections to modify comprise only
    the UML representation of SRM.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

concept of "resource"

  • Key: MARTE-7
  • Legacy Issue Number: 11402
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The General Resource Model of MARTE seems to define the concept of "resource" both at the instance and classifier levels. For instance, the GRM::Resource stereotype extends both InstanceSpecification and Classifier.

    The SwResource stereotype defined in the Software Resource Model of MARTE specializes the GRM::Resource stereotype. However, reading the SRM chapter, it seems that its use is much more focused on description of classifiers (to characterize properties or behavioral features for instance) than instances.

    In that context, does it make sense to apply a SRM::SwResource stereotype or one of its subclasses (for instance SRM::SwSchedulableResource) on an instance specification? Note that it seems to be legal given that SRM::SwResource specializes GRM::Resource, which extends InstanceSpecification.

    I would be pretty handy to do so, in order to describe a resource platform model provided in input of a scheduling analysis.

  • Reported: MARTE 1.0b1 — Thu, 13 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Complete the paragraph 7.3 with the rules for the default values of attributes of the stereotypes for instance of classifiers also stereotyped.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

grammar defined for conditional expressions

  • Key: MARTE-20
  • Legacy Issue Number: 11545
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The grammar defined for conditional expressions does not allow one to use operation call expressions in the condition predicate. The BNF defines only <condition-expr> ::= <variable-declaration> | <variable-call-expr> | <property-call-expr> As a consequence, it is not possible to define predicates based on value comparison. Thus, it is not possible to implement the expression "(clock_rate>5)?(5):(clock_rate)", provided as example page 404.

  • Reported: MARTE 1.0b1 — Thu, 4 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We add a new terminal to the <condition-expr> rule, which is operation call expression. This allows us to specify: "(clock_rate>5)" which is an infix operation call of ">" in clock_rate.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex D

  • Key: MARTE-19
  • Legacy Issue Number: 11544
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Operators (e.g., +, -, *, /, =, <, >) are not defined for the types in the MARTE_Library::BasicNFP_Types package. Such operators are required if one wants to define expressions such as "(end - start) < (10, ms)" where "end" and "start" are ObsCallExpression, for instance. Ideally, all the operators defined for the MARTE_Library::MARTE_PrimitiveTypes types should also exist for their MARTE_Library::BasicNFP_Types counterpart

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    One aspect that appears here is that the operations for NFP types like
    NFP_Real, NFP_String, etc, should be the same as the primitive type
    counterparts. So, it seems natural to reuse those operation definitions. One
    mechanism to reuse the operations (e.g., +, -, *, /, =, <, >) is to inherit NFP types
    from the primitive types.
    Hence, this resolution proposes to define the operations of Nfp_Types by
    inheriting from the corresponding MARTE primitive types.
    In addition, the semantic of such NfpTypes operations (in physical Nfp_Types
    such as NFP_Duration, NFP_Temperature, etc.) are different than their primitive
    type counterparts (Real primitive types). Indeed, operations in NfpTypes involve
    evaluating not only the “value” part but also the measurement “unit” part. This is
    left out of the scope of this specification, and an implementation supporting
    measurement unit conversion should take care of this.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex B VSL BNF

  • Key: MARTE-23
  • Legacy Issue Number: 11548
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In the VSL BNF, the use of the "[ ]" symbol should not be limited to collections. One may want to use it along with variable call expressions (e.g. "collec[2]"), property call expressions. Maybe other kinds of value specifications also apply.

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The current mechanism of defining operations on data types allows one to define a given operation independently of the current value itself. For instance, a property could be typed by a Collection of Integers, and this collection could be specified by a Variable. So, we can apply to this variable, all the operations defined for Collections.

    This issue is also related to Issue 11547, and do not need any modification in the spec.

    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

VSL meta-model

  • Key: MARTE-22
  • Legacy Issue Number: 11547
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The VSL BNF defines a "[ ]" symbol that can be used along with a collection. The specification introduces the example: "

    {'a', 'b', 'c', 'd'}

    [2]". However, there is no related concept (access to a collection) in the VSL meta-model.

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    This notation (to get collection elements by using the index), comes from the TVL language in SPT, but the mentioned example was not updated to the current VSL mechanism to define operations in data types. For that, VSL uses the same approach as OCL, so that the operation for finding an element in a given collection should be defined and described at library level, in the operations of the concerned data types (collections in this case). The specification of the function will be allowed by using OperationCallExpression.

    The resolution is to remove the proposed examples from VSL.

    If new operations are required for Collections in the MARTE library of data types, this should be solved by posting a separated issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex B3.3.3

  • Key: MARTE-5
  • Legacy Issue Number: 11339
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The <value-specification> rule references an <opaque-expression> rule that is not defined in the VSL grammar.

  • Reported: MARTE 1.0b1 — Tue, 11 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    VSL expressions are specified in OpaqueExpressions. Adding new opaque expressions within a VSL expression would make VSL expressions complex, and without a real added value. Hence, we do not support in VSL nested expressions written in new languages. Note that this doesn't mean that we do not allow one to extend VSL. VSL can be extended by reusing its metaclasses, as the Clock Constraint Language in MARTE.

    Hence, the term <opaque-expression> in the VSL grammar is not right. This resolution proposes to remove that term from the VSL grammar.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MARTE_Library::MeasurementUnits model library

  • Key: MARTE-4
  • Legacy Issue Number: 11338
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Chokri Mraidha)
  • Summary:

    MARTE_Library::MeasurementUnits model library contains following bugs. In FrequencyUnitKind enumeration baseUnit tag value specified is W instead of Hz. In LenghtUnitKind enumeration baseUnit tag value is m for mm literal. In AreaUnitKind enumeration baseUnit tag value is mm2 for um2 litreal. In DataTxRateUnitKind convaFactor is 1024 instead of 1E3.

  • Reported: MARTE 1.0b1 — Mon, 10 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Modify Figures D.3 according to proposed corrections.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

rtf stereotype

  • Key: MARTE-10
  • Legacy Issue Number: 11417
  • Status: closed  
  • Source: SODIUS ( Philippe Soulard)
  • Summary:

    rtf stereotype is the only one which name does not start with an upperCase. Should be Rtf (or RTF). Lack of coherency.

  • Reported: MARTE 1.0b1 — Tue, 18 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The name of the RealTimeFeature stereotype SHALL be "Rtf".

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: GRM / 10.3.1 - p 96

  • Key: MARTE-9
  • Legacy Issue Number: 11412
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The GRM package defines a <<MutualExclusionResource>> stereotype. The SRM package, which is presented as a specialization of GRM to model software resources, defines a stereotype with a similar name: <<SwMutualExclusionResource>>. However, there is no direct link between these two stereotypes. GRM::MutualExclusionResource directly specializes GRM::Resource, while SRM::SwMutualExclusionResource specializes SRM::SwSynchronizationResource, which specializes SRM::SwResource, which specializes GRM::Resource. Stereotypes have quite similar names, which may think of related concepts. However, their use and their related stereotype attributes are quite different.

  • Reported: MARTE 1.0b1 — Fri, 14 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Make stereotype SwMutualExclusionResource inherit from MutualExclusionResource.
    Since this inheritance is not present in the domain view, the sections to modify comprise
    both, the domain view, and the UML representation of SRM.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consider adding a new attribute to «boundedSubtype»

  • Key: MARTE-2
  • Legacy Issue Number: 11163
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Consider adding a new attribute to «boundedSubtype» to specify what the default value for the new type is. Something like <<boundedSubtype>>.defaultValue

  • Reported: MARTE 1.0b1 — Thu, 19 Jul 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Resolution:
    A BoundedSubtype, as other data types, defines a space of valid values. However, it doesn't describe any particular value property. Specifying a default value is to be done at property declaration level, and it's already supported by UML itself. This approach is natural from a pragmatic viewpoint (different properties typed by the proposed BoundedSubtypes could have different default values), and from the general practice in (modeling, programming) languages.

    For these reasons, we don't add default values for BoundedSubtype, or whatever data types.

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Profile for MARTE acronym list

  • Key: MARTE-1
  • Legacy Issue Number: 11112
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The MARTE spec has a large number of Acronyms.

    Some (e.g. MARTE) are not expanded anywhere in the spec.

    It would be helpful to the reader to have a common section of the document to fully expand all acronyms used in the spec.

    Proposed resolution:
    Place a table of acronym expansions in the now empty Symbols section of the spec (perhaps relabeling the section as Symbols and Acronyms)

  • Reported: MARTE 1.0b1 — Tue, 26 Jun 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming conventions and typing errors

  • Key: MARTE-3
  • Legacy Issue Number: 11337
  • Status: closed  
  • Source: SODIUS ( Philippe Soulard)
  • Summary:

    Naming conventions and typing errors: - MARTE::MARTE_Foundations::GRM::GRService -> GrService for coherence - MARTE_Library::GRM_BasicTypes::EDFParameters -> EDF_Parameters or EdfParameters - MARTE::MARTE_AnalysisModel::SAM::SaSchedObs::suspentions -> suspensions

  • Reported: MARTE 1.0b1 — Mon, 10 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The convention of using uppercase for the prefixes would have been more consistent with the English style, but it has been almost consistently used along the spec the capitalization of only the first letter to reduce space, for this reason is probably better to just correct GRService in GRM as well as EDFParameters suspentios is clearly a typo to correct.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex B3.3.3 p 397

  • Key: MARTE-6
  • Legacy Issue Number: 11340
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    A circular reference between the <value-specification> -> <time-expression> -> <instant-expr> -> <value-specification> rules prevents a straightforward implementation of the VSL BNF grammar.

  • Reported: MARTE 1.0b1 — Tue, 11 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    We modify the grammar for time expressions to prevent the circular reference.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 6/6.3

  • Key: MARTE-17
  • Legacy Issue Number: 11528
  • Status: closed  
  • Source: UFRGS - DELET ( WILSON PARDI JUNIOR)
  • Summary:

    In the first paragraph of sub-section 6.3.1 it is written "These are shown by the RTEM package in Figure 6.4, and the cluster of four AnalysisModelling packages, respectively". However, I see only three packages under the MARTE analysis model: GQAM, SAM, and PAM. Also I don't see the TCRM package (by the way, I presume that the RTEM and RTEMoCC are the same packages). Am I wrong at my assumptions?

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

    At the beginning, the Analysis package aims including an additional package dedicated to WCET analysis. At the end, this purpose was not achieved. So, this package contains at last only 3 packages => text need to be revised as described in the next section.
    In general, the figure 6.4 reflects correctly the current architecture of the MARTE extensions but the text put on top of this figure needs to be updated to take into account the final name of the package as described in the figure.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 6/6/2/1

  • Key: MARTE-16
  • Legacy Issue Number: 11527
  • Status: closed  
  • Source: UFRGS - DELET ( WILSON PARDI JUNIOR)
  • Summary:

    In the first paragraph of section 6.2.1 is written "...it is possible to give some general descriptions of four main sub categories included in the RT/E domain category...". However, five domains are described: - Embedded domain - Reactive domain - Control/Command domain - Intensive data flow computation domain - Best-effort service domain Also, only the 'Intensive data flow computation domain' is sub-sectioned as 6.2.1.1 (how about the other domains?)...

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

    The resolution of this issue consists in making the required editorial changes as described in the next section.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex D3 MARTE model library for time

  • Key: MARTE-11
  • Legacy Issue Number: 11504
  • Status: closed  
  • Source: INRIA ( Charles Andre)
  • Summary:

    In Annex D3 MARTE model library for time, 2 enumerations (EventKind and TimeStandardKind) have to be moved from the Time library to the TimeTypesLibrary, because these enumerations are used in the profile definition.

  • Reported: MARTE 1.0b1 — Thu, 20 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with the proposed modifications.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

non-terminal symbol

  • Key: MARTE-25
  • Legacy Issue Number: 11550
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The VSL grammar introduces a non-terminal symbol <namespace> in the syntax definition of property call expression and variable call expression. However, this symbol seems to be missing in the syntax definition of enumeration specification as well as observation call expression. As a consequence, it is not possible to reference without ambiguity two time instant observations with the same name but with different fully qualified names. That prevents from using observations with similar names in different packages.

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    For the case of Enumeration specification, it is not necessary to specify the namespace. Enumerations values are always related to a typed property or tag definition. The type of those properties or tag definitions (an Enumeration data type) defines the scope of the enumeration literal specified.
    For the case of Observation Call Expression, the namespace is missing. This resolution proposes to add such a namespace.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The VSL grammar does not define the "( )" symbol

  • Key: MARTE-24
  • Legacy Issue Number: 11549
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The VSL grammar does not define the "( )" symbol that allows one to indicate priorities in the syntax of arithmetical expressions. In the expression, "((1+2) * 3)" for instance.

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    To allow building unambiguous expressions (mainly arithmetical ones), the
    language should include both proper rules supporting parentheses (i.e., “(“ and
    “)”) as well as precedence rules to specify the order in operations evaluation.
    In VSL, these aspects concern two different sections of MARTE. Parentheses
    need to be specified in the VSL grammar section, and precedence rules in the
    library of primitive types. The latter is because “operations” (e.g., arithmetic
    operations: +, -, *, /) are defined as operations of MARTE primitive types (Real,
    Integer, etc.).
    Hence, this resolution proposes to add/modify VSL as defined below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

automotive example

  • Key: MARTE-26
  • Legacy Issue Number: 11551
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    The automotive example still uses stereotypes that have been renamed in the lastest versions of the document (e.g. <<msgPort>> instead of <<messagePort>>, <<serviceSpecification>> and <<signalSpecification>> instead of <<bFeatureSpecification>>). Such inconsistencies appear in diagrams and descriptions.

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    1) Remove references to the msgPort stereotype and replace by the messagePort stereotype.
    2) Remove references to the serviceSpecification and signalSpecification and replace by the bFeatureSpecification stereotype.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 14.70 - HwCommunication package details

  • Key: MARTE-13
  • Legacy Issue Number: 11521
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Yann Tanguy)
  • Summary:

    Lack of homogeneity in the enumeration litterals naming (considering the rest of the document) : - litteral should start with lowercase - "undef" should be used instead of "undefined"

  • Reported: MARTE 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed in all the figures affected by this issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

the property named "isSynchronous" is misspelled

  • Key: MARTE-12
  • Legacy Issue Number: 11520
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Yann Tanguy)
  • Summary:

    On the stereotype HwBus in the diagram, the property named "isSynchronous" is mispelled ("isSynchrnous")

  • Reported: MARTE 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed in both Domain Model and Profile Definition.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 6/6.4

  • Key: MARTE-18
  • Legacy Issue Number: 11529
  • Status: closed  
  • Source: UFRGS - DELET ( WILSON PARDI JUNIOR)
  • Summary:

    There a lot of spelling errors in the section 6.4.1: - "...; chapter 0, General Component Model, introdces a general componenet model suitable for RTES." should be rewritten as "...; chapter 11, General Component Model, introduces a general component model suitable for RTES." - "..., chapter 13, RTE Model of Compuation and Communication, ..." should be rewritten as "..., chapter 13, RTE Model of Computation and Communication, ..." - "It does not intend to define new analmysis technologies, but to define the information required for annotation models on whoch external analysis techniques may be applied." should be rewritten as "It does not intend to define new analysis technologies, but to define the information required for annotation models on which external analysis techniques may be applied." - "..., specializes the generic framework for performaing schedulability analysis, whereas ..." should be rewritten as "..., specializes the generic framework for performing schedulability analysis, whereas ..."

  • Reported: MARTE 1.0b1 — Thu, 4 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Do editiorial change as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Annex B

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

    Invalid reference in caption of Figure B.1. The caption of Figure B.1 is currently "Figure B.1 - Structure of the NFP framework" when it should be "Figure B.1 - Structure of the VSL framework".

  • Reported: MARTE 1.0b1 — Thu, 25 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Revise caption of Figure B.1

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14.2.3

  • Key: MARTE-34
  • Legacy Issue Number: 11632
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    << tupleType >> stereotypes would need to be added on HRM datatypes, to enable the use of VSL expressions. The UML representation section of HRM defines several datatypes (Timing, CacheStructure, PLD_Organisation, MemoryOrganisation, Env_Condition) that are not stereotyped as << tupleType >>. As a consequence, it is not possible to edit properties typed by these datatypes as VSL expressions. Proposed resolution: to apply the << tupleType >> stereotype on every datatype defined in HRM.

  • Reported: MARTE 1.0b1 — Thu, 25 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Proceed with the modification of all the datatypes with tupletype in the HRM chapter.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 14/2

  • Key: MARTE-31
  • Legacy Issue Number: 11619
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In HRM, a stereotype called HwResource is used in the HwLogical subpackage to provide a logical representation of a hardware resource. At the same time, a stereotype with the name is used in the HwPhysical subpackage to provide a physical representation of a hardware resource. Although it is legal in this context, defining two stereotypes with the same names that have different semantics may create confusion in a user's mind. I would suggest renaming HwResource into HwLogicalResource / HwPhysicalResource. The same thing applies for HwLogical::HwResourceService and HwPhysical::HwResourceService.

  • Reported: MARTE 1.0b1 — Tue, 16 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Class descriptions are missing in the MARTE model library for GRM (Annex D4

  • Key: MARTE-30
  • Legacy Issue Number: 11555
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Class descriptions are missing in the MARTE model library for GRM (Annex D4).

  • Reported: MARTE 1.0b1 — Tue, 9 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    These Class descriptions are in section 10.3.3. They can be referenced from the annex or move to the annex and referenced in section 10.3.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.1 figure 11.4

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

    In figure 11.4, MessagePort is represented as an abstract class (“italic”). According to the description written in the spec, there is no particular reason to do that. This class should be represented as a concrete class

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    Update Figure 11.4 to represent MessagePort as a concrete class (no italic).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.1

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

    The ability to type FlowPorts by Signals (or by FlowSpecifications containing FlowProperties typed by Signals) is confusing. MessagePorts (which are just a light specialization of UML ports) already enable signal-based communications. Things would be clearer if FlowPorts would only enable data-flow communications, and if MessagePorts would be used for service or signal-based communications (just as classical UML ports are). I suppose that this feature is inherited from SysML, but this is however confusing in the context of UML

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GRM::SchedulableResource should not have a property "host:ExecutionHost"

  • Key: MARTE-27
  • Legacy Issue Number: 11552
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    In the class diagram, the GRM::SchedulableResource should not have a property "host:ExecutionHost" (defined in QGAM). There is no dependency from GRM to GQAM, therefore the "host" property cannot be typed by "ExecutionHost". Moreover, GRM::SchedulableResource already has a property called "host: Scheduler". In that context, I would suggest just removing the "host: ExecutionHost" property from SchedulableResource in Figure 15.5.

  • Reported: MARTE 1.0b1 — Tue, 9 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    To add an inheritance from scheduler in figure 15.5 for both executionHost and communicationHost. Then the association between SchedulableResource and executionHost is the same that already exist in GRM to scheduler. The scheduler in communicationHost is easy to justify as the arbitration/protocol that gives to each message access to the media.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

no explicit dependency to QVT concepts

  • Key: MARTE-28
  • Legacy Issue Number: 11553
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    It is stated that MARTE uses "MOF 2.0 Queries, Views, and Transformation framework to define any model transformation rules...". Additionally, Figure 6.1 shows a <<use>> dependency between MARTE and QVT. However, no explicit dependency to QVT concepts has been used/found in this document.

  • Reported: MARTE 1.0b1 — Tue, 9 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    The comment is correct. I suggest then to modify the text of the first paragraph of the section 6.1 and modify the figure 6.1 in order to suppress this reference to MOF QVT.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong references in page 397

  • Key: MARTE-21
  • Legacy Issue Number: 11546
  • Status: closed  
  • Source: THALES ( Sebastien Demathieu)
  • Summary:

    Wrong references in page 397 : "The nature of these mechanisms is described in chapters Model Processing and The Model Configurer on page X-X" and "we use the standard BNF notational convention defined in Annex X". The chapters "Model Processing" and "The Model Configurer" may not exist anymore in the Beta 1 version.

  • Reported: MARTE 1.0b1 — Mon, 8 Oct 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    I suggest to remove these sentences that contain old (SPT) references.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 2/2.2

  • Key: MARTE-15
  • Legacy Issue Number: 11526
  • Status: closed  
  • Source: UFRGS - DELET ( WILSON PARDI JUNIOR)
  • Summary:

    "The extensionUnits defined in this specification..." should be written as "The Extension Units defined in this specification..."

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

    Text to update according to the previous proposal. DDDDDDwxvcx

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The type NFP_Price does not exist in the document.

  • Key: MARTE-14
  • Legacy Issue Number: 11522
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Mr. Yann Tanguy)
  • Summary:

    HwComponent stereotype has a property named "price" typed by "NFP_Price". The type NFP_Price does not exist in the document.

  • Reported: MARTE 1.0b1 — Wed, 26 Sep 2007 04:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    To add the nfpType NFP_Price in Annex D.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.1

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

    FlowPort and MessagePort are subclasses of InteractionPort. These two classes have common properties: isConjugated and isAtomatic (there is actually a third one, “direction”, but I think there is an issue with this property). These properties could be directly defined as properties of the common parent class, i.e. InteractionPort.

  • Reported: MARTE 1.0b1 — Tue, 20 Nov 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT