## Model Details

### Qualified name

The following image shows the logical dependency between the name segments and describe the used notations. The details differ in terms of delimiters and encoding of the segments.

### Unique ID generation

AMALTHEA uses a named based schema to reference other elements inside of a model.
A custom implementation is used instead of the standard EMF mechanism, which uses an index based implementation.
The target element id is identified by the following schema:

    java.net.URLEncoder.encode(<name of element>, StandardCharsets.UTF_8.toString)) + "?type=" + <element>.eClass.name

Samples:

Refering to a Runnable element with name foo in a RunnableCall looks like the following snippet:

    <items xsi:type="am:RunnableCall" runnable="foo?type=Runnable" />

### Interfaces and base objects

Several interfaces and abstract classes are defined in the common model.
They provide basic common functionality for all objects, which are extending it, like the possibility to add CustomAttributes or Tags. Tags are available at different elements with the purpose to group them together or to annotate them.

### Derived references

Some derived references are introduces to simplify a multi-level navigation. They are read only.

| Reference |
`ISystem` | innerPorts → | `QualifiedPort`
`HwStructure` | innerPorts → | `HwPort`
`HwPath` | source → | `ProcessingUnit`
`HwPath` | destination → | `HwDestination`
`TaskScheduler` | childSchedulers → | `TaskScheduler`
`TaskScheduler` | parentScheduler → | `TaskScheduler`

### Transient back pointers

AMALTHEA maintains a number of back pointers in the model. These transient references of an object ‘point back’ to the object referring to it.

#### Container references

Container references provide an easier access to the eContainer of an object.

The following references are specified as opposite references and can be modified.
By the prefix “containing” they clearly indicate that a containment is changed.

| Container reference | Containment reference |
`Component` | ← containingComponent | ports → | `ComponentPort`
`EnumMode` | ← containingMode | literals → | `ModeLiteral`
`HwFeatureCategory` | ← containingCategory | features → | `HwFeature`
`HwAccessElement` | ← containingAccessElement | accessPath → | `HwAccessPath`
`RunnableCall` | ← containingCall | arguments → | `CallArgument`
`ISystem` | ← containingSystem | componentInstances → | `ComponentInstance`
`ISystem` | ← containingSystem | connectors → | `Connector`
`Namespace` | ← previousSegment | nextSegments → | `Namespace`
`Runnable` | ← containingRunnable | parameters → | `RunnableParameter`
`ComponentInterface` | ← containingInterface | subInterfaces → | `SubInterface`

The following references are specified as opposite references.

| Container reference (read only) | Reference |
`ProcessingUnit` | ← source | accessElements → | `HwAccessElement`
`TaskScheduler` | ← child | parentAssociation → | `SchedulerAssociation`

The following container references are a special case. Because of the nested structure of sub elements the access to a dedicated container object is computed by traversing multiple eContainer references.

| Container reference (read only) | Containment reference |
`Runnable` | ← containingRunnable | activityGraph ... → | `ActivityGraphItem`
`Process` | ← containingProcess | activityGraph ... → | `ActivityGraphItem`
`ActivityGraph` | ← containingActivityGraph | items ... → | `ActivityGraphItem`
`Runnable` | ← containingRunnable | ... → | `DataDependency`

#### References (via inverse index)

The inverse index allows easier and faster navigation, at the expense of greater memory consumption.
The index is built on demand.

The data model has some intermediate objects to express the call of a runnable or the access to a label.
These objects are containments of Task or Runnable and can have additional attributes. The back pointers support an easy way to answer queries like “Which tasks call runnable x ?” or “Which functions read label y ?”.

| Back pointer (read only) | Reference |
`LabelAccess` | ← labelAccesses | data → | `Label`
`ChannelAccess` | ← channelAccesses | data → | `Channel`
`SemaphoreAccess` | ← semaphoreAccesses | semaphore → | `Semaphore`
`RunnableCall` | ← runnableCalls | runnable → | `Runnable`

All elements with memory representation (e.g. labels, runnables) can be mapped to a memory via a MemoryMapping. The back pointers provides a list of all mapping elements that refer to a specific memory or a specific MemoryElement.

| Back pointer (read only) | Reference |
`MemoryMapping` | ← mappings | memory → | `Memory`
`MemoryMapping` | ← mappings | abstractElement → | `AbstractMemoryElement`

Labels and runnables can be located in exactly one section. The back pointer provides a list of all elements that are assigned to a specific section.

| Back pointer (read only) | Reference |
`Label` | ← labels | section → | `Section`
`Runnable` | ← runnables | section → | `Section`

CustomEvent and InterProcessStimulus can have explicit triggers. The pointer is established from CustomEventTrigger and InterProcessTrigger. The back pointers provides easier access to the triggering runnables / processes.

| Back pointer (read only) | Reference |
`CustomEventTrigger` | ← explicitTriggers | event → | `CustomEvent`
`InterProcessTrigger` | ← explicitTriggers | stimulus → | `InterProcessStimulus`

Components define lists of included software elements (e.g. labels, runnables, semaphores). The back pointer provides access to all referring components.

| Back pointer (read only) | Reference |
`Component` | ← referringComponents | labels → | `Label`
`Component` | ← referringComponents | runnables → | `Runnable`
`Component` | ← referringComponents | processes → | `AbstractProcess`
`Component` | ← referringComponents | semaphores → | `Semaphore`
`Component` | ← referringComponents | osEvents → | `OsEvent`

Allocations refer to a scheduler (Scheduler, TaskScheduler, InterruptController). The back pointer provides access from the scheduler to the allocations.

| Back pointer (read only) | Reference |
`SchedulerAllocation` | ← schedulerAllocations | scheduler → | `Scheduler`
`RunnableAllocation` | ← runnableAllocations | scheduler → | `Scheduler`
`TaskAllocation` | ← taskAllocations | scheduler → | `TaskScheduler`
`ISRAllocation` | ← isrAllocations | controller → | `InterruptController`

Some other useful back references.

| Back pointer (read only) | Reference |
`Process` | ← affectedProcesses | stimuli → | `Stimulus`
`ITaggable` | ← taggedObjects | tags → | `Tag`
`SchedulerAssociation` | ← childAssociations | parent → | `TaskScheduler`
`INamespaceMember` | ← memberObjects | namespace → | `Namespace`
`IComponentStructureMember` | ← memberObjects | structure → | `ComponentStructure`
`HwConnection` | ← connections | port1 → | `HwPort`
`HwConnection` | ← connections | port2 → | `HwPort`

#### Implementation

Xcore:

A derived back pointer is computed by AmaltheaIndex.getInverseReferences(...) .
The visiblity in the generated code and in the user interface is controlled by @GenModel annotations.

Example

    class Runnable extends AbstractMemoryElement
    {	...
    	// back pointer (readonly)
    	@GenModel(documentation="<p><b>Returns an <em>immutable</em> list of callers (RunnableCalls).</b></p>")
    	@GenModel(propertyCategory="Read only", propertyFilterFlags="org.eclipse.ui.views.properties.expert")
    	refers transient readonly volatile derived RunnableCall[] runnableCalls get {
    		AmaltheaIndex.getInverseReferences(this, AmaltheaPackage.eINSTANCE.runnable_RunnableCalls,
    			#{AmaltheaPackage.eINSTANCE.runnableCall_Runnable} )
    	}

#### User Interface