Institute for Software Integrated Systems Vanderbilt University Copyright © Vanderbilt University/ISIS 2008 Model Interpreters Janos Mathe based on Peter Volgyesi’s slides Implementing model transformations via model interpretation

October 11, Why do we need model interpreters ?  The metamodel describes the (abstract) syntax of the domain  The GME modeler tool does not “understand” the domain but enforces the syntax  The domain developer needs to define semantics  Model interpreters (software plugins)  Model transformations (graph rewriting rules)  Semantic anchoring (rewriting rules to a well defined set of “semantic units”)

October 11, Model Interpreters Typical uses  Text file generation (special case of rewriting)  Source code  Configurations files  Documentation  Analysis & verification  Simulation  Model transformation & migration  Formal graph rewriting rules are preferred

October 11, Model Interpreters How do they work  The interpreter has (hard-coded) knowledge about the entities and relationships in the DSML  Custom classes/interfaces/types  The developer needs to keep the metamodel and the interpreter in sync  The modeler tool can invoke the interpreter  Upon user request  On internally generated events (eg. “new obect added”)  Context  The interpreter can traverse the model hierarchy,  or processes only the event context  Actions  Generates output (files, GUI windows, etc.)  Can veto the model modification (if triggered from event)  eg: constraint manager  Modifies the model

October 11, Model Interpreters in GME  Interpreter  DSML specific component  Invoked explicitly by the user  Most components fall into this category (eg.: MetaInterpreter)  Plug-in  Domain independent component  Invoked explicitly by the user  Eg.: Search plug-in, XML export/import  Add-on  DSML specific or domain independent component  Invoked on (model change) events  Eg.: Constraint Manager

Interfaces October 11, Generic API Generic API MGA DB MGA DB Specific API Specific API Specific API Specific API Specific API Specific API MGA DB MGA DB Interpreters BON2Extender, UDM COM, BON, BON2, JavaBON MGA DB MGA DB

October 11, GME Internals Storage Components DB File Core Storage COM MGAMeta Core COM MGA COMMeta COM GUI ViewBrowserInspectrXML Constraint Manager Add-ons Metainterpreter InterpretersPlug-ins

October 11, GME Internals  Territories  MGA library clients have at least one territory  Objects are automatically added to them  One object can belong to multiple territories  When the object changes those clients will be notified whose territory contains the object  Transactions  Consistent model database  Undo/Redo operations  Initiated within a territory

October 11, COM Interfaces Motivation  Problems with C++ at run-time  The “client” allocates the memory (new operator)  The application needs to be recompiled if the library changes  Name mangling is not standardized  The application needs to be compiled with the same compiler tools  Object life cycle management (new and delete operators)  Language interoperability  The original C++ object model is closed and most of the OOP concepts are killed by the compiler  NOTE: The root of the problem: the execution platform is not OO (answer: virtual machines in Java and.NET)  Distributed objects

October 11, COM Interfaces Implementation  Interfaces are defined in interface description files (.idl)  The IDL compiler generates C++ classes with virtual methods only  Library classes can “implement” these interfaces  Using multiple inheritance  Using aggregation  Library classes (COM objects) are created with factory methods exported from the library

October 11, COM Objects and Interfaces Example MgaModel IMgaModel 270B4F9A-B17C-11D3-9AD1-00AA00B6FE26 IMgaFCO 270B4F98-B17C-11D3-9AD1-00AA00B6FE26 IMgaObject 32D1F3A7-D276-11D3-9AD5-00AA00B6FE26 COM InterfacesCOM Object “Mga.MgaModel” 83BA3237-B758-11D3-ABAE Stored in the Windows Registry Used when a new object is requested Stored in the library code (class) Used when a new interface is requested IUnknown is always supported See the “Interfaces” folder in the GME program directory

October 11, Problems with COM  Steep learning curve  Error-prone low-level details  Eg.: COM strings (BSTR), output parameters, reference counting  However:  very efficient components (almost zero overhead)  some components (eg.: add-ons) can be implemented in raw COM only

October 11, High level interfaces  Builder Object Network (BON)  C++ classes (custom DSML specific classes can be defined)  The entire model hierarchy is created/duplicated in memory initially  Very limited model modification support  BON2 and MON  C++ classes and meta classes (custom DSML specific classes can be defined)  BON2 objects are created on-demand  Full support for modifying the GME model  JavaBON  Python, Visual Basic support  Basically raw COM with minimal infrastructure support

October 11, Meta Object Network  Programmatic access to the paradigm (abstract syntax)  Similar to the introspection/reflection APIs in OOP languages  Every object in BON2 has a reference to one of these classes  Wrapper classes around the Meta COM library  See: architecture diagram  The classes are defined in the “MON::” namespace

October 11, Meta Object Network Entities

October 11, Meta Object Network Relations

October 11, BON2  Layered architecture  COM layer (interface with Mga and Meta). Hidden from the developer  Implementation layer  High level API mapping to raw COM  Object caching  Eg.: “BON::FCOImpl”  Wrapper layer  The “real” API for the interpreter developer  Pointer-like interface (smart pointers)  Eg.: “BON::FCO”  Classes are defined in the “BON::” namespace

October 11, BON2 Wrapper Classes  Pointer interface  use “->” to access the contained (implementation class) method  Validity of the object  boolean (“!“) operators  Equality (between MGA objects)  “=“, “!=“ operators  Smart casting  The cast operation succeeds if the MGA object can be encapsulated with the target class

October 11, BON2 Implementation Classes  Objects are created on-demand and cached  Multiple wrapper objects can contain the same implementation object  Impl. objects are released if there is no reference to them from wrapper classes  Reference counting is automatic  Slight differences between add-ons and interpreters

October 11, BON2 Components  The interpreter is represented by “BON::Component”  The following methods need to be implemented  void Component::initialize( … )  void Component::finalize( … )  void Component::invokeEx( … )  Entry point for interpreters and plug-ins  void Component::globalEventPerformed( … )  void Component::objectEventPerformed( … )  “Entry point” for add-ons

FSM Example 1.Metamodel  Create an FSM metamodel using MetaGME 2.Models  Build FSMs (models) using the FSM metamodel 3.Interpreter  Translate FSM models to executable code 4.Execution of a model  Feed events to the FSM thus causing state changes October 11,

Creating an interpreter  Create, register  CreateNewComponent.exe at GME install dir  By default at C:\Program Files\GME\SDK  Implement  Use MS Visual Studio 2003/2005 to implement the interpreter logic  Run  Invoke the interpreter in GME by clicking on the dedicated button  Create executable  Take the generated C++ file and build it  DOS PROMPT> cl TestFSM.cpp  Execute  Run the generated TestFSM.exe file  Feed events (by typing “a” and hitting Enter), when finished type “exit” October 11,

FSM interpreter logic Start: Project root 1.Find FSM models 2.Iterate through FSMs a)Create and open source file in a specific folder b)Traverse FSM model and generate code c)Close file October 11,

October 11, BON2 Extension Classes  Extendable classes: FCO, Atom, Model, Connection, Set, Reference  Realizing a new implementation class class CustomImpl : public BON::ModelImpl { public: void initalize() { … } void finalize() { … } … };  Create a new wrapper class DECLARE_BONEXTENSION( BON::Model, CustomImpl, Custom ); IMPLEMENT_BONEXTENSION( Compound, “Compound” );

October 11, BON2 Extension Classes  Support for abstract base classes:  DECLARE_ABSTRACT_BONEXTENSION  IMPLEMENT_ABSTRACT_BONEXTENSION  Multiple inheritance:  DECLARE_BONEXTENSION2  DECLARE_BONEXTENSION3

October 11, Essential BON2 Classes

October 11, BON Extender  Automatically generates BON2 extension classes from the metamodel  For all (even abstract) classes  Container classes will have customized “get” methods for the contained roles  Connections will have specialized source and destination “get” methods  Customized “get” methods for attributes  User code is protected and preserved by special comments  “//BUP”  “//EUP”