Omg issue Number

Disposition: Deferred

OMG Issue No: 11851

Title: How to use MARTE to modelize AADL applications

Source:

THALES (M. Faugere, [e-mail])

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, specifying when 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.

Discussion:

MARTE proposes different views (design, SW/HW platform modeling, and analysis views), enhancing different model and analysis scenarios reuse. AADL is based on a more synthetic process, fixing architectural choices. The end user focus on data/event communication between component.

The best MARTE process and the use of modeling, sw/hw platform, and analysis views shall be study in more details to “better” match the AADL way of thinking.

Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11853

Title: MARTE VSL and AADL expression language alignment

Source:

Thales (M. Faugère, [e-mail])

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

Discussion:

A detailed mapping should be provided in order to transform VSL expressions into AADL expressions.

Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11854

Title: AADL examplification

Source:

THALES (M. Faugere, [e-mail])

Summary:

Examples provided in the AADL annex of MARTE should be enriched:

1. 
   An example on how to model the AADL dispatch protocol with MARTE is missing.
   
2. 
   An example on how to model AADL flows with MARTE is missing
   
3. 
   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.
   

Discussion:

More discussion need

Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11855

Title: Dequeued Protocol AllItems representation

Source:

Thales (M. Faugère, [e-mail])

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.

Discussion:

This resolution needs MARTE concepts evolutions.

Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11856

Title: attribute “Synchronisation between SRM, GRM, HRM and analysis part”

Source:

ESEO (Dr. Jerome Delatour, [e-mail])

Summary:

(a) A simplification of GRM should be envisaged.

(b) 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..

Discussion:

There are two different opinions regarding the proposed re-structuring the concepts in the profile.

In the opinion of ESEO:
As mentioned for instance in issues 11411 and 11412, regarding GRM and SRM in particular, redundancy emerges between GRM concepts and packages depending on it (SRM, HRM but also SAM and GQAM). The same concept could be redefined twice, and this redefinition will let the designer express the same idea in different MARTE meta-classes (or stereotypes). In addition to a problem of consistency, there is a problem of readability and understanding for the designer.
Behind this issue, it is the central role given to GRM and the way Analysis models (GQAM and SAM) and XRM (GRM, SRM and HRM) elements are related which could be discussed. It's not certain that a clear consensus or agreement is reached on this central role of GRM. A broader discussion is needed in order to reach a consensus.
Different approaches for resolving this issue are possible. More time is needed to make a better analysis of the advantages/default and change impacts of each one.
For theses reasons, this issue is deferred.
In the opinion of UC:
As mentioned in Issues 11411 and 11412 regarding GRM and SRM in particular, they may get significant “synchronization” by simply including in the SRM stereotypes the inheritance from the corresponding in GRM, but they do not have to be forced to stay totally “synchronized” since they are meant for different purposes, and use and promote very different modeling styles. GRM goes for architectural models that can provide and be extended to lead easily to analysis of the basic NFPs, while the main concern in the current flavor of SRM is to enable easier platform independence through model transformations.

Even considering these different modeling intents in the two subprofiles, avoiding inheritance at the profile level seems to indicate that it is due to a matter of purism more than to a technical reason.

In response to the issue :

1. 
   GRM is not that complex considering that it must provide the minimum additional elements to UML to deal with design at the architectural level, as well as foundations for design and analysis, design for platform and application oriented models, and finally the hardware and software aspects of the platform. The suggestion to reduce it means probably not comprehension of this multifaceted role, or the implicit assumption that all these different aspects have totally nothing in common, which is wrong. They share the absolute necessity to have at the minimum the capability of being able to do evaluations of a system feasibility even at the very basic level against its non functional properties, and at least its timing properties.
   
2. 
   For this reason, there must be aspects like scheduling in GRM. The concept of scheduler is crucial for almost all of the mentioned chapters (exception made of HRM probably). The attributes on it are the very basic ones to get the minimal capabilities to say something of the system feasibility in the context of the large majority of applications. Even particular techniques that model explicitly the behavior of the scheduler require this concept at this level of description.
   

Along this discussion, one week before the start of the voting period, this issue has been pushed to create a polemic enough to deserve further attention. More even considering that making such a coarse change in the structure of the standard may require a very deep reformulation.

In the opinion of UC this issue should be closed. A better alignment between the different models inside MARTE may be gotten, but restructuring it in the way it seems to be proposed will require a significant number of methodological choices, which may be good for one application or modeling style but not for others. This is a different alternative for standardization, and may lead to a new RFP, in which a concrete number of industrial applications, with their corresponding development styles, analysis techniques, and certification requirements, find precise modeling methodologies and tool support. This may require a per-domain response. Anyway in order to give the community the possibility to elaborate on all these, it has been deferred at this time.
Resolution:

Defer the issue so that a wider discussion may lead to consensus.

Revised Text:
Disposition: Deferred