AUTOMATIC GENERATION OF MODEL TRAVERSALS FROM METAMODEL DEFINITIONS Authors: Tomaž Lukman, Marjan Mernik, Zekai Demirezen, Barrett Bryant, Jeff Gray ACM SE ‘10, Oxford, MS, 4/17/2010 FACULTY OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Maribor, Slovenia Jožef Stefan Institute, Ljubljana, Slovenia

Agenda  Introduction  Research problem  Research objectives  Related work  Proposed approach  Specification of semantics  Model traversal algorithm  Example  Conclusion 2/18

Introduction  Modeling is an important part of software engineering  Model-Driven Engineering (MDE) promotes the systematic and disciplined use of precise models throughout the software lifecycle  Increases productivity and software quality  Domain-Specific Modeling Languages (DSMLs) – use concepts (e.g., terms, symbols and pictures) and abstractions that are common to a specific domain  MDE needs tool support to enable various development tasks with a specific DSML  model editor, model debugger, test suite, interpreters  Without tool support a DSML can become obsolete 3/18

Model-Driven Engineering (MDE)  MDE: specifies and generates software systems based on high-level models  Domain-Specific Modeling (DSM): a paradigm of MDE that uses notations and rules from an application domain  Metamodel: defines a Domain-specific Modeling language (DSML) by specifying the entities and their relationships in an application domain  Model: an instance of the metamodel  Model Transformation: a process that converts one or more models to various levels of software artifacts (e.g., other models, source code) 4/18

Research problem  DSMLs are not defined precisely  The potential benefits of MDE cannot be achieved  Semantics are the most challenging part of a DSML definition  State-of-the-practice: semantics are specified with model interpreters  Low understandability  Model-based tools cannot be automatically generated (e.g., code interpreters, debuggers)  Manual development of model-based tools is time consuming, error prone and expensive  Challenge: How to generate model based tools automatically? 5/18

Research objectives  Analogy: in the field of programming languages, language- based tools can be automatically generated  E.g., attribute grammars -> debuggers, animators, test suites  Broad objective: Development of a formalism for semantics from which model based tools can be automatically generated  Current work: The generation of model interpreters  What is needed for the generation of model interpreters:  A formalism to specify the semantics  An algorithm to traverse the model and generate the parser 6/18

Semantics specification for modeling languages  State-of-the-art: several proposals for specifying the semantics of modeling languages already exist  Translation semantics: semantics are defined trough a mapping into formalism with well-known semantics (e.g., Abstract State Machines)  Drawback: backward mapping of computation results  Weaving behavior: an action language specifies the bodies of the operations in the metamodel  Drawback: action languages are imperative  Semantics based on rewriting systems: operational approach for defining through rewrite rules e.g., graph grammars  Issue: None of the proposed approaches focuses on the automatic generation of model-based tools 7/18

Proposed approach  Idea: extend metamodels with semantic information  Similar to attribute grammars in programming languages  Consists of two parts:  Information about semantics in the metamodel = specification of semantics  Automatic synthesis of this information to generate model based tools = traversal algorithm 8/18

Specification of semantics  The semantics is specified with semantic attributes and semantic rules  Semantic attribute – associate with each metaclass  Semantic rules - carry semantic information that specifies how semantic attributes are calculated  Currently specified through Java  The meaning of the model will be obtained by evaluating attribute occurrences  The initial value of the attribute is undefined  Redefined by the traversal algorithm during its execution  They are used to obtain/compute the meaning of the whole model 9/18

Model traversal algorithm  A traversal algorithm over models (graphs) is needed to evaluating semantics attributes based on semantic rules  The algorithm depends on the metamodel and the API (application programming interface) of the model repository  Example of modeling environments:  GME (Generic Modeling Environment)  GMF (Graphical Modeling Framework)  We developed an initial algorithm that works with EMF (Eclipse Modeling Framework)  Optimized and extended to other environments in the future  The development of the traversal algorithm represents the most challenging part of our approach 10/18

Development of the model traversal algorithm (1/3)  The requirements for the model traversal algorithm: i. All model elements should be visited ii. Avoidance of endless loops iii. It must find the start element of the model iv. Executabiltiy on disconnected models (there are some modes that are not connected to other nodes) 11/18

Development of the model traversal algorithm (2/3)  Interpreters are developed based on the metamodel nodes and relationships between them  We specified: what the algorithm should do (i.e., where to navigate) when a specific relationship occurs  The types of relationships in Ecore (EMFs metamodeling language):  Root metaclass – traverse all traversable relationships  Unidirectional metarelationship – traverse into one direction (where arrow is pointing)  Bidirectional metarelationship – traverse in both ways 12/18

Development of the model traversal algorithm (3/3)  To use an algorithm based on these simple rules we have to use metamodels that satisfy this requirements:  The root metaclass should not be connected to each other with any relationship except the composition relationship  Bidirectional metarelationships are not used  Composition metarelationship – traverse away from the composition  Generalization metarelationship – traverse down the inheritance tree  Root metaclass with a self-containing metarelationship – traverse away from the filled diamond until the current instance is the root 13/18

The developed traversal algorithm  Based on the previous design decisions we have defined the following algorithm: modelRoot = findAbsoluteModelRoot(); visit(modelRoot); // recursive visiting function function visit(currentModelElement) // evaluate the current node evaluateInheritedAttributes(); // visit possible generalizations – top down if currentModelElement has subMetaclass subMetaclassOfCurrent = getSubMetaclass(currentModelElement); visit(subMetaclassOfCurrent); end-if // visit possible unidirectional relationships foreach unidirectionalRel in currentModelElement if unidirectionalRel.source == currentModelElement evaluateInheritedAttributes(); foreach modelElement in unidirectionalRel.target visit(modelElement); end-foreach evaluateSynthesizedAttributes(); markPathAsVisited(); end-if end-foreach // visit possible composition relationships foreach compositionRel in currentModelElement if compositionRel.source == currentModelElement evaluateInheritedAttributes(); foreach modelElement in compositionRel.target visit(modelElement); end-foreach evaluateSynthesizedAttributes(); markPathAsVisited(); end-if end-foreach evaluateSynthesizedAttributes(); end-function 14/18

Example (1/2)  We demonstrate our approach on the finite state machine (FSM) modeling language (metamodel below) 15/18

Example (1/2)  According to our algorithm and the semantic specification, the following interpreter can be generated: modelRoot = StateMachine(); modelRoot->TransitionList.envt=new EList(); modelRoot->AbstractState.envs=new EList(); foreach AbstractState in modelRoot->states if notVisited() AbstractState.envs.insert(AbstractState.text); markPathAsVisited(); end-if end-foreach foreach Transition in modelRoot->states if notVisited() Transition.envt.insert(Transition.src, Transition.dst); markPathAsVisited(); end-if end-foreach modelRoot.code = compute(AbstractSate.envs, Transition.envt); 16/18

Conclusion  Identified the need for automatic generation of model- based tools  Proposed a semantics specification, which allows the generation of model interpreters  Consists of a semantics definition and a traversal algorithm  Showed a FSM example that uses our approach  This was our first step towards the theory of generating various model based tools from DSML definitions 17/18

Questions 18/18 Contact me: