Model to Code Transformation

The objective of the model to code transformation is to transform a Platform-Independent Model (PIM) into a Platform-Specific Model (PSM). The PIM is typically expressed as an UML model whereas the PSM is represented as source code.

Transformation Process

The code generation is based on a transformation mechanism that converts elements of a UML source model to elements of a target model (i.e. Java or C++ code). The transformation process of the code generator depends on conversion rules, where a rule converts one type of source element into one or more target elements. For example, a given rule may only be executed if the model element type is a UML class and that element has a specific stereotype applied to it. Therefore, some transformations may require a particular UML profile be applied to the source model elements before it can successfully convert those elements into target elements.

Transformation Technology

The chosen technology for the code generation process is Eclipse's Java Emitter Templates (JET) that is an open source tool for code generation within the Eclipse Modeling Framework (EMF). JET uses a subset of Java Server Pages syntax (JSP) for writing templates expressing the code that should be generated. JET is a generic template engine allowing to generate any type of source code.

Writing templates within Eclipse is very simple if we use a JET editor (e.g. Merlin) having features such as syntax coloring, code completion and dynamic checking. Templates are stored in the Eclipse workspace together with other code. They can be easily shared, imported, and exported. However, using JET technology for code generation has also some disadvantages. The most serious problem is complexity of the templates and the use of Java code for acquiring information from a model.

The following figure demonstrates the the code generation process based on JET templates.

Hierarchical State Machine

Hierarchical state machines are the key modeling element that is used to express functional behavior. There are several solutions available for mapping hierarchical state machines to source code (nested if and switch statements, object-oriented state design pattern, generic state machine interpreters, concurrent hierarchical state machines), but none of them meets the specific needs of the embedded applications instantiated from a software framework. Hence, a decision was taken to develop own state machine concept conforming to UML 2.0 state machine package. The primary goal was to provide a simple concept and its efficient implementation. The concept implements the following features forming a subset of UML state machines:

  • state nesting

  • inheritance and specialization of states and transitions

  • guarded transitions

  • execution of entry/exit actions upon entering/exiting states

State Nesting

The proposed structure of the Hierarchical State Machine (HSM) concept is shown in figure below. States of a state machine are represented as an instances of the State class, where the state nesting is achieved with state inclusion.

State machine extension

The most important feature of the new state machine design defined in the UML 2.0 standard is an extension mechanism. There are two kinds of state machine extensions available: state addition and transition addition. However, only extension through state addition is considered in the proposed described concept. For example, if a base class B has an associated state machine SM-B and class D is derived from B and has an associated state machine SM-D that is derived by extension from SM-B, then the proposed state machine concept allows SM-D to be implemented without touching the implementation of SM-B.

State Transitions

A state transition is equipped by trigger operation, guard and an action, optionally a name can be associated. The trigger operations are supposed to be implemented as normal operations that implements inactivation of the current state (there is only one active state in the whole state machine) and activation of the target state in case that all conditions (i.e. the transitions guards) for making the state transition are fulfilled.

Entering/exiting Actions of States

State entry/exit actions are not implemented by means of the delegation mechanism, see the following figure.

State Machine Instantiation

The topological structure of a state machine and marking of an active state and a default state (a state to which an initial state is connected) in the state machine hierarchy is created in the constructor of a class to which the state machine is associated. Before the state machine can be used, all states must be initialized by invocation of the 'initialize()' operation according to the top-down hierarchical order.

Target Language

As it will be demonstrated in the UML2 Model to Java Transformation Example section the generated code has a format of standard Java language. To generate other code format or to use different target language would require to develop a new PSM code generator or to make appropriate extensions if possible.

Manual Code Completion

The objective of the model-to-code transformation is to minimize manual coding in order to reduce tedious and faulty programming work. Nevertheless, not all code can be generated completely by the proposed transformation. The PSM model to code transformation generates complete implementation of dynamic behavior expressed by state machines and for the static part of the software architecture generates code skeleton that have to be completed manually in order to produce a fully functional program.

Variant vs. Invariant Code

After running the model-to-code transformation (using the PSM code generator in our case), it is still possible to change the UML model at anytime and re-run the transformation again without losing code written manually. The transformation merges changes to source code by using @generated tags in the Javadocs. Removing the @generated tags from the generated source code is enabled prevention from overwriting or deleting the code elements when the next model to code transformation is executed. In practice, this means that state machine and other elements from an UML model will be equipped with the @generated tag at the level of target code. The technology behind the code protection is called JMerge, which is a part of Eclipse Modeling Framework. The code merging mechanism is fully supported by the current version of the model-to-code transformation plug-in implementing the described concept and can be even extended by custom tags.

Code to be Completed

Operations that are part of a class having an associated state machine and are not trigger operations have to be implemented manually, unless they are recognized as simple setter and getter operations. To increase code completeness requires a definition of new rules for the model-to-code transformation process, and an extended PSM code generator.