MARS: A metamodel recovery system using grammar inference

Available online at www.sciencedirect.com

www.elsevier.com/locate/infsof

Information and Software Technology 50 (2008) 948–968

MARS: A metamodel recovery system using grammar inference

Faizan Javed a,*, Marjan Mernik b, Jeff Gray a, Barrett R. Bryant a

a Department of Computer & Information Sciences, University of Alabama at Birmingham, 1300 University Boulevard, Birmingham, AL 35294-1170, USAb Faculty of Electrical Engineering and Computer Science, University of Maribor, Maribor, Slovenia

Received 21 September 2006; received in revised form 25 July 2007; accepted 21 August 2007Available online 1 September 2007

Abstract

Domain-specific modeling (DSM) assists subject matter experts in describing the essential characteristics of a problem in theirdomain. When a metamodel is lost, repositories of domain models can become orphaned from their defining metamodel. Within thepurview of model-driven engineering, the ability to recover the design knowledge in a repository of legacy models is needed.

In this paper we describe MARS, a semi-automatic grammar-centric system that leverages grammar inference techniques to solve themetamodel recovery problem. The paper also contains an applicative case study, as well as experimental results from the recovery ofseveral metamodels in diverse domains.� 2007 Elsevier B.V. All rights reserved.

Keywords: Domain-specific modeling; Metamodeling; Reverse engineering; Grammar inference

1. Introduction

During the various phases of the software developmentprocess, numerous artifacts may be created (e.g., documen-tation, models, source code, testing scripts) and stored in arepository. Some of the artifacts involved in development,such as source code and models, depend on a languageschema definition that provides the context for syntacticstructure. For example, a programming language is depen-dent on a grammar, and a model is defined by a metamod-el; as such, both grammars and metamodels represent aschema that defines the syntax of a language. Over time,evolution of the schema definition is often required toaddress new feature requests (e.g., evolution of a languageto provide new language features, or adaptation of a meta-model to accommodate new stakeholder concerns). If therepository artifacts are not transformed to conform tothe new schema definition, it is possible that the repositorymay become stale with obsolete artifacts.

0950-5849/$ - see front matter � 2007 Elsevier B.V. All rights reserved.

doi:10.1016/j.infsof.2007.08.003

* Corresponding author. Tel.: +1 205 934 2213; fax: +1 205 934 5473.E-mail address: [email protected] (F. Javed).

In the realm of programming languages, Lammel andVerhoef [1] have motivated the need to fabricate tools forsoftware renovation problems. With more than 500 gen-eral-purpose and proprietary programming languagesbeing used in the commercial and public domains, the needfor a rapid and reliable renovation tool is very real. Such atool can be used to solve re-engineering problems, or canbe useful in commercial installations where source imple-mentations either need to be recovered or translated to adifferent language dialect. Lammel and Verhoef make astrong case for using a grammar-centric solution to solvethese problems by stating that the dominant factor in pro-ducing any renovation tool is building a parser. When agrammar for a language can be obtained, a parser genera-tor can be used to create a parser for the recoveredlanguage.

With the proliferation of modeling tools in the commer-cial and research arenas [2], the number of renovationproblems in the modeling community is rising. Fig. 1 cate-gorizes several evolution tasks that require automatedassistance to manage the various dependencies amongmetamodels, domain models, and corresponding sourcecode in Model-Driven Engineering (MDE). Along the

mailto:[email protected]

Fig. 1. An overview of schema evolution dependencies in model-driven engineering.

F. Javed et al. / Information and Software Technology 50 (2008) 948–968 949

top of Fig. 1 is a sequence of intermediate metamodel ver-sions that represent the evolving definition of a specificmodeling language in a particular domain. Each new ver-sion of the metamodel captures some change in the model-ing language (represented by DMM). The domain modelsthat are in the middle of Fig. 1 are dependent on the meta-model definition. The problem of metamodel evolution asit relates to updating dependent domain models hasalready been investigated. As an initial solution to themetamodel schema evolution problem, Sprinkle and Kar-sai define a visual language for mapping between old andnew metamodels [3]. Their approach uses graph-rewritingtechniques to update the domain models accordingly.However, this schema evolution approach fails when boththe metamodels and the intermediate transformation stepsdo not exist, or are not accessible. A computationally effi-cient framework for managing and deploying incrementaldata transformations between models is proposed in [4].In [5], Diskin and Dingel propose a formal algebraic frame-work for efficient model transformations in a generic(metamodel-independent) way. The approach avoids thelaborious elementwise specification of source and targetmodels encountered in conventional metamodel transfor-mation methodology by specifying a mapping betweensource and target metamodels using generic operators.Graaf et al. [6] formulate the migration of supervisorymachine control systems as a model transformation prob-lem based on the Symphony [7] view-driven software archi-tecture (SA) reconstruction process. CacOphoNy [8] is a

generic metamodel-driven software architecture processsimilar to Symphony. While Symphony is confined to SAreconstruction, CacOphoNy integrates SA with MDE tocreate an integrated SA reconstruction approach which ismore expansive and broader in scope than Symphony.

A correspondence also exists between the domain mod-els and a legacy source code base, as shown in the bottomof Fig. 1. In order to maintain a causal connection betweenthe domain models and the corresponding source code, atechnique to synchronize model changes to existing sourcecode is needed. An initial inquiry into model-driven pro-gram transformation is presented in [9], which generatesprogram transformation rules from model changes. Thegenerated transformation rules are applied to a transfor-mation engine that parses and modifies the correspondingrepresentation of the legacy source. To keep the illustrationsimplified, Fig. 1 does not consider reverse engineering ofsource code into a model representation. This representsanother issue outside the scope of this paper, but acknowl-edged as an area that needs further investigation. The workby Favre et al. [10] on using the Generic Software Explora-tion Environment (GSEE) platform to reverse engineerlarge scale object-oriented and component-based systemsis an example of reverse engineering source code into mod-els. In GSEE, a metamodel for component models wasdesigned. This metamodel is used to view reverse engi-neered source code as a model. Furthermore, there areother artifacts that may need to be transformed duringmetamodel evolution (e.g., OCL constraints, model

950 F. Javed et al. / Information and Software Technology 50 (2008) 948–968

interpreters, model transformation rules), but are notshown in Fig. 1.

From our experience in model-driven engineering, it isoften the case that a metamodel undergoes frequent evolu-tion, which may result in previous model instances beingorphaned from the new definition. This has also beenobserved by others in practice [11,12]. We call this phenom-enon metamodel drift. When the metamodel is no longeravailable, a domain model may not be loaded into themodeling tool (this is similar in concept to a change in alanguage definition that invalidates prior programs andthe associated compiler). However, if a metamodel can beinferred from a set of domain models (as indicated by the‘‘Inference’’ arrow in Fig. 1), the design knowledge con-tained in the domain models can be recovered. Some exam-ples of problems that require the need to recover or reverseengineer a metamodel include losing a metamodel defini-tion due to a hard-drive crash, and encountering versioningconflicts when trying to load domain models based onobsolete metamodels. In this paper, we describe a tech-nique to recover the metamodel schema definition frominstances that have been separated from their originaldefining metamodel. The technique is semi-automatedand grammar-driven. It uses concepts from the grammarinference domain, and is applicable even when the onlyaccessible resources are the domain models.

The paper is organized as follows: Section 2 introduces acase study used throughout the paper and also highlightsthe key challenges involved in metamodel inference. Thesection outlines the solution approach adopted within theMetAmodel Recovery System (MARS). A textualDomain-Specific Language (DSL) is introduced in Section3. This DSL is used as an intermediate mapping betweenmodels and the notation needed for the inference process.The heart of the paper is contained in Section 4, which doc-uments the specific details of the metamodel inference tech-nique used in MARS. Additional case studies are describedin Section 5. Related work is compared in Section 6 and a

Fig. 2. A metamodel for crea

list of current limitations that will drive future work is con-tained in Section 7. A brief summary serves as a conclusionin Section 8.

2. The metamodel recovery system: an overview

Throughout the history of programming languages,abstraction has been improved through evolution towardshigher levels of specification. Domain-Specific Modeling(DSM) has adopted a different approach by raising thelevel of abstraction, while at the same time narrowing thedesign space to a single domain of discourse with visualmodels [13]. When applying DSM, models are constructedthat follow the domain abstractions and semantics, allow-ing developers to perceive themselves as working directlywith domain concepts. The DSM language captures thesyntax of the domain and the production rules of theinstantiation environment.

An important activity in DSM is the construction of ametamodel that defines the key elements of the domain.Instances of the metamodel can be created to define specificconfigurations of the domain. An example is shown inFig. 2, which represents the metamodel for a simple lan-guage for specifying properties of a Finite State Machine(FSM). The metamodel contains FSM concepts (e.g., startstate, end state, and state) as well as the valid connectionsamong all entities. An instance of this metamodel is shownin Fig. 3, which illustrates a FSM composed of a start state,a state and two end states.

The Generic Modeling Environment (GME) [14] is themodeling tool used in our research. The GME is a meta-configurable modeling environment that can be configuredand adapted from metamodels that describe the domain[15]. When using the GME, an end-user loads a metamodelinto the tool to define an environment containing all themodeling elements and valid relationships that can be con-structed in a specific domain [16]. Domain models arestored in the GME as objects in a database repository.

ting finite state machines.

Fig. 3. An instance of a finite state machine.


An API is provided by GME for traversing a model. Fromthe API, it is possible to create model compilers that tra-verse the internal representation of the model and generatenew artifacts (e.g., XML configuration files, source code,or even hardware logic) based on the model properties.In the GME, a metamodel is described with UML classdiagrams and constraints that are specified in the ObjectConstraint Language (OCL) [17]. The metamodel shownin Fig. 2 represents the example to be used throughout thispaper to demonstrate metamodel inference from individualinstances.

There are several challenges involved in mining a set ofdomain models in order to recover the metamodel. The keychallenges and a summary of the solutions presented in thispaper are as follows:

1. Inference techniques for domain models: The research lit-erature in the modeling community has not addressedthe issue of recovering a metamodel from a set ofdomain models. However, a rich body of work has beenreported in the grammar inference community to infer adefining grammar for a programming language from arepository of example programs. Inductive learning is

Fig. 4. Overview

the process of learning from examples [18]. The relatedarea of grammatical inference can be defined as a partic-ular instance of inductive learning where the examplesare sets of strings defined on a specific alphabet. Thesesets of strings can be further classified into positive sam-ples (i.e., the set of strings belonging to the target lan-guage) and negative samples (i.e., the set of strings notbelonging to the target language). Primarily, grammati-cal learning research has focused on regular and context-free grammars. It has been proven that exact identifica-tion in the limit of any of the four classes of languages inthe Chomsky hierarchy is NP-complete [19], and in [20]it is shown that the average case is polynomial. A keycontribution of this paper is the use of grammar infer-ence techniques applied to the metamodel inferenceproblem.

2. Model representation problem: Most modeling tools pro-vide a capability to export a model as an XML file.However, there is a mismatch between the XML repre-sentation of a model, and the syntax expected by thegrammar inference tools. To mitigate the effect of thismismatch, the technique presented in this paper trans-lates the XML representation of an instance of a domainmodel into a textual domain-specific language that canbe analyzed by traditional grammar inference tools.

To address these two challenges, we have createdMARS, which is a metamodel recovery tool based on thefoundational research in grammar inference. An overviewof MARS is illustrated in Fig. 4. The metamodel inferenceprocess begins with the translation of various domainmodels into a DSL that filters the accidental complexitiesof the XML representation in order to capture the essenceof the domain models (represented as step 1 in Fig. 4). Theinference is performed within the LISA [21] language

of MARS.


description environment (step 2 in Fig. 4). LISA is aninteractive environment for programming language devel-opment where users can specify, generate, compile-on-the-fly and execute programs in a newly specified language.LISA was chosen for this project because of its benefits indesigning DSLs [22]. Moreover, the LISA system has beenused successfully in our evolutionary-based context-freegrammar (CFG) inference engine [23]. The result of theinference process is a context-free grammar that is gener-ated concurrently with the XML file containing the meta-model, which can be used to load the domain modelsinto the modeling tool (step 3 in Fig. 4). Section 3 willintroduce the generated DSL from the model instances,as indicated by step 1 in Fig. 4.

Table 1Context-free grammar for MRL

START ::= GME

GME ::= MODEL_OR_ATOM {MODEL_OR_ATOM}MODEL_OR_ATOM ::= MODEL j ATOMMODEL ::= model #Id n{M_BODY n}M_BODY ::= [MODELS] FIELDS [connection CONNECT]MODELS ::= #Id n; {#Id n;}FIELDS ::= fields {#Id n,} n;CONNECT ::= {#Id n: #Id nfi #Id n;}ATOM ::= atom #Id n{FIELDS n}

3. The model representation language

A grammar-based system is defined as, ‘‘any system that

uses a grammar and/or sentences produced by this grammar

to solve various problems outside the domain of programming

language definition and its implementation. The vital compo-

nent of such a system is well structured and expressed with agrammar or with sentences produced by this grammar in an

explicit or implicit manner’’ [24]. One of the identified ben-efits of a grammar-based solution is that some problemscan be solved simply by converting the representation athand to a CFG, because appropriate tools and methodsfor working with CFGs already exist.

A difficulty in inferring metamodels is the mismatch innotations. Each GME domain model is persistently storedas an XML file, but the grammar inference process is bettersuited for a more constrained language. The inference pro-cess could be applied to the XML representation, but at acost of greater complexity. To bridge the gap between therepresentations, and to make use of already existing infer-ence tools and techniques, a DSL was created called theModel Representation Language (MRL). The definingproperties of DSLs are that they are small, more focusedthan General-Purpose Programming Languages (GPLs),and usually declarative [25]. Although DSL developmentis challenging, and requires domain knowledge and lan-guage development expertise, language development tool-kits exist to facilitate the DSL implementation process.LISA was used to develop the MRL and supporting tools.

The primary use of the MRL is to describe the compo-nents of the domain models in a form that can be used by agrammar inference engine. In particular, an MRL programcontains the various metamodel elements (e.g., models,atoms and connections) that are stated in a specific order.The most useful information contained in the domain mod-els is the kind (type) of the elements, which can be a model,atom, field or connection. The inference process is not con-cerned with the name of the modeling instance, but ratherits type. Thus, an MRL program is a collection of Ækind,identifieræ implicit bindings. In terms of declaration order,models and atoms can be declared in any order. However,

there is a particular order to be followed when declaringthe composition of models and atoms.

A model must first declare any constituent atoms andmodels, followed by field (attribute) and connection decla-rations. The complete grammar for the MRL is given inTable 1. Due to the fact that connections in GME are bin-ary relationships [14], the MRL has only binary relation-ships. Metamodels are more expressive than a CFG inthat they can model references and explicit aggregationand composition relationships [26,27], while CFGs needadditional annotations to be able to express them. Analyz-ing CFGs along with their annotations to discover suchrelationships can result in increased processing time. Inthe case of the MRL, all aggregations and compositionsare modeled as compositions. The MRL is able to handlereferences by utilizing transformation rules that exactlycapture such references and which can be seen as annota-tions to the base grammar. For example, rule 2 in Table3 allows exact identification of the source and destinationof a connection. The binary relationship inherent in theMRL results in a concise grammar that expedites parsingof MRL programs. Thus, MRL is sufficiently succinct inits design to be feasible for the inference process, but alsoexpressive enough to represent the GME metamodels accu-rately. Adopting MARS within a modeling tool other thanthe GME would require an MRL grammar definition forthat tool, but such a grammar is very simple to produceif the meta-metamodel of the modeling tool is well-under-stood. The MRL grammar would also need to be adaptedto handle n-ary relationships if the tool supports them.

A first stage of this work was to design a DSL that couldaccurately represent the (visual) GME domain models in atextual form. This was accomplished through a visual-to-textual-representation transformation process. Becausethe GME models are represented as XML files, the trans-formation to MRL is done by the Extensible StylesheetLanguage Transformation Language (XSLT) [28]. XSLTis a transformation language that can transform XML doc-uments to any other text-based format. XSLT uses theXML Path Language (XPath) [29] to locate specific nodesin an XML document. XPath is a string-based language ofexpressions. We use XSLT and XPath to parse the XML-based model files and convert the model information in theXML file into an intermediate but equivalent representa-tion in the form of MRL. The domain models shown inFig. 5, which are based on the metamodel of Fig. 2, are

Fig. 5. Two instances of the FSM metamodel.


represented as the MRL programs in Table 2. For example,model 1 is composed of a StateDiagram model and twoState atoms. A StateDiagram consists of one Start-State, EndState and a connection named Transi-

tion that connects both states. The Start states inFig. 5 are atoms with no fields and are transformed toatom StartState {fields;}. Section 4.3 describesthe transformation between the two representations inmore detail. The primary artifact from which a metamodelwill be inferred is the intermediate textual representation astranslated in the MRL. The MRL serves as input into thenext stage of the MARS metamodel recovery process, asdescribed in Section 4.

4. Metamodel inference engine

As previously discussed in Section 1, a correspondenceexists between a metamodel and its instances, and a pro-gramming language and valid programs defined by the lan-guage. By considering a metamodel as a representation of aCFG, named G, the corresponding domain models can bedelineated as sentences generated by the language L(G).This section describes the subcomponent of the MARS sys-

Table 2Two MRL programs as representations of models from Fig. 5

tem that applies CFG inference methods and techniques tothe metamodel inference problem.

4.1. Metamodels as context-free grammars

In the next step toward defining a process to infer ametamodel, all of the relationships and transformationprocedures between metamodels and CFGs are identified.A key part of the process involves the mapping from themetamodel representation to the non-terminals and termi-nals of a corresponding grammar. The role of non-terminalsymbols in a CFG is twofold. At a higher level of abstrac-tion, non-terminal symbols are used to describe differentconcepts in a programming language (e.g., an expressionor a declaration). At a more concrete lower level, non-ter-minal and terminal symbols are used to describe the struc-ture of a concept (e.g., a variable declaration consists of avariable type and a variable name). Language concepts,and the relationships between them, can be representedby CFGs. This is also true for the GME metamodels[16], which describe concepts (e.g., model, atom) and therelationships that hold between them (e.g., connection).Therefore, both formalisms can be used for the same pur-pose (at differing levels of abstraction), and a two-way


transformation from a metamodel to a CFG can bedefined. The transformations relating a metamodel to aCFG are depicted in Table 3. Note that the type informa-tion of fields is not converted into the CFG representationbecause this information is not available in the domainmodels. MARS infers all the fields as generic ‘field’ types.The user can modify the field information manually afterloading the inferred metamodel.

As an example application of the transformations inTable 3, the Finite State Machine (FSM) metamodelshown in Fig. 2 is semantically equivalent to the corre-sponding CFG represented in Table 4. The obtainedCFG is a rather intuitive representation of the metamodel

Table 3Transformation from a metamodel to a context-free grammar

in Fig. 2. Productions 1 and 2 state that a StateDiagram(or FSM) is a model consisting of models, atoms, fields andconnections. Models and atoms (production 3) that can beused in a FSM are StartState, EndState, and State.A FSM has no fields (production 6) and at least one con-nection called Transition (production 8). The sourceof the connections can be StartState or State (pro-ductions 10 and 12), and the destination can be End-

State, or State (production 11 and 13), which all areatoms without fields (productions 14–19). From such adescription, a metamodel can be drawn manually usingthe GME tool. However, this manual process can be auto-mated. In the final step of the MARS inference system, the

Table 4Context-free grammar representation of the metamodel in Fig. 2

1. STATEDIAGRAM fi 0model 0 StateDiagram {PARTS0}2. PARTS0 fi MODELATOM0 FIELDS0 CONNECTIONS0

3. MODELATOM0 fi STARTSTATE STATES ENDSTATES

4. STATES fi STATE STATES j e5. ENDSTATES fi ENDSTATE ENDSTATES j ENDSTATE6. FIELDS0 fi e7. CONNECTIONS0 fi TRANSITIONS

8. TRANSITIONS fi TRANSITION TRANSITIONS jTRANSITION

9. TRANSITION fi 0connection 0 transition : SRC0 0fi 0

DST0

10. SRC0 fi 0fco 0 STATEINHERITANCESRC

11. DST0 fi 0fco 0 STATEINHERITANCEDST

12. STATEINHERITANCESRC fi STARTSTATE j STATE13. STATEINHERITANCEDST fi STATE j ENDSTATE14. STARTSTATE fi 0atom 0 StartState {FIELDS1}15. FIELDS1 fie16. STATE fi 0atom0 State {FIELDS2}17. FIELDS2 fie18. ENDSTATE fi 0atom0 EndState {FIELDS3}19. FIELDS3 fie


CFG is transformed to the GME metamodel XML repre-sentation that can be loaded by GME. This is accom-plished by using transformation rules already presentedin Table 3.

Fig. 7. Inferred metamodel based on the first domain model.

4.2. Inferring the metamodel from domain models

Before formally explaining the metamodel inferenceengine in Section 4.2.1, we first describe the inference pro-cess from a less formal viewpoint. The working example isthe FSM metamodel introduced earlier in Fig. 2. The meta-model contains FSM concepts (e.g., start state, states, endstates) as well as valid connections among all entities. Themetamodel also contains two FCO (First Class Object) ele-ments by the names of StateInheritanceSrc andStateInheritanceDst. The purpose of an FCO ele-ment is to serve as an intermediate generalization that helpsto better organize the inheritance relationships amongmodel entities. In the case of the FSM metamodel, theStartState and State atom elements are generalizedto the StateInheritanceSrc FCO and the EndStateand State atom elements are generalized to a StateIn-heritanceDst FCO. In the GME, model elements cancontain other models or atoms, but atoms are primitivesthat cannot contain other elements. The FSM metamodelstates that valid instances of the metamodel must have

Fig. 6. The first domain model and

exactly one start state, zero or more states, one or moreend states, and at least one transition. All valid instancesof a metamodel have to be compliant with the UML classdiagram that defines the metamodel.

4.2.1. Incrementally inferring a metamodelAssume that the metamodel is lost and we have to

recover the metamodel only from available instances. Thefirst sample domain model and corresponding MRL pro-gram is shown in Fig. 6. The FSM is composed of a startstate, end state and a transition going from the start stateto the end state.

Because the domain model exposes only one start state,one end state and one transition, the inferred metamodel(Fig. 7) is only an approximation of the original metamodel(Fig. 2).

Consider a second sample domain model shown inFig. 8. In this case, the domain model is richer in detailthan the previous domain model. The two transitions indi-cate that the FSM metamodel can have one or more tran-sitions. This generalization is shown in the metamodel inFig. 9 as the cardinality 1..* under transition. Moreover,source and destination of transitions can now be inferredmore accurately. The domain model from Fig. 8 shows thatthe source of a transition can be StartState or State,and the destination can be State or EndState. All ofthese additional details allow inference of a more accuratemetamodel (Fig. 9). However, both models (Figs. 6 and 8)are needed to infer the original metamodel accurately. Thefirst domain model indicates the possibility that a FSM canonly have a start and end state, and the second domainmodel shows that intermediate states are allowed. There-fore, a more accurate metamodel can be inferred if bothdomain models can be used (Fig. 10).

corresponding MRL program.

Fig. 8. The second domain model and corresponding MRL program.

Fig. 9. Inferred metamodel based on second domain model.

Fig. 10. Inferred metamodel based on first and second domain models.


To infer the original metamodel, more domain modelsare needed that exhibit other possible FSMs. For example,the domain model in Fig. 11 is an example of a FSM withmany states. The domain model of Fig. 12 is an example ofa FSM with many end states.

Fig. 11. The third domain model an

When all four domain models (Figs. 6, 8, 11 and 12) areused in the inference process, the inferred metamodel(Fig. 13) and the inferred CFG (Table 5) exploit common-alities (e.g., all domain models have exactly one start state)and variabilities (e.g., zero or more states, one or more endstates, one or more transitions) of all domain models. Acomparison between the original metamodel (Fig. 2) andthe inferred metamodel (Fig. 13) reveals that the inferredmetamodel is almost exactly the same as the original meta-model except for the fact that the names of the twoStateInheritance FCOs in the original metamodelhave been inferred as generic names FCO1 and FCO2. Thispresents no real consequence with respect to the essentialcapabilities as seen from an end-user’s perspective. Thegeneralization hierarchy and all the metamodel elementsare inferred accurately.

The quality of the inferred metamodel depends on thelevel of detail available in the domain models as well asthe total number of domain models used. If the set ofdomain models used do not make use of all the constituentelements of the original metamodel, then those particularelements cannot be inferred. As already mentioned, wecan represent the metamodels as CFGs and various instan-tiations of this CFG correspond to CFG representations ofdomain models. For experimental purposes, when the CFGfor the original metamodel is available, we can enumerateall possible instantiations of the CFG to obtain all thedomain models defined by that CFG. Because the languagethat the CFG describes could be infinite, it is not feasible toenumerate all the possible CFG instantiations. A keyobservation here is that to generate all possible domainmodels, all possible combinations of the productions inthe CFG need to be enumerated. If the CFG includes

d corresponding MRL program.

Fig. 12. The fourth domain model and corresponding MRL program.

Fig. 13. Inferred metamodel based on four instances.


recursive rules, then these rules need to be exercised onlyonce because multiple runs through the rules will notappend any new meaning to the domain models. Takingthis into account, we can calculate exactly how many differ-ent domain models need to be used in the inference process.The calculation is similar to the variability calculation offeature diagrams [30], with additional rules to handlerecursion.

Table 5Inferred CFG for the FSM metamodel

1. STATEDIAGRAM fi 0model 0 StateDiagram {PARTS0}2. PARTS0 fi MODELATOM0 FIELDS0 CONNECTIONS0

3. MODELATOM0 fi STARTSTATES ENDSTATES STATES

4. STARTSTATES fi STARTSTATE

5. ENDSTATES fi ENDSTATE ENDSTATES j ENDSTATE6. STATES fi STATE STATES j e7. FIELDS0 fi e8. CONNECTIONS0 fi 0connection 0 TRANSITION

9. TRANSITION fi transition: SRC0 fi DST0; TRANSITIONj transition: SRC0 fi DST0;

10. SRC0 fi 0fco 0 FCO1

11. FCO1 fi STARTSTATEjSTATE12. DST0 fi 0fco 0 FCO2

13. FCO2 fi ENDSTATEjSTATE14. STARTSTATE fi 0atom 0 StartState {FIELDS1}15. FIELDS1 fi e16. ENDSTATE fi 0atom0 EndState {FIELDS2}17. FIELDS2 fi e18. STATE fi 0atom0 State {FIELDS3}19. FIELDS3 fi e

4.3. The induction process

Because existing CFG inference algorithms are success-ful only at inducing small programming languages, theMRL description has been purposely simplified, but iscomplete such that all of the essential mappings betweenthe metamodel and MRL are possible. Note that for theinference process, it is sufficient to know the importantconstituent elements of the metamodel. Because we werepreviously successful in inferring DSLs of a similar sizeusing the evolutionary-based CFG inference engine [23],the same inference system was applied to induce the appro-priate CFGs for the MRL. The evolutionary-based CFGinference engine accepts positive and negative sentences(in the case of metamodel inference, negative sentencesdo not exist) and generates an initial population of CFGsbased on positive sentences. These CFGs are then evalu-ated and better grammars are selected for the next genera-tion. Before an evolutionary cycle is completed, mutation,crossover and heuristic operators are applied on randomlychosen survived CFGs. Through many generations, CFGsevolve in such a manner that they correctly recognize allpositive sentences and reject all negative sentences. Nega-tive examples help converge the grammar to be inferredand keep it from becoming too generalized. Because nega-tive examples do not exist in the metamodel inference par-adigm, the CFG inferred by the evolutionary-basedinference engine was greatly generalized. The inferredgrammar had a direct correspondence to the definition ofthe GME meta-metamodel. One of the most importantresults in the field of general grammatical inference statesthat a CFG cannot be induced solely from positive sam-ples, except under special circumstances [19]. However, thislimitation can be overcome in our case because additionalknowledge about the format of GME metamodels is used.For MARS, a new inference algorithm resembling typeinference algorithms (e.g., the Hindley-Milner algorithm,which always infers the most general type [31]) wasinvented. In a similar manner to type inference algorithms,grammar productions can be inferred from MRL descrip-tions of models. The algorithm has heuristics (discussedbelow) that allow it to generalize beyond the informationcontained in the domain models (a key characteristic ofgrammar inference algorithms). MRL programs consist


of atom and model descriptions. An atom is described inMRL as:

atom name {
fields f1, . . . ,fm;
}

For every atom description in MRL, the following produc-tion is inferred (if a production with a left-hand non-termi-nal NAME does not already exist in grammar G):

NAME fi 0atom 0 name {FIELDS}FIELDS fi 0fields 0 f1f2 . . . fm

If a production with a left-hand non-terminal NAME existsin grammar G, then no changes in grammar G need to bemade. Note that fields in the same atom cannot change.

A model is described in MRL as:

model name {
name1 ; . . . ; namek;fields f1, . . . , fm;connection
con-name1: src1 fi dst1;. . .con-namen: srcnfi dstn;

}

Note that the name of fields f1, . . . , fm must be distinct.For every model description in MRL, the following pro-duction is inferred (if a production with a left-hand non-terminal NAME does not already exist in grammar G):

NAME fi 0model 0 name {PARTS}

In this case, the following productions are also added togrammar G:

PARTS
fi MODELATOM FIELDS
CONNECTIONS

MODELATOM
fi NAME1 NAME2 . . . NAMEk
FIELDS
fi 0fields 0 f1 f2 . . . fm CONNECTIONS fi 0connection 0 CON-NAME1 CON-
NAME2 . . .CON-NAMEn
CON-NAMEi fi con-namei
0: 0 SRCi0fi 0 DSTi

0; 0

The preceding examples assumed that a connection has
only one source and destination. This assumption will berelaxed later when needed. However, in this case more pro-ductions (FCO elements) will be generated that are notneeded in the case of a single source or destination. Inthe MODELATOM production above, it can be assumed thatNAME1, . . . , NAMEk are distinct. If some of the names arenot distinct, then repetitions of these non-terminals will beinferred. If it is the case that NAME1 = NAMEk, then the fol-lowing productions replace the previously inferredproductions:
MODELATOM
fi NAMES1 NAME2 . . . NAMEk�1
NAMES1
fi NAME1 NAMES1 jNAME1
Moreover, the same is true for connections CON-

NAME1, . . .,CON-NAMEn. In the case where CON-

NAME1 = CON-NAMEn, the following productions replacepreviously inferred productions:

CONNECTIONS
fi 0connection 0 CON-NAMES1 CON-
NAME2 . . . CON-NAMEn�1

CON-NAMES1
fi CON-NAME1 CON-NAMES1 jCON-NAME1//repetition
CON-NAME1
fi con-name10: 0 SRC-FCO 0fi 0 DST-
FCO 0; 0

SRC-FCO
fi 0fco 0 SRC DST-FCO fi 0fco 0 DST SRC fi SRC1 j SRCn DST fi DST1 j DSTn
Although the name of the connections is the same, thesource and destination of these connections can be differ-ent. To handle this, alternative productions for sourceand destination are inferred.

If a production with a left-hand non-terminal NAMEexists in grammar G, such as:

NAME fi 0model 0 name {PARTS}

then this situation denotes the case where several possibledifferent instances of a metamodel exist. The differencebetween the previous and the new instance needs to beidentified and can be in the MODELATOM part (e.g., amodel or atom is missing or added) or in the CONNEC-

TIONS part (e.g., a connection is missing or added, orthe source or destination is not the same as in the previ-ous instance).

As just described, for all models or atoms repre-sented by non-terminals NAMEi that do not appear inboth instances, the inference process is different.Assume that NAME1 is such a non-terminal; two casesare possible:

(a) A non-terminal that represents a model or an atom isoptional in the model description

MODELATOM
fi NAMEOPT1 NAME2 . . . NAMEk
NAMEOPT1
fi NAME1 j e
(b) A non-terminal that represents a model or an atomcan appear zero or more times in the model description

MODELATOM
fi NAMES1 NAME2 . . . NAMEk
NAMES1
fi NAME1 NAMES1 je
The inference process is different for the case where con-nections represented by non-terminals CON-NAMEi do not


appear in both instances. Consider the following two cases(assuming that CON-NAME1 is such a non-terminal):

(a) A non-terminal that represents a connection isoptional in the model description:

CONNECTIONS fi
0 connection 0 CON-NAMEOPT1
CON-NAME2 . . . CON-NAMEn�1

CON-NAMEOPT1 fi
C ON-NAME1 j e
(b) A non-terminal that represents a connection canappear zero or more times in the model description:

CONNECTIONSfi
0 connection 0 CON-NAMES1 CON-
NAME2 . . . CON-NAMEn�1

CON-NAMES1 fi
C ON-NAME1 CON-NAMES1 je
Finally, the last difference between instances is when theconnection source or destination is not the same as in theprevious description. To handle this case, all differencesin source and destination are identified and the followingproductions are inferred:

CON-NAMEi fi
c on-namei0: 0 SRC-FCO 0fi 0 DST-FCO 0; 0
SRC-FCO fi
0 fco 0 SRC DST-FCO fi 0 fco 0 DST SRC fi S RC1 j . . . j SRCp DST fi D ST1 j . . . j DSTp
For example, in the MRL description of ‘‘Model 2’’ inTable 2 there are three connections, as shown below:

Transition
: StartState fi State; Transition : State fi State; Transition : State fi EndState;
All of these connections have the same name (Transi-tion). However, the source and destinations are differentand the following productions are inferred:

CONNECTIONS
fi 0connection 0 TRANSITIONS TRANSITIONS fi TRANSITION TRANSITIONS j
TRANSITION

TRANSITION
fi transition 0: 0 SRC-FCO 0fi 0 DST-FCO 0; 0
SRC-FCO
fi 0fco 0 SRC DST-FCO fi 0fco 0 DST SRC fi STARTSTATE j STATE DST fi ENDSTATE j STATE
Note that cardinality information can be inferred ifenough model examples are available. It is not possible togeneralize the cardinality value from a collection of domainmodels that always exhibit the same cardinality, but the car-dinality can be generalized from a sample of models that dif-fer in their definitions. Of course, the most general case canbe assumed (i.e., a cardinality value of 0. . .*).

The grammar inference process is performed duringthe parsing of MRL models using LISA. The inferredCFG for the FSM example is shown in Table 5, whichis quite similar to the manually created CFG shown pre-viously in Table 4. Table 6 details the metamodel infer-ence algorithm and we now show that the algorithmachieves (worst case) polynomial time in complexity.The input to the algorithm are vectors that contain theconstituent elements (models, atoms, connections, fields)of the domain models and are bounded by N, the totalnumber of elements in the instance set. The process

action in lines 2, 7, 10, 15, 19, 21, 23, 27, 29, 31, 33and 36 represents a group of statements that outputthe corresponding model element in CFG and XML for-mat and runs in linear time. Lines 1–31 compute modeldefinitions and are responsible for the bulk of the com-putational complexity of the algorithm. Lines 3–7 com-pute subitems (child atoms and models) of models byiterating over the cardinality vectors. The cardinalitycomputation step in line 6 uses conditional tests for spe-cific cardinality conditions, which takes linear time.Thus, the complexity of inferring subitems of a modelis O(N3). The time required to infer the fields of a model(lines 8–10) is O(N). The connections of a model arehandled in lines 11–31. Like the cardinality computationstep of model subitems in line 6, the cardinality compu-tation of connections is composed of conditional state-ments, which takes linear time. The check_for_fco

action in lines 17 and 25 checks whether an FCO gener-alization exists that can be used as the source or destina-tion for the connection under consideration instead ofcreating a new FCO generalization. This check is doneusing a nested for loop and runs in O(N2) time. Thetotal computation time for inferring connections of amodel is bounded by O(N*(N + 2N2)). Lines 32–36 inferatoms and take O(N2) time. Thus, the overall upperbound of the algorithm’s complexity isO(N*(N3 + N + (N*(N +2N2)))) + O(N2) � O(N4).

5. Experimental studies of metamodel inference

We conducted experimental studies to test MARS onvarious example domains and analyzed its performanceunder a variety of metamodel recovery situations thatmight be encountered in practice. Specifically, we testedthe following hypothesis: Is it possible to infer a meta-model from one model only? Is it possible to infer ametamodel from models that do not exhibit all the prop-erties of the metamodel? To test these hypotheses, wedesigned experiments to infer a metamodel from multipleinstances (or a single instance), which contain completeinformation about the metamodel, and a metamodelfrom instances which contain incomplete information.We applied the system to the following diverse domainswhich are a mix of small examples that have been cre-ated as pedagogical case studies used to teach domain-

Table 6The metamodel inference algorithm

Input: Vectors containing contents of domain models

Output: The inferred metamodel in CFG and XML formats

1. for all models in Model_Vector2. process_ model 3. for all model subitems Model_Subitem_Vector4. for all vectors in Cardinality_Vector5. for all subitems in Cardinality_Vector_items 6. compute_cardinality_of_subitem7. process subitem

8. if Model_Fields_Vector is not empty9. for all fields in Model_Fields_Vector10. process model_fields

11. if Model_Connections_Vector is not empty12. for all connections in Model_Connections_Vector13. for all connections in Connections_Cardinality_Vector14. compute_cardinality_of_connection_name15. process_connection_name16. if connection has more than 1 source17. check_for_fco18. if fco exists19. process_source_with_fco20. else21. process_source_with_new_fco22. else23. process_source

24. if connection has more than 1 destination25. check_for_fco26. if fco exists27. process_destination_with_fco28. else29. process_destination_with_new_fco30. else31. process_destination

32. for all atoms in Atom_Vector33. process_ atom34. if Atom_Fields_Vector is not empty35. for all fields in Atom_Fields_Vector36. process atom_fields


specific modeling: Finite State Machine (FSM – casestudy of this paper), Network Diagram Modeling Lan-guage,1 AudioVideo System Modeling Language,2 andthe Petri Net Modeling Language. The model instanceswere created by hand to explore the metamodel recoverysituations mentioned above.

5.1. Inferring the network diagram metamodel

The Network metamodel is larger and more elaboratethan the FSM metamodel. Fig. 14 shows the metamodelfor a simple language for specifying properties of a net-

1 The Network Diagram Modeling Language is the case study usedwithin the tutorial that is installed by the GME.

2 The Audio/Video metamodel was created by Jonathan Sprinkle, GregNordstrom, and James Davis as a pedagogical tool for the Model-Integrated Computing graduate course at Vanderbilt University.

work. The metamodel contains networking concepts (e.g.,routers, hosts, and ports) as well as the valid connectionsamong all entities. An instance of this metamodel is shownin Fig. 15, which illustrates different company configura-tions that are connected on the network.

We used domain models corresponding to the followingconfigurations to infer the metamodel for this domain:

(1) A NetDiagram containing multiple Host andWSGroup elements.

(2) A NetDiagram containing multiple Network andPerimeter elements.

(3) A NetDiagram containing multiple instances of thefollowing configuration: connections from Host toNetwork and Perimeter.

(4) A NetDiagram containing multiple instances of thefollowing configuration: connections from WSGroup

to Network and Perimeter.

Fig. 14. Original metamodel for creating network diagrams.

Fig. 16. Inferred metamodel

Fig. 15. An instance of a network.


(5) A NetDiagram containing multiple instances of thefollowing configuration: connections from Port toNetwork and Perimeter.

(6) A NetDiagram containing multiple instances of thefollowing configuration: connections from Perime-

ter to Network and Perimeter.(7) A NetDiagram containing multiple Routers, with

some of those routers containing multiple Ports.(8) A NetDiagram containing other NetDiagrams.

Fig. 16 shows the inferred metamodel for the networkdomain.

Comparing the original metamodel for the Networkdomain in Fig. 14 to the inferred metamodel inFig. 16, we observe that the NetInterface and Gen-

Net generalizations are inferred as FCO1 and FCO2 gen-eralizations, respectively. The reason for this is that thegeneralization hierarchy is not explicitly defined in thedomain models. Also, the fields Family, IFType, andWorkload, originally of type ‘enum’, are inferred asthe more general type ‘field’. This is because MARS

for the network domain.


currently infers all field attributes as the more generaltype ‘field’.

Fig. 18. Dining philosophers: an instance of a Petri Net.

5.2. Inferring the Petri Net metamodel

The inferred metamodels from the FSM example weredetermined from artificially created domain models. Inpractice, a metamodel is inferred using the domain modelsavailable at hand, which can vary in number as well as intheir information content. We demonstrate this scenariousing a Petri Net [32] modeling language, which consistsof the elements Place and Transition, as well as theconnections between them. A Place can also hold a cer-tain number of tokens. Fig. 17 shows the original meta-model for this domain.

An instance of this metamodel is shown in Fig. 18,which depicts a model of the dining philosophers problem.The visualization icons for various elements of the PetriNet metamodel are the standard icons like a circle for aplace and a horizontal bar for a transition. GME alsoallows domain models to be reconfigured to display user-specified icons; the domain model in Fig. 18 has been con-figured to use different icons to better illustrate the diningphilosophers problem. The Petri Net metamodel can beinferred using this sole domain model, which makes useof all the elements and connections of the original meta-model and allows the complete inference of an accuratemetamodel. Fig. 19 shows the inferred metamodel for thePetri Net domain. The only difference is that the petri-Elements FCO generalization hierarchy in the originalmetamodel is missing from the inferred metamodel. Thereason for this is that the petriElements generalizationin the original metamodel was designed using the domainknowledge that Place and Transition are ‘‘Petri NetElements’’ of various kinds. The inference process doesnot have this kind of built-in domain knowledge; thus, ithas to perform the inference with the amount of informa-tion available in the domain models under consideration.A consequence of this is that the attributes of the petri-

Fig. 17. Original metamodel

Elements FCO (Name and Description) are inferredas attributes for Place and Transition in the inferredmetamodel.

5.3. Inferring the AudioVideo System metamodel

The AudioVideo System is a domain example that illus-trates the scenario of inferring a partial metamodel whenthe available examples do not contain all possible elementand connection possibilities. The AudioVideo Systemmetamodel describes a language for configuring a homeentertainment system consisting of domain elements (e.g.,VCR, DVD, LD, MiniDisc, and other assorted electronics)and the connections between them. Figs. 20 and 21 showthe original metamodel and an instance of the metamodel,respectively. Note that in the domain model, SONYSTR-DB1070 is an instance of an AudioProcessor modeland houses further metamodel component configurations.Fig. 22 shows the inferred metamodel after using threeavailable instances.

for the petri net domain.

Fig. 19. Inferred metamodel for the Petri Net domain.

Fig. 20. Original metamodel for the AudioVideo System domain.

Fig. 21. An instance of the AudioVideo System domain.


When compared to the original metamodel, the follow-ing are the differences observed in the inferred AudioVideoSystem metamodel:

• Some of the atom elements (e.g., Cassette and Mini-Disc) from the original metamodel are missing; this isbecause these elements were not present in the exampledomain models.

• Specializations of the various generalizations (e.g.,CableConnection, PowerSource, and IODevice)in the original metamodels, instead of the generaliza-tions themselves, are used in the inferred metamodel.For example, Battery is a direct part of AudioPro-cessor. The reason for this is the lack of domainknowledge available to the inference process. We pro-pose some initial ideas on how to solve this problem.For example, elements with the same attributes (e.g.,InputPort and OutputPort) can be considered aspotential candidates for generalization, although thismight not be valid for all cases. In the case of a con-

nection generalization, if the elements have the samesource and destination connections, they can be poten-tial generalization candidates. For example, in theinferred metamodel the connections FiberOpticCa-ble, CoaxialCable and RCACable all haveAudioProcessor as the destination and Component

specialization as the source.

Fig. 22. Inferred metamodel for the AudioVideo system domain.


• In addition to the missing elements, some connectionsbetween elements are absent. For example, in the originalmetamodel, the connection RCACable is a connectionbetween the Component elements (e.g., DVD, CD,LP) as the source and the AudioProcessor model asa destination. In the inferred metamodel, the source forthe RCACable connection is the element FCO5, whichis actually the inferred metamodel equivalent to the origi-nal metamodel’s Component generalization hierarchy(albeit with a few missing elements), and the destinationis the AudioProcessor model. In the original meta-model, the IOPortConn connection defines a connec-tion between the Port and IODevice generalizations,either of which can be source or destination. In theinferred metamodel, this is translated to FCO1 as source(e.g., MIC and OutputPort) and FCO2 as destination(e.g., InputPort and Speaker) because these are thepossible set of connections between elements exhibitedin the domain models. Similarly, Port2Conn in the ori-ginal metamodel is part of both AudioProcessor andAudioSystem in the original metamodel, but onlyAudioProcessor in the inferred metamodel.

• There are also differences in the cardinalities. All thespecializations of Component (e.g., LD, CD, DVD) havea cardinality of 1 in the inferred metamodel. This isbecause only one instance of these components is usedin the example domain models.

• The attribute Quality is of type ‘field’ in the originalmetamodel, but ‘enum’ in the inferred metamodel.

• Mic and Speaker have Quality attributes in theinferred metamodel, but this attribute belongs to IODe-

vice (i.e., their generalization) in the original metamodel.

5.4. Evaluation and results

We have also applied MARS on the large multi-tieredEmbedded Systems Modeling Language (ESML), whichrepresents a domain-specific graphical modeling languagedeveloped for modeling Real-Time Mission Computing

Embedded Avionics applications [33]. The ESML containsdomain models representing mission computing avionicsscenarios. The ESML is a large domain, with modelsarranged in multiple folders. MARS was able to infer anESML metamodel which had over 80 elements. However,this inferred metamodel was incomplete because it was sin-gle-tiered and did not contain information on metamodelsin other folders. MARS is currently limited to inferring sin-gle folder metamodel domains. We plan to extend thiscapability to infer multi-tiered metamodels.

Table 7 summarizes the results of the metamodel infer-ence experiments. The complexity of a metamodel is mea-sured by counting the total number of elements,aggregations, generalizations and connections in the meta-model. All the metamodels (including the large ESMLmetamodel) were inferred in less than 3 seconds on a mod-ern notebook (Pentium 1.6 GHz, 1GB RAM) indicatingthat MARS is capable of scaling well to large single-tieredmetamodels.

The MARS project website [34] contains the results ofexperimental runs of these domains, as well as all the arti-facts of the inference process (e.g., XSLT rules, samplemetamodels, domain models and grammars) for all of thedomains discussed in this paper.

6. Related work

In this section, we compare MARS to some of the work inthe area of programming language grammar recovery, com-ponent-based software reverse engineering and domainmodel evolution. We also compare our work to two systemsthat take a grammatical inference approach to DocumentType Definition (DTD) [35] and XML schema [36] extraction.

6.1. Grammar stealing, software reverse engineering and

model evolution

As mentioned in Section 1, the work of Lammel and Ver-hoef [1] focused on recovering a programming language

Table 7Summary of the inference experiments

Domain Instancesused

N, number of elementsin instance set

Original metamodelcomplexity

Inferred metamodelcomplexity

Observations

Finite state machine 4 22 7 elements, 2 generalizations,4 aggregations, 1 connection

7 elements, 2 generalizations,4 aggregations, 1 connection

Some generalization FCOobjects are renamed to FCO1and FCO2Sum = 14 Sum = 14

Network 8 205 11 elements, 2generalizations, 9aggregations, 2 connections

11 elements, 2generalizations, 9aggregations, 2 connections

Some generalization FCOobjects are renamed to FCO1and FCO2

Sum = 24 Sum = 24

Petri Net 1 175 6 elements, 1 generalization,3 aggregations, 2 connections

5 elements, 0 generalizations,4 aggregates, 2 connections

The petriElementsgeneralization in the originalmetamodel is not inferred sinceit was designed by using thedomain knowledge that Placeand Transition are‘‘Petrinet Elements’’ of variouskinds

Sum = 12 Sum = 11

AudioVideo System 3 310 27 elements, 5generalizations, 10aggregations, 3 connections

25 elements, 5generalizations, 19aggregations, 5 connections

Some model elements,generalizations and connectionconfigurations are not inferred

Sum = 45 Sum = 54


grammar for renovation tool construction. More specifi-cally, they discussed the concept of grammar stealing:a tech-nique that uses either compiler sources or language referencemanuals to obtain a grammar, from which renovation toolsare constructed. In the absence of reference manuals or com-piler sources (a more problematic scenario), grammar steal-ing will not be very successful. However, recent advances [23]have allowed the application of grammar inference tech-niques to the renovation tool construction problem. Ourtechnique can recover a grammar (albeit for small DSLs likeMRL) from source code. The GSEE software explorationenvironment is used in [10] to reverse engineer component-based software systems. Unlike MARS, GSEE operates atthe level of source code, but MARS infers models at adomain-specific modeling level. To the best of our knowl-edge, MARS represents the first effort that applies grammarinference techniques to the model recovery problem.

Sprinkle and Karsai [3] presented a schema evolutionsolution for DSM. In their approach, a visual languageto allow mappings between metamodels is introduced andgraph-rewriting techniques are exploited to map domainmodels from one metamodel schema to another. In otherwords, as the metamodel evolves, the domain models canbe transformed accordingly to conform to the new meta-model. However, the mapping between different metamod-els requires a distinct algorithm for each new schemaevolution. The user has to manually observe the differencesbetween the two metamodels, and then using the definedvisual language, create an algorithm that suitably mapsone metamodel to the other. By comparison, our approachuses the same algorithm and steps regardless of the specificmetamodel. Also, the work in [3] is only applicable whenthe user is migrating domain models in an environmentwhere a metamodel versioning system is maintained.

Graaf, Weber and van Deursen propose a generic modeltransformation based approach for migration of supervi-sory machine control architectures [6]. Similar to Sprinkleand Karsai’s approach [3], this model transformationbased migration technique specifies mappings from sourcemetamodels to target metamodels. In comparison, MARSis a metamodel recovery technique not a metamodel trans-

formation technique. MARS offers a solution to the moreextreme case of recovering metamodels and is also applica-ble in model evolution scenarios.

CacOphoNy [8] integrates software architecture andMDE to reverse engineer software architectures. It sharesmany similarities with the GSEE environment [10] (aresearch tool from the same group) and can be viewedas executing GSEE at a higher layer of abstraction.CacOphoNy has six major steps, one of which deals withmetamodel recovery. The metamodel recovery capabili-ties of CacOphoNy appear to be manual. Although itis suggested by the authors that attempts be made bysoftware maintenance engineers to go beyond the directlyaccessible information in the instances and extract inter-esting information, no concrete inference algorithm orheuristics to do so are discussed. The recovery relies onthe software maintenance engineers’ analysis of the factscontained in the source repository. In contrast, MARS isa semi-automatic approach for recovering metamodelsand uses an iterative algorithm with heuristics to gener-alize beyond the information contained in domainmodels.

6.2. Grammar inference applied to XML schema extraction

Grammar inference has also been applied to DTD andXML Schema extraction from XML documents. A DTD


specifies the internal structure of an XML document usingregular expressions. However, due to their limited capabil-ities in both syntax and expressive power for wide rangingapplications, a host of grammar-based XML schema lan-guages like XML Schema have been proposed to replaceDTD. The XTRACT [37] system concentrates on inducingthe DTD from XML documents using a regular grammarinduction engine to infer equivalent regular expressionsfrom DTD patterns, and then utilizes the MinimumDescription Length (MDL) [38] principle to choose thebest DTD from a group of candidate DTDs. In [39], anExtended Context-Free Grammar (ECFG) based systemis proposed to allow extraction of more complex XMLschemas. Our induction system parallels these works inthe sense that it is XML based, makes use of grammarinference techniques, and extracts the metamodel (analo-gous to DTD or other forms of XML schemas) of a specificdomain model (analogous to the XML document). Asintermediate representations of the XML document, theXTRACT system uses regular expressions and theECFG-based system represents XML documents as exam-ples of an unknown ECFG (and then tries to infer theECFG). In comparison, our approach in MARS representsthe XML document as a DSL (with a corresponding parserwritten as LISA specifications), resulting in a higher levelof abstraction. Regarding content generalization compari-sons (i.e., the process of being able to infer a concisehypothesis regarding a set of elements), the XTRACT sys-tem chooses the DTDs with the MDL score. The ECFG-system merges non-terminals as long as no production inthe grammar contains ambiguous terms. Our generaliza-tion mechanism is similar to the one found in theXTRACT system in that containment information regard-ing models and atoms in a domain model XML file is usedto compute the cardinality of the constituent elements ofthe models and the connections.

7. Limitations and future work

There are several limitations to the current investigation.Each limitation can be eased by considering additionalinput from a model engineer. The complete metamodelinference process can be described as a semi-automatictechnique that derives much of the required metamodelfrom the mined domain models, but must rely on a domainor modeling expert to complete a few parts of the task. Theparts of the metamodel inference process that involve inter-action with a user are:

• Data type inference: For each field (attribute) of themodel elements, it is not always possible to infer the attri-bute type from the representative XML of the modelinstances. For example, a string value associated withan attribute in a domain model could correspond to astring or an enumeration value. In addition to thedomain models there are other artifacts that can bemined in the modeling repository. For example, model

compilers can traverse the internal representation of amodel and generate source code. They may also containtype information that cannot be inferred from thedomain models. The key challenge with mining informa-tion from a model compiler is the difficulty of parsingthe model compiler source (e.g., a complex C++ pro-gram) and performing the appropriate analysis to deter-mine the type information. To address this problem, weare currently investigating the use of a program trans-formation system to parse the code of the model com-piler and recover the type information of metamodelentities. More specifically, the program transformationsystem uses a powerful term rewriting engine to allowsophisticated program analysis and transformationtasks to be performed on the code of the model compilerto extract the type information from the modelcompiler.

• Domain-specific visualization: In the GME, the visualiza-tion of a domain-specific model (i.e., the icons used in rep-resenting domain concepts) is specified in the metamodel.Each metamodeling entity can be assigned a file name thatcontains the graphic to be displayed when rendering thedomain element. Because the visualization cannot bedetermined from the domain models, the inferred meta-model contains generic icons. To complete the visualiza-tion of the inferred metamodel, a domain expert needsto be consulted to associate the inferred conceptualdomain entities with appropriate visualization.

• OCL constraints: An OCL constraint is specified at theGME metamodeling level to capture domain semanticsthat cannot be captured by static class diagrams. Theseconstraints are evaluated when a domain model is cre-ated. Any violation of a constraint raises an error toinform the model engineer that some aspect of the modelis incorrect with respect to the metamodel. MARS iscurrently unable to infer OCL constraints from domainmodels. The constraint definitions do not appear in thedomain models explicitly. Because of this, an inferredmetamodel needs to be augmented manually with con-straints. Without constraints, the inferred metamodelmay be too liberal with respect to the domain modelsthat are to be accepted by the original metamodel thatwas lost (i.e., the original metamodel may have con-straints that would have rejected domain models thatare legally defined by the inferred metamodel).

• Unavailability of negative counter examples: If negativeexamples were available, perhaps simple OCL con-straints could be inferred. It is not certain, however,what degree of constraint complexity could be inferredfrom negative examples. To a large degree, the level ofdetail that can be inferred depends on the amount ofavailable sample models, and the degree to which theydiffer. The concept of inferring a constraint is a non-issue, however, because negative examples typically donot exist in the modeling process. This is not a limitationof MARS, per se, but an acknowledgement of the lackof availability of such examples in the process itself.


• Inferring the modularization of large metamodels: Meta-models for large domains such as ESML are multi-tieredand are arranged in multiple folders. Currently, MARSis limited to inferring metamodels which are containedin single folders. When applied to domain models ofmulti-tiered domains like ESML, MARS only infersthe elements and relationships contained in the primaryfolder. Our future work involves extending MARS toinfer multi-tiered metamodels. This would possiblyinvolve a search for all elements and their relationshipswhich might be arranged according to folders in thedomain model XML files, and may require modifyingthe MRL to handle scoping rules.

Although the application of MARS has focused specifi-cally on recovering metamodels for the GME, the sameprocess can be applied to other metamodeling tools, suchas MetaCase’s metaEdit + (http://www.metacase.com),Microsoft’s DSL tools (http://msdn.microsoft.com/vstudio/dsltools/), the Eclipse Modeling Project (http://www.eclipse.org/modeling/), and Honeywell’s Domain Modeling Envi-ronment (DOME) (http://www.htc.honeywell.com/dome/).As an area of future work, we plan to explore the abilityto apply MARS to these other environments. We are alsoinvestigating the use of our approach to situations whereintermediate metamodels leading to the evolved metamodelare available. Using the information contained in old meta-models, more accurate metamodels can be recovered (pos-sibly with the need of fewer domain models) whencompared to the situation when no metamodels areavailable.

8. Conclusion

In most metamodeling environments, the domain mod-els cannot be loaded properly into the modeling tool with-out a corresponding metamodel. The goal of the MARSproject is to infer a metamodel from a collection of domainmodels. The motivating problem was to address the issueof metamodel drift, which occurs when domain models ina repository are separated from their defining metamodel.A growing number of research and industrial projectsexhibiting the metamodel drift problem were observedwhich served as further motivation for this work. Althoughprevious works have addressed the problem of metamodelevolution using model transformation techniques by speci-fying mappings between source and target metamodels,they do not address the more extreme situation where ametamodel needs to be recovered from models. Someresearch efforts like CacOphoNy do have a metamodelrecovery component, but they lack precise inference heuris-tics and algorithms and rely on the user’s analysis of infor-mation contained in the source repository.

The key contribution of the paper is a discussion ofMARS, which is a semi-automatic inference system forrecovering a metamodel that correctly defines the mineddomain models through application of grammar inference

techniques. MARS has a three-step process that uses a hostof technologies such as XSLT, LISA and an inference algo-rithm to recover metamodels. MARS also leverages thefact that a correspondence exists between the domain mod-els that can be instantiated from a metamodel, and the setof programs that can be described by a grammar. MRLbridges the gap between the input expected by grammarinference engines and XML representations of the domainmodels. It is comprehensive enough to express all of theGME concepts that we encountered, yet concise in itsdesign to assist as an intermediate representation for theinference process. The paper also discusses the inductiontechniques used to infer metamodels and gives a complex-ity analysis of the algorithm that runs in polynomial time.MARS has been applied to several case studies and scenar-ios that reflect metamodel recovery situations encounteredin practice. The results successfully demonstrate the feasi-bility and scalability of the approach. MARS can, withina few seconds, infer single-tiered metamodels composedof a large number of elements but is currently not able toinfer multi-tiered metamodels. The future work involvesextending MARS to infer metamodel element types andmulti-tiered metamodels. All of the extended listings (e.g.,XSLT rules, sample metamodels, domain models andgrammars) are available at the MARS website [34].

Acknowledgements

This work was supported in part by an NSF CAREERaward (CCF-0643725).

References

[1] R. Lammel, C. Verhoef, Cracking the 500 language problem, IEEESoftware 18 (6) (2001) 78–88.

[2] D. Schmidt, Model-driven engineering, IEEE Computer 39 (2) (2006)25–31.

[3] J. Sprinkle, G. Karsai, A domain-specific visual language for domainmodel evolution, Journal of Visual Languages and Computing 15 (3–4) (2004) 291–307.

[4] S. Johann, A. Egyed, Instant and incremental transformation ofmodels, in: Proceedings of the 19th IEEE International Conferenceon Automated Software Engineering (ASE 2004), IEEE ComputerSociety Press, Los Alamitos CA, 2004, pp. 362–365.

[5] Z. Diskin, J. Dingel, A metamodel independent framework for modeltransformation: Towards generic model management patterns inreverse engineering, in: Proceedings of the 3rd International Work-shop on Metamodels, Schemas, Grammars and Ontologies forReverse Engineering (ATEM 2006), Genoa, Italy, 2006.

[6] B. Graaf, S. Weber, A. van Deursen, Model-driven migration ofsupervisory machine control architectures, Journal of Systems andSoftware, 2007, in press, doi:10.1016/j.jss.2007.06.007.

[7] A. van Deursen, C. Hofmeister, R. Koschke, L. Moonen, C. Riva,Symphony: view-driven software architecture reconstruction, in:Proceedings of the 4th Working IEEE/IFIP Conference on SoftwareArchitecture (WICSA’04), IEEE Computer Society, 2004, pp. 122–134.

[8] J.-M. Favre, CacOphoNy: Metamodel driven architecture recon-struction, in: Proceedings of the 11th Working Conference on ReverseEngineering (WCRE2004), IEEE Computer Society, Delft, TheNetherlands, 2004, pp. 204–213.

http://www.metacase.com

http://msdn.microsoft.com/vstudio/dsltools/

http://msdn.microsoft.com/vstudio/dsltools/

http://www.eclipse.org/modeling/

http://www.eclipse.org/modeling/

http://www.htc.honeywell.com/dome/

http://dx.doi.org/10.1016/j.jss.2007.06.007


[9] J. Gray, J. Zhang, Y. Lin, H. Wu, S. Roychoudhury, R. Sudarsan, A.Gokhale, S. Neema, F. Shi, T. Bapty, Model-driven programtransformation of a large avionics framework, in: Proceedings ofGenerative Programming and Component Engineering (GPCE 2004),Springer, Heidelberg, Germany, 2004, pp. 361–378.

[10] J.-M. Favre, F. Duclos, J. Estublier, R. Sanlaville, J.-J. Aufrette,Reverse engineering a large component-based software product, in:Proceedings of the Fifth Conference on Software Maintenance andReengineering (CSMR 2001), IEEE Computer Society, Lisbon,Portugal, 2001, pp. 95–104.

[11] GME Users Mailing List, http://list.isis.vanderbilt.edu/pipermail/gme-users/2005-March/000697.html (14 February 2006).

[12] GME Users Mailing List, http://list.isis.vanderbilt.edu/pipermail/gme-users/2005-May/000776.html (14 February 2006).

[13] J. Gray, J.-P. Tolvanen, S. Kelly, A. Gokhale, S. Neema, J. Sprinkle,Domain-specific modelingCRC Handbook on Dynamic SystemModeling, CRC Press, Boca Raton FL, 2007.

[14] A. Ledeczi, A. Bakay, M. Maroti, P. Volgyesi, G. Nordstrom, J.Sprinkle, G. Karsai, Composing domain-specific design environ-ments, IEEE Computer 34 (11) (2001) 44–51.

[15] K. Balasubramaniam, A. Gokhale, G. Karsai, J. Sztipanovits, S.Neema, Developing applications using model-driven design environ-ments, IEEE Computer 39 (2) (2006) 33–40.

[16] G. Karsai, M. Maroti, A. Ledeczi, J. Gray, J. Sztipanovits,Composition and cloning in modeling and metamodeling, IEEETransactions on Control System Technology 12 (2) (2004) 263–278.

[17] J. Warmer, A. Kleppe, The Object Constraint Language, Addison-Wesley, Reading, MA, 2003.

[18] M. Pazzani, D. Kibler, The utility of knowledge in inductive learning,Machine Learning 9 (1) (1992) 57–94.

[19] E.M. Gold, Language identification in the limit, Information andControl 10 (5) (1967) 447–474.

[20] Y. Freund, M. Kearns, D. Ron, R. Rubinfeld, R. Shapire, L. Sellie,Efficient learning of typical finite automata from random walks, in:Proceedings of the Twenty-Fifth Annual Symposium on Theory ofComputing, ACM Press, New York, NY, 1993, pp. 315–324.

[21] M. Mernik, M. Lenic, E. Avdicausevic, V. Zumer, LISA: aninteractive environment for programming language development, in:Proceedings of the 11th International Conference on CompilerConstruction, Springer, Heidelberg, Germany, 2002, pp. 1–4.

[22] M. Mernik, V. Zumer, Incremental programming language develop-ment, Computer Languages, Systems and Structures 31 (1) (2005) 1–16.

[23] M. Crepinsek, M. Mernik, F. Javed, B.R. Bryant, A. Sprague,Extracting grammar from programs: an evolutionary approach,ACM SIGPLAN Notices 40 (4) (2005) 39–46.

[24] M. Mernik, M. Crepinsek, T. Kosar, D. Rebernak, V. Zumer,Grammar-based systems: Definition and examples, Informatica 28 (3)(2004) 245–255.

[25] M. Mernik, J. Heering, T. Sloane, When and how to developdomain-specific languages, ACM Computing Surveys 37 (4) (2005)316–344.

[26] M. Wimmer, G. Kramler, Bridging grammarware and modelware, in:Proceedings of the 4th Workshop in Software Model Engineering(WiSME 2005), LNCS 3844, 2005, pp. 159–168.

[27] M. Alaanen, I. Porres, A relation between context-free grammars andmeta object facility metamodels, Technical Report 606, TUCS,March 2004.

[28] J. Clark, XSL Transformations (XSLT) (Version 1). W3C TechnicalReport, November 1999, http://www.w3.org/TR/1999/REC-xslt-19991116 (14 February 2006).

[29] J. Clark, S. DeRose, XML path language (XPath) (Version 1.0). W3CTechnical Report, November 1999, http://www.w3.org/TR/1999/REC-xpath-19991116 (14 February 2006).

[30] K.C. Kang, S.G. Cohen, J.A. Hess, W.E. Novak, A.S. Peterson,Feature-oriented domain analysis (FODA) feasibility study, Tech-nical Report, CMU/SEI-90-TR-21, ADA 235785, Software Engi-neering Institute, Carnegie Mellon University, Pittsburgh, PA,1990.

[31] S. Peyton-Jones, Implementation of Functional Programming Lan-guages, Prentice-Hall International, London, England, 1997.

[32] J. Peterson, Petri nets, ACM Computing Surveys 9 (3) (1977) 223–252.

[33] D. Sharp, Component-based product line development of avionicssoftware, in: Proceedings of the First Software Product LinesConference (SPLC-1), Kluwer International, Boston, MA, 2000, pp.353–359.

[34] The MetAmodel Recovery System Project: http://www.cis.uab.edu/softcom/GenParse/mars.htm.

[35] T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler, F. Yergeau,Extensible Markup Language (XML) 1.0, third ed., W3C TechnicalReport, February 2004, http://www.w3.org/TR/2004/REC-xml-20040204 (14 February 2006).

[36] J. Simeon, P. Wadler, The essence of XML, in: Proceedings of the30th ACM SIGPLAN Symposium on Principles of ProgrammingLanguages, ACM Press, New York, NY, 2003, pp. 1–13.

[37] M.N. Garofalakis, A. Gionis, R. Rastogi, S. Seshadri, K. Shim,XTRACT: A system for extracting document type descriptors fromXML documents, in: Proceedings of the ACM SIGMOD Interna-tional Conference on Management of Data (SIGMOD’00), ACMPress, New York, NY, 2000, pp. 165–176.

[38] J. Rissanen, Hypothesis selection and testing by the MDL principle,The Computer Journal 42 (4) (1999) 260–269.

[39] B. Chidlovskii, Schema extraction from XML data: A grammaticalinference approach, Proceedings of the Eighth International Work-shop on Knowledge Representation meets Databases (KRDB 2001),CEUR Workshop Proceedings, Rome, Italy, 2001.

http://list.isis.vanderbilt.edu/pipermail/gme-users/2005-March/000697.html

http://list.isis.vanderbilt.edu/pipermail/gme-users/2005-March/000697.html

http://list.isis.vanderbilt.edu/pipermail/gme-users/2005-May/000776.html

http://list.isis.vanderbilt.edu/pipermail/gme-users/2005-May/000776.html

http://www.w3.org/TR/1999/REC-xslt-19991116

http://www.w3.org/TR/1999/REC-xslt-19991116

http://www.w3.org/TR/1999/REC-xpath-19991116

http://www.w3.org/TR/1999/REC-xpath-19991116

http://www.cis.uab.edu/softcom/GenParse/mars.htm

http://www.cis.uab.edu/softcom/GenParse/mars.htm

http://www.w3.org/TR/2004/REC-xml-20040204

http://www.w3.org/TR/2004/REC-xml-20040204

MARS: A metamodel recovery system using grammar inference

Documents

Transcript of MARS: A metamodel recovery system using grammar inference