UML Profile for MARTE Avatar
  1. OMG Specification

UML Profile for MARTE — Closed Issues

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

Issues Summary

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

Issues Descriptions

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

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

    The stereotype GRM::SchedulableResource should have an attribute describing its activation parameters (arrival pattern and parameters). This is useful in multi-rate systems, where, in addition to the activations defined at application level (activation events triggering action/event chains), OS tasks/threads can be defined with a given activation rate. For instance, almost all automotive systems are multi-rate systems. Even if the functional application appears as a single rate system, multiplexing mechanisms both in the communication or in data sampling mechanisms can induce to more complicated timing behaviors, which are a characteristics of multi-rate systems.

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

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

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

MARTE/section 7.2.1/ "No Metamodel root" bug

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

    The metamodel can not be executed/implemented since their is no root
    element in the metamodel. It would be useful to introduce the
    packageableElement, Model (A model owns * PackageableElements). This
    addition has several consequences on other parts of the metamodel in
    order for this latter to be used for instance to create MARTE model
    conforms to the MARTE metamodel.

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

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

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

Example in Figure 10.21 makes use of directed arrows

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

    The example in Figure 10.21 makes use of directed arrows to represent connectors in a composite structure. Moreover, it seems that the element inside the composite structure look more like classes than parts.

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

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

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

align the notation section of 11.3.2.7 to the profile diagram.

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

    The notation section of 11.3.2.7 makes use of stereotypes that are inconsistent with the profile diagram. Proposed resolution: align the notation section of 11.3.2.7 to the profile diagram.

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

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

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

associations between Instance and ModelElement (subclasses)

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

    On fig. 7.6 three association between Instance and ModelElement (subclasses) have properties subsetted "type", but the "type" property only appear between Instance and Classifier (not ModelElement) fig. 7.3.

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

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

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

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

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

    A simplification of GRM should be envisaged.
    GRM defines too many detailled concepts (for instance the Scheduler which seems more
    appropriate in the SRM package), these concepts could be defined in
    SRM or HRM package or even in SAM package.

    The way to define different types of services need to be aligned between GRM, SRM
    and HRM.

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

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

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

Section: 10/3

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

    The GRM::Resource stereotype (and its specializations in GRM, SRM, HRM, such as HRM::HwProcessor) extends the following UML metaclasses: Classifier, Property, InstanceSpecification, Lifeline, ConnectableElement. When modeling resources within a composite structure, one has the choice to : 1) apply the stereotype on a UML::Classifier, and then type the parts by this classifier 2) directly apply the stereotype on parts (UML::Property) 3) both 1) and 2) In the case of 3), the relationships between the stereotype attributes defined on the classifer and those defined on the parts need to be clarified. A possible answer would be to formulate the following: "a stereotype applied to an instance (part, instance specification, lifeline, connectable element) allows one to assign values that are instance-specific and which overrive the default values of the stereotype applied to the class".

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

    No Data Available

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

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

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

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

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

    See issue 13126 for disposition

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

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

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

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

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

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

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

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

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

Marte: consistent capitalization of stereotypes in Sec 17.4

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

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

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

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

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

Typos in example Figures 17.15/16/17/27

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

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

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

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

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

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

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

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

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

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

In HRM, the structure of the subprofile is ill formed

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

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

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

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

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

Missing attributes

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

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

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

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

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

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

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

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

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

    See issue 13408 for disposition

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

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

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

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

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

    See issue 13408 for disposition

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

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

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

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

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

    See issue 13408 for disposition

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

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

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

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

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

    See issue 13408 for disposition

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

In B.3.3.13, namespace must be replaced

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

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

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

    See issue 13408 for disposition

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

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

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

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

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

    See issue 13408 for disposition

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

Variable call expression and property call expression are ambiguous

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

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

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

    See issue 13408 for disposition

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

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

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

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

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

    See issue 13408 for disposition

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

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

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

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

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

    See issue 13408 for disposition

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

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

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

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

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

    See issue 13408 for disposition

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

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

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

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

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

    See issue 13408 for disposition

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

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

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

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

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

    See issue 13408 for disposition

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

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

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

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

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

    See issue 13408 for disposition

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

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

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

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

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

    See issue 13408 for disposition

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

Section B.3.3.3 is duplicated.

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

    Section B.3.3.3 is duplicated.

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

    See issue 13408 for disposition

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

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

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

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

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

    See issue 13408 for disposition

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

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

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

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

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

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

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

FlowPort stereotype

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

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

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

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

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

The notion of value is missing the NFP_Declaration domain model Description

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

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

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

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

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

ARINC 653 Annex of MARTE

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

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

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

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

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

The dependency between NFP and VSL is not necessary

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GCM Classes Description in Annex should be revised:

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

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

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

    See issue 13125 for disposition

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

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

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

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

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

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

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

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

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

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

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

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

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

MARTE/RSM/repetition index port missing

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

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

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

    No Data Available

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

MARTE/RSM/generalization of the reshape stereotype

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

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

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

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

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

inconsistencies in the HLAM subprofile

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

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

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

    See issue 11838 for disposition

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

Figure 13.1 (pg 149)

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

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

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

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

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

Section: Annex D

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

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

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

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

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

Figure12.4 is wrong

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

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

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

    See issue 13125 for disposition

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

Section: GQAM-SAM-PAM

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

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

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

    No Data Available

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

Figure 16.6: multiplicity

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

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

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

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

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

definition of ResourceUsage (F.4.27) in annex F

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

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

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

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

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

NFP_Type

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

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

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

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

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

concrete syntax

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

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

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

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

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

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

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

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

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

    See issue 11820 for disposition

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

Clarification in chapter "General Component Model" needed

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

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

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

    See issue 11820 for disposition

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

MARTE aligment with SYSML 1.1

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

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

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

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

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

check UML 2.2 modifications impacts on MARTE Metamodel and definitions

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

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

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

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

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

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

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

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

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

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

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

rteConnector concept

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

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

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

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

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

Fig 15-7 shows that GaCommStep has the property

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

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

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

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

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

ordered association "subUsages"

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

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

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

    Add the

    {ordered}

    quality to the subUsages association depicted in Figure 10.18

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

property 'msgSize' in figure 15-7

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

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

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

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

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

MARTE profile-library interdependency should be revised and enhanced

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

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

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

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

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

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

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

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

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

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

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

typos in section E.3.2

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

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

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

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

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

Missing illustration for "Shape" and "reshape" stereotype

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

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

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

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

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

MARTE Beta: 12.3.2.4 FlowBFeature issue # 2

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

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

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

    See issue 11820 for disposition

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

MARTE Beta: 12.3.2.4 FlowBFeature issue # 1

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

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

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

    See issue 11820 for disposition

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

Annex 3

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

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

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

    This resolution provides a revised text that completes Annex 3.

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

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

  • Key: MARTE-187
  • Legacy Issue Number: 12238
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( 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 ( 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

SAM: General

  • Key: MARTE-70
  • Legacy Issue Number: 11780
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • 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 ( Huascar Espinoza)
  • 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

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

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

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

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

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

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

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 ( 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

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

NFP: value syntax

  • Key: MARTE-71
  • Legacy Issue Number: 11781
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • 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

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

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

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

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

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

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

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

page 64 ClockConstraintSpecification

  • Key: MARTE-148
  • Legacy Issue Number: 12237
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( 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

Correct the inconsistency between the diagram and the text

  • Key: MARTE-147
  • Legacy Issue Number: 12233
  • Status: closed  
  • Source: Thematix Partners LLC ( 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

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

  • Key: MARTE-146
  • Legacy Issue Number: 12232
  • Status: closed  
  • Source: Thematix Partners LLC ( 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: Thematix Partners LLC ( 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

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

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

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

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

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

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

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

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

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

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

GQAM Domain view inheritances

  • Key: MARTE-171
  • Legacy Issue Number: 12418
  • Status: closed  
  • Source: Universidad de Cantabria ( 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

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

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

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

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

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

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

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

RTF stereotype

  • Key: MARTE-138
  • Legacy Issue Number: 12185
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( 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

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

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

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

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 ( 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

Support for Views or sets of profile annotations

  • Key: MARTE-128
  • Legacy Issue Number: 11883
  • Status: closed  
  • Source: Universidad de Cantabria ( 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 ( 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

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

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

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

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

"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

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

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

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 ( 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

Section: Annex A3

  • Key: MARTE-159
  • Legacy Issue Number: 12297
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( 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

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 ( 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

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

Section: Annex B (VSL)

  • Key: MARTE-154
  • Legacy Issue Number: 12248
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • 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 ( Huascar Espinoza)
  • 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

Section 16.2.2 (SAM)

  • Key: MARTE-152
  • Legacy Issue Number: 12246
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • 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 ( Huascar Espinoza)
  • 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

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

[SAM: Profile]

  • Key: MARTE-68
  • Legacy Issue Number: 11778
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • 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 ( Huascar Espinoza)
  • 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 ( Huascar Espinoza)
  • 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

GQAM: Domain Model & Profile (02)

  • Key: MARTE-65
  • Legacy Issue Number: 11775
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • 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 ( Huascar Espinoza)
  • 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

[GQAM: General]

  • Key: MARTE-63
  • Legacy Issue Number: 11773
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • 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 ( Huascar Espinoza)
  • 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 ( Huascar Espinoza)
  • 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 ( Huascar Espinoza)
  • 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 ( Huascar Espinoza)
  • 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 ( Huascar Espinoza)
  • 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

[Time] Fig. 9.29

  • Key: MARTE-57
  • Legacy Issue Number: 11766
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • 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 ( Huascar Espinoza)
  • 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 ( Huascar Espinoza)
  • 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

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

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