simon
/
yakindu


			
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543
							<?xml version='1.0' encoding='utf-8' ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
		<title>reference</title>
		<link type="text/css" rel="stylesheet" href="../style.css"/>
	</head>
	<body>
		<h1 id="YAKINDUSCT2Reference">YAKINDU SCT 2 Reference</h1>
		<h2 id="Statechartelements">State chart elements</h2>
		<p>In the following the state chart elements of the YAKINDU SCT 2 editor are described. The meta model of the YAKINDU SCT 2 is the model of finite state machines. It is based on the view of a system that is defined by a finite number of states. The behavior of that system is based on the active states. These states are determined by the history of the state machine. Very important are the theoretical models for state machines by Mealy and Moore. Mealy state machines associate actions with transitions. Moore machines associate actions with states (entry, exit). In the YAKINDU SCT 2 both is possible.</p>
		<p>The YAKINDU SCT 2 meta model is designed similar to the UML state chart meta model with the following differences</p>
		<ul>
			<li>they are self contained with interfaces defined by events and variables</li>
			<li>core execution semantics are cycle driven, not event driven
				<ul>
					<li>this allows to process concurrent events</li>
					<li>event driven behavior can be defined on top</li>
				</ul>
			</li>
			<li>time is an abstract concept for state charts</li>
			<li>time control is delegated to the environment</li>
		</ul>
		<p>The model interpreter and different flavors of generated code follow these same core semantics.</p>
		<p>Please refer to the description of the 
			<a href="http://en.wikipedia.org/wiki/UML_state_machine">UML Statecharts</a> for more details.
		</p>
		<h3 id="Regions">Regions</h3>
		<p>As already mentioned the YAKINDU state charts are self contained. They are organized in regions. Due to this it is possible to organize multiple state machines in different regions and to run them concurrently.  </p>
		<p>
			<img border="0" src="images/parallelRegions.jpg"/>
		</p>
		<h3 id="States">States</h3>
		<p>States are the central elements of a state machine. A state has to be placed inside a region and needs a unique name inside this region. During simulation each state can be active or passive. An active state has actions that are accomplished. Either an action is carried out on entering a state, during active state or on exit.   </p>
		<h3 id="Transitions">Transitions</h3>
		<p>A transition is the transfer of one state to another. Transitions are diagrammed as arrows and can carry events and actions but must not. </p>
		<p>The syntax of events and actions is defined by a textual description language (#Statechartdescriptionlanguage). Please refer to the documentation section 
			<a href="#Events">Events</a> for more details. For more details on Actions refer to the chapter 
			<a href="#ReactionTriggers">Actions</a>.
		</p>
		<p>If a state has more than one outgoing transition without event that transition is carried out first that was modeled first.</p>
		<h3 id="Initialstateandfinalstate">Initial state and final state</h3>
		<p>Initial and final states are pseudo states, because the state chart does not rest on them. Pseudo states express characteristics that are impossible to express by simple states. </p>
		<p>The initial state is always the first state that is active during interpretation or simulation of the state machine. An initial state can only have one outgoing transition and no incoming. This transition has no events or actions.</p>
		<p>Inside a region only one initial state is allowed, but every region can have an initial state.</p>
		<h3 id="Choice">Choice</h3>
		<p>Choice is also a pseudo state. It can be used to model a conditional path. Choice nodes divide a transition into multiple parts. </p>
		<p>Usually the first transition points towards the choice node. One of the choice outgoing transitions can carry a condition. </p>
		<h3 id="Junction">Junction</h3>
		<p>A junction is a pseudo state do combine transitions. This is very comfortable if a state machine has many similar transitions. Junctions add clear arrangement to the state machine.</p>
		<h3 id="CompositeState">Composite State</h3>
		<p>A composite state is a state that is composed of other state machines. These are also organized in regions. Besides the simple composite state YAKINDU knows two kinds of composite states: orthogonal state and submachine states.</p>
		<p>Composite states contain other state machine branches.</p>
		<h4 id="Orthogonalstates">Orthogonal states</h4>
		<p>In the context of state machines orthogonal states are states that are independent from each other. The most famous example is the keyboard example:</p>
		<p>
			<img border="0" src="images/orthogonalState_example.jpg"/>
		</p>
		<h4 id="Submachinestates">Submachine states</h4>
		<p>Submachine states may contain complete state machines. Here the user can chose another state machine to be included or create a new sub statemachine. During simulation only the top level statemachine is interpreted. It is not possible to jump to the sub level state machines and back.</p>
		<p>
			<img border="0" src="images/substatemachine_example.jpg"/>
		</p>
		<h3 id="ShallowHistory">Shallow History</h3>
		<p>The shallow history state is a pseudo state that is placed inside regions of composite states. It is used to &#8218;remember&#8217; the last active state inside a composite state. So it is possible to jump to this state instead of starting at the inner entry state again. The following example of a questionaire answering will explain this:</p>
		<p>
			<img border="0" src="images/shallowHistory01.jpg"/>
		</p>
		<p>The interesting parts in this state chart are the events 
			<em>checkProgress</em> and 
			<em>goon</em>. CheckProgress jumps back to the init state while assigning the current progress count to the variable 
			<em>temp</em>. 
			<em>goon</em> jumps to the shallow history state that was placed inside the composite state.
		</p>
		<p>
			<img border="0" src="images/shallowHistory02.jpg"/>
		</p>
		<p>
			<img border="0" src="images/shallowHistory03.jpg"/>
		</p>
		<p>On triggering the 
			<em>goon</em> event the last active state is activated again.
		</p>
		<h3 id="DeepHistory">Deep History</h3>
		<p>Deep history is similar to shallow history but more complex. With a deep history the latest state of multiple nested states is remembered.</p>
		<h2 id="Statechartdescriptionlanguage">Statechart description language</h2>
		<p>The textual description language is used to declare and describe behaviors in the state machine. It is case sensitive.</p>
		<h3 id="Typesystem">Typesystem</h3>
		<p>The language has an integrated small typesystem with the following simple types:</p>
		<ul>
			<li>integer</li>
			<li>real</li>
			<li>boolean</li>
			<li>string</li>
			<li>void</li>
		</ul>
		<p>So events and variables can be declared with types:</p>
		<pre><code>var intVar : integer
var realVar : real
var boolVar : boolean
var stringVar : string
var voidVar : void
event addInt : integer
event checkValidity : boolean
 

</code></pre>
		<h3 id="Expressions">Expressions</h3>
		<p>Expressions can be defined similar to other programming languages. The language offers operators to define logical expressions, bitwise arithmetic, and arithmetic expressions and bit shifting.</p>
		<p>Logical expressions are similar to other programming languages. The return type is 
			<strong>boolean</strong>. In the following there are some examples of these:
		</p>
		<h4 id="LogicalAND">Logical AND</h4>
		<pre><code>var1 &amp;&amp; var2
</code></pre>
		<h4 id="LogicalOR">Logical OR</h4>
		<pre><code>var1 ||  var2 
</code></pre>
		<h4 id="LogicalNOT">Logical NOT</h4>
		<pre><code>!var1 
</code></pre>
		<h4 id="Conditionalexpression">Conditional expression</h4>
		<pre><code>var1 ? var2 : 23 
</code></pre>
		<h4 id="BitwiseXOR">Bitwise XOR</h4>
		<pre><code>var1 ^ var2
</code></pre>
		<h4 id="BitwiseOR">Bitwise OR</h4>
		<pre><code>var1 | var2
</code></pre>
		<h4 id="BitwiseAND">Bitwise AND</h4>
		<pre><code>var1 &amp; var2
</code></pre>
		<h4 id="LogicalRelationsandShiftOperators">Logical Relations and Shift Operators</h4>
		<table>
			<tr>
				<td>less than </td>
				<td>&lt; </td>
			</tr>
			<tr>
				<td>equal or less than </td>
				<td>&lt;= </td>
			</tr>
			<tr>
				<td>greater than </td>
				<td>&gt; </td>
			</tr>
			<tr>
				<td>equal or greater than </td>
				<td>&gt;= </td>
			</tr>
			<tr>
				<td>equal </td>
				<td>== </td>
			</tr>
			<tr>
				<td>not equal </td>
				<td>!= </td>
			</tr>
			<tr>
				<td>shift left </td>
				<td>&lt;&lt; </td>
			</tr>
			<tr>
				<td>shift right </td>
				<td>&gt;&gt; </td>
			</tr>
		</table>
		<h4 id="Binaryarithmeticoperators">Binary arithmetic operators</h4>
		<table>
			<tr>
				<td>plus </td>
				<td>+ </td>
			</tr>
			<tr>
				<td>minus </td>
				<td>- </td>
			</tr>
			<tr>
				<td>multiply </td>
				<td>* </td>
			</tr>
			<tr>
				<td>divide </td>
				<td>/ </td>
			</tr>
			<tr>
				<td>modulo </td>
				<td>% </td>
			</tr>
		</table>
		<h4 id="Unaryarithmeticoperators">Unary arithmetic operators</h4>
		<table>
			<tr>
				<td>positive </td>
				<td>+ </td>
			</tr>
			<tr>
				<td>negative </td>
				<td>- </td>
			</tr>
			<tr>
				<td>circa	</td>
				<td>~ </td>
			</tr>
		</table>
		<h3 id="Statements">Statements</h3>
		<p>A statements can be either an assignment, raising an event or call an operation. The language has the following assignment operators:</p>
		<ul>
			<li>simple assignment:  = </li>
			<li>multiply and assign: *= </li>
			<li>divide and assign: /= </li>
			<li>calculate modulo and assign: %= </li>
			<li>add and assign: += </li>
			<li>subtract and assign: -= </li>
			<li>bitshift left and assign: &lt;&lt;= </li>
			<li>bitshift right and assign: &gt;&gt;= </li>
			<li>bitwise AND and assign: &amp;= </li>
			<li>bitwise XOR and assign: ^= </li>
			<li>bitwise OR and assign: 
				<code>|=</code> 
			</li>
		</ul>
		<p>An event is raised by the keyword 
			<em>raise</em> followed by the event name and if it is an interface event the name of the interface.
		</p>
		<p>An operation is called similar to other programming languages with the operation name and passing concrete parameters. The parameters can be expressions.</p>
		<h3 id="Scopes">Scopes</h3>
		<p><!-- Start stext_keyword_namespace --></p>
		<h4 id="Namespace">Namespace</h4>
		<p>The language allows to define unique namespaces, which can be used to qualify references to the statechart.</p>
		<pre><code>namespace trafficlights

</code></pre>
		<p><!-- End stext_keyword_namespace -->
			<br/><!-- Start stext_keyword_interface -->
		</p>
		<h4 id="interfacescope">interface scope</h4>
		<p>Declarations in the interface scope are externally visible. They can be shared within the environment.</p>
		<pre><code>interface NamedInterface:
in event event1
out event event3
var variable1 : real
entrypoint entry1
exitpoint exit1

</code></pre>
		<p><!-- End stext_keyword_interface -->
			<br/><!-- Start stext_keyword_internal -->
		</p>
		<h4 id="internalscope">internal scope</h4>
		<p>Declarations made in an internal scope are only visible for contained states.</p>
		<pre><code>internal:
var localVariable1: integer
event localEvent: integer
local event localEvent2: NamedInterface.event1 || localEvent
local event localEvent3: localEvent || localEvent2 : 25
operation localOperation (integer, integer): integer
localEvent3 / raise NamedInterface.event3 :
localOperation(valueOf(localEvent),NamedInterface.variable1);

</code></pre>
		<p><!-- End stext_keyword_internal --></p>
		<h3 id="Declarations">Declarations</h3>
		<p>Within scopes there can be declarations of Events, Variables, Operations, LocalReactions, EntryPoints and ExitPoints.</p>
		<p><!-- Start stext_keyword_event --></p>
		<h3 id="Events">Events</h3>
		<p>Within interface scope events have an direction. They can either be ingoing or outgoing:</p>
		<pre><code>interface NamedInterface:
in event event1
out event event2
</code></pre>
		<p>Within local scope events can carry variables:</p>
		<pre><code>internal:
event localEvent1 : integer
</code></pre>
		<p>Local events can be derived from interface events or other local events and can have a value assignment:</p>
		<pre><code>internal:
event localEvent1: integer
local event localEvent2 = NamedInterface.event1 || localEvent1
local event localEvent3 = localEvent2 || 25

</code></pre>
		<p><!-- End stext_keyword_event --></p>
		<p><!-- Start stext_keyword_var --></p>
		<h3 id="Variables">Variables</h3>
		<p>Variables can have different visibilities. They can be visible for the environment:</p>
		<pre><code>var variable1: real
</code></pre>
		<p>Variables can be 
			<strong>readonly</strong> (constants):
		</p>
		<pre><code>var readonly pi: real = 3.1415
</code></pre>
		<p>Variables can be referenced by the environment.</p>
		<pre><code>var external variable3: integer = 34

</code></pre>
		<p><!-- End stext_keyword_var --></p>
		<h3 id="ReactionTriggers">Reaction Triggers</h3>
		<p>Actions are key constructs in state machines to model behavior. The YAKINDU SCT 2 knows the following kinds of actions.</p>
		<p><!-- Start stext_keyword_after --></p>
		<h4 id="after">after</h4>
		<p>The 
			<em>after</em> trigger specifies one-shot time events. 
		</p>
		<p>After the specified time the reaction is triggered. An 
			<em>after</em> trigger can be used in transitions of states as well in local reactions of states and statecharts. The specified time starts when the state or statechart is entered. 
		</p>
		<pre><code>after 20 s
</code></pre>
		<p>Structure: </p>
		<p>
			<code>after</code> 
			<em>
				<code>time</code>
			</em> (
			<em>
				<code>unit</code>
			</em>)? 
		</p>
		<p>The time unit can be:</p>
		<ul>
			<li><!-- Start stext_keyword_s --> s &#8211; seconds <!-- End stext_keyword_s --></li>
			<li><!-- Start stext_keyword_ms --> ms &#8211; milliseconds <!-- End stext_keyword_ms --></li>
			<li><!-- Start stext_keyword_us --> us &#8211; microseconds <!-- End stext_keyword_us --></li>
			<li><!-- Start stext_keyword_ns --> ns &#8211; nanoseconds <!-- End stext_keyword_ns --></li>
			<li>empty &#8211; implies seconds</li>
		</ul>
		<p><!-- End stext_keyword_after -->
			<br/><!-- Start stext_keyword_every -->
		</p>
		<h4 id="every">every</h4>
		<p>The 
			<em>every</em> trigger specifies periodic time events. 
		</p>
		<p>The reaction is triggered periodically after the specified time. An 
			<em>every</em> trigger can be used in transitions of states as well in local reactions of states and statecharts. The specified time starts when the state or statechart is entered and repeats periodically. 
		</p>
		<pre><code>every 200 ms
</code></pre>
		<p>Structure: </p>
		<p>
			<code>every</code> 
			<em>
				<code>time</code>
			</em> (
			<em>
				<code>unit</code>
			</em>)? 
		</p>
		<p>The time unit can be:</p>
		<ul>
			<li>s &#8211; seconds</li>
			<li>ms &#8211; milliseconds</li>
			<li>us &#8211; microseconds</li>
			<li>ns &#8211; nanoseconds</li>
			<li>empty &#8211; implies seconds</li>
		</ul>
		<p><!-- End stext_keyword_every -->
			<br/><!-- Start stext_keyword_always -->
		</p>
		<h4 id="always">always</h4>
		<p>This trigger is always true and enables a reaction to be executed in every run to completion step (RTS). It is equivalent to 
			<em>oncycle</em>.
		</p>
		<p><!-- End stext_keyword_always --></p>
		<p><!-- Start stext_keyword_default -->
			<br/><!-- Start stext_keyword_else -->
		</p>
		<h4 id="defaultelse">default, else</h4>
		<p>The 
			<em>default</em> trigger is equivalent to the 
			<em>else</em> trigger. It is intended for use for the outgoing transitions of 
			<em>choice</em> pseudo states, to make sure that always an outgoing transition can be taken. It can only be be used in transitions and implies the lowest evaluation priority for that transition. 
		</p>
		<p><!-- End stext_keyword_else -->
			<br/><!-- End stext_keyword_default -->
		</p>
		<p><!-- Start stext_keyword_entry --></p>
		<h4 id="entry">entry</h4>
		<p>An 
			<em>entry</em> trigger marks actions that are carried out on entering a state or state machine.
		</p>
		<p><!-- End stext_keyword_entry -->
			<br/><!-- Start stext_keyword_exit -->
		</p>
		<h4 id="exit">exit</h4>
		<p>An 
			<em>exit</em> trigger marks actions that are carried out on exiting a state or state machine.
		</p>
		<p><!-- End stext_keyword_exit -->
			<br/><!-- Start stext_keyword_oncycle -->
		</p>
		<h4 id="oncycle">oncycle</h4>
		<p>The 
			<em>oncycle</em> trigger is always true and enables a reaction to be executed in every run to completion step (RTS). It is equivalent to 
			<em>always</em>.
		</p>
		<p><!-- End stext_keyword_oncycle -->
			<br/><!-- Start stext_keyword_operation -->
		</p>
		<h3 id="Operations">Operations</h3>
		<p>Operations can have none, one or multiple parameters. The parameters are only declarated by their type. An operation can have one return type similar to Java.</p>
		<pre><code>operation localOperation (integer, integer):integer
localEvent3/ raise NamedInterface3.event1

</code></pre>
		<p><!-- End stext_keyword_operation --></p>
		<h3 id="LocalReactions">LocalReactions</h3>
		<p>Local reactions describe the internal behavior of a state. So they have internal scope. A local reaction is  declared as follows:</p>
		<pre><code>LocalReaction: ReactionTrigger '/' ReactionEffect ('#' ReactionProperties)?

ReactionTrigger: (Event ("," Event	)* 	(=&gt; '[' Expression ']')?) | '[' Expression ']'					

ReactionEffect:  Statement (';' Statement )* (';')?

Statement: Assignment | EventRaising | OperationCall

ReactionProperties: (EntryPoint | ExitPoint)*
</code></pre>
		<p>Within a local reaction an interface event can be raised:</p>
		<pre><code>internal:
localEvent1 / raise NamedInterface.event3 : localOperation (valueOf(localEvent), NamedInterface.variable1);
</code></pre>
		<p>Local reactions can have priority values. These are defined by a following # and the integer number of priority:</p>
		<pre><code>localEvent2 / NamedInterface.variable2 += 3; #1
localEvent3 / NamedInterface.variable4 += 2.0; #2

</code></pre>
		<p><!-- Start stext_keyword_entrypoint --></p>
		<h3 id="EntryPoints">EntryPoints</h3>
		<p>Every state chart has an entry point. An entry point can be declared like the following:</p>
		<pre><code>entrypoint entry1

</code></pre>
		<p><!-- End stext_keyword_entrypoint -->
			<br/><!-- Start stext_keyword_exitpoint -->
		</p>
		<h3 id="ExitPoints">ExitPoints</h3>
		<p>Every state chart has an exit point. This exit point can be declared like the following.</p>
		<pre><code>exitpoint exit1
</code></pre>
		<p><!-- End stext_keyword_exitpoint --></p>
		<h2 id="SGraph">SGraph</h2>
		<p>SGraph is the metamodel for the graphical part of the statechart editor. It owns all core elements of a state machine like states, pseudostates, transitons etc. but it describes how these elements shall be shown by the editor.</p>
		<h2 id="SExec">SExec</h2>
		<p>SExec is the name of an intermediate execution model. This intermediate model is used behind the scenes as a foundation for the code generators and the simulation engine. This guarantees that the simulation behaves in the same way as the generated Statechart implementations. It captures the execution behavior and may also serve as the basis of custom code generators.</p>
		<h2 id="SGen">SGen</h2>
		<p>All generators can be customized with a generator model. This is a textual model file where generator features, like i.e. the outlet path, can be specified. The following screenshot shows an example configuration for the java code generator. </p>
		<p>To get started with the generator model, we included a new Eclipse wizard that creates a basic configuration file with default values.</p>
		<p>
			<img border="0" src="images/sGenEditor.png"/>
		</p>
		<p>The generator model is associated with the builder. If 
			<strong>Project</strong> &gt; 
			<strong>Build Automatically</strong> is checked the files are generated. In the following the specific customizing features of the generator models are explained.
		</p>
		<h3 id="GeneratormodelforJava">Generator model for Java</h3>
		<p>The generator model for Java is used to customize the generation of Java code from the state chart model. </p>
		<h4 id="FeatureOutlet">Feature Outlet</h4>
		<p>With the feature 
			<strong>Outlet</strong> you define the folder the source files will be generated in:
		</p>
		<pre><code>		feature Outlet {
			targetProject = "org.terra.coffee.machine"
			targetFolder = "src-gen"			
		}

</code></pre>
		<h4 id="FeatureLicenseHeader">Feature LicenseHeader</h4>
		<p>With the feature Licence header you can set a licence text that is added to the headers of all generated files:</p>
		<pre><code>		feature licenseHeader {
			licenseText = "Copyright (c) 2012 itemis AG.
 All rights reserved."			
		}


</code></pre>
		<h4 id="FeatureDebug">Feature Debug</h4>
		<p>The feature debug controls the output of debug information. An important information source is the intermediate model sExec.</p>
		<pre><code>		feature Debug {
			dumpSexec = false			
		}

</code></pre>
		<h4 id="FeatureFunctionInlining">Feature FunctionInlining</h4>
		<pre><code>		feature FunctionInlining {
			inlineChoices=true
			inlineEnterRegion=true
			inlineEnterSequences=true
			inlineEntries=true
			inlineEntryActions=true
			inlineExitActions=true
			inlineExitRegion=true
			inlineExitSequences=true
			inlineReactions=true
		}

</code></pre>
		<h4 id="FeatureGeneralFeatures">Feature GeneralFeatures</h4>
		<pre><code>		feature GeneralFeatures {
			EventBasedStatemachine=true
			GenericInterfaceSupport=true
			InterfaceObserverSupport=true
			RuntimeService=false
			StatemachineFactorySupport=true
			TimerService=true
		}

</code></pre>
		<h4 id="FeatureNaming">Feature Naming</h4>
		<pre><code>		feature Naming {
			basePackage="org.java"
			implementationSuffix="ipl"
		}
</code></pre>
		<h3 id="GeneratormodelforC">Generator model for C</h3>
		<h4 id="FeatureOutlet2">Feature Outlet</h4>
		<p>The feature is similar to the target language Java.</p>
		<h4 id="FeatureLicenseHeader2">Feature LicenseHeader</h4>
		<p>The feature is similar to the target language Java.</p>
		<h4 id="FeatureDebug2">Feature Debug</h4>
		<p>The feature is similar to the target language Java.</p>
		<h4 id="FeatureCCodeFeature">Feature CCodeFeature</h4>
		<pre><code>		feature CCodeFeature {
			DebugType="DEBUG"
			InterfaceEventListener=false
			Singleton=true
		}

</code></pre>
		<h4 id="FeatureFunctionInlining2">Feature FunctionInlining</h4>
		<h3 id="GeneratormodelforC2">Generator model for C++</h3>
		<h4 id="FeatureOutlet3">Feature Outlet</h4>
		<p>The feature is similar to the target language Java.</p>
		<h4 id="FeatureLicenseHeader3">Feature LicenseHeader</h4>
		<p>The feature is similar to the target language Java.</p>
		<h4 id="FeatureDebug3">Feature Debug</h4>
		<p>The feature is similar to the target language Java.</p>
		<h4 id="FeatureFunctionInlining3">Feature FunctionInlining</h4>
	</body>
</html>