MARTE — MARTE-AADL Issue 7

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.

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)