Transcript Slide 1
Institute for Software Integrated Systems
Vanderbilt University
Model Interpreters
Implementing model transformations via model
interpretation
Janos Mathe
based on Peter Volgyesi’s slides
Copyright © Vanderbilt University/ISIS 2008
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”)
July 6, 2015
2
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
July 6, 2015
3
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
July 6, 2015
4
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
July 6, 2015
5
Interfaces
Interpreters
Specific
API
Specific
API
Generic
API
Specific
API
BON2Extender, UDM
COM, BON, BON2, JavaBON
MGA
DB
July 6, 2015
6
GME Internals
GUI
View
Browser
Plug-ins
Add-ons
Interpreters
XML
Constraint
Manager
Metainterpreter
Inspectr
MGA COM
Meta COM
MGA
Meta
Core COM
Core
Storage COM
Storage Components
DB
July 6, 2015
File
7
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
July 6, 2015
8
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
July 6, 2015
10
COM Objects and Interfaces
Example
See the “Interfaces” folder in the GME program directory
COM Interfaces
COM Object
IMgaModel
270B4F9A-B17C-11D3-9AD1-00AA00B6FE26
IMgaFCO
270B4F98-B17C-11D3-9AD1-00AA00B6FE26
IMgaObject
32D1F3A7-D276-11D3-9AD5-00AA00B6FE26
MgaModel
•Stored in the library code (class)
“Mga.MgaModel”
•Used when a new interface is requested 83BA3237-B758-11D3-ABAE-000000000000
•IUnknown is always supported
•Stored in the Windows Registry
•Used when a new object is requested
July 6, 2015
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
July 6, 2015
12
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
July 6, 2015
13
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
July 6, 2015
14
Meta Object Network
Entities
July 6, 2015
15
Meta Object Network
Relations
July 6, 2015
16
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
July 6, 2015
17
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
July 6, 2015
18
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
July 6, 2015
19
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
July 6, 2015
20
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
July 6, 2015
21
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”
July 6, 2015
22
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
July 6, 2015
23
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” );
July 6, 2015
24
BON2 Extension Classes
Support for abstract base classes:
DECLARE_ABSTRACT_BONEXTENSION
IMPLEMENT_ABSTRACT_BONEXTENSION
Multiple inheritance:
DECLARE_BONEXTENSION2
DECLARE_BONEXTENSION3
July 6, 2015
25
Essential BON2 Classes
July 6, 2015
26
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”
July 6, 2015
27