Adaptable Architecture for Meta Programmable Modeling Tools Matt

Adaptable Architecture for Meta. Programmable Modeling Tools Matt Emerson Advisor: Janos Sztipanovits http: //www. isis. vanderbilt. edu Tool Challenges The Myriad of Metamodeling Languages • Coping with the heterogeneous The Role of Model-to-Model Transformations • Mitigating the complexity of tool metamodeling universe component and component interface design. • Supporting cross-tool compatibility and model interchange • Leveraging the power of domainspecific modeling to maintain the tool architecture • Allowing developers to evolve metaprogrammable tools as relevant standards evolve • Decoupling the meta-language from other tool components • Increasing tool flexibility by supporting multiple metamodeling languages • Representing meta-language translation as model-to-model transformation Adaptable Component-Based Tool Architecture: Changing the Metamodeling Language Model Editor Model Interpreter Model Interchanger Meta-Language Translation Model Interchanger Meta-Language – Specific Model Repository We can use one or more wrappers to convert the repository-specific metalanguage 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. Core Meta-Language/Storage Decoupling 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? We can provide a Core layer of the tool architecture to translate between different persistent storage formats and the repository-specific metalanguage 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. Adapting the Architecture Using Model-to-Model Transformations 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 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-tomodel transformations from metamodels to models from an interface modeling language. November 18, 2004 Model Editor Core Model Repository Model Interpreter Model Repository Model Interchanger Model Repository 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 metaprogrammable modeling tool, to support MOF alongside its native metamodeling language. GME now supports MOF as a wrapper around its native meta-language. 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.