Commit 0fa89804 authored by Simon Barner's avatar Simon Barner
Browse files

Merge branch '3524_af3_component_doc' into 'master'

3524 af3 component doc

See merge request af3/af3!147
parents ff6634b4 92df3ba7
documentation.html 54373a5beed76fda975bb28b64a371fccbf6b377 RED
documentation.html 24c55e0a163060d58a1bb21253c10eda8c4012ed GREEN
<html><body>
<H1>Developer Documentation for <I>org.fortiss.af3.component.ui</I></H1>
<P>// TODO
</body></html>
<html>
<h1>Developer Documentation for <i>org.fortiss.af3.component.ui</i></h1>
<h2>Plugin description</h2>
<p>This is the user interface part of the af3.component plugin. It provides a component and a
code specification editor. Also it provides a simulator, in which the user observe the
execution of the model and debug it.</p>
<h2>Package description</h2>
<ul>
<li><tt>component.ui</tt>: main package for component.</li>
<li><tt>component.ui.behavior</tt>: implementation for converters and validators</li>
<li><tt>component.ui.commands</tt>: implementation for commands.</li>
<li><tt>component.ui.compose</tt>: connection compositor for directly connecting components.</li>
<li><tt>component.ui.editor</tt>: package for editors of the AF3 component language.</li>
<li><tt>component.ui.editor.code</tt>: implementation of the code specification editor.</li>
<li><tt>component.ui.editor.datastate</tt>: editor for the data state variables.</li>
<li><tt>component.ui.editpart</tt>: implementation for edit parts.</li>
<li><tt> component.ui.editpart.figures</tt>: implementation for figures. A figure can be a rectangle
or an ellipse with text inside.</li>
<li><tt>component.ui.examples</tt>: implementation for examples.</li>
<li><tt>component.ui.generator</tt>: implementation of C code generator.</li>
<li><tt>component.ui.handler</tt>: implementation of handlers for model elements.</li>
<li><tt>component.ui.library</tt>: this package contains actions for the components library.</li>
<li><tt>component.ui.properties</tt>: implementation of properties.</li>
<li><tt>component.ui.simulator</tt>: implementation of the AF3 simulator.</li>
<li><tt>component.ui.simulator.component</tt>: implementation of components simulator.</li>
<li><tt>component.ui.simulator.menu</tt>: implementation of simulator menu.</li>
<li><tt>component.ui.simulator.views</tt>: implementation of simulator views.</li>
<li><tt>component.ui.simulator.utils</tt>: utility classes for component UI.</li>
</ul>
</body>
</html>
\ No newline at end of file
documentation.html 5a2ca7a915947460d270932825ee4d5f59a732e0 RED
documentation.html e66e28a6276439808c7cbcdac8b3e62f1e734067 GREEN
<html><body>
<H1>Developer Documentation for <I>org.fortiss.af3.component</I></H1>
<P>// TODO
</body></html>
<html>
<body>
<h1>Developer Documentation for <i>org.fortiss.af3.component</i></h1>
<h2>Plugin description</h2>
<p>The plugin represents a component language with a set of behavior
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>, <i>double</i> or
user-defined <i>structs</i> and <i>arrays</i> can be propagated between ports.</p>
<p>A component may contain one 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 <i>Test Suite Specification</i>
and <i>Refinement Specification</i>. Every component can have at most one 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), 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 that cannot be
decomposed in other components. Complex components, constituted
of many sub-components on different levels can be decomposed by the
<i>unpack</i> function and vice versa, many components can be packed in one
component by the <i>pack</i> function. The 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>
<li><tt>component.constraint</tt>: constraint-checkers.</li>
<li><tt>component.generator.c: </tt>C-code generator.</li>
<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 <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>
<li><tt>component.simulator</tt>: handling for simulation of components.</li>
<li><tt>component.utils</tt>: utility functions for components.</li>
</ul>
<h2>Metamodel description</h2>
The <i>component metamodel</i> contains the following classes and interfaces:
<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,
implementing a behavior by means of any kind of behavioral specification or
hierarchical, containing sub-components with behaviors.</li>
<li><tt>Channel</tt>: a channel is a connection between two ports of a component or more
components. a channel is outgoing for an output port and is incoming for an input port.</li>
<li><tt>Port</tt>: class by means of which a component communicates with other
components. A port is connected to other input or output ports by channels.</li>
<li><tt>InputPort</tt>: an input port is connected to an output port by an incoming channel.</li>
<li><tt>OutputPort</tt>: an output port is connected to other input ports by outgoing channels.</li>
<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>
<li><tt>PortSpecification</tt>: specifies the initial value and the type of the data propagated from
one port to another.</li>
<li><tt>ComponentRef</tt>: describes a reference to a component that is in a library of components.</li>
<li><tt>LibraryComponent</tt>: represents a library of components.</li>
<li><tt>LibraryComponentPackage</tt>: represents a package of libraries of components.</li>
<li><tt>PropagatableSpecification</tt>: describes how data can be propagated from one port to another.</li>
<li><tt>ComponentSpecificationsContainer</tt>: interface implementing methods that allow to get the specifications of a component container.</li>
<li><tt>VerifBehaviourComponentSpecification</tt>: interface implementing methods that allow to get the specifications of a component and to verify its behavior.</li>
<li><tt>IReadOnlyBehaviorSpecification</tt>: interface implementing methods that allow to get only readable specifications of a component.</li>
</ul>
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.
</br><b>Note</b>: This annotation is deprecated. See <tt>RamRequirement</tt> in
<a href="../../../org.fortiss.af3.task/html/developer/documentation.html">task architecture</a> instead.</li>
</ul>
The sub-package <i>behavior</i> contains:
<ul>
<li><tt>IComponentBehaviorDefinitionSpecification</tt> interface implementing methods working with component behavior specification.</li>
<li><tt>common.DataStateVariable</tt>: internal variables that can be accessed in all states of a state
automaton. Valid types are int, double and boolean.</li>
<li><tt>common.Guard</tt>: used in a state automaton to create a conditional expression for a transition
from one state to another.</li>
<li><tt>common.Action</tt>: used in a state automaton to create an assignment expression inside of a state, which means to create an action, when this state is achieved.</li>
<li><tt>common.IDataStateVariableProvider</tt>: returns the value of the <i>Data State Variables</i> containment reference list.</li>
<li><tt>code.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>
</ul>
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 component function names.</li>
<li><tt>LocalFunction</tt>: defines the identifiers for the local function names.</li>
<li><tt>PortVariable</tt>: defines the identifiers for the port variable names.</li>
<li><tt>LocalVariable</tt>: defines the identifiers for the local variable names.</li>
<li><tt>port.PortVariableOperation</tt>: interface implementing methods working with port operations. </li>
<li><tt>port.WritePortVariableStatement</tt>: interface implementing methods working with port variable statement to be written.</li>
<li><tt>port.ReadPortVariableExpression</tt>: interface implementing methods working with port variable expression to be read.</li>
<li><tt>port.TestPortVariableExpression</tt>: interface implementing methods working with port variable expression to be tested.</li>
<li><tt>port.PortVariableOperationArgument</tt>: interface implementing methods working with port operation arguments.</li>
<li><tt>port.NoValArgument</tt>: interface implementing methods working with 'no value' arguments.</li>
<li><tt>port.PortArgument</tt>: interface implementing methods working with port arguments.</li>
<li><tt>port.ValueArgument</tt>: interface implementing methods working with value arguments.</li></ul>
</body>
</html>
\ No newline at end of file
component.ecore 53e9021aab7ee4a7331e1ef3d2eb4bc2e30afe7e GREEN
component.ecore 0f73aaa543d3ba434c263bd046cdebc75f2fea86 GREEN
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