MARTE — MARTE-AADL Issue 4

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, specifyingwhen 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. Managing the set of properties is indeed not easy. In AADL we have the property set mechanism through which we can introduce new properties that can be associated with existing AADL concepts. As such they enhance the semantics of those concepts and may introduce new concepts. For example, at the SEI we have defined a set of security related properties and associated them with components (system, process, thread, …), ports, and connections. In doing so we represent security related concepts of subjects, object, roles. To us these properties act as annotations to the base architecture model, and their mapping into a analysis-specific model (meta model for security models) understands the mapping of core AADL concepts into analysis-domain concepts. In some cases the existing core architecture concepts are not sufficient; then new concepts can be introduced through the annex mechanism. For example, the error model annex allows users to introduce additional concepts such as “error events” (faults), which exist as separate entities and are associated with core AADL entities. They themselves can have properties as defined through property sets. MARTE, by doing the same in the context of a meta model, e.g., through GQAM, SAM etc., have an explicit way of identifying these analysis specific concepts by name. At the same time when I have an architecture model and want to associate specific analysis interests, I would have to identify the collection of stereo types, some representing the base architecture model, and some the analysis specific abstractions and annotations to bee attached. When I look at the predeclared properties in the AADL standard, they deal with more than one analysis area. We are attempting to subcategorize them. If you have good insight on how to do some of this better, we are looking for input on doing this better on the AADL side as well.

See issue 11850 for disposition