Commit 139af5fc authored by Simon Barner's avatar Simon Barner
Browse files

RED

* See TODOs in HTML file

Issue-Ref: 3524
Issue-Url: https://af3-developer.fortiss.org/issues/3524

Signed-off-by: Simon Barner's avatarSimon Barner <barner@fortiss.org>
parent a7739778
documentation.html c01263de0f89a751f4958aea91394a1050c98065 RED
documentation.html 98b05eb3509484cf1eace9439e855f601df0b44e RED
......@@ -8,32 +8,32 @@ specifications.</p>
<p>A component contains one behavior to execute and it can be related to other
components by input or output ports and incoming and outgoing
channels between ports. The data of types <i>boolean</i>, <i>int</i>,
or <i>double</i> can be propagated between ports.</p>
channels between ports. The data of types <i>boolean</i>, <i>int</i>, <i>double</i> or
user-defined <i>structs</i> and <i>arrays</i> can be propagated between ports.</p>
<p>A component may contain the next behavioral specifications: Code,
<p>A component may contain of the following behavioral specifications: Code,
<a href="../../../org.fortiss.af3.mode/html/developer/documentation.html">Mode Switch</a>,
<a href="../../../org.fortiss.af3.state/html/developer/documentation.html">State Automaton</a>,
<a href="../../../org.fortiss.af3.cosimulation/html/developer/documentation.html">Simulink</a>,
<a href="../../../org.fortiss.af3.cosimulation/html/developer/documentation.html">FMU</a>, Specifications
and <a href="../../../org.fortiss.af3.operatorpanel/html/developer/documentation.html">Operator Panel</a> for
the simulator user interface design There are also secondary specifications as Test Suite Specification
and Refinement Specification. Every component can have only one of the mentioned above behavioral specifications or
nothing. A component without a behavior evidently cannot generate any meaningful code, but can be
used for the further development of a project. All these specifications allow to generate code in C or Java for the simulator
or for a hardware platform implementation.</p>
the simulator user interface design. There are also secondary specifications as <i>Test Suite Specification</i>
and <i>Refinement Specification</i>. Every component can have at most of the aforementioned behavioral specifications.
A component without a behavior evidently cannot generate any meaningful code, but can be
used for the further development of a project. All these specifications allow to generate code in
<i>C</i> or <i>Java</i> for the simulator, or for a hardware platform implementation.</p>
<p>A component can contain other components (sub-components), this way having a
<p>A component can contain other components (sub-components), resulting into a
hierarchy of components. The superior component is called the parent
component and the inferior one, correspondingly, the child component
or the sub-component. If a component does not have another component
inside, it is called an atomic component, i. e. one, which cannot be
decomposed in other components. The complex components, constituted
decomposed in other components. Complex components, constituted
of many sub-components on different levels can be decomposed by the
unpack function and vice versa, many components can be packed in one
component by the pack function. All the components constitutes a
Component Architecture and the highest component of this architecture
is called the Component Architecture Root. </p>
<i>unpack</i> function and vice versa, many components can be packed in one
component by the <i>pack</i> function. Set set of all components constitutes a
<i>Component Architecture</i>. The top-most component of this architecture
is called the <i>Component Architecture Root</i>.</p>
<h2>Package description</h2>
<ul>
......@@ -42,8 +42,8 @@ is called the Component Architecture Root. </p>
<li><tt>component.generator.component</tt>: intermediate language generator for composite components and code
specifications.</li>
<li><tt>component.generator.java</tt>: java code generator.</li>
<li><tt>component.generator.nusmv</tt>: a collection of transformations from this model to nusmv.</li>
<li><tt>component.library</tt>: classes for dealing with the library ofcomponents.</li>
<li><tt>component.generator.nusmv</tt>: a collection of transformations from this model to <i>NuSMV</i>.</li>
<li><tt>component.library</tt>: classes for dealing with the library of components.</li>
<li><tt>component.library.prototypes</tt>: prototypes for the library of components.</li>
<li><tt>component.model.behavior.common.impl</tt>: static implementations for EOperations defined by
meta-model classes in the Ecore model.</li>
......@@ -52,7 +52,15 @@ meta-model classes in the Ecore model.</li>
</ul>
<h2>Metamodel description</h2>
The <i>metamodel</i> contains the next classes:
<font color="red">TODO: Ensure that
<ol>
<li>the following lists contain all meta classes</li>
<li>the sub-package hierarchy is correctly represented (e.g., in package <i>behavior</i>, use <tt>common.DataStateVariablel</tt>, etc.)</li>
</ol>
</br>
</font>
The <i>component metamodel</i> contains the following classes:
<ul>
<li><tt>ComponentArchitecture</tt>: the root class of the component architecture.</li>
<li><tt></span>Component</tt>: the main concept to encapsulate behaviors. A component can be atomic,
......@@ -68,18 +76,18 @@ components. A channel is outgoing for an output port and is incoming for an inpu
<li><tt>PortSpecification</tt>: specifies the initial value and the type of the data propagated from
one port to another.</li>
<li><tt>PropagatableSpecification</tt>: describes how data can be propagated from one port to another.</li>
<li><tt>CuasalityComponentSpecification</tt>: specifies the causality of a component. Strong causality means that
<li><tt>CausalityComponentSpecification</tt>: specifies the causality of a component. Strong causality means that
the data is passing through a component with a certain time delay. Weak causality means that data passes without a
time delay.</li>
</ul>
The submodel <i>annotation</i> contains:
The sub-package <i>annotation</i> contains:
<ul>
<li><tt>MemoryRequirement</tt>: annotation that returns the estimated memory requirement of a
component, i.e. the sum of its local memory requirement plus the memory requirements of its children.</li>
</ul>
The submodel <i>behavior</i> contains:
The sub-package <i>behavior</i> contains:
<ul>
<li><tt>CodeSpecification</tt>: a way to provide behavior to a component by means of writing a
c-like code directly in the body of a component.</li>
......@@ -91,14 +99,14 @@ from one state to another.</li>
of a state, which means to create an action when this state is achieved.</li>
</ul>
The submodel <i>generator</i> contains:
The sub-package <i>generator</i> contains:
<ul>
<li><tt> ComponentProgram</tt>: used to transform components into generated c-code or java-code.</li>
<li><tt>ComponentFunction</tt>: defines the identifiers for the various function names generated by
the imperative code generator.</li>
</ul>
The meaning of the next classes are self explanatory by their names:
The sub-package <i>TODO</i> contains:
<ul>
<li><tt>LocalFunction</tt>: TODO</li>
<li><tt>PortVariable</tt>: TODO</li>
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment