Position Papers of the Federated Conference on Computer DOI: 10.15439/2016F485 Science and Information Systems pp. 283–290 ACSIS, Vol. 9. ISSN 2300-5963 From UML State Machines to code and back again! Van Cam Pham, Ansgar Radermacher, Sébastien Gérard CEA-List, Laboratory of Model-Driven Engineering for Embedded Systems (LISE) Gif-sur-Yvette, France Email: fi[email protected] Abstract—UML state machines and their visual representa- move between different representations [8] and stay efficient tions are much more suitable to describe logical behaviors of with their favorite working environment. system entities than equivalent text based description such as IF-THEN-ELSE or SWITH-CASE constructions. Although many Unfortunately, current industrial tools such as for instance industrial tools and research prototypes can generate executable Enterprise Architect [9] and IBM Rhapsody[10] only support code from such a graphical language, generated code could be structural concepts for RTE such as those available from class manually modified by programmers. After code modifications, diagrams and code. Compared to RTE of class diagrams and round-trip engineering is needed to make the model and code code, RTE of USMs and code is non-trivial. It requires a consistent, which is a critical aspect to meet quality and perfor- mance constraints required for software systems. Unfortunately, semantical analysis of the source code, code pattern detection current UML tools only support structural concepts for round- and mapping patterns into USM elements. This is a hard task, trip engineering such as those available from class diagrams. In since mainstream programming languages such as C++ and this paper, we address the round-trip engineering of UML state- JAVA do not have a trivial mapping between USM elements machine and its related generated code. We propose an approach and source code statements. consisting of a forward process which generates code by using transformation patterns, and a backward process which is based For software development, one may wonder whether this on code pattern detection to update the original state machine RTE is doable. That is, why do the industrial tools not support model from the modified code. We implemented a prototype and the propagation of source code modifications back to original conducted several experiments on different aspects of the round- state machines? Several possible reasons to this lack are (1) trip engineering to verify the proposed approach. the gap between USMs and code, (2) not every source code I. INTRODUCTION modification can be reverse engineered back to the original model, and (3) the penalty of using transformation patterns HE so-called Model-Driven Engineering (MDE) ap- facilitating the reverse engineering that may not be the most proach relies on two paradigms, abstraction and automa- T efficient (e.g. a slightly larger memory overhead). tion [1]. It is recognized as very efficient for dealing with complexity of today’s systems. Abstraction provides simplified This paper addresses the RTE of USMs and object-oriented and focused views of a system and requires adequate graph- programming languages such as C++ and JAVA. The main idea ical modeling languages such as Unified Modeling Language is to utilize transformation patterns from USMs to source code (UML). Even, if the latter is not the silver bullet for all that aggregates code segments associated with a USM element software related concerns, it provides better support than into source code methods/classes rather than scatters these text-based solutions for some concerns such as architecture segments in different places. Therefore, the reverse direction and logical behavior of application development. UML state of the RTE can easily statically analyze the generated code machines (USMs) and their visual representations are much by using code pattern detection and maps the code segments more suitable to describe logical behaviors of system entities back to USM elements. Specifically, in the forward direction, than any equivalent text based descriptions. The gap from we extend the double dispatch pattern presented in [11]. USMs to system implementation is reduced by the ability of Traceability information is stored during the transformations. automatically generating code from USMs [2], [3], [4], [3]. We implemented a prototype supporting RTE of state-machine and C++ code, and conducted several experiments on different Ideally, a full model-centric approach is preferred by MDE aspects of the RTE to verify the proposed approach. To the community due to its advantages [5]. However, in industrial best of our knowledge, our implementation is the first tool practice, there is significant reticence [6] to adopt it. On one supporting RTE of SM and code. hand, programmers prefer to use the more familiar textual programming language. On the other hand, software architects, To sum up, our contribution is as followings: working at higher levels of abstraction, tend to favor the • An approach to round-tripping USMs and object-oriented use of models, and therefore prefer graphical languages for code. describing the architecture of the system. The code modified • A first tooling prototype supporting RTE of USMs and by programmers and the model are then inconsistent. Round- C++ code. trip engineering (RTE) [7] is proposed to synchronize different • An evaluation of the proposed approach including: software artifacts, model and code in this case [8]. RTE – An automatic evaluation of the proposed RTE ap- enables actors (software architect and programmers) to freely proach with the prototype. c 2016, PTI 283 284 POSITION PAPERS OF THE FEDCSIS. GDANSK,´ 2016 – A lightweight evaluation of the semantic confor- Forward Engineering mance of the runtime execution of generated code. -Transformation 1a 2a -Code generation using patterns -Storage of traces The remainder of this paper is organized as follows: Our -Storage of traces proposed approach is detailed in Section II. The implementa- tion of the prototype is described in Section III. Section IV UML Model Intermediate UML Model Source Code reports our results of experimenting with the implementation and our approach. Section V shows related work. The conclu- Reverse Engineering sion and future work are presented in Section VI. Model AST Code Syntax Update Transition Analysis II. APPROACH 2b 1b This section presents our RTE approach. At first, it sketches Fig. 1. Outline of state machine and code RTE USM concepts supported by this study. The outline and the detail of the approach are presented afterward. StateMachine A. Scope /Initialize Operating A USM describes the behavior of an active UML class On[x == 0] /entry Prepare Stopped /exit Disable which is called context class. A USM has a number of states / Enable and well-defined conditional transitions. A state is either an Off atomic state or a composite state that is composed of sub- states and has at most one active sub-state at a certain time. Fig. 2. An example of USM for tracing table Transitions between states can be triggered by external or internal events. An action (effect) can also be activated by the example in Fig. 2. It consists of two states (Stopped and trigger while transitioning from one state to another state. A Operating), two external events (On and Off ), transitions, and state can have associated actions such as entry/exit/doActivity an initial and a final pseudo state. Listing 1 shows a code executed when the state is entered/exited or while it is active, portion generated from the USM following our approach. respectively. Listing 1. A segment of C++ generated code 1 c l a s s CompositeState: p u b l i c S t a t e { B. Approach outline p r o t e c t e d : 3 S t a t e ∗ activeSubState; Our RTE approach is based on the double-dispatch pattern p u b l i c : 5 bool dispatchEvent(Event ∗ e v e n t ) { presented in [11] for mapping from USM to a set of classes bool r e t = f a l s e ; with embedded code fragments. Fig. 1 shows the outline of our 7 i f (activeSubState != NULL) { ret = activeSubState −>dispatchEvent(event);} RTE approach consisting of a forward and a backward/reverse 9 r e t u r n r e t | | event −>processFrom( t h i s );}} (engineering) process. In the forward process, a USM is StateMachine :: StateMachine(Client ∗ c t x ) { 11 t h i s −>context = ctx; transformed into UML classes in an intermediate model. The s t o p p e d = new Stopped ( t h i s , c t x ) ; use of the intermediate model facilitates the transformation 13 o p e r a t i n g = new O p e r a t i n g ( t h i s , c t x ) ; t h i s −>setIniDefaultState (); from the USM to code. Each class of the intermediate model 15 t h i s −>activeSubState −>e n t r y ( ) ; } contains attributes, operations and method bodies (block of void StateMachine:: setIniDefaultState (){ 17 t h i s −>c o n t e x t −>Initialize(); text) associated with each implemented operation. The trans- t h i s −>activeSubState = stopped;} 19 bool StateMachine :: transition (Stopped ∗ s t a t e , formation utilizes several patterns which will be presented On∗ e v e n t ) { later. 21 i f ( t h i s −>c o n t e x t −>guard(event)){ t h i s −>activeSubState −> e x i t ( ) ; When the source code is modified, a syntactic analysis 23 t h i s −>c o n t e x t −>Enable(event); process belonging to the backward transformation checks t h i s −>activeSubState = t h i s −>operating; 25 t h i s −>activeSubState −>e n t r y ( ) ; whether the modified code conforms to the USM semantics r e t u r n t r u e ;} 27 return false ;} (see Subsection II-D3 for the detail of the analysis).