[aadl-modeling]: new to aadl graphical editor in OSATE v2.2.2 - need pointer

[Denis Buzdalov]

Randy,

> 2.       Is there a way to add stereotypes ,  like <<data>>, << bus
> access >> etc to the diagrams?  These are shown in the book
> “Model-Based Engineering with AADL”.

Well, actually UML/SysML terminology like "stereotype" is not very
common in AADL community. Probably, it is okay to use this term, but to
avoid misunderstandings, let me try to briefly show what is understood
by these "data" and etc.

In AADL, model elements can be firstly divided generally to components
(boxes of different shapes on graphical diagrams), features (interfaces
of components which are represented as figures on borders of
components) and connections (lines between features and between
features and components).

All of these three sorts of elements can have ``category''. For
instance, components can be data, devices, processors, threads, systems
and etc. Features can be ports, bus accesses, data accesses,
subprogram accesses, etc. Each category is meant to have particular
semantics (more or less precisely defined in the standard). For
instance, "threads" (roughly) are meant to be pieces of code with
particular timing properties like period and deadlines, "processors"
are meant to be components incorporating processor as a physical
module and an operating system with scheduling facilities (this
implies that components with the "processor" category can be enriched
with appropriate physical and scheduling-related parameters in the
model). Model elements of different categories have different shapes
in the standardized graphical representation of AADL.

Users can define their own classifiers (types and implementations) of
components. These classifiers must have one (and only one) category.
When defining a feature (when defining a component's interface), one
must assign a single (and only one) category to it (with possibly
additional parameters).

At the moment, the list of possible categories that can be used for
defining component classifiers and features is strongly fixed in the
standard and users cannot add any.

There were some discussions about whether is it adequate to have a
restriction on having only a single category for classifiers and
features. Also it was slightly discussed whether do we need an ability
to define user categories. This question ran into a problem of (more or
less) formal definition of semantics for user-defined categories (for
correctness and interoperability between different instruments and
users). Some people in AADL community consider such definition very
useful, but it is obviously a thing that would add complexity to the
language.

This issue also becomes more sophisticated considering the special
category "abstract" for components and "feature" for features which mean
a generalized category with meaning of "no category yet". These
categories are widely used when modelling on abstract levels. They can
be refined to any existing category and sometimes there are doubts to
which one. For example, we can consider a component with category of
"device" as some compound subsystem with its own complex structure, for
which AADL standard uses category "system". In fact, there is a need to
define a component with two categories at the moment or with
user-defined category. Now "abstract" can be used for this as a dirty
solution, but this is obviously a bad practice.

So, the question to you: can you formulate your question in terms
of categories, component classifiers and features? Whether do you need
to define your own categories and why do you need them? Since, we are
working on the next refreshed version of AADL, your ideas and needs may
be helpful.

--
Denis Buzdalov
Software Engineering Department, ISPRAS