Adaptable Architecture for Meta-Programmable Modeling Tools

1
Matt Emerson Advisor Janos Sztipanovits
Adaptable Architecture for Meta-Programmable
Modeling Tools
http//www.isis.vanderbilt.edu
Tool Challenges

• The Role of Model-to-Model Transformations
• Mitigating the complexity of tool component and
  component interface design.
• Leveraging the power of domain-specific modeling
  to maintain the tool architecture
• Decoupling the meta-language from other tool
  components
• Representing meta-language translation as
  model-to-model transformation

• The Myriad of Metamodeling Languages
• Coping with the heterogeneous metamodeling
  universe
• Supporting cross-tool compatibility and model
  interchange
• Allowing developers to evolve meta-programmable
  tools as relevant standards evolve
• Increasing tool flexibility by supporting
  multiple metamodeling languages

Adaptable Component-Based Tool Architecture
Changing the Metamodeling Language
Model Editor
Model Editor
Meta-Language Translation We can use one or more
wrappers to convert the repository-specific
meta-language concepts into the concepts of other
metamodeling languages. This pattern allows a
transparent swapping out of different model
repositories to change the underlying
meta-language of the tool. It also allows
components designed for different meta-languages
to work with the same repository.
?
Meta-Language Specific
Model Repository
Model Repository
Core
?
Meta-Language/Storage Decoupling We can provide a
Core layer of the tool architecture to translate
between different persistent storage formats and
the repository-specific meta-language concepts.
Adding a new persistent storage format will only
require changes to the backend of the Core. This
also protects the storage formats from changes in
the repository or metamodeling language used.
Persistent Storage Formats
Persistent Storage Formats
Different CRUD tool components such as model
editors, browsers, constraint checkers, and
interpreters may require interfaces to
repositories based on different metamodeling
languages, different versions of the same
language, or different implementations of the
same ambiguous specification. Likewise, model
data stored in some persistent format may need to
be imported into a number of different model
repositories, each of which supports a different
meta-language. However, the interface for a
model repository may be set in the specification
of the meta-language which it supports. How can
we design a meta-programmable tool architecture
which can withstand changes to the metamodeling
language without needing a drastic re-engineering
of the tool?
Adapting the Architecture Using Model-to-Model
Transformations
Model Editor
Meta-Language Translation Transformations of
metamodels between metamodeling languages can be
used to overcome many of the difficulties posed
by the large number of competing metamodeling
standards. We have previously used metamodeling
and graphical model-to-model transformation to
adapt GME, a meta-programmable modeling tool, to
support MOF alongside its native metamodeling
language. GME now supports MOF as a wrapper
around its native meta-language.
The Core Layer The Core layer of the tool
architecture can be conceptualized as a bundle of
model-to-model transformations one for each
storage format. Generally, persistent storage
must record both the model data and the
meta-information needed to interpret it. The Core
transforms metamodels and domain-specific models
into models from the storage format language,
thus decoupling the storage formats from the
repository meta-language.
Model Repository
Core
Model Repository
The Model Interchanger Model interchange
languages allow the migration of models between
tools. MOF provides a mapping to XMI, the OMG
standard model interchange language. This type
of mapping can be most easily implemented as a
model-to-model translation from metamodels or
domain models to models in the interchange
language. Such a transformation would be easy to
maintain as the relevant standards change and
evolve.
Model Interpreter
Domain-Specific Model APIs In MIC, model
interpreters are used to provide the execution
semantics for domain-specific modeling languages.
The interpreters are usually created with a
programming language such as C using an
automatically-generated domain-specific API to
traverse the models. MOF also provides a mapping
from a metamodel into a domain-specific CORBA IDL
API. These mappings may be constructed as
model-to-model transformations from metamodels to
models from an interface modeling language.
Model Interchanger
Model Repository
Model Repository
November 18, 2004