SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 1

1

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 2

Towards Domain-specific Model Editors withAutomatic Model Completion

Sagar Sen , Benoit Baudry, Hans Vangheluwe

Abstract

Integrated development environments such asEclipse allow users to write programs quickly by presenting a set of recommen-dations for code completion. Similarly, word processing tools such asMicrosoft Word present corrections for grammatical errorsin sentences. Both of these existing structure editors use aset of constraints expressed in the form of a natural language grammarto restrict/correct the user (syntax-directed editing) or formal grammar (language-directed editing) to aid document completion.Taking this idea further, in this paper we present an integrated software system capable of generating recommendationsfor modelcompletion of partial models built in editors fordomain-specific modelling languages. We present a methodology to synthesizemodel editors equipped with automatic completion from a modelling language’s declarative specification consisting ofa meta-model with a visual syntax. Thismeta-model directedcompletion feature is powered by a first-order relational logic engineimplemented in ALLOY . We incorporate automatic completion in the generative tool AToM3. We use theFinite State Machinesmodelling language as a concise running example. Our approach leverages acorrect by constructionphilosophy that renderssubsequent simulation of models considerably less error-prone.

Index Terms

Meta-model directed editing, Domain-specific modelling language, Structure editor, Partial model, Model completion, AToM3,Alloy

I. I NTRODUCTION

Documents in the form of computer programs, diagrams, chemical formulas, and markup text can currently be editedin document editors calledstructure editors. These structure editors are cognizant of the document’s underlying structuresuch as the grammatical syntax or a formal grammar of the language. Functionally, these structure editors are syntax orlanguage-directed to aid the user by presenting recommendations for completion of code, text, or a diagram based on correctpossibilities prescribed by the underlying structure. This enables faster document development with fewer errors. However,structure editors are separately constructed for each domain-specific language and are built mainly for grammar-basedtextuallanguages. We are interested in the subject of extending structure editors from high-level models built using the principles ofModel Driven Engineering(MDE) [13] where domain-specific model editors are automatically synthesized for a variety ofmodelling languages.

In MDE, given a meta-model specification of a domain-specificmodelling language, software tools can automatically generatedomain-specific model editors. For example, generative modelling tools such asAToM3 (A Tool for Multi-formalism Meta-modelling) [11] [17],GME (Generic Modelling Environment) [3],GMF (Eclipse Graphical Modelling Framework) [21] cansynthesize a domain-specific visual model editor from a declarative specification of a domain-specific modelling language. Adeclarative specification consists of a meta-model and a visual/textual syntax that describes how language elements (objects andrelationships) manifest in the model editor. The designer of a model uses this model editor to construct a model on a drawingcanvas. This is analogous to using an integrated development environment (IDE) to enter a program or a word processor toenter sentences. However, IDEs such asEclipse present recommendations for completing a program statement when possiblebased on its grammar and existing libraries [5]. Similarly,Microsoft Word presents grammatical correction recommendationsif a sentence does not conform to a natural language grammar.Therefore, we ask: Can we extrapolate similar technology ordevelop new technology for partial models constructed in a model editor for a domain-specific modelling language (DSML)?

Extrapolating code completion techniques for model completion is not feasible in the general case. The first reason is thedifference between the underlying structure of code and models. Code completion techniques use the Backus-Naur Form(BNF) grammar of a programming language while models are specified by a meta-model and constraints on it. Second, modelcompletion must consider completing the entire model as constraints can span entire models unlike code completion whichpresents solutions at a program statement level. Third, in terms of reduction in effort model completion must help reducethe effort of a modeller by automatically satisfying all relevant language constraints since in general they may be too hardfor a modeller to resolve manually. The output of model completion must be one or many valid models that conform totheir language. This notion of reduction in effort is different from that in code completion. Code completion presents local

Received 4 May, 2008, Revised 18 Sept, 2008, 22 Mar 2009, Accepted 19 May, 2009Sagar Senis thecorresponding author. Email: ssen@irisa.fr, Postal Address: INRIA Rennes Bretagne-Atlantique, Campus universitaire de beaulieu, Rennes

35042, France, tel : + 33 2 99 84 72 98 fax : + 33 2 99 84 71 71

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 3

suggestions to complete navigational expressions or concept names but it does not perform constraint satisfaction to output avalid program. In the general case, model completion may take more time than code or sentence completion which are almostinstantaneous. Therefore, there is a need to develop new techniques for model completion with different goals such as relaxingthe exigence towards time to complete.

The major difficulty for providing completion capabilitiesin model editors is to integrate heterogeneous sources of knowledgein the computation of the possible solutions for completion. The completion algorithm must take into account the conceptsdefined in the meta-model, constraints on the concepts and the partial model built by a domain expert/user. The difficultyisthat these three sources of knowledge are obviously related(they refer to the same concepts) but are expressed in differentlanguages, sometimes in different files, and in most cases bydifferent people and at different moments in the developmentcycle as they are separable concerns.

In this paper, we propose an automatic transformation from heterogenous sources of knowledge to an ALLOY [10] [20]constraint model. ALLOY is a declarative constraint language based onquantified first-order logicwith support for operators inrelational calculus. The generated ALLOY model is then used to synthesize a set of Boolean CNF formulaewhich are solvedusing an appropriate satisfiability (SAT) solver. The solutions are parsed and transformed from low-level logic and returned ashigh-level models to the model editor as recommendations for completing the partial model. These solutions are shown intheconcrete visual syntax of the modelling language. Our transformation from the different sources to ALLOY is integrated in thesoftware toolAToM3. We selectAToM3 since its has a light-weight python implementation for rapid-prototyping and proof ofconcept. Also,AToM3 supports an easy to use icon editor andDSML generator for rapidly synthesizingDSML visual modellingenvironments from meta-model and visual syntax specifications. A transformation module inAToM3 can also also serializestandard XMI versions of models for use in industry standardtools such as Eclipse GMF. The simple and easy to use Python-API of AToM3 allows fast integration of new features and transformations in modelling languages. A similar implementationin widely used tools such as Eclipse GMF is certainly feasible but will need more programming effort as it is Java-basedwhere one needs experience in using the several interdependent libraries available in the Eclipse platform. Nevertheless, anymodel in theAToM3 environment can be used in the Eclipse GMF environment usingthe standard XMI interchange format.The meta-model for aDSML is built directly in AToM3’s model editor using its class diagram formalism. The constraintson the concepts of this meta-model are defined using ALLOY facts. Using this information and a description of the concretevisual syntax (specified in an icon editor) for a modelling language,AToM3 synthesizes a visual model editor for theDSML.The partial model can be built and edited in the generated model editor and the designer can ask for recommendations forpossible automatic completions. The partial model is automatically transformed to a constraint called an ALLOY predicate.This ALLOY predicate is then augmented to the ALLOY model to give the whole set of constraints. We invoke a solveronthis this set of constraints to obtain zero/one/more complete model(s).

In Section II we present related work. An overview of our methodology is presented in Section III. One of the key partsof our methodology is the automatic synthesis of domain-specific model editors from their specification comprising of themeta-model and visual syntax. This process is described in Section IV. The component that will add model completion abilityto the synthesized model editor is a transformation from themeta-model and partial model to an ALLOY model. We presentthis transformation in Section V. Once we include this transformation into the synthesis of a domain-specific model editorwe are able to synthesize domain-specific model editors withautomatic model completion. We describe the model completionprocess in Section VI. We present examples of model completion recommendations generated for partial models in SectionVII. We conclude in Section VIII.

II. RELATED WORK

Language-directed editors have been around for since the early 1980s. Some of the well-cited research on language-directed editors are Mentor [12], Interlisp [34], Program Synthesizer [33], Rational [6], PECAN [28], and Gandalf [16].Most of the existing language-based editors such as inEclipse are based onattribute grammars[15]. These systems havebeen widely adopted and integrated in many editors for taskssuch as syntax highlighting and syntax-directed editing. TheopenArchitectureWare[1] framework , based on theEcore [14] meta-modelling framework, supports automatic sentencecompletion already implemented in Eclipse to help make recommendations to sentences in textual domain-specific modellinglanguages. These suggestions for sentence completion are based on the textual syntax of the modelling language and do notconsider the complete consistency of the model with respectto the meta-model and constraints of the language.

In Model Driven Engineering(MDE), models built in domain-specific model editors pose a new challenge. The challenge isto complete a partial model specified in the model editor. This involves the editor to use domain-specific modelling languageconstraints to direct the completion of the partial model. Simply put, this involves constraint solving using knowledge describedin the partial model to synthesize a model that conforms to the domain-specific modelling language. Constraint solving formodel synthesis has been well-studied in the literature such as model design space exploration [31], partial model completionusing Prolog [29] and constraint logic programming [22]. In[30] we present a model completion system in a domain-specificeditor by combining knowledge from the meta-model and the partial model specified in the model editor to SWI-Prolog. TheProlog program is solved using a backtracking based solver to return results to the domain-specific environment which was

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 4

originally synthesized byAToM3 using the meta-model. Our methodology is valid for any domain-specific modelling languagein the limits of first-order Horn clause logic of SWI-Prolog.However, their primary limitation is that the number of objectsin the complete model is equal to the number of objects in the partial model. No new objects are suggested by the modelcompletion system and the user is limited to specifying onlythe correct number of objects in the partial model. This is primarilydue to the fact that constraints are specified at the object property level in SWI-Prolog and not at the meta-level such as onsets of objects.

We identify the need to develop a model completion system that can automatically suggest complete models especially forDSML meta-models containing constraints both on sets of objectsand their properties. This typically involves mapping of ameta-model and constraints basedDSML specification to a mathematical formalism with tool supportthat solves constraints togive correct instances of theDSML. Notably, such instances should contain the network of objects (original object identitiesneed not be preserved) specified in the partial model and additional objects (if required) with appropriate property values suchthat the complete model conforms to itsDSML. We would also like to control the maximum size or scope of thecompletemodel for practical time considerations. Transformation of meta-models expressed in UML/OCL [27] to various formal systemsis not new [9] [4] [19] [24] [2] [8] [23]. In [9] the authors present a transformation from UML Class Diagrams to DescriptionLogics. Their approach is theoretically rigourous where a knowledge base in description logic on its variants is obtained fora UML Class diagram and theorem provers such asFACT [18] and RACER [35] are used to obtain instances by inferringfrom the knowledge base. They prove that the time for inference using a description logic representation of an UML Classdiagram in EXPTIME-complete. However, their approach doesnot support transformation of meta-level constraints suchasthose expressed inObject Constraint Language (OCL) [27] to description logic. An extension of this work for obtaininginstances in finite domain is presented in [24]. The transformation of meta-level constraints such asOCL along with UML classdiagrams to formal higher-order logic language called Isabelle has been explored in tools such as HOL-OCL [2]. Similarly, wehave seen the transformation to constraint programming language ECLiPSE in [19]. Both, these approaches are used primarilyfor verification of a UML Class Diagram instance against theUMLCD meta-model specification. A constraint inOCL can beverified against an instance ofUMLCD but we need the instance itself. In our pursuit to find complete models we need toautomatically synthesize instances of a meta-model ratherthan verifying an arbitrary constraint against an existinginstance.

In our approach, we transform the specification of a domain-specific modelling language and the partial model to thecommon language of first-order relational logic. The targetcommon language is implemented in ALLOY . Transformation of ameta-model specification from UML to ALLOY has previously been explored in the toolUML2Alloy [8] [23] [7]. UML2Alloysupports transformation from meta-model concepts to ALLOY model concepts such as class to signature, property to signaturefield, operation to function, enumeration/enumeration literal to extends signature, and constraints to predicates. In our approachto transforming a meta-model to an ALLOY model we keep the same transformation format such we transform classes tosignatures and properties to class fields. InUML2Alloy composition and aggregation are transformed first toOCL constraintsand then to ALLOY . In our tool we transform composition and aggregation in a meta-model directly to ALLOY facts. Our,approach to transforming inheritance is the same as inUML2Alloy. Inheritance is transformed to an ALLOY signature thatextends an other ALLOY signature. There is no clear specification inUML2Alloy related articles [8] [23] [7] about transformingmultiplicities to ALLOY . In our case we transform multiplicity constraints to ALLOY signature fields in case of occurrence of0, 0..1, or 0..∗ multiplicities. If the multiplicity is variable such asa..b we synthesize an ALLOY fact constraining the sizeof a set of relations. The constraints in meta-model is restricted to a small subset ofOCL as UML2Alloy transforms onlythis subset ofOCL to ALLOY . However, in our tool we propose the user to directly enter ALLOY predicates and facts in theALLOY model giving the user the flexibility of expressing a wider range of constraints (those that have not been implementedin UML2Alloy) such constraints with transitive closure which cannot be expressed directly inOCL. We also present a methodto synthesize ALLOY predicates from a partial model. This use of partial knowledge to synthesize complete models greatlyreduces model development time. The toolUML2Alloy, does not support the use of partial model knowledge to help generatemodels.

III. M ETHODOLOGY OVERVIEW

The development and use of a domain-specific model editor with automatic model completion can be divided into thefollowing phases and sub-phases:

1) Specification of a domain-specific modelling language (inAToM3)a) Specification of a meta-model

i) Specification of a class diagram (AToM3 class diagram in our case)ii) Specification of facts on the concepts in the class diagram (ALLOY facts in our case)

b) Specification of a visual syntax in an icon editor (available in AToM3) for concepts in the meta-model2) Transformation of meta-model and visual syntax to a modeleditor

a) Synthesis of an editor with buttons, menus and iconsb) Synthesis of a drawing canvas with features such as automatic layoutc) Synthesis of a clickable widget for model completion

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 5

d) Synthesis of a dialog box for specifying model completionparameters

3) User interaction

a) Drawing a partial model on the canvasb) Editing model completion parametersc) Click on a button to generate complete model(s)

4) Model Completion (hidden from user)

a) Synthesis of base ALLOY model from theAToM3 class diagram.b) Augmenting meta-model facts with base ALLOY modelc) Synthesis of an ALLOY predicate from partial model and augmentation to base ALLOY modeld) Synthesis of run commands from the model completion parameters and augmentation to current ALLOY modele) Solving final ALLOY model and returning complete models as recommendations to the model editor

The specification of a domain-specific language is usually done by alanguage designerwho interacts with domain expertsto identify the concepts, their properties and relationships in a domain of knowledge, science or engineering. The languagedesigner also develops a repository of constraints among the concepts and its properties. The assembly of the concepts andrelationships is expressed as aClass Diagram (CD) by the language designer. In our methodology we use theAToM3 CDformalism for this purpose. The constraints on theCD are expressed in a formal constraint language. Preferably,a constraintlanguage that has a finite number of solutions and is decidable. In our methodology we usefacts expressed in the languageALLOY to represent such constraints. TheCD and the set of constraints on it results in themeta-modelof a Domain-specificModelling Language (DSML)

A visual syntax designerspecifies a concrete visual syntax for the concepts and relationships in the modelling language. Inour methodology we use theAToM3 icon editor to specify a visual syntax. In Section IV we discuss in detail the specificationof the modelling language forFinite State Machines (FSM) along with a visual syntax.

Once we have all the elements (meta-model and visual syntax)necessary for a domain-specific modelling language amodeltransformation engineerdevelops a transformation to synthesize a visual domain-specific model editor from these elements.The model editor consists of buttons, menus, and a canvas. A user can select and drop objects on a drawing canvas and connectthem using relationships. The objects are manifested as icons as specified in the icon editor for the concrete visual syntax bythe visual syntax designer. The relationships are links between these icons. In the model editor by clicking on the icon theuser can edit or specify the values of properties.

In our work, we extend this model transformation by transforming the meta-model to an ALLOY model. The transformationalso synthesizes a button widget in the domain-specific model editor. A domain expertor usercan click on this button resultingin the solving of the ALLOY model augmented with ALLOY predicates synthesized from the partial model drawn on the canvas.Recommendations as one or more complete models (if found) are returned to the model drawing canvas. In Section V wepresent the transformation from the meta-model and the partial model to ALLOY . An illustrative outline of the model completionmethodology is shown in Figure 1.

One of the key benefits in using ALLOY is its ability to handle constraints specified on a set of objects using quantifierssuch assome, all, one, and lone. The new system allows us to synthesize models with new objects (if required) to ensurethat the complete model is consistent with its meta-model which normally contains quantified constraints on sets of objects ofdifferent classes. The solver finds the closest complete model in a given scope and returns the result as a recommendationformodel completion.

The methodology described in the paper supports any meta-model with the following characteristics:

• With classes containing attributes of the basic typesInteger, String, andBoolean• With classes containing references with variable multiplicities such asa..b to other classes in the meta-model• Constraints on the concepts in the meta-model that are expressible as ALLOY facts and predicates. These facts and

predicates are constraints in first-order relational logicwith quantifiers.

We currently do not support floating-point attributes in meta-models. Although such properties can be approximated asintegers. We also do not support the entire range of characters in unicode for string attributes. We either model stringsas asequence of characters or as an integer value. Higher-orderconstraints where a constraint is specified on another constraintis not supported. In a constraint language such as ALLOY this transforms to the expression of the unsupported higher-orderrelations (a tuple of relations) instead of supported first-order relations (a tuple of atoms).

IV. SPECIFYING A DOMAIN -SPECIFICMODELLING LANGUAGE

In this section we explain the steps taken to declaratively specify a domain-specific modelling language. We useFinite StateMachines (FSM) as a running example for a modelling language. TheFSM modelling language is a visual language withcircles representing states and directed arrows representing transitions between states. To define a modelling language and togenerate a visual model editor from it requires three inputs:

1) A Meta-model as anAToM3 Class Diagram (CD)

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 6

TABLE I

DOMAINS FOR PRIMITIVE DATATYPES

Type Domain

Boolean {0, 1}

Integer {MinInt, .., MaxInt}

String {”a”, ”b”, “c”, ”event1”, .., }

2) A Set ofAlloy Facts on the concepts in theCD3) A Visual SyntaxWe briefly describe the specifications of these aspects of theFSM language in the following sub-sections.

A. Meta-model

A model consists of objects and relationships between them.The meta-model of the modelling language specifies the typesof all the objects and their possible inter-relationships in a specific domain. The type of an object is referred to as aclass.The meta-model for theFSM modelling language is presented in Figure 2. The classes in the meta-model areFSM, StateandTransition.

In this paper we use theClass Diagram formalism inAToM3 for specifying a meta-model. TheClass Diagram formalismcan specify itself and hence exhibits the property ofbootstrapping. We use the visual language notation of class diagrams tospecify the meta-model for theFSM modelling language in Figure 2.

Each class in the meta-model hasproperties. A property is either anattribute or a reference. An attribute is of a primitivetype which is eitherInteger, String, or Boolean. For instance, the attributes of the classState are isInitial and isFinal bothof which are of primitive type Boolean. An example domain of values for the primitive attributes is given in Table I. TheString variable can be a finite set consisting of a null string, and finite length strings that specify a set of strings. In this paper,we consider a finite domain for each attribute.

Describing the state of a class of objects with only primitive attributes is not sufficient in many cases. Modelling manyreal-world systems elicits the need to model complex relationships such as modelling that an object contains another set ofobjects or an object is related to another finite set of objects. This set of related objects is constrained by amultiplicity. Whena class is related to another class, the related classes refer to each other viareferences. For instance, in Figure 2 the classesState andTransition refer to each other via references annotated with unidirectional relationships. The multiplicity constraintsare also annotated with the relationship.

Containmentrelationships exist between theFSM class and theState andTransition classes. The black-fill ended arrow atthe FSM Class signifies that all objects of typeState andTransition are always inside anFSM object. There is exactly oneFSM object that contains allState andTransition objects.

Apart from attributes and references, objects can inherit properties from other classes. The attributes and references of aclass called asuperclassare inherited bysubclasses. Similarly, a subclass inherits the references in the superclass. There is noinheritance in ourFSM meta-model, nevertheless we consider transformation of inheritance relationships in the transformationpresented in Section V.

B. Constraints on Meta-model

Constraints on a meta-model are not always conveniently specified using diagrams such asCDs. They are better expressedin a textual constraint language who’s semantics have no side-effect (does not change the state of an object or structureof themodel) on the meta-model or its instances (models). TheOMG standard for constraint specification is theObject ConstraintLanguage (OCL); however, in our current work we use first-order relationallogic statements in the form of ALLOY facts. Inthis paper, we transformOCL constraints to ALLOY manually. In future, we intend to transform a subset ofOCL to ALLOY

using an automatic model transformation. This is a challenging task asOCL and ALLOY are very different in terms of whatthey express.OCL is a query language with no side-effects while ALLOY enforces certain values on objects and propertiessuch that facts are always satisfied (if consistent).OCL is a language in higher-order logic without a thoroughly well-definedsemantics. ALLOY on the other hand is a first-order relational logic language with quantifiers that has well-defined semanticsfor analysis. Bridging this gap in expressiveness is the hurdle in completely automating theOCL to ALLOY transformation.Therefore, we directly present ALLOY facts specified on a meta-model’s objects and properties. A brief introduction to theALLOY language is given in Section V-A.

In Table II we present the constraints on theFSM meta-model in natural language and as ALLOY facts.The ALLOY signatures [10] used to specify the ALLOY facts are extracted from theFSM meta-modelCD. This transformation

is discussed in Section V. In the appendix we present the complete ALLOY model for theFSM modelling language. ThisALLOY model can be loaded into the ALLOY Analyzer [20] for directly obtaining validFSM models.

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 7

TABLE II

CONSTRAINTS IN NATURAL LANGUAGE AND AS ALLOY FACTS

Constraint Name and Definition Alloy FactexactlyOneFSM: There must be exactlyoneFSM object in aFSM model fact exactlyOneFSM

{one FSM

}

atleastOneFinalState: There must be atleast one final state in aFSM model fact at leastOneFinalState

{some s:State|s.isFinal==True

}

exactlyOneInitialState : There must beexactly one initial state in theFSM model fact exactlyOneInitialState

{one s:State|s.isInitial==True

}

sameSourceDiffTarget : All transitionswith the same source must have differenttarget

fact sameSourceDiffTarget{

all t1:Transition,t2:Transition|(t1!=t2 and t1.source==t2.source) =>t1.target!=t2.target

}

setTargetAndSource : The target of anincoming transition to aState itself andthe source of all its outgoing transitions isthe sameState

fact setTargetAndSource{all s:State |s.incomingTransition.target = s ands.outgoingTransition.source=s

}

noUnreachableStates: There can be nounreachable states in theFSM from aninitial state. Since, its a ternary constraintwe approximate it by stating that a non-initial state can be reached from an initialstate up to a maximum depth of N (N=3is the given example).

fact noUnreachableStates{all s:State| (s.isInitial==False) =>#s.incomingTransition >=1 and(s.isInitial==True and #State > 1) =>#s.outgoingTransition >=1 ands.outgoingTransition.target!=s

}

uniqueStateLabels : All State objectshave unique labels fact uniqueStateLabels

{#State>1 => all s1:State,s2:State |s1!=s2=>s1.label != s2.label

}

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 8

C. Visual Syntax

The final step (in specifying aDSML for synthesizing a model editor) we take is to specify the concrete visual syntax ofthe class of objects in the meta-model. The visual syntax specifies what an object looks like on a 2D canvas. An icon editorin AToM3 is used to specify the visual syntax of the classes in the meta-model.

An icon editor is used to specify the visual syntax of meta-model concepts such as classes and relationships. The icon forState is a circle annotated with three of its attributes (isFinal, isInitial, and label). The connectors in the diagram are pointsof connection betweenState objects andTransition objects.

The visual syntax can also by dynamically changed based on the properties of the model. In an iconic visual modellinglanguage such asFSM, the first step taken in specifying a visual syntax is drawingan icon that represents a class of objects.If needed it is annotated with text and its properties. Connectors are added to the visual object so that it can be connected toother objects if they are related.

V. TRANSFORMATION FROMMETA-MODEL AND A PARTIAL MODEL TO ALLOY

The transformation of a meta-model consists of transforming theClass Diagram of a domain-specific modelling languageto ALLOY signatures and specification of other constraints as ALLOY facts. We first describe ALLOY and then explain ourtransformations using relevant examples in the following sections.

A. TheALLOY Language

We present ALLOY [20] [10] as a common constraint language equipped with a solver to help complete partial models. Itis founded on quantified first-order logic with support for operators in relational calculus. The domain of a constraint modelin ALLOY is given by a set of types called signatures. These signatures may contain a number of fields. Constraints may beadded as facts or predicates to the ALLOY model to express additional invariants. ALLOY can be used to perform two kinds ofanalysis. First, we can solve a predicate to generate model instances that satisfy the facts in an ALLOY model. Second, we canuse ALLOY to generationcounter-examplesfor assertions that we assume to be true. These, analyses rely on the small scopehypothesis ( [10]): only a finite subspace is searched based on the assumption that if there is an instance or a counterexamplethere is one of small size. The rest of the article contains several commented or described ALLOY listings to give the readera better intuition of the language.

B. Transformation of a Class Diagram

The transformation of a class diagram consists of the transformation of a class and its properties, transformation of themultiplicity constraints in the class diagram to ALLOY facts, transformation of containment constraints to ALLOY facts andfinally the transformation of inheritance to an ALLOY extends relationship between ALLOY signatures. This results in a baseALLOY model. We discuss these transformations in detail below.

1) Class and its Properties:A class is transformed to an ALLOY signature. Consider theState class in theFSM meta-modelin Figure 2. This class is transformed to the following ALLOY signature:

sig State{

label: Int,outgoingTransition: set Transition,incomingTransition: set Transition,fsmCurrentState: one FSM,fsmStates: one FSM,isFinal:one Bool,isInitial:one Bool

}

The class containspropertieswhich are eitherattributesor referencesto other objects. We see how these properties aretransformed to ALLOY using ourState class example. Theattributes of the class are transformed tofields in the ALLOY

signature. For instance, thelabel attribute of theState class is transformed to an ALLOY field of type Int. The ALLOY

implementation contains a built-in implementation for thedefinition of integers (Int) for which a domain size can be set usinga bit length. The attributesisFinal and isInitial are set as fields of typeBool (boolean values). ALLOY also contains a built-inimplementation ofBool. There are several operations defined on theBool and Int types in ALLOY which allow us to specifyseveral complex constraints on such properties. An attribute of typeString is transformed to aString type we define as followsin ALLOY :

abstract sig Character{}one sig A extends Character {}

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 9

one sig B extends Character {}...sig String

{content : seq Character

}

First, we describe an abstract signatureCharacter and characters such asA,B,C,D,... that inherit fromCharacter. However,the language in ALLOY prevents the use of digits. A substitute will be to use D1, D2,... for the digit 1,2,... respectively. AString signature is now defined as a sequence of characters. In this paper, we consider integers as simplified abstractions forstrings and replace all possible string types to integers. After all, characters have a numerical encoding in a computer. Tospecify constraints onString objects also requires the specification of ALLOY functions on theString class.

The referencesof a class are also transformed to fields in the ALLOY signature of its containing class. For instance, in theState object the referencesoutgoingTransitionand incomingTransitionare transformed to an ALLOY field expressing a set ofTransition instances. Thesetkeyword indicates that there can be0..∗ Transition objects related to theState object. The otherquantifiers likeset are onemeaning exactly one andlone meaning0..1 objects. For instance, the referencefsmStatesto oneFSM object indicates that there must be exactly one containerFSM for all State objects.

2) Multiplicity: If we want to specify a reference to a set of objects with multiplicity betweena andb number of objectswe synthesize an ALLOY fact. For instance, if we want to specify that aState object has at least 3 and at most 7Transitionobject references as incoming transitions, we synthesize the following fact:

fact multiplicity_incomingTransition{#State.incomingTransition >=3 and #State.incomingTransition<=7

}

3) Containment:We synthesize an ALLOY fact from a containment relation between two classes. For example, the fact thatall Transition objects are contained in theFSM object is expressed as the following ALLOY fact:

fact containmentTransition{Transition in FSM.transitions

}

All Transition objects in a complete model of theFSM modelling language now have a containment relation with thetop-levelFSM object.

4) Inheritance: Inheritance between a superclass and subclass in a meta-model is transformed to anextendsrelation. Thecurrent FSM meta-model used as a running example in the paper does not contain an inheritance relationship. However,imagine a meta-model with an abstract classAbstractState which is inherited by two subclassesState andComposite. Wefirst synthesize anabstractsignature for theAbstractState class such as:

abstract sig AbstractState{label: Int,outgoingTransition: set Transition,incomingTransition: set Transition,container: lone Composite,fsmCurrentState: one FSM,fsmStates: one FSM

}

The State class which inherits from thisAbstractState class looks like:

sig State extends AbstractState{isFinal: one Bool,isInitial: one Bool

}

The attributes isInitial and isFinal attributes are transformed to fields in ALLOY . The field isFinal : one Bool implies that allState objects have an isFinal property that can be either True or False. Similarly, the isInitial field in allState objects can beeither True or False. These fields model an intial state, finalstates, and regular states in anFSM.

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 10

C. SpecifyingALLOY facts on the Meta-model

We specify ALLOY facts using the names of the classes and properties on theAToM3 class diagram in a text-box calledTextual Meta-informationin the meta-modelling language canvas. The specification offacts in ALLOY is possible because theALLOY model we generate from theAToM3 class diagram preserves the names of classes and propertiesenabling the use ofthe ALLOY constraint language for specification of constraints on themeta-model. All the facts in Table II are specified on theFSM class diagram. During the model completion process these facts are augmented to the base ALLOY model. This gives usa complete description of the meta-model.

D. Transformation of a Partial Model

We define a partial model as a graph of objects such that: (1) The objects are instances of classes in the modelling languagemetamodel (2) The partial model either does not conform to the language metamodel or its invariants expressed in a textualconstraint language. A complete model on the other hand contains all the objects of the partial model and additional objectsor property value assignments in new/existing objects suchthat it conforms both to the metamodel and its invariants.

A partial model, such as in Figure 3 (a), isautomaticallytransformed to a set of ALLOY predicates by navigating it objectby object in the canvas. We navigate all objects of a certain type and put them together as an ALLOY predicate. We want tokeep the already specified properties for each object in the partial model but also allow for extensibility. For instance, for alltheState objects in the partial model of Figure 3 (a) we create an ALLOY predicate as shown in the first predicate of Figure 3(b). The ALLOY predicate states that there exists at least oneState object s1, at least oneState object s2, at least oneStateobject s3, at least oneState object s4 (representing the fourState objects in the partial model), at least oneTransition objectt1, and at least oneTransition object t2 such that s1,s2,s3,s4 are not equal and t1,t2 are not equal. The predicate also statesthat theTransition objects t1 and t2 are in the set of outgoing transitions forState object s1.Transition object t1 is in theset of incoming transitions of s1. TheTransition object t2 is in the set of incoming transitions of s2. These sets are open forinclusion of newTransition objects. These predicates preserve all knowledge coming from the partial model while allowingthe extension to relations to more objects.

We present a procedure to describe the transformation from the partial model to a set of ALLOY predicates below:The following represents the procedure to synthesize an ALLOY predicate from a partial model1) We start by synthesizing the header of a partial model:

pred partialModel {

2) For all objects ofoij of type Classj in a partial model we synthesize an ALLOY expression:someoij : Classj , ... |

3) For all objects ofoij of type Classj and all objectsokj of type Classj in a partial model we synthesize an ALLOY

expression:oij ! = okj , each expression separated byand

4) For all defined attributesaijk of oij we synthesize the expression:oij .aijk = v, wherev is the specified value separated by commas

5) For all defined referencesrijk of oij we synthesize the expression:v in oij .rijk, wherev is the object in the set of referred objects separated by commas

6) We finish the predicate by closing the brace.

E. TransformingALLOY Model Completion Parameters

The user is provided with a dialog box to insertmodel completion parameters. Model completion parameters include finitescopes such as the upper bound on the number of objects of any class, or the upper-bound on the number of objects for eachclass, or the exact number of objects for each class, or a mixture of upper bounds and exact number of objects for differentclasses. The default scope is number of objects in the partial model. An other parameter is the number of solutions requiredS. This information is used to synthesize an ALLOY run commandthat is finally inserted in the ALLOY model. For example,if the partial model predicate is calledpartialModel1and the user states that he wants exactly one object of class A, up to 10objects of class B, and a scope of 5 for integers then the following run statements is synthesized:

run partialModel1 for exactly 1 A, 10 B, 5 Int

If the number of objects in the partial model is N, then the default run command the editor generates is:

run partialModel1 for N

VI. M ODEL COMPLETION PROCESS

The model completion process integrated in the domain-specific model editor takes as input theAToM3 class diagram,augmented ALLOY facts, and a partial model drawn in the model editor synthesized from the class diagram of a modelling

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 11

language, and set of parameters to define the scope of the complete models to be synthesized. The process is invoked when auser draws a partial model in the modelling canvas and clickson theGenerate Completion Recommendationsbutton.

The following steps are executed during the completion process:1) An ALLOY model (ALS) file is synthesized containing the signature definitions of the classes in theAToM3 class diagram

and the facts corresponding to the multiplicity and containment constraints as described in Section V-B2) The modelling language facts are augmented to the ALLOY model. These facts are specified as described in Section V-C3) The partial model drawn in the model editor canvas is transformed to a predicate as described in Section V-D and

augmented to the current ALLOY model4) The model completion parameters are transformed to a run command (See Section V-E) and augmented to the ALLOY

model giving us an adequate description for model completion.5) An ALLOY API call is made to load the ALLOY model, parse it and store signatures, facts, predicates, run command as

objects in memory.6) An ALLOY API call is made to transform the first-order relational logic signatures, facts, predicates and model completion

parameters to a finite Boolean CNF.7) We then use the ALLOY API to invoke a third-party SAT solver such as ZChaff [36] or Minisat [25] [26] to solve the

Boolean CNF.8) If a solution exists, then it is stored as an XML file. If a number of solutions (given by model completion parameterS)

are required then we attempt to produceS solutions and store them in XML Files.9) The editor then loads and parses these XML files. The complete model recommendations are presented in the domain-

specific model editor in their concrete visual syntax. The user can click onNext to scan through all possible completions.The results of model completion are also stored as model filesrepresenting graph structures in a temporary directory.They can be loaded into the model editor when required or usedby another program for transformation.

It is important to note that the partial model is specified as asource of knowledge about what objects and properties thatthe user wants to absolutely see in the complete model. In thecomplete model we can see the intact contents of the partialmodel. However, the object identifiers of the partial model are not preserved in the complete model. We also do not performpattern matching to identify the original partial model in the complete model, although such a mechanism can be incorporatedif needed. In the default case we find the nearest-consistentcomplete model(s) to a given partial model.

If a solution is not found the ALLOY API returns ano solution found exceptionto AToM3 (the invoker). We show thisresult in a dialog box in theAToM3 environment. In our work we do not debug a partial model to findthe exact source ofinconsistency. This incurs a computational cost and time aswe need to check every partial model predicate expression againstthe meta-model constraints to see which characteristics ofthe partial model leads to an inconsistency. We leave it to the userand depend on his/her expertise of theDSML to identify the inconsistent part of the partial model and correct it.

VII. E XAMPLES

In this section, we consider four examples of partial modelsin the FSM modelling language. The examples are shown inFigure 4 (a), 4 (b), 4 (c) , 4 (d) respectively. The synthesized predicates for these models are shown in Figures 4 (e), 4 (f)and 4 (g) , 4 (h). The example in Figure 4 (a) contains only oneState object with none of the properties having been set.The example in Figure 4 (b) contains twoState objects and aTransition object not connected. In Figure 4 (c) we considera more complex model with severalState andTransition objects with some properties set and some not. Finally, in Figure 4(d) we present a model containing at least twoState objects withisInitial set to True.

We perform the model completion of these models using two methods of setting parameters for completion:• Scope: Here we specify a scope as a model completion parameter. Thescope is a unique number that defines the maximum

number of objects for all concepts in the meta-model. We choose the default scope to be 10. The corresponding ALLOY

run statement generated is:pred partialModel {}run partialModel for 10

The partialModelpredicate is empty and is simply used to obtain a complete model instance. We solve for up to a scopeof 10 objects for each concept in the meta-model.

• Exact Number and/or Scope: Another mechanism to complete a model is to specify the exact number of objects and/orscope for objects we expect in the complete model.

pred partialModel {}run partialModel for exactly 1 FSM, exactly 5 State,exactly 10 Transition, 5 int

Here we find a solution for a partial model containing exactly1 FSM object, exactly 5State objects, exactly 10Transitionobjects. Finally we set a bit-width for integers which is 5. This means that all integers range between−25 to 25.

All the above parameters were initially set in the synthesizedAToM3 modelling environment. The user is only exposed to thegraphical syntax of the concepts in the meta-model and with atext-box to specify the exact number of objects or a scope. The

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 12

TABLE III

MODEL COMPLETION T IMES

Partial Model Description(I=Inconsistent)

T imeScope (s) T imeExact T imeScopeScaled T imeExactScaled

Fig. 4 (a) Only oneState ob-ject with no proper-ties specified

1.283 0.447 118.045 32.002

Fig. 4 (b) Two State objectsand one Transitionobject

1.289 0.496 115.994 31.488

Fig. 4 (c) Several State andTransition objectswith some propertiesspecified and somenot

1.315 0.575 11.4301 32.517

Fig. 4 (d) Several State andTransition objectswith two initialState objects

1.291 (I) 0.402 (I) 111.352 (I) 31.734 (I)

model completions were performed on a Macbook Pro laptop with an Intel Core 2 Duo processor running at 2.6 GHz clockspeed and with 2 GB of RAM. We use the ALLOY analyzer API to invoke the SAT solver Minisat [25] [26] from ChalmersUniversity to solve the Boolean CNF synthesized from the ALLOY model. The time to obtain the solutions for the four partialmodels for the completion parameters is presented in Table III.

We show the complete models themselves in Figure 5 with a scope of 10. Normally, there is more than one solution toa model completion. We show one of the possible solutions. Wedo not show that the complete models synthesized for theexact number of objects due to large size of the models. However, it is interesting to note in Table III that the time taken tosynthesize models with the exact number of objects specifiedfor each class is a lot faster even though the models are larger.This is because the additional knowledge about the number ofobjects makes the search space of the models much smaller,therefore allowing us to obtain a solution faster.

The complete model in Figure 5 (a) satisfies all the meta-model constraints such that the singleState label has a unique value7. There is at least one final state and exactly one initial state. In addition, the complete model contains aTransition objectof the State to itself with an event 7. This new object added to the complete model does not violate any of the knowledgealready present in the partial model.

The second complete model in Figure 5 (b) originally was a partial model with twoState objects and aTransition object.The complete model now contains two finalState objects and exactly one initialState object. There is also an inclusion ofa Transition object in the complete model. The synthesized model conforms to all meta-model constraints.

The third complete model in 5 (c) contains a complex partial model with additional objects that preserve the knowledgein the partial model. We can scale up to a model with several hundred atoms using ALLOY to obtain results in a reasonableamount of time (for online user interaction with the modelling environment). An atom consists of any non-divisible entity inthe ALLOY model. This includes objects and their properties connected via relations.

The fourth partial model in 4 (d) consisted of two initialState objects which is not permitted by the meta-model constraintwhich states that theFSM meta-model must contain only one initialState object. Therefore, the SAT solver was unable tofind a complete model that could take into account the partialmodel.

A. Scalability Concerns

In this section we address the question of scalability in ourapproach. We identify two forms of scalability:

1) Scalability in the size of the meta-models such as in the number of classes, properties and complexity of constraints.2) Scalability in the size of the models that conform to a meta-model.

We first consider the scalability of aDSML meta-model. A meta-model can be scaled in terms of the concepts in the classdiagram. This includes number of classes, number of attributes in a class, and number of references in a class. We can alsoscale the implicit constraints in the meta-model class diagram such as number of inheritances, containment relations,and rangeof multiplicities. Finally, we can scale a meta-model basedon the number of facts and arity of each fact on the concepts inthe meta-model and the coupling between these constraints.We cannot define the notion of scalability as an increase in the

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 13

number of classes or attributes to observe greater time to solve. This is because change in constraints on classes and attributescan also lead to higher solution times. Even a simple language such asFSM contains some hard to solve constraints such asnoUnreachableStates. This constraint states that any non-initial state will have to be connected to the initialState via at mostthree transitions. This is a finite approximation of the constraint that there can be no unreachable states in anFSM. The timetaken to solve the partial model increases considerably if we increase the depth to 5. The scaled constraint is:

fact noUnreachableStates{

all s: State | (s. isInitial == False) =>all inc1 : s.incomingTransition |inc1.source.isInitial = True orall inc2 : inc1.source.incomingTransition| inc2.source.isInitial = True orall inc3 : inc2.source.incomingTransition| inc3.source.isInitial = True orall inc4 : inc3.source.incomingTransition| inc4.source.isInitial = True orall inc5 : inc4.source.incomingTransition| inc5.source.isInitial = True

}

The numerical results for model completion are summarized in Table III. In the columnsT imeScope and T imeExact wepresent the time taken to solve a model completion for the unscaled meta-model withnoUnreachableStateshaving a depthof 3. In the columnsT imeScopeScaled and T imeExactScaled we present the time taken to solve a model completion for ascaled meta-model withnoUnreachableStateshaving depth of 5. In general, when the exact number of objects (<= scope) isspecified the time taken to solve a model is less than the time taken for a given scope. This is because, the solver knows inadvance about the number of objects needed to satisfy all requirements in the model. While, when a scope is specified thesolver starts from attempting to solve models with no objects for each signature and incrementally increases the numberofobjects of each signature until a solution is found. The timetaken to solve a partial model for scaled meta-model is about90 times that of time taken to solve a partial model expressedin an an unscaled version of the meta-model. These resultsare obtained by averaging and dividing the values shown in columnsT imeScopeScaled and T imeScope for scope of 10. Forexact values the time taken is about 70 times higher for the scaled version of the meta-model. These results are obtained byaveraging and dividing the results in the columnsT imeExact andT imeExactScaled.

We summarize the discussion on the scalability of our approach to variations in meta-model structure. The scalability ofthis approach cannot be defined based on general rules that increase in the number of classes or properties will increase thetime to find solutions. This we see due to the fact that simply increasing the depth of thenoUnreachableStatesconstraint fora 3 class language such asFSM led to a many-fold increase in solution time. There is a complex inter-dependence betweenthe classes, its properties, constraints on them, and the partial model. A thorough experimental study needs to be performedfor a specific language where each factor such as number of classes, properties, relationships and constraints are varied overseveral ranges of values. This can then give us an idea about how a specific language performs using our approach for modelcompletion. This study is out of the scope of our paper as we propose a first solution applicable to any modelling language.

The scalability of the size of the model instances of a meta-model is the second form of scalability. The question is fora given fixedDSML, what is the largest model we can obtain in a reasonable amount of time? For example, we synthesizea complete model from Partial Model 3 using the parameters: exactly 1 FSM object, exactly 8State objects, exactly 10Transition objects, 5 Int. The solution was found in 72930 ms (= 73 s). Forinteractive model completion 73 s could be toomuch when compared to almost instantaneous code completionin tools such as Eclipse. However, we give the user full controlover the model completion parameters. With experience, he can put the correct number of objects he is looking for in thecomplete model resulting in a faster feedback. When our approach is used for automatic model synthesis such as for automatictest model generation [32] or for design space exploration [31] we pay less attention to instantaneous responses. In these caseswe obtain several hundred or even thousands of complete and effective models through several hours of model synthesis.

Scaling model completion also provides reflective insight into the design of the language itself. A language with constraintsthat are highly constrained or not optimally designed can perhaps take a long time to resolve. However, this does not ruleout the fact that manual creation of the model will be easier for a user of the language. He/she can also be entangled in thecomplexity of the constraint while creating his model. Therefore, automatic model completion also reveals design flawsinmodelling languages that can be corrected in parallel to obtain reasonable completion times.

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 14

VIII. C ONCLUSION

We present a methodology to synthesize domain-specific model editors with meta-model directed model completion fordomain-specific modelling languages. Our goal has been to provide model editors with completion capabilities similar to textor code editors in IDEs such as Eclipse or word processors such as Microsoft Word. A potential future application of ourapproach is generation of test models from partial knowledge. A DSML user draws a partial test model for testing a modeltransformation and subsequently sets model completion parameters. Then he/she clicks on a button to generate completetestmodels that are valid test cases for model transformations.Moreover, the model completions are displayed in the concretevisual syntax of the modelling language while evading all the details in the CNF, XML files, or other intermediate low-levelrepresentations. This aspect of our tool helps reduce the time to develop models in the modelling environment as the useronlyworks in his domain language. The user does not need to manually transform his models to a different constraint language,solve his models and return the results to the editor anymoresince the underlying model completion process is hidden fromthe user. After all, the goal of MDE is to leverage modelling to the highest possible level of abstraction.

Our approach uses a modelling language metamodel , the syntax, and its static semanticsin the form of metamodelconstraints to perform model completion. However, since the presented approach is modelling language independent wedo not considerdynamic semanticsoften realized in a simulator for model completion. Nevertheless, we project severalimplications to simulation as it goes hand in hand with modelling. Model simulators, such as MATLAB/Simulink for causalblock diagrams, often containhard-coded declarative constraints or program statementsthat check and report on the validityof input models during simulation. For example, a causal block diagram simulator analyzes input models to detect cyclesandwarns the modeller. These statements that are integrated insimulator code come from heterogenous sources of knowledgesuch as domain experience, static/dynamic analysis, and testing. This gradual inclusion of model validity knowledge directlyinto simulator code makes them bulky and slow to execute. This approach also obscures the user from potentially usingthis knowledge to build correct models. Extracting knowledge from simulators and developing modelling language invariantsto guide modellers to create invariant-validated models leverages acorrect by constructionphilosophy. Further, using theseinvariants for automatic model completion of partial models makes the modelling and simulation process less error-prone asmodels are first checked and then completed to satisfy invariants before simulation.

Our lightweight approach is effective for small yet useful modelling languages. Time to complete models by the state ofthe art SAT solvers for about 50 objects in the model is not more than a few minutes forFSM. The completion time greatlydepends on the complexityof the DSML. The time taken to obtain complete models also gives us insight about how restricteda DSML is and how it can be relaxed.

As future work we intend to run thorough performance experiments on a specific industry strengthDSML. Such aDSMLwill have a larger meta-model with a several complex constraints. We will limit ourselves to the confines of first-order relationallogic in ALLOY as the language to express constraints. We also wish to enlist the set of detailed requirements to synthesizeDSML modelling environments with completion. For example, an interesting factor is user interaction time. If a complete modelis not returned within a given time then the user can no longermake developments quickly. Other aspects of model completioninclude completion of models when two or more meta-models are involved, expression of partial models as invariants orconstraints, and aiding the user by helping him/her set parameters for model completion.

APPENDIX IALLOY MODEL SYNTHESIZED FROMFSM META-MODEL WITH FACTS AND PARTIAL MODEL PREDICATES

module metamodelFSM

open util/boolean as Bool

sig FSM{states:set State,currentState: lone State,transitions: set Transition

}

sig State{label: Int,outgoingTransition: set Transition,incomingTransition: set Transition,

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 15

fsmCurrentState: one FSM,fsmStates: one FSM,isFinal:one Bool,isInitial:one Bool

}

sig Transition{event: Int,target: one State,source: one State,fsmTransitions:one FSM

}

//Meta-model constraints//

//Exactly one initial statefact exactlyOneInitialState{one s:State|s.isInitial == True

}

//Atleast one final statefact at leastOneFinalState{

some s:State | s.isFinal == True}

//Exactly one HFSMfact exactlyOneFSM{one FSM

}

fact sameSourceDiffTarget{all t1:Transition,t2:Transition| (t1!=t2 and t1.source==t2.source) =>t1.target!=t2.target

}

fact setTargetAndSource{all s:State| s.incomingTransition.target = s ands.outgoingTransition.source=s

}

fact noUnreachableStates{all s: State | (s. isInitial == False) =>all inc1 : s.incomingTransition |inc1.source.isInitial = True orall inc2 : inc1.source.incomingTransition| inc2.source.isInitial = True orall inc3 : inc2.source.incomingTransition| inc3.source.isInitial = True

}

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 16

fact uniqueStateLabels{#State>1 => all s1:State,s2:State | s1!=s2=>s1.label != s2.label

}

fact containmentState{State in FSM.states

}

fact containmentTransition{Transition in FSM.transitions

}

//Partial Model Facts

//Partial Model 1

pred partialModel1_Fact{some State

}

//Partial Model 2

pred partialModel2_Fact{some s1:State,s2:State,t1:Transition |s1!=s2 andt1 in s1.outgoingTransition and t1 ins2.incomingTransition

}

//Partial Model 3

pred partialModel3_Fact{some s1:State,s2:State,s3:State,s4:State,t1:Transition, t2:Transition|s1!=s2 and s2!=s3 and s3!=s4 and s1!=s3 ands1!=s4 and s2!=s4 and t1!=t2 andt1 in s2.incomingTransition and t2 ins3.incomingTransition and t1 in s1.outgoingTransitionand t2 in s1.outgoingTransition ands2.isInitial = True and s4.isFinal = True

}

//Partial Model 4

pred partialModel4_Fact{some s1:State,s2:State,s3:State,s4:State,t1:Transition,t2:Transition|s1!=s2 and s2!=s3 and s3!=s4 and s1!=s3 ands1!=s4 and s2!=s4 and t1!=t2 andt1 in s2.incomingTransition and t2 ins3.incomingTransition and t1 in s1.outgoingTransition

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 17

and t1 in s1.outgoingTransition ands2.isInitial=True and s3.isInitial=True

}

run partialModel1_Fact for 10run partialModel2_Fact for 10run partialModel3_Fact for 10run partialModel4_Fact for 10run partialModel1_Fact for exactly 1 FSM, exactly 5 State,exactly 5 Transition, 5 intrun partialModel2_Fact for exactly 1 FSM, exactly 5 State,exactly 5 Transition, 5 intrun partialModel3_Fact for exactly 1 FSM, exactly 5 State,exactly 5 Transition, 7 intrun partialModel4_Fact for exactly 1 FSM, exactly 5 State,exactly 5 Transition, 5 int

ACKNOWLEDGMENT

We thank the ANR Domino and European S-Cube Projects for research funding.

REFERENCES

[1] http://www.openarchitectureware.org/.[2] A. D. Brucker and B.Wolff. The HOL-OCL book. Technical Report 525, ETH Zurich, 2006.[3] A. Ledeczi, A. Bakay, M. Maroti, P. Volgyesi, G. Nordstrom, J. Sprinkle, and G. Karsai. Composing Domain-Specific Design Environments.Computer,

pages 44–51, November 2001.[4] A. Queralt and E. Teniente. Reasoning on UML class diagrams with OCL constraints.Lecture Notes in Computer Science ER 2006, Springer-Verlag,

4215:497512, 2006.[5] Andrew J. Ko, Htet Htet Aung, and Brad A. Myers. Design requirements for more flexible structured editors from a study of programmer’s text editing.

In CHI 2005, 2005.[6] Archer J.E. Jr. and Delvin M.T. Rational’s experience using Ada for very large systems. InThe First International Conference on Ada Programming

Language Applications for the NASA Space Station, pages B.2.5.1–B.2.5.11, Houston, Texas, NASA, June 1986.[7] Behzad Bordbar and Kyriakos Anastasakis. Mda and analysis of web applications.In Trends in Enterprise Application Architecture (TEAA) inLecture

notes in Computer Science, Trondheim, Norway, 3888:44–55, 2005.[8] Behzad Bordbar and Kyriakos Anastasakis. Uml2alloy: A tool for lightweight modelling of discrete event systems. InNuno Guimares and Pedro Isaas,

editors,IADIS International Conference in Applied Computing, volume 1, pages 209–216, Algarve, Portugal, 2005. IADIS Press.[9] D. Berardi, D. Calvanese, and G. D. Giacomo. Reasoning onUML class diagrams.Artificial Intelligence, 168:70118, 2005.

[10] Daniel Jackson.Software Abstractions: Logic, Language, and Analysis. MIT Press, March 2006.[11] Juan de Lara and Hans Vangheluwe. Atom3: A tool for multi-formalism modelling and meta-modelling.In Lecture Notes in Computer Science, number

2306, pages 174–188, 2002.[12] Donzeau-Gouge, V. Huet, G. Kahn, and Lang B.Interactive Programming Environments, chapter Programming environments based on structured editors:

The Mentor experience, pages 128–140. McGraw-Hill, New York, 1984.[13] Robert France and Bernhard Rumpe. Model-driven development of complex software: A research roadmap,. InFOSE ’07: 2007 Future of Software

Engineering, 2007.[14] Budinsky Frank.Eclipse Modeling Framework, volume 1 ofThe Eclipse Series. Addison-Wesley, 2004.[15] Gail E. Kaiser. Incremental Dynamic Semantics for Language-Based Programming Environments.ACM Transactions on Programming Languages and

Systems, 11(2):169–193, April 1989.[16] Habermann A.N. and David Notkin. Gandalf: Software development environments.IEEE Trans. of Softw. Eng., SE-12, 12:1117–1127, December 1986.[17] Hans Vangheluwe and Juan de Lara. Domain-Specific Modelling with AToM3. In The 4th OOPSLA Workshop on Domain-Specific Modeling, Vancouver,

Canada, October 2004.[18] Ian Horrocks. Using an expressive description logic: FaCT or fiction? In6th International Conference on Principiles of Knowledge Representation and

Reasoning, pages 636–647, 1998.[19] J. Cabot, R. Claris, and D. Riera. Verification of UML/OCL Class Diagrams Using Constraint Programming. InICST Workshop on Model Driven

Engineering, Verification and Validation (MoDeVVa’2008), 2008.[20] Daniel Jackson. http://alloy.mit.edu. 2008.[21] Karsten Ehrig, Claudia Ermel, and Stegan Hansgen. Generation of Visual Editors as Eclipse Plug-ins. InThe 20th IEEE/ACM Internation Conference

on Automated Software Engineering, pages 134–143, 2005.[22] Krysztof R. Apt and Mark G. Wallace.Constraint Logic Programming with ECLiPSe. Cambridge University Press, 2007.[23] Kyriakos Anastasakis, Behzad Bordbar, Geri Georg, andIndrakshi Ray. UML2Alloy: A Challenging Model Transformation. In MoDELS, pages 436–450,

2007.[24] M. Cadoli, D. Calvanese, G. D. Giacomo, and T. Mancini. Finite satisfiability of UML class diagrams by Constraint Programming. InInt.Workshop on

Description Logics (DL2004), CEUR Workshop, number 104, 2004.[25] Niklas Een and Niklas Srensson. An Extensible SAT-Solver. In SAT 2003, 2003.[26] Niklas Een and Niklas Srensson. MiniSat A SAT Solver with Conflict-Clause Minimization, Poster. InSAT 2005, 2005.

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 18

[27] OMG. The Object Constraint Language Specification 2.0,OMG Document: ad/03- 01-07, 2007.[28] Reiss S.P. Graphical program development with PECAN program development systems. InSIGSOFT/SIGPLAN Software Engineering Symposium on

Practical Software Development Environments, pages 30–41, Pittsburg, Pa., April 1984. ACM, New York.[29] Sagar Sen, Benoit Baudry, and Doina Precup. Partial Model Completion in Model Driven Engineering using ConstraintLogic Programming. In

International Conference on the Applications of Declarative Programming, 2007.[30] Sagar Sen, Benoit Baudry, and Hans Vangheluwe. Domain-specific Model Editors with Model Completion. InMulti-paradigm modelling workshop

associated with MoDeLs 2007, Nashville, TN, USA, October 2007.[31] Sandeep Neema, Janos Szitpanovits, and Gabor Karsai. Constraint-Based Design Space Exploration and Model Synthesis. In Proceedings of EMSOFT

2003, Lecture Notes in Computer Science, number 2855, pages 290–305, 2003.[32] Sagar Sen, Benoit Baudry, and Jean-Marie Mottu. On combining mullti-formalism knowledge to select test models formodel transformaion testing. In

ACM/IEEE International Conference on Software Testing, Lillehammer, Norway, April 2008.[33] Teitelbaum T. and T. Reps. The Cornell Program Synthesizer: A syntax-directed programming environment.Communications of the ACM, 24(9):563–573,

1981.[34] Teitelman W. and L. Masinter. The Interlisp Programming Environment.IEEE Computer, 14(4):25–34, 1981.[35] Volker Haarslev and Ralf Mller. RACER system description. In International Joint Conference on Automated Reasoning (IJCAR 2001), volume 2083

of Lecture Notes in Artificial Intelligence, pages 701–705. Springer, 2001.[36] Y. S. Mahajan, Z. Fu, and S. Malik. ZChaff2004: An Efficient SAT Solver. InLecture Notes in Computer Science SAT 2004 Special Volume LNCS

3542., pages 360–375, 2004.

Sagar SenSagar Sen is a 2nd year PhD student at INRIA Rennes Bretagne-Atlantique, France. He obtained his M.Sc. in ComputerScience from McGill University, Canada as a Commonwealth Fellow and B.E. from Viveswaraiah Technological University,Bangalore,India. He has held the position of research assistant at the Jawaharlal Nehru Center for Advanced Scientific Research, Bangalore.His current research interests are automated validation inmodel-driven development and service-oriented software systems.

Benoit Baudry Benoit Baudry is a researcher in software engineering at INRIA Rennes Bretagne Atlantique. He received his PhDin computer science from the University of Rennes, France in2003. He first worked at CEA (French government nuclear agency)before joining INRIA in 2004. In 2008 he was an invited scientist at Colorado State University. His research interests includesoftware testing, fault localization, aspect-oriented software development, model transformation and model-driven development. Heis the vice-chair of the steering committee of the International Conference on Software Testing Verification and Validation.

Hans VangheluweHans Vangheluwe is a Professor of Computer Science at Antwerp University in Belgium and an Associate Professorat McGill University, Montreal, Canada. He received his D.Sc. M.Sc. in Computer Science, and B.Sc. degrees in Theoretical Physicsand Education from Ghent University in Belgium. His currentinterests are in domain-specific modelling and simulation,includingthe development of graphical user interfaces using the toolAToM3 (A Tool for Multi-formalism and Meta-Modelling), developed incollaboration with Prof. Juan de Lara. Recently, he has become active in the design of Automotive applications.

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 19

Fig. 1. Methodology Overview

Fig. 2. The Finite State Machine Meta-model

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 20

Fig. 3. (a) Partial Model (b) Synthesized Predicates from Partial Model

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 21

Fig. 4. (a) Partial model 1, (b) Partial model 2, (c) Partial model 3, (d) Partial model 4, (e) Predicate synthesized for Partial model 1 (f) Predicate synthesizedfor Partial model 2, (g) Predicate synthesized for Partial model 3, (f) Predicate synthesized for Partial model 4

SIMULATION : TRANSACTIONS OF THE MODELING AND SIMULATION SOCIETY, VOL. XX, NO. Y, MONTH 2009 22

Fig. 5. (a) Complete Model for Partial Model 1 (b) Complete Model for Partial Model 2 (c) Complete Model for Partial Model 3