Metamodel updates

From AadlWiki

Jump to: navigation, search


Internal Features and Processor Features

Internal features explicitly represent events originating inside a component. Processor features are explicit representations of ports and subprogram access features provided by the processor a component is bound to. So far these did not have to be declared.

Syntax Example

thread implementation T.i
internal features
  e: event; -- event source
  ed: event data D; -- event data source
processor feature
  p: port; -- port proxy
  s: subprogram S; -- subprogram proxy
end T.i;
  • Internal features do not need a direction, they are always sources. They can be used in connections and as mode transition triggers. The data classifier for an event data source is optional.
  • A subprogram proxy names a provided subprogram access of the processor this component is bound to, the subprogram classifier is optional.
  • A port proxy names a port of the processor this component is bound to.
  • Internal features and Processor features are inherited from extended component implementations. They are part of the component implementation's namespace.
  • Both internal and processor features are modal and can have property associations.
  • There is (currently) no refinement of these features.
  • Internal and processor features are used according to the standard. However, their names can be used with or without the prefix self. and processor..
  • Internal features can be declared in component implementations of any category.
  • Processor features can be declared in component implementations of categories that can be bound to a processor: system, process, thread group, thread, device, virtual processor.


  1. Port proxies may need to be refined further: direction, kind of port, data classifier reference
  2. Need to clarify if refinement should be added.
  3. Do they need to be instantiated
  4. Semantic rules need to be defined and checked, e.g., currently OSATE allows a connection between two internal features.
  5. DefaultAnnexLibrary and DefaultAnnexSubclause hold the annex text. They also need to hold on to the root of the parsed annex if a plug-in with a parser exists.

Metamodel Changes

These are the diagrams showing the changed portions.

New Metaclasses





Component Implementation


The parser enforces an additional rule about which category may contain internal and/or processor features. These are currently not encoded in the metamodel.


Metaclass AbstractConnectionEnd was removed because it has ConnectionEnd as its only subclass.


Mode Transition Triggers

Metaclass ModeTransitionTrigger is now a concrete class that holds references to context and triggering port. TriggerPort is now abstract.



The abstract metaclass CallSpecification has been removed because it had SubprogramCall as its only subclass.



Removed Metaclasses

The following metaclasses were removed (from git diff --name-status output)

D       org.osate.aadl2/src/org/osate/aadl2/
D       org.osate.aadl2/src/org/osate/aadl2/
D       org.osate.aadl2/src/org/osate/aadl2/
D       org.osate.aadl2/src/org/osate/aadl2/
D       org.osate.aadl2/src/org/osate/aadl2/
D       org.osate.aadl2/src/org/osate/aadl2/
D       org.osate.aadl2/src/org/osate/aadl2/
D       org.osate.aadl2/src/org/osate/aadl2/

Annex handling

The whole issue was pushed by us getting ready to release the graphical editor by Philip. When the model is modified by the graphical editor it needs to be serialized and Xtext complains that it does not find the Default annex object that it expects from the grammar.

In the current implementation the DefaultAnnexLibrary and DefaultAnnexSubclause get replaced in the model by the actual annex library or subclause returned by the annex parser. This confuses the Xtext validator since it expects the Default class according to the grammar rules.

We are making a change to the Meta model regarding the AnnexLibrary and AnnexSubclause, actually the DefaultAnnexLibrary and DefaultAnnexSubclause. The Default object are used by the AADL2 parser to hold on to the annex text. This text is then handed to the parser registered for that annex.

The change is to record the actual parsed annex root object in the Default objects.

HINT: For those who implement annexes: If you need to get to the enclosing classifier that contains the annex, instead of simply going to the owner of your annex root object via eContainer or getOwner, please use getContainingClassifier.

Personal tools