| <?xml version="1.0" encoding="iso-8859-1" ?> |
| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" |
| "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| <!--http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd--> |
| <html xmlns="http://www.w3.org/1999/xhtml" |
| > |
| <head><title>Component Overview</title> |
| <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> |
| <meta name="generator" content="TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)" /> |
| <meta name="originator" content="TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)" /> |
| <!-- xhtml,3,next,html --> |
| <meta name="src" content="etrice-doc.tex" /> |
| <meta name="date" content="2015-08-27 23:56:00" /> |
| <link rel="stylesheet" type="text/css" href="etrice-doc.css" /> |
| </head><body |
| > |
| <!--l. 201--><div class="crosslinks"><p class="noindent">[<a |
| href="etrice-docse25.html" >prev</a>] [<a |
| href="etrice-docse25.html#tailetrice-docse25.html" >prev-tail</a>] [<a |
| href="#tailetrice-docse26.html">tail</a>] [<a |
| href="etrice-docch8.html#etrice-docse26.html" >up</a>] </p></div> |
| <h3 class="sectionHead"><span class="titlemark">8.2 </span> <a |
| id="x36-2260002"></a>Component Overview</h3> |
| <a |
| id="x36-226001r299"></a> |
| <h4 class="subsectionHead"><span class="titlemark">8.2.1 </span> <a |
| id="x36-2270001"></a>Room Language Overview</h4> |
| <!--l. 205--><p class="noindent" >We assume that the reader is familiar with the Xtext concepts. So we concentrate on the details of our implementation that |
| are worth to be pointed out. |
| <a |
| id="Q1-36-302"></a> |
| </p> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2280001"></a>Model Tweaks</h5> |
| <!--l. 210--><p class="noindent" >All language EMF models of eTrice are inferred from their respective grammar. However, this powerful mechanism has to be |
| tweaked in some places. |
| </p><!--l. 213--><p class="noindent" >In order to do so post processors are added that are invoked by the Xtext framework on language generation. This is done for |
| the FSM language by <span |
| class="ec-lmsso-10">/org.eclipse.etrice.core.fsm/src/org/eclipse/etrice/core/fsm/postprocessing/ImplPostprocessor.xtend</span>. |
| </p><!--l. 216--><p class="noindent" >The following parts of the model are changed or added: </p> |
| <ul class="itemize1"> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getName </span>is added to the <span |
| class="ec-lmtt-10">State </span>class |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getName </span>is added to the <span |
| class="ec-lmtt-10">StateGraphItem </span>class |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getSemantics </span>is added to the <span |
| class="ec-lmtt-10">AbstractInterfaceItem</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getAllIncomingAbstractMessages </span>is added to the <span |
| class="ec-lmtt-10">AbstractInterfaceItem</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getAllOutgoingAbstractMessages </span>is added to the <span |
| class="ec-lmtt-10">AbstractInterfaceItem</span> |
| </li> |
| <li class="itemize">an interface class <span |
| class="ec-lmtt-10">IInterfaceItemOwner </span>is added |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getAbstractInterfaceItems </span>is added to the <span |
| class="ec-lmtt-10">AbstractInterfaceItem</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getAllAbstractInterfaceItems </span>is added to the <span |
| class="ec-lmtt-10">AbstractInterfaceItem</span> |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">IInterfaceItemOwner </span>is made a super class of <span |
| class="ec-lmtt-10">ModelComponent</span></li></ul> |
| <!--l. 228--><p class="noindent" >All but the first two items in the list are part of the abstract FSM definition and are used to interface to the model |
| embedding the FSM language, e.g. ROOM. |
| </p><!--l. 231--><p class="noindent" >For the ROOM language the post processor is <span |
| class="ec-lmsso-10">/org.eclipse.etrice.core.room/src/org/eclipse/etrice/core/RoomPostprocessor.ext</span>. |
| </p><!--l. 234--><p class="noindent" >The following parts of the model are changed or added: </p> |
| <ul class="itemize1"> |
| <li class="itemize">the default <span |
| class="ec-lmtt-10">multiplicity </span>of the <span |
| class="ec-lmtt-10">Port </span>is set to 1 |
| </li> |
| <li class="itemize">the operation <span |
| class="ec-lmtt-10">isReplicated </span>is added to the <span |
| class="ec-lmtt-10">Port</span> |
| |
| |
| </li> |
| <li class="itemize">the default <span |
| class="ec-lmtt-10">multiplicity </span>of the <span |
| class="ec-lmtt-10">ActorRef </span>is set to 1 |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getGeneralProtocol </span>is added to the <span |
| class="ec-lmtt-10">InterfaceItem</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getSemantics </span>is added to the <span |
| class="ec-lmtt-10">InterfaceItem</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getAllIncomingAbstractMessages </span>is added to the <span |
| class="ec-lmtt-10">InterfaceItem</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getAllOutgoingAbstractMessages </span>is added to the <span |
| class="ec-lmtt-10">InterfaceItem</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getExternalEndPorts </span>is added to the <span |
| class="ec-lmtt-10">ActorClass</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getRelayPorts </span>is added to the <span |
| class="ec-lmtt-10">ActorClass</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getImplementedSPPs </span>is added to the <span |
| class="ec-lmtt-10">ActorClass</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getActorBase </span>is added to the <span |
| class="ec-lmtt-10">ActorClass</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getComponentName </span>is added to the <span |
| class="ec-lmtt-10">ActorClass</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getAbstractInterfaceItems </span>is added to the <span |
| class="ec-lmtt-10">ActorClass</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getAllAbstractInterfaceItems </span>is added to the <span |
| class="ec-lmtt-10">ActorClass</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getStructureClass </span>is added to the <span |
| class="ec-lmtt-10">ActorContainerRef</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">toString </span>is added to the <span |
| class="ec-lmtt-10">RefPath</span> |
| </li> |
| <li class="itemize">for attribute <span |
| class="ec-lmtt-10">idx </span>of <span |
| class="ec-lmtt-10">RefSegment </span>the default is changed to -1 |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">toString </span>is added to the <span |
| class="ec-lmtt-10">RefSegment</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getLiteralValue </span>is added to the <span |
| class="ec-lmtt-10">EnumLiteral</span> |
| </li> |
| <li class="itemize">an operation <span |
| class="ec-lmtt-10">getFullName </span>is added to the <span |
| class="ec-lmtt-10">EnumLiteral</span></li></ul> |
| <a |
| id="Q1-36-304"></a> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2290001"></a>Imports by URI Using Namespaces</h5> |
| <!--l. 260--><p class="noindent" >The import mechanism employed is based on URIs. This is configured for one part in the GenerateRoom.mwe2 model |
| workflow by setting the fragments ImportURIScopingFragment and ImportUriValidator). For the other part it is configured in |
| the Guice modules by binding </p> |
| <ul class="itemize1"> |
| <li class="itemize"><span |
| class="ec-lmtt-10">PlatformRelativeUriResolver </span>– this class tries to convert the import URI into a platform relative URI. It |
| also replaces environment variables written in $ with their respective values. |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">ImportedNamespaceAwareLocalScopeProvider </span>– this is a standard scope provider which is aware of |
| namespaces |
| |
| |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">GlobalNonPlatformURIEditorOpener </span>– this editor opener tries to convert general URIs into platform URIs |
| because editors can only open platform URIs |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">ImportAwareHyperlinkHelper </span>– turns the URI part of an import into a navigatable hyper link</li></ul> |
| <a |
| id="Q1-36-306"></a> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2300001"></a>Naming</h5> |
| <!--l. 275--><p class="noindent" >Two classes provide object names used for link resolution and for labels. The <span |
| class="ec-lmtt-10">RoomNameProvider </span>provides frequently used |
| name strings, some of them are hierarchical like State paths. The <span |
| class="ec-lmtt-10">RoomFragmentProvider </span>serves a more formal purpose |
| since it provides a link between EMF models (as used by the diagram editors) and the textual model representation used by |
| Xtext. |
| <a |
| id="Q1-36-308"></a> |
| </p> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2310001"></a>Helpers</h5> |
| <!--l. 283--><p class="noindent" >The <span |
| class="ec-lmtt-10">RoomHelpers </span>class provides a great deal of static methods that help retrieve frequently used information from the |
| model. Among many, many others </p> |
| <ul class="itemize1"> |
| <li class="itemize"><span |
| class="ec-lmtt-10">getAllEndPorts(ActorClass) </span>- returns a list of all end ports of an actor class including inherited ones |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">getInheritedActionCode(Transition, ActorClass) </span>- get the inherited part of a transition’s action code |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">getSignature(Operation) </span>- returns a string representing the operation signature suited for a label</li></ul> |
| <a |
| id="Q1-36-310"></a> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2320001"></a>Validation</h5> |
| <!--l. 297--><p class="noindent" >Validation is used from various places. Therefore all validation code is accumulated in the @ValidationUtil@ class. All methods |
| are static and many of them return a Result object which contains information about the problem detected as well as object |
| and feature as suited for most validation purposes. |
| <a |
| id="x36-232001r301"></a> |
| </p> |
| <h4 class="subsectionHead"><span class="titlemark">8.2.2 </span> <a |
| id="x36-2330002"></a>Config Language Overview</h4> |
| <a |
| id="Q1-36-313"></a> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2340002"></a>Model Tweaks</h5> |
| <!--l. 305--><p class="noindent" >A couple of operations are added to the ConfigModel </p> |
| <ul class="itemize1"> |
| <li class="itemize"><span |
| class="ec-lmtt-10">getActorClassConfigs</span> |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">getActorInstanceConfigs</span> |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">getProtocolClassConfigs</span> |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">getSubSystemConfigs</span></li></ul> |
| <a |
| id="Q1-36-315"></a> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2350002"></a>Imports by URI Using Namespaces</h5> |
| <!--l. 315--><p class="noindent" >Imports are treated like in Room language, section <span |
| class="ec-lmsso-10">Imports by URI Using Namespaces</span>. |
| <a |
| id="Q1-36-317"></a> |
| </p> |
| |
| |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2360002"></a>Util</h5> |
| <!--l. 319--><p class="noindent" >A set of static utility methods can be found in the <span |
| class="ec-lmtt-10">ConfigUtil </span>class. |
| <a |
| id="x36-236001r312"></a> |
| </p> |
| <h4 class="subsectionHead"><span class="titlemark">8.2.3 </span> <a |
| id="x36-2370003"></a>Aggregation Layer Overview</h4> |
| <!--l. 323--><p class="noindent" >The eTrice Generator Model (genmodel.fsm and genmodel) serves as an aggregation layer. Its purpose is to |
| allow easy access to information which is implicitly contained in the Room model but not simple to retrieve. |
| Examples of this are the state machine with inherited items or a list of all triggers active at a state in the |
| order in which they will be evaluated or the actual peer port of an end port (following bindings through relay |
| ports). |
| </p><!--l. 329--><p class="noindent" >The lower level <span |
| class="ec-lmtt-10">FSMGeneratorModelBuilder </span>takes a <span |
| class="ec-lmtt-10">ModelComponent </span>and returns a <span |
| class="ec-lmtt-10">ExpandedModelComponent </span>which has |
| the inheritance hierarchy of the state machine collapsed into one state machine. This lower level generator model only |
| depends on general parts and doesn’t refer to the ROOM model. |
| </p><!--l. 333--><p class="noindent" >The higher level Generator Model includes the FSM Generator Model. It is created from a list of Room models by a call of |
| the |
| |
| |
| </p> |
| <div class="verbatim" id="verbatim-6"> |
| createGeneratorModel(List<RoomModel>, boolean) |
| </div> |
| <!--l. 336--><p class="nopar" > |
| </p><!--l. 338--><p class="noindent" >method of the <span |
| class="ec-lmtt-10">GeneratorModelBuilder </span>class. |
| </p><!--l. 340--><p class="noindent" >The <span |
| class="ec-lmtt-10">Root </span>object of the resulting Generator Model provides chiefly two things: </p> |
| <ul class="itemize1"> |
| <li class="itemize">a tree of instances starting at each <span |
| class="ec-lmtt-10">SubSystem </span>with representations of each <span |
| class="ec-lmtt-10">ActorInstance </span>and <span |
| class="ec-lmtt-10">PortInstance</span> |
| </li> |
| <li class="itemize">for each <span |
| class="ec-lmtt-10">ActorClass </span>a corresponding <span |
| class="ec-lmtt-10">ExpandedActorClass </span>with an explicit state machine containing all |
| inherited state graph items</li></ul> |
| <a |
| id="Q1-36-320"></a> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2380003"></a>The Instance Model</h5> |
| <!--l. 350--><p class="noindent" >The instance model allows easy access to instances including their unique paths and object IDs. Also it is possible to |
| get a list of all peer port instances for each port instance without having to bother about port and actor |
| replication. |
| <a |
| id="Q1-36-322"></a> |
| </p> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2390003"></a>The Expanded Model Component</h5> |
| <!--l. 356--><p class="noindent" >The expanded model component contains, as already mentioned, the complete state machine of the model component. This |
| considerably simplifies the task of state machine generation. Note that the generated code always contains the complete state |
| machine of an actor. I.e. no target language inheritance is used to implement the state machine inheritance. Furthermore the |
| <span |
| class="ec-lmtt-10">ExpandedModelComponent </span>gives access to </p> |
| <ul class="itemize1"> |
| <li class="itemize"><span |
| class="ec-lmtt-10">getIncomingTransitions(StateGraphNode) </span>– the set of incoming transition of a <span |
| class="ec-lmtt-10">StateGraphNode </span>(<span |
| class="ec-lmtt-10">State</span>, |
| <span |
| class="ec-lmtt-10">ChoicePoint </span>or <span |
| class="ec-lmtt-10">TransitionPoint</span>) |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">getOutgoingTransitions(StateGraphNode) </span>– the set of outgoing transition of a <span |
| class="ec-lmtt-10">StateGraphNode</span> |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">getActiveTriggers(State) </span>– the triggers that are active in this <span |
| class="ec-lmtt-10">State </span>in the order they are evaluated</li></ul> |
| <a |
| id="Q1-36-324"></a> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2400003"></a>The Expanded Actor Class</h5> |
| <!--l. 372--><p class="noindent" >The <span |
| class="ec-lmtt-10">ExpandedActorClass </span>is derived from the <span |
| class="ec-lmtt-10">ExpandedModelComponent </span>and adds only minor new features. |
| </p> |
| <ul class="itemize1"> |
| <li class="itemize"><span |
| class="ec-lmtt-10">getActorClass() </span>– for convenience to avoid casts of the <span |
| class="ec-lmtt-10">ModelComponent </span>to an <span |
| class="ec-lmtt-10">ActorClass</span> |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">getVarDeclData(Transition) </span>– for convenience to avoid casts to <span |
| class="ec-lmtt-10">VarDecl</span></li></ul> |
| <a |
| id="Q1-36-326"></a> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2410003"></a>Transition Chains</h5> |
| <!--l. 380--><p class="noindent" >By transition chains we denote a connected subset of the (hierarchical) state machine that starts with a transition starting at |
| a state and continues over transitional state graph nodes (choice points and transition points) and continuation transitions |
| until a state is reached. In general a transition chain starts at one state and ends in several states (the chain may branch in |
| choice points). A <span |
| class="ec-lmtt-10">TransitionChain </span>of a transition is retrieved by a call of <span |
| class="ec-lmtt-10">getChain(Transition) </span>of the |
| <span |
| class="ec-lmtt-10">ExpandedActorClass</span>. The <span |
| class="ec-lmtt-10">TransitionChain </span>accepts an <span |
| class="ec-lmtt-10">ITransitionChainVisitor </span>which is called along the chain to |
| generate the action codes of involved transitions and the conditional statements arising from the involved choice |
| points. |
| |
| |
| <a |
| id="x36-241001r319"></a> |
| </p> |
| <h4 class="subsectionHead"><span class="titlemark">8.2.4 </span> <a |
| id="x36-2420004"></a>Generator Overview</h4> |
| <!--l. 392--><p class="noindent" >There is one plug-in that consists of base classes and some generic generator parts which are re-used by all language specific |
| generators |
| <a |
| id="Q1-36-329"></a> |
| </p> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2430004"></a>Base Classes and Interfaces</h5> |
| <!--l. 397--><p class="noindent" >We just want to mention the most important classes and interfaces. Some of them can be found in the |
| <span |
| class="ec-lmtt-10">org.eclipse.etrice.generator.fsm </span>and th rest in <span |
| class="ec-lmtt-10">org.eclipse.etrice.generator</span>. |
| </p> |
| <ul class="itemize1"> |
| <li class="itemize"> |
| <div class="flushleft" |
| > |
| <!--l. 402--><p class="noindent" > |
| <span |
| class="ec-lmtt-10">ITranslationProvider </span>— this interface is used by the <span |
| class="ec-lmtt-10">DetailCodeTranslator </span>for the language dependent |
| translation of e.g. port.message() notation in detail code</p></div> |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">AbstractGenerator </span>— concrete language generators should derive from this base class |
| </li> |
| <li class="itemize"> |
| <div class="flushleft" |
| > |
| <!--l. 406--><p class="noindent" > |
| <span |
| class="ec-lmtt-10">DefaultFSMTranslationProvider </span>and <span |
| class="ec-lmtt-10">DefaultTranslationProvider </span>— a stub implementation of |
| <span |
| class="ec-lmtt-10">IFSMTranslationProvider </span>and <span |
| class="ec-lmtt-10">ITranslationProvider </span>from which clients may derive</p></div> |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">Indexed </span>— provides an indexed iterable of a given iterable |
| </li> |
| <li class="itemize"><span |
| class="ec-lmtt-10">GeneratorBaseModule </span>— a Google Guice module that binds a couple of basic services. Concrete language generators |
| should use a module that derives from this</li></ul> |
| <a |
| id="Q1-36-331"></a> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2440004"></a>Generic Generator Parts</h5> |
| <!--l. 415--><p class="noindent" >The generic generator parts provide code generation blocks on a medium granularity. The language dependent top level |
| generators embed those blocks in a larger context (file, class, ...). Language dependent low level constructs are provided by |
| means of an <span |
| class="ec-lmtt-10">ILanguageExtension</span>. This extension and other parts of the generator be configured using Google Guice |
| dependency injection. |
| <a |
| id="Q1-36-333"></a> |
| <span |
| class="ec-lmssbx-10">GenericActorClassGenerator </span>The <span |
| class="ec-lmtt-10">GenericActorClassGenerator </span>generates constants for the interface items of a actor. |
| Those constants are used by the generated state machine. |
| <a |
| id="Q1-36-334"></a> |
| <span |
| class="ec-lmssbx-10">GenericProtocolClassGenerator </span>The <span |
| class="ec-lmtt-10">GenericProtocolClassGenerator </span>generates message ID constants for a |
| protocol. |
| <a |
| id="Q1-36-335"></a> |
| </p> |
| <span |
| class="ec-lmssbx-10">GenericStateMachineGenerator</span> |
| <div class="flushleft" |
| > |
| |
| |
| <!--l. 431--><p class="noindent" > |
| The <span |
| class="ec-lmtt-10">GenericStateMachineGenerator </span>generates the complete state machine implementation. The skeleton of the |
| generated code is</p></div> |
| <ul class="itemize1"> |
| <li class="itemize">definition state ID constants |
| </li> |
| <li class="itemize">definition of transition chain constants |
| </li> |
| <li class="itemize">definition of trigger constants |
| </li> |
| <li class="itemize">entry, exit and action code methods |
| </li> |
| <li class="itemize">the <span |
| class="ec-lmtt-10">exitTo </span>method |
| </li> |
| <li class="itemize">the <span |
| class="ec-lmtt-10">executeTransitionChain </span>method |
| </li> |
| <li class="itemize">the <span |
| class="ec-lmtt-10">enterHistory </span>method |
| </li> |
| <li class="itemize">the <span |
| class="ec-lmtt-10">executeInitTransition </span>method |
| </li> |
| <li class="itemize">the <span |
| class="ec-lmtt-10">receiveEvent </span>method</li></ul> |
| <!--l. 446--><p class="noindent" >The state machine works as follows. The main entry method is the <br |
| class="newline" /><span |
| class="ec-lmtt-10">receiveEvent </span>method. This is the case for both, data driven (polled) and event driven state machines. Then a number of |
| nested switch/case statements evaluates trigger conditions and derives the transition chain that is executed. If a |
| trigger fires then the <span |
| class="ec-lmtt-10">exitTo </span>method is called to execute all exit codes involved. Then the transition chain |
| action codes are executed and the choice point conditions are evaluated in the <span |
| class="ec-lmtt-10">executeTransitionChain</span> |
| method. Finally the history of the state where the chain ends is entered and all entry codes are executed by |
| <span |
| class="ec-lmtt-10">enterHistory</span>. |
| <a |
| id="Q1-36-336"></a> |
| </p> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2450004"></a>The Java Generator</h5> |
| <!--l. 456--><p class="noindent" >The Java generator employs the generic parts of the generator. The <span |
| class="ec-lmtt-10">JavaTranslationProvider </span>is very simple and only |
| handles the case of sending a message from a distinct replicated port: <span |
| class="ec-lmtt-10">replPort[2].message()</span>. Other cases are handled by |
| the base class by returning the original text. |
| </p><!--l. 460--><p class="noindent" >The <span |
| class="ec-lmtt-10">DataClassGen </span>uses Java inheritance for the generated data classes. Otherwise it is pretty much straight |
| forward. |
| </p><!--l. 463--><p class="noindent" >The <span |
| class="ec-lmtt-10">ProtocolClassGen </span>generates a class for the protocol with nested static classes for regular and conjugated ports and |
| similar for replicated ports. |
| </p><!--l. 466--><p class="noindent" >The <span |
| class="ec-lmtt-10">ActorClassGen </span>uses Java inheritance for the generated actor classes. So ports, SAPs and attributes and detail code |
| methods are inherited. Not inherited is the state machine implementation. |
| <a |
| id="Q1-36-338"></a> |
| </p> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2460004"></a>The ANSI-C Generator</h5> |
| <!--l. 471--><p class="noindent" >The C generator translates data, protocol and actor classes into structs together with a set of methods that operate on them |
| and receive a pointer to those data (called <span |
| class="ec-lmtt-10">self </span>in analogy to the implicit C++ <span |
| class="ec-lmtt-10">this </span>pointer). No dynamic memory |
| allocation is employed. All actor instances are statically initialized. One of the design goals for the generated C code was an |
| optimized footprint in terms of memory and performance to be able to utilize modeling with ROOM also for tiny low end |
| micro controllers. |
| |
| |
| <a |
| id="Q1-36-340"></a> |
| </p> |
| <h5 class="likesubsubsectionHead"><a |
| id="x36-2470004"></a>The Documentation Generator</h5> |
| <!--l. 480--><p class="noindent" >The documentation generator creates documentation in LaTex format which can be converted into PDF and many other |
| formats. |
| </p> |
| <!--l. 126--><div class="crosslinks"><p class="noindent">[<a |
| href="etrice-docse25.html" >prev</a>] [<a |
| href="etrice-docse25.html#tailetrice-docse25.html" >prev-tail</a>] [<a |
| href="etrice-docse26.html" >front</a>] [<a |
| href="etrice-docch8.html#etrice-docse26.html" >up</a>] </p></div> |
| <!--l. 126--><p class="noindent" ><a |
| id="tailetrice-docse26.html"></a></p> |
| </body></html> |