Motorola WEAVR

  a   aaaaaaaaaaaaaaaaa
MOTOROLA  WEAVR
Weaving Aspects at the Modeling Level         
        WEAVR                MDE                JOINPOINT MODEL             RESOURCES             LICENSES      

Executable Models

he translationist interpretation of the MDA emphasizes model executability. The precise behavior of the model is defined imperatively by embedding actions within statechart transitions. Actions are executed during a transition from one state to another. The obvious advantage of the translationist approach is that PIM’s can be tested early in the lifecycle. This style of modeling is also more in line with the Agile development methology.

Figure 1 illustrates the translationist approach to the MDA. The PIM is fully automatically mapped to a PSM, which in turn is fully automatically transformed into executable code, given an extensive set of platform-specific generation rules.

As the PIM specifies the complete behavior of the application, there is no need to manually elaborate the PSM and the generated code. The mappings between models and code generation can therefore include various platform-specific optimizations. Yet, the PSM and the generated code are not appropriate for human inspection, and are hidden from the developer.

Tools supporting the translationist approach such as Telelogic TAU typically do not support reverse engineering from code to models because behavior is supposed to be fully specified at the modeling level. Round-trip engineering techniques might be used in the context of legacy code evolution, but not for system design. Also, these tools do not provide support for the OCL, because behavior is defined imperatively. On the other hand, they provide an advanced simulation environment for model verification and testing. The translationist approach has two main weaknesses:

1.  The PIM must include the complete behavior of the application. Inevitably, technical considerations must also be modeled at this level in order to produce a complete application.

2.  Scalability of statecharts. The behavior of the system is driven by inner-object transitions from one state to another, in response to events. UML 2.0 statecharts support composite states, which allow a hierarchical decomposition of state machines and behavioral inheritance. Yet, some concerns do not map well to this decomposition. For example, alternative use cases tend to introduce multiple branches in the statechart transitions, leading to an explosion of alternative execution paths.



This page is under construction - Please send comments and suggestions to thomas.cottenier@motorola.com