Code Generation for UML

1. Code Generation for UML Morgan Bird Tom Lilley Lauren Revard Min Deng, Sascha Konrad, Karli López Dr. Betty H.C. Cheng

2. Outline • Background • Project Overview • Approach • Validation • Conclusions • Demonstration

3. Background

4. Unified Modeling Language • Abbreviated “UML” • Models software systems using standardized graphical notation • De facto standard • Model-driven development • Syntax well-defined; Semantics not well defined • Challenge: • Provide formal semantics for UML • Create code generator that will define semantics in terms of a particular language

5. Quantum Programming • Reactive systems • Event-driven • Events can happen at any time • Difficult to understand and code

6. Quantum Programming • Abbreviated “QP” • New programming paradigm • Built-in support for creating reactive systems • New features • HSM design pattern • asynchronous communication • increases level of abstraction • Allows programmer to model reactive systems directly

7. Embedded C++ • Abbreviated “EC++” • Subset of C++ created for embedded systems applications • Differences between C++ and EC++ • EC++ does not support • Multiple inheritance • Exceptions • Templates • Namespace • Simplified language to reduce size of programs

8. Project Overview

9. GOAL: Create a code generator that converts a UML state diagram to EC++ code

10. How it’s Done • Models created with Rational XDE, exported as XMI files • Code generation program parses XMI files, creates a tree that contains classes such as “Transition” or “CompositeState” • Visitor function traverses the tree and outputs EC++ code that corresponds to the model

11. Our Work • Most elements of the code generator were provided to us • Our implementation: The visitor function • Written in Java • Created on the Eclipse platform • Example:

13. Example enum QHsmTstSignals { A_SIG = _Q_USER_SIG, B_SIG, C_SIG, D_SIG, E_SIG, F_SIG, G_SIG, H_SIG }; class QHsmTst() : public QHsm { public: QHsmTst() : QHsm((QPseudoState)initial) {} protected: void initial (QEvent const *e); QSTATE s0(QEvent const *e); QSTATE s1(QEvent const *e); QSTATE s11(QEvent const *e); QSTATE s2(QEvent const *e); QSTATE s21(QEvent const *e); QSTATE s211(QEvent const *e); private: int myFoo; };

14. Example void QHsmTst::initial(QEvent const *) { printf(“top-INIT;”); myFoo = 0; Q_INIT(&QHsmTst::s0); } QSTATE QHsmTst::s0(QEvent const *e) { switch (e->sig) { case Q_ENTRY_SIG: printf(“s0-ENTRY;”); return(0); case Q_EXIT_SIG: printf(“s0-EXIT;”); return(0); case Q_INIT_SIG: printf(“s0-INIT;”); Q_INIT(&QHsmTst::s1); return(0); case E_SIG: printf(“s0-E;”); Q_TRAN(&QHsmTst::s211); return 0; } return (QSTATE) &QHsmTst::top; }

15. Approach

16. Creating the Tree • Convert the XMI file into a data structure that the application can use • Based on UML metamodel of state diagram • Consists of a tree of items that inherit from the abstract class ModelElement

18. Using the Visitor Pattern • Use the tree to create EC++ code • Implemented with a visitor function • Each node in the tree implements accept() method, which calls a class-specific visitor function

19. Using the Visitor Pattern // This is the base Node class where all other nodes // inherit the accept routine public abstract class Node{ public void accept(Visitor v) { } } // These definition of a node we might find // in our structure. public class ActionNode extends Node { public void accept(Visitor v) { v.visitActionNode(this); } } // This is the base Visitor class where all other nodes // inherit the proper visit Routines called by the nodes. public abstract class Visitor{ public void visitStateNode(StateNode n) { } public void visitTransitionNode(TransitionNode n) { } public void visitActionNode(ActionNode n) { } }

20. Rules • The visitor function will take the data in the node and convert it into code • Requires a set of formalized rules for each object • Rules will be language-specific • Include: • Overview • Names and definitions of all variables and terms that will be used • Pseudocode for each visitor function • Sample output for each visitor function

21. Rules (example psuedocode) //add transitionName to the enumeration of signals if transitionData is empty transitionData + transitionName transitionData + “ = Q_USER_SIG” else transitionData + “, “ transitionData + transitionName if guard exists stateData + “if (“ visitGuard(guard) stateData + “) {” // any actions given in the transition stateBody + codeBody stateBody + “Q_TRAN(&QHsmTest::” stateBody + target->name stateBody + “);” stateBody + “return 0;”

22. Validation

23. Testing Phase • Two sample models • Practical Statecharts in EC++ example • Academic example • Encompasses all basic elements • Composite states • Transitions • Guards • Ect… • Eaton Corp. example • Real world test • Remote wireless sensors

24. Practical Statecharts Model

25. Eaton Corp. Model

26. Conclusions

27. Program • Completed application is capable of taking an XMI of a moderately complex statechart and producing EC++ code • Can be used to test validity of statechart • Can be used to implement the system in the model

28. Our Biggest Challenges • Amount of time • Grasping new concepts • Quantum Programming • Automated code generation • Understanding and extending pre-existing code • Standardizing code generation rules for a variety of implementations

29. Future Improvements • Doesn’t handle some features of state diagrams • Concurrent states • Event queues • Only supports one language (EC++) • Only supports one kind of UML diagram (state diagrams)

30. Demonstration