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. Create a code generator that converts a UML state diagram to EC++ code GOAL:

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