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 its 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

12
(No Transcript)
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 QHsmTstinitial(QEvent const )
• printf(top-INIT)
• myFoo 0
• Q_INIT(QHsmTsts0)
• QSTATE QHsmTsts0(QEvent const e)
• switch (e-gtsig)
• 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(QHsmTsts1) return(0)
• case E_SIG printf(s0-E) Q_TRAN(QHsmTsts21
  1) return 0
• return (QSTATE) QHsmTsttop

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

17
(No Transcript)
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-gtname
• 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

• Doesnt 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