Issues for UML Profile for MARTE Finalization Task Force

To comment on any of these issues, send email to marte-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 11112: UML Profile for MARTE acronym list (marte-ftf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom@coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

The MARTE spec has a large number of Acronyms.


Some (e.g. MARTE) are not expanded anywhere in the spec.


It would be helpful to the reader to have a common section of the document to fully expand all acronyms used in the spec.


Proposed resolution:
Place a table of acronym expansions in the now empty Symbols section of the spec (perhaps relabeling the section as Symbols and Acronyms)

Resolution:
Revised Text:
Actions taken:
June 26, 2007: received issue

Issue 11163: Consider adding a new attribute to ŤboundedSubtypeť (marte-ftf)

Click here for this issue's archive.
Source: The MathWorks (Mr. Alan Moore, alan.moore@mathworks.co.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Consider adding a new attribute to ŤboundedSubtypeť to specify what the default value for the new type is.  Something like <<boundedSubtype>>.defaultValue

Resolution:
Revised Text:
Actions taken:
July 19, 2007: received issue

Issue 11337: Naming conventions and typing errors (marte-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Naming conventions and typing errors: - MARTE::MARTE_Foundations::GRM::GRService -> GrService for coherence - MARTE_Library::GRM_BasicTypes::EDFParameters -> EDF_Parameters or EdfParameters - MARTE::MARTE_AnalysisModel::SAM::SaSchedObs::suspentions -> suspensions

Resolution:
Revised Text:
Actions taken:
September 10, 2007: received issue

Issue 11338: MARTE_Library::MeasurementUnits model library (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA/LIST (Mr. Chokri Mraidha, chokri.mraidha@cea.fr)
Nature: Clarification
Severity: Significant
Summary:

MARTE_Library::MeasurementUnits model library contains following bugs. In FrequencyUnitKind enumeration baseUnit tag value specified is W instead of Hz. In LenghtUnitKind enumeration baseUnit tag value is m for mm literal. In AreaUnitKind enumeration baseUnit tag value is mm2 for um2 litreal. In DataTxRateUnitKind convaFactor is 1024 instead of 1E3.

Resolution:
Revised Text:
Actions taken:
September 10, 2007: received issue

Issue 11339: Section: Annex B3.3.3 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

The <value-specification> rule references an <opaque-expression> rule that is not defined in the VSL grammar.

Resolution:
Revised Text:
Actions taken:
September 11, 2007: received issue

Issue 11340: Section: Annex B3.3.3 p 397 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

A circular reference between the <value-specification> -> <time-expression> -> <instant-expr> -> <value-specification> rules prevents a straightforward implementation of the VSL BNF grammar.

Resolution:
Revised Text:
Actions taken:
September 11, 2007: received issue

Issue 11402: concept of "resource" (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

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

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


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

Resolution:
Revised Text:
Actions taken:
September 13, 2007: received issue

Issue 11411: Section: GRM / 10.3.1 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 14, 2007: received issue

Discussion:

Issue 11412: Section: GRM / 10.3.1 - p 96 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 14, 2007: received issue

Issue 11417: rtf stereotype (marte-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

rtf stereotype is the only one which name does not start with an upperCase. Should be Rtf (or RTF). Lack of coherency.

Resolution:
Revised Text:
Actions taken:
September 18, 2007: received issue

Issue 11504: Annex D3 MARTE model library for time (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Charles Andre, Charles.ANDRE@unice.fr charles.andre@unice.fr andre@unice.fr)
Nature: Uncategorized Issue
Severity:
Summary:

In Annex D3  MARTE model library for time, 2 enumerations (EventKind and TimeStandardKind) have to be moved from the Time library to the TimeTypesLibrary, because these enumerations are used in the profile definition.

Resolution:
Revised Text:
Actions taken:
September 20, 2007: received issue

Issue 11520: the property named "isSynchronous" is misspelled (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA/LIST (Mr. Yann Tanguy, yann.tanguy@cea.fr)
Nature: Clarification
Severity: Minor
Summary:

On the stereotype HwBus in the diagram, the property named "isSynchronous" is mispelled ("isSynchrnous")

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11521: Figure 14.70 - HwCommunication package details (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA/LIST (Mr. Yann Tanguy, yann.tanguy@cea.fr)
Nature: Clarification
Severity: Minor
Summary:

Lack of homogeneity in the enumeration litterals naming (considering the rest of the document) : - litteral should start with lowercase - "undef" should be used instead of "undefined"

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Issue 11522: The type NFP_Price does not exist in the document. (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA/LIST (Mr. Yann Tanguy, yann.tanguy@cea.fr)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 26, 2007: received issue

Discussion:

Issue 11526: Section 2/2.2 (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

"The extensionUnits defined in this specification..." should be written as "The Extension Units defined in this specification..."

Resolution:
Revised Text:
Actions taken:
October 3, 2007: received issue

Issue 11527: Section 6/6/2/1 (marte-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In the first paragraph of section 6.2.1 is written "...it is possible to give some general descriptions of four main sub categories included in the RT/E domain category...". However, five domains are described: - Embedded domain - Reactive domain - Control/Command domain - Intensive data flow computation domain - Best-effort service domain Also, only the 'Intensive data flow computation domain' is sub-sectioned as 6.2.1.1 (how about the other domains?)...

Resolution:
Revised Text:
Actions taken:
October 3, 2007: received issue

Issue 11528: Section 6/6.3 (marte-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In the first paragraph of sub-section 6.3.1 it is written "These are shown by the RTEM package in Figure 6.4, and the cluster of four AnalysisModelling packages, respectively". However, I see only three packages under the MARTE analysis model: GQAM, SAM, and PAM. Also I don't see the TCRM package (by the way, I presume that the RTEM and RTEMoCC are the same packages). Am I wrong at my assumptions?

Resolution:
Revised Text:
Actions taken:
October 3, 2007: received issue

Issue 11529: Section 6/6.4 (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

There a lot of spelling errors in the section 6.4.1: - "...; chapter 0, General Component Model, introdces a general componenet model suitable for RTES." should be rewritten as "...; chapter 11, General Component Model, introduces a general component model suitable for RTES." - "..., chapter 13, RTE Model of Compuation and Communication, ..." should be rewritten as "..., chapter 13, RTE Model of Computation and Communication, ..." - "It does not intend to define new analmysis technologies, but to define the information required for annotation models on whoch external analysis techniques may be applied." should be rewritten as "It does not intend to define new analysis technologies, but to define the information required for annotation models on which external analysis techniques may be applied." - "..., specializes the generic framework for performaing schedulability analysis, whereas ..." should be rewritten as "..., specializes the generic framework for performing schedulability analysis, whereas ..."

Resolution:
Revised Text:
Actions taken:
October 4, 2007: received issue

Issue 11530: first sentence of sub-section 6.4.2 (marte-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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.

Resolution:
Revised Text:
Actions taken:
October 4, 2007: received issue

Issue 11544: Annex D (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

Operators (e.g., +, -, *, /, =, <, >) are not defined for the types in the MARTE_Library::BasicNFP_Types package. Such operators are required if one wants to define expressions such as "(end - start) < (10, ms)" where "end" and "start" are ObsCallExpression, for instance. Ideally, all the operators defined for the MARTE_Library::MARTE_PrimitiveTypes types should also exist for their MARTE_Library::BasicNFP_Types counterpart

Resolution:
Revised Text:
Actions taken:
October 8, 2007: received issue

Issue 11545: grammar defined for conditional expressions (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
October 8, 2007: received issue

Issue 11546: Wrong references in page 397 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

Wrong references in page 397 : "The nature of these mechanisms is described in chapters Model Processing and The Model Configurer on page X-X" and "we use the standard BNF notational convention defined in Annex X". The chapters "Model Processing" and "The Model Configurer" may not exist anymore in the Beta 1 version.

Resolution:
Revised Text:
Actions taken:
October 8, 2007: received issue

Issue 11547: VSL meta-model (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

The VSL BNF defines a "[ ]" symbol that can be used along with a collection. The specification introduces the example: "{'a', 'b', 'c', 'd'} [2]". However, there is no related concept (access to a collection) in the VSL meta-model.

Resolution:
Revised Text:
Actions taken:
October 8, 2007: received issue

Issue 11548: Annex B VSL BNF (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

In the VSL BNF, the use of the "[ ]" symbol should not be limited to collections. One may want to use it along with variable call expressions (e.g. "collec[2]"), property call expressions. Maybe other kinds of value specifications also apply.

Resolution:
Revised Text:
Actions taken:
October 8, 2007: received issue

Issue 11549: The VSL grammar does not define the "( )" symbol (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

The VSL grammar does not define the "( )" symbol that allows one to indicate priorities in the syntax of arithmetical expressions. In the expression, "((1+2) * 3)" for instance.

Resolution:
Revised Text:
Actions taken:
October 8, 2007: received issue

Issue 11550: non-terminal symbol <namespace> automotive example (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

The VSL grammar introduces a non-terminal symbol <namespace> in the syntax definition of property call expression and variable call expression. However, this symbol seems to be missing in the syntax definition of enumeration specification as well as observation call expression. As a consequence, it is not possible to reference without ambiguity two time instant observations with the same name but with different fully qualified names. That prevents from using observations with similar names in different packages.

Resolution:
Revised Text:
Actions taken:
October 8, 2007: received issue

Issue 11551: automotive example (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

The automotive example still uses stereotypes that have been renamed in the lastest versions of the document (e.g. <<msgPort>> instead of <<messagePort>>, <<serviceSpecification>> and <<signalSpecification>> instead of <<bFeatureSpecification>>). Such inconsistencies appear in diagrams and descriptions.

Resolution:
Revised Text:
Actions taken:
October 8, 2007: received issue

Issue 11552: GRM::SchedulableResource should not have a property "host:ExecutionHost" (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

In the class diagram, the GRM::SchedulableResource should not have a property "host:ExecutionHost" (defined in QGAM). There is no dependency from GRM to GQAM, therefore the "host" property cannot be typed by "ExecutionHost". Moreover, GRM::SchedulableResource already has a property called "host: Scheduler". In that context, I would suggest just removing the "host: ExecutionHost" property from SchedulableResource in Figure 15.5.

Resolution:
Revised Text:
Actions taken:
October 9, 2007: received issue

Issue 11553: no explicit dependency to QVT concepts (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

It is stated that MARTE uses "MOF 2.0 Queries, Views, and Transformation framework to define any model transformation rules...". Additionally, Figure 6.1 shows a <<use>> dependency between MARTE and QVT. However, no explicit dependency to QVT concepts has been used/found in this document.

Resolution:
Revised Text:
Actions taken:
October 9, 2007: received issue

Issue 11554: Class descriptions are missing (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
October 9, 2007: received issue

Issue 11555: Class descriptions are missing in the MARTE model library for GRM (Annex D4 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Enhancement
Severity: Minor
Summary:

Class descriptions are missing in the MARTE model library for GRM (Annex D4).

Resolution:
Revised Text:
Actions taken:
October 9, 2007: received issue

Issue 11619: Section: 14/2 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

In HRM, a stereotype called HwResource is used in the HwLogical subpackage to provide a logical representation of a hardware resource. At the same time, a stereotype with the name is used in the HwPhysical subpackage to provide a physical representation of a hardware resource. Although it is legal in this context, defining two stereotypes with the same names that have different semantics may create confusion in a user's mind. I would suggest renaming HwResource into HwLogicalResource / HwPhysicalResource. The same thing applies for HwLogical::HwResourceService and HwPhysical::HwResourceService.

Resolution:
Revised Text:
Actions taken:
October 16, 2007: received issue

Issue 11620: Section: 15/3 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
October 16, 2007: received issue

Issue 11631: Section: 15.3.1 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
October 24, 2007: received issue

Issue 11632: Section: 14.2.3 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

<< tupleType >> stereotypes would need to be added on HRM datatypes, to enable the use of VSL expressions. The UML representation section of HRM defines several datatypes (Timing, CacheStructure, PLD_Organisation, MemoryOrganisation, Env_Condition) that are not stereotyped as << tupleType >>. As a consequence, it is not possible to edit properties typed by these datatypes as VSL expressions. Proposed resolution: to apply the << tupleType >> stereotype on every datatype defined in HRM.

Resolution:
Revised Text:
Actions taken:
October 25, 2007: received issue

Issue 11633: Section: Annex B (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Revision
Severity: Minor
Summary:

Invalid reference in caption of Figure B.1. The caption of Figure B.1 is currently "Figure B.1 - Structure of the NFP framework" when it should be "Figure B.1 - Structure of the VSL framework".

Resolution:
Revised Text:
Actions taken:
October 25, 2007: received issue

Issue 11644: Section: Annex B.2.4 (marte-ftf)

Click here for this issue's archive.
Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 6, 2007: received issue

Issue 11649: Minor edits to MARTE Chapter 17 (marte-ftf)

Click here for this issue's archive.
Source: Carleton University (Dr. Murray Woodside, cmw@sce.carleton.ca)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


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


p 314 line 2 Figure 17.4


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


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


p 322 line 10 "identity of the resource" spelling


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


p 338 bottom ...Figure 17.25


p 339 line 1 Figure 17.25


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


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


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


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


p 342 para 1, add a sentence for clarification:


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

Resolution:
Revised Text:
Actions taken:
November 11, 2007: received issue

Issue 11658: Section: 11.2.1 (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA/LIST (Dr. Arnaud Cuccuru, arnaud.cuccuru@cea.fr)
Nature: Enhancement
Severity: Minor
Summary:

FlowPort and MessagePort are subclasses of InteractionPort. These two classes have common properties: isConjugated and isAtomatic (there is actually a third one, direction, but I think there is an issue with this property). These properties could be directly defined as properties of the common parent class, i.e. InteractionPort.

Resolution:
Revised Text:
Actions taken:
November 20, 2007: received issue

Discussion:

Issue 11659: Section: 11.2.1 (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA/LIST (Dr. Arnaud Cuccuru, arnaud.cuccuru@cea.fr)
Nature: Enhancement
Severity: Significant
Summary:

The ability to type FlowPorts by Signals (or by FlowSpecifications containing FlowProperties typed by Signals) is confusing. MessagePorts (which are just a light specialization of UML ports) already enable signal-based communications. Things would be clearer if FlowPorts would only enable data-flow communications, and if MessagePorts would be used for service or signal-based communications (just as classical UML ports are). I suppose that this feature is inherited from SysML, but this is however confusing in the context of UML

Resolution:
Revised Text:
Actions taken:
November 20, 2007: received issue

Discussion:

Issue 11660: Section: 11.2.1 figure 11.4 (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA/LIST (Dr. Arnaud Cuccuru, arnaud.cuccuru@cea.fr)
Nature: Clarification
Severity: Minor
Summary:

In figure 11.4, MessagePort is represented as an abstract class (italic). According to the description written in the spec, there is no particular reason to do that. This class should be represented as a concrete class

Resolution:
Revised Text:
Actions taken:
November 20, 2007: received issue

Issue 11661: Section: 11.2.1 (marte-ftf)

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

Resolution:
Revised Text:
Actions taken:
November 20, 2007: received issue

Issue 11662: Section: 11.2.1 (data reception) (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA/LIST (Dr. Arnaud Cuccuru, arnaud.cuccuru@cea.fr)
Nature: Uncategorized Issue
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 20, 2007: received issue

Discussion:

Issue 11663: Section: 11.3.2 (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA/LIST (Dr. Arnaud Cuccuru, arnaud.cuccuru@cea.fr)
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 20, 2007: received issue

Discussion:

Issue 11664: Section: 11.3.1 (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA/LIST (Dr. Arnaud Cuccuru, arnaud.cuccuru@cea.fr)
Nature: Clarification
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 20, 2007: received issue

Discussion:

Issue 11665: Section: 11.3.1 figure 11.6 (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA/LIST (Dr. Arnaud Cuccuru, arnaud.cuccuru@cea.fr)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 20, 2007: received issue

Discussion:

Issue 11666: Section: 11.3.2.1 (marte-ftf)

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

Resolution:
Revised Text:
Actions taken:
November 20, 2007: received issue

Issue 11667: Section: 11.4.1 (marte-ftf)

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

Resolution:
Revised Text:
Actions taken:
November 20, 2007: received issue

Issue 11692: Section: 14.2 (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 28, 2007: received issue

Issue 11693: Section: 14.2 add two stereotypes corresponding to HwSensor and HwActuator (marte-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 28, 2007: received issue

Issue 11694: HwTiming model of the HwLogical profile (marte-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
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.

Resolution:
Revised Text:
Actions taken:
November 28, 2007: received issue

Issue 11696: Suggest to extend ClockConstraints to ClockTypes (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Mr. Charles Andre, Charles.ANDRE@unice.fr charles.andre@unice.fr andre@unice.fr)
Nature: Enhancement
Severity: Significant
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.

Resolution:
Revised Text:
Actions taken:
November 29, 2007: received issue

Issue 11704: Editorial issue (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, frederic.mallet@sophia.inria.fr)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 30, 2007: received issue

Issue 11705: In 12.4, all references to figures are wrong (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, frederic.mallet@sophia.inria.fr)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 30, 2007: received issue

Issue 11707: Consider providing a tabular notation (as in SysML) (marte-ftf)

Click here for this issue's archive.
Source: INRIA (Dr. Frederic Mallet, frederic.mallet@sophia.inria.fr)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
November 30, 2007: received issue

Issue 11764: Section: NFP (marte-ftf)

Click here for this issue's archive.
Source: Commissariat a l Energie Atomique-CEA/LIST (Mr. Huascar Espinoza, huascar.espinoza@cea.fr)
Nature: Enhancement
Severity: Significant
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.