Omg issue Number

Disposition: Resolved

OMG Issue No: 11551

Title: automotive example (marte-ftf)

Source:

Thales (Sébastien Demathieu, [e-mail])}

Summary:

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

Resolution:

1) Remove references to the msgPort stereotype and replace by the messagePort stereotype.

2) Remove references to the serviceSpecification and signalSpecification and replace by the bFeatureSpecification stereotype.

Revised Text:

Section 11.4.1, page 129, replace sentence: “The RegInterface is a UML2 interface stereotyped with "signalSpecification" and "serviceSpecification" because it specifies respectively that the Start signal may be consumed (This latter has been previously declared within the package SignalDeclarations) and the controlEngine service is required.” by “The RegInterface is a UML2 interface stereotyped with "bFeatureSpecification" because it specifies that the Start signal may be consumed (this latter has been previously declared within the package SignalDeclarations) and the controlEngine service is required.”
Section 11.4.1, page 129, replace sentence: “The ECInterface interface is stereotyped as serviceSpecification (in this case, the graphical representation of this interface shown at top-right side of Figure 11.15 only displays its associated iconographic representation " ").” by “The ECInterface interface is also stereotyped as bFeatureSpecification (in this case, the graphical representation of this interface shown at top-right side of Figure 11.15 only displays its associated iconographic representation "").”
Section 11.4.1, page 129, replace sentence: “This interface defines the controlEngine required service (denoted here by the icon " " placed before the operation name).” by “This interface defines the controlEngine required service (denoted here by the icon "" placed before the operation name).”
Section 11.4.1, page 129, replace sentence: “Finally, the SpeedInterface interface is a "signalSpecification" interface that declares a produced signal, Start (in this case, we only used the textual form of the stereotype).” by “Finally, the SpeedInterface interface is also a "bFeatureSpecification" interface that declares a produced signal, Start (in this case, we only used the textual form of the

stereotype).”

Section 11.4.1, page 129, replace sentence: “The three previous interfaces are examples of applying the stereotypes defined in the general component model (GCM) of MARTE. We have illustrated the usage of stereotypes following the three possibilities offered by UML: textual and iconographic form (e.g., RegInterface), only iconographic form (e.g., ECInterface) and only textual form (e.g., SpeedInterface).” by “These interfaces illustrate the use of stereotypes defined in the general component model of MARTE. The three possibilities offered by UML to represent the stereotypes have been used here: textual and iconographic form (e.g., RegInterface), only iconographic form (e.g., ECInterface) and only textual form (e.g., SpeedInterface).”

Replace Figure 11.15, page 130 by the following figure:



Section 11.4.1, page 130, replace sentence: “This class has two ports stereotyped with "msgPort": regOn and engineCmd.” by “This class has two ports stereotyped with "messagePort": regOn and engineCmd.”

Section 11.4.1, page 130, replace sentence: “It is a port stereotyped by "msgPort".” by “It is a port stereotyped by "messagePort".”

Section 11.4.1, page 130, replace sentence: “The direction property of the stereotype does not apply in this case because the type of the port is an interface stereotyped with "serviceSpecification" (this latter, ECInterface, defines a required service as denoted in Figure 11.15.).” by “The direction property of the stereotype does not apply in this case because the type of the port is an interface stereotyped with "bFeatureSpecification" (this latter, ECInterface, defines a required service as denoted in Figure 11.15.).”

Section 11.4.1, page 130, replace sentence: “The second port owned by the rgm part (the rp port) is a message port (stereotype "msgPort" and associated icon " ").” by “The second port owned by the rgm part (the rp port) is a message port (stereotype "messagePort" and associated icon "").”

Replace Figure 11.16, page 131 by the following figure:



Replace Figure 11.17, page 131 by the following figure:



Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11552

Title: attribute “GRM SchedulableResource should not have a property "host ExecutionHost"”

Source:

Thales: Sébastien Demathieu, [e-mail])

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:
To add an inheritance from scheduler in figure 15.5 for both executionHost and communicationHost. Then the association between SchedulableResource and executionHost is the same that already exist in GRM to scheduler. The scheduler in communicationHost is easy to justify as the arbitration/protocol that gives to each message access to the media.

Revised Text:

New visio file for fig 15.5 and 15.9. Add the inheritance from scheduler in the class descriptions this means editing sections: 15.3.2.4, 15.3.2.7 adding the generalization

Scheduler (from MARTE::GRM)
Also indicate in the constraints the two self pointing associations processingUnits and mainScheduler
Disposition: Resolved