Issue 11854: MARTE-AADL Issue 7 (marte-ftf) Source: INRIA (Dr. Frederic Mallet, Frederic.Mallet(at)inria.fr) Nature: Enhancement Severity: Significant 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. Resolution: 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) Revised Text: see ptc/2009-05-12 pages 121 - 127 Actions taken: December 21, 2007: received issue October 16, 2009: closed issue Discussion: Discussion: More discussion need Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 21 Dec 2007 04:59:12 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Frederic Mallet, Madeleine Faugere, Huascar Espinoza, Peter Feiler Company: INRIA Sophia, Thales TRT, CEA LIST, CMU SEI mailFrom: fmallet @ unice.fr Notification: Yes Specification: UML Profile for MARTE Section: Annex A: AADL-like models with MARTE FormalNumber: ptc/07-08-04 Version: Beta 1 RevisionDate: 21/12/07 Page: 345-382 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; InfoPath.1) Description [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.