Adaptable Architecture for Meta-Adaptable Architecture for Meta-Programmable Modeling ToolsProgrammable Modeling Tools

Matt EmersonAdvisor: Janos Sztipanovits

http://www.isis.vanderbilt.edu

The Core LayerThe 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.

The Core LayerThe 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.

Meta-Language TranslationWe 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 TranslationWe 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.

Adaptable Component-Based Tool Architecture: Changing the Metamodeling Language

Adapting the Architecture Using Model-to-Model Transformations

Tool Challenges

Model RepositoryModel Repository

Model Interchanger

Model Interchanger

Model EditorModel EditorModel

InterpreterModel

Interpreter

Persistent Storage FormatsPersistent Storage Formats

Meta-Language – SpecificMeta-Language – Specific

Model RepositoryModel Repository

Model Interchanger

Model Interchanger

Model EditorModel EditorModel

InterpreterModel

Interpreter

Persistent Storage FormatsPersistent Storage Formats

CoreCore

Meta-Language/Storage DecouplingWe 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.

Meta-Language/Storage DecouplingWe 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.

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?

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?

The Model InterchangerModel 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.

The Model InterchangerModel 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 RepositoryModel Repository

Model Interpreter

Model Interpreter

Domain-Specific Model APIsIn 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.

Domain-Specific Model APIsIn 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 RepositoryModel Repository

Meta-Language TranslationTransformations 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.

Meta-Language TranslationTransformations 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.

Model RepositoryModel Repository

CoreCore

Model RepositoryModel Repository

Model Interchanger

Model Interchanger

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

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

Model EditorModel Editor

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 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

November 18, 2004