Automated Analysis, Validation and Suboptimal Code Detection in Model Management Programs Ran Wei Dimitrios S. Kolovos University of York University of York Deramore Lane, Heslington Deramore Lane, Heslington York, United Kingdom York, United Kingdom ran.wei@york.ac.uk dimitris.kolovos@york.ac.uk ABSTRACT static analyser for EOL and the languages that build atop As MDE is increasingly applied to larger and more complex it, implies that a wide range of genuine errors that could be systems, the models that MDE platforms need to manage detected at design time are only detected at runtime. can grow significantly in size. Additionally, model manage- ment programs that interact with such models become larger Beyond detecting type-related errors, a static analyser could and more complicated, which introduces further challenges also be used to support advanced analysis capabilities, such in ensuring their correctness and maintainability. This paper as code detection, to improve the performance of model presents an automated static analysis and validation frame- querying and transformation programs, particularly in the work for languages of the Epsilon platform. By perform- context of processing large models. ing static analysis on model management programs written in the Epsilon languages, this framework aims to improve The remainder of the paper is organised as follows. In Sec- program correctness and development efficiency in MDE tion 2 we briefly motivate the need for static analysis capa- development processes. In addition, by applying analysis bilities in model management languages, in particular the on model management programs, sub-optimal performance Epsilon platform. In Section 3 we present the architecture patterns can be detected early in the development process of a static analysis framework for the Epsilon platform and a and feedback can be provided to the developers to enable static analyser for the Epsilon Object Language. In Section efficient management of large models. 4 we present a sub-optimal code detection facility developed atop the static analysis framework. In Section 5 we discuss 1. INTRODUCTION preliminary evaluation of our work. In Section 6 we dis- Model Driven Engineering (MDE) aims at raising the level cuss related work and in Section 7 we conclude and provide of abstraction at which software is developed, by promoting directions for further work. models into first-class artefacts of the development process. For MDE to be applicable in the large and complex sys- 2. BACKGROUND tems, a set of model management tools and languages are MDE allows developers to construct models which abstract needed to enable developers to manage their models in an away from technical details, using concepts closely related to automated and efficient manner. Typically, model manage- the domain of interest to reduce accidental complexity. The ment tasks include validation, transformation, comparison, constructed models are then transformed into part (or all) of merging and text generation [7]. the target system under development. Whilst Model Trans- formation is considered to be the heart and soul of Model The Epsilon platform [7] is a platform which provides a Driven Engineering [12], other model management opera- broad range of model management languages built on top of tions are equally important. Typically, such operations in- an extensible common imperative model query and modifi- clude model validation, model merging, model comparison, cation language called the Epsilon Object Language (EOL). etc. EOL is an interpreted language that supports optional typ- ing of variables, operations, and operation parameters. This provides a high degree of flexibility (for example, it enables 2.1 Epsilon Epsilon is a mature and well-established family of interop- duck typing [6]) and eliminates the need for explicit type erable languages for model management. Languages in Ep- casts, as typing-related information is currently only con- silon can be used to manage models of diverse metamod- sidered at runtime. On the other hand, the absence of a els and technologies. The architecture of the Epsilon plat- form is depicted in Figure 1. At the core of Epsilon is the Epsilon Object Language (EOL) [9]. EOL is an impera- tive language which reuses a part of the Object Constraint Language OCL) but provides additional features such as multiple model access, statement sequencing and groupings, Copyright c 2014 for the individual papers by the papers’ authors. Copy- uniformity of function invocation, model modification, de- ing permitted for private and academic purposes. This volume is published bugging and error reporting. Although EOL can be used and copyrighted by its editors. BigMDE ’14, July 24, 2014 York, UK as a general purpose model management language, its pri- mary aim is to be reused in task-specific languages. Thus, Figure 1: The basic structure of the Epsilon platform. by extending EOL, a number of task-specific model man- On the other hand, some genuine errors can also remain agement languages have been implemented, including those hidden until runtime without the help of static analysis. for model transformation (ETL), model comparison (ECL), The listing below demonstrates an example of a genuine er- model merging (EML), model validation (EVL), model refac- ror. In line 1, a variable named o is defined to be of type toring (EWL) and model-to-text transformation (EGL). Ecore!EClass, and in line 2, o is assigned the value of a random EClass in the Ecore model. In line 3, the program Epsilon is metamodeling-technology agnostic [7], models writ- tries to print the value property of o which does not exist ten in different modelling languages can be managed by Ep- according to the Ecore metamodel. As such, an error will silon model management languages via the Epsilon Model be thrown at runtime. Connectivity (EMC) layer, which offers a uniform interface for interacting with models of different modelling technolo- 1 var o : Ecore!EClass; 2 o = Ecore!EClass.all.first(); gies. Currently, EMC drivers have been implemented to 3 o.value.println(); support EMF [13], MDR, Z specifications in LaTeX using CZT and plain XML. Epsilon is an Eclipse project and is widely used both in the academia and the industry1 . As the size of such programs grow, locating genuine errors becomes an increasingly difficult task. For example, the EOL program that underpins the widely-used EuGENia tool 2.2 Epsilon and static analysis [10] consists of 1212 lines of code, that query and modify 4 EOL supports optional typing of variables, operations and models that conform to 4 different metamodels concurrently. operation parameters. The listing below demonstrates the Performing code review on this code for genuine error detec- flexibility that this delivers using as an example, a program tion is a time consuming process. Additionally, performing that operates on an Ecore model. In line 1, an operation changes is also difficult, as developers have to manually iden- called getName() is defined, its context type is Any, which tify and manage dependencies and relations between build- means that the operation can be invoked on objects/model ing blocks (operations for example) of such programs. Such elements of any type. In line 2, the keyword self refers tasks require effort and time [15]. For instance, to delete an to the object on which the operation is called, for exam- operation named F1 it is necessary to know if it is invoked ple, in the statement o.getName(), self refers to o. Thus in by any other operations or code blocks. Manually perform- line 2, the operation checks if the object is an instance of ing this task is error-prone. ENamedElement, if it is, it will return self.name. A typi- cal static analyser would complain in line 3 that ”self.name” Since model management programs interact with models, does not exist because the type of self is declared as Any, performing static analysis on model management programs not Ecore!ENameElement. However, this will never be a can also help identify sub-optimal performance patterns in problem at run-time due to the if condition in line 2. the process of accessing models. Analysis can also help com- prehend the model management programs. For example, 1 operation Any getName() { 2 if(self.isTypeOf(Ecore!ENamedElement)) coverage analysis can be performed to find out which parts 3 return self.name; of the metamodel of particular models are accessed, and 4 else return "Unnamed"; test cases can be generated based on this comprehension to 5 } better test a model management program. With the poten- tial benefits mentioned above, we propose and implement a static analysis framework for Epsilon. 1 http://eclipse.org/epsilon/users/ Figure 2: Detecting sub-optimal performance patterns from Abstract Syntax Trees. 3. TOWARDS A STATIC ANALYSIS FRAME- program that involves processing models, Epsilon currently WORK FOR EPSILON requires the user to select the required models/metamod- In this section we discuss the proposed static analysis frame- els via a user interface at runtime. To facilitate accessing work in detail. The general idea of our approach can be il- models at design-time for static analysis, we introduce the lustrated by Figure 2. We first transform the Homogeneous ModelDeclarationStatement to declare references to models Abstract Syntax Tree of an EOL program into a Heteroge- in the source code. The syntax of a model declaration state- neous Abstract Syntax Tree, we then apply resolution al- ment is as follows. gorithms (including variable resolution and type resolution) 1 model library driver EMF { to derive a Heterogeneous Abstract Syntax Graph, with its 2 nsuri = "http://library/1.0" elements connected to each other. We then perform pattern 3 }; detection to detect sub-optimal code. The aim of the frame- work is to provide a generic static analysis facility for all languages of the Epsilon platform. Since the core language Like Epsilon, the static analysis framework is also technology- of the Epsilon platform is EOL, we first develop a static agnostic. As such, beyond the model’s local name, a model analyser for EOL. declaration statement defines the type of the model in ques- tion (in this case EMF), as well as a set of model-type- specific key-value parameters (in this case nsuri = http : 3.1 Deriving Heterogeneous Abstract Syntax //library/1.0) that the framework can use to obtain the Trees model’s metamodel. We have currently implemented facili- Currently, Epsilon provides an ANTLR [7] based parser for ties to support models defined using EMF and plain XML. EOL. The ANTLR parser produces homogeneous Abstract In the future we plan to extend the static analysis frame- Syntax Trees (AST) with each node containing a text and work with support for other types of models supported by an id, which the EOL execution engine consumes. To facil- Epsilon, such as models defined in MDR, spreadsheets, etc. itate static analysis at a high level of abstraction, our first step was to define an EMF-based metamodel for EOL and With the metamodel defined, we developed a facility which to transform these homogeneous ASTs to models (heteroge- transforms the ANTLR based ASTs into models that con- neous trees) that conform to the EOL metamodel. form to the EOL metamodel. It should be noted that at the stage of AST to EOL model transformation, declared models As EOL is a reasonably complex language, we only intro- are not inspected. So at this stage, for the statement duce the basic and novel parts of the EOL metamodel and the EOL standard library. Figure 3 lists a number of basic 1 var book : Book building blocks that constitute an EOL program. The fun- damental element of the EOL metamodel is the EolElement it is only known that variable book is of type ModelElement- metaclass, as all other metaclasses in the EOL metamodel Type whose elementName is Book. Later in the type res- directly or indirectly extend it, and contains information olution process, this information is used against declared related to the line and column numbers of the respective models so that the Book type can be resolved. text in an EOL program for traceability purposes. A Pro- gram contains a number of Import(s), which are used to im- Comparing with our current approach, an alternative ap- port other programs. A Program also contains a number of proach would have been to redefine EOL’s grammar using a OperationDefinition(s) which define additional operations/- toolkit such as Xtext or EMFText which can automate the functions on existing types. A Program contains a Block, source-code to model transformation process but we have which contains a number of Statement(s). Expression is opted for an intermediate transformation instead in order also a fundamental element which is generally contained in to reuse Epsilon’s robust and proven parsers. Statement(s) and other EolElement(s). For each of the Ex- pression, there is a Type associated to it. The type of the Expression is generally unknown at the time the source code of a program is parsed into an EOL model, but is resolved 3.2 Deriving Heterogeneous Abstract Syntax later in the type resolution process. In order to run an EOL Graphs Figure 3: The basic structure the EOL metamodel. With the EOL metamodel and the AST to EOL transfor- Variable resolution also applies to parameters in operation mation defined, the next step of the process involves linking definitions. In the following listing, the variable resolver elements of the EOL model (heterogeneous tree) constructed will establish a link between the reference of the parameter in the previous phase to derive an abstract syntax graph. We toP rint in line 2 and its declaration in line 1. have created several facilities to achieve this. 1 operation definedPrint(toPrint: String) : String { 2 toPrint.println(); 3 } 3.2.1 EOL Visitor To facilitate the traversal of different elements in the EOL model and to support extensibility, we developed a facility There are also some implicit variables which are not declared which generates Java visitor classes from Ecore metamodels. by the developer but are rather provided by the execution We then generated visitor classes from the EOL metamodel engine. For example, the keyword self in an operation def- which provide a general mechanism to traverse all elements inition refers to the object/model element on which the op- in an EOL model. The EOL Visitor serves as the infrastruc- eration is invoked. The following listing demonstrates how ture of the static analysis framework, as all other facilities self is used. The variable resolver will establish a link be- in the static analysis framework extend the EOL visitors to tween self and the object on which printSelf is invoked. implement functionalities. The EOL visitor also provides high extensibility as new analysis mechanisms can be imple- 1 operation Any printSelf() { mented simply by extending the EOL visitor. 2 self.println(); 3 } 3.2.2 Variable Resolver The first phase of the static analysis on an EOL program in- It is important to note that at the stage of variable resolu- volves resolving identifiers to their definitions. Context-free tion, model element types are not resolved. identifiers in EOL can refer to 1) declared variables/oper- ation parameters and 2) undeclared variables provided by the execution engine at run-time. For declared variables, 3.2.3 Type Resolver the variable resolver establishes links between the variable In EOL there are several built-in primitive types (Boolean, declaration and its references. For example, in line 1 of the Integer, Real, String) and collection types (Set, Bag, Se- listing provided below, a variable named a is declared. In quence and OrderedSet). There is also a built-in Map type line 2, a is referenced. The variable resolver will establish a and the Any type. These types are all subclasses of Type link between the reference in line 2 and the declaration in in the EOL metamodel. The resolution of the above types line 1. is performed during the heterogeneous abstract syntax tree derivation. There is also a subclass of T ype in the EOL 1 var a : Integer; metamodel called M odelElementT ype which includes typ- 2 a = 10; ing information regarding models defined using different tech- nologies. Such typing information should be determined by Metamodel EOL Type Resolver Connectivity EOL Visitor EOL Variable Resolver EOL AST2EOL Metamodel EOL Abstract Syntax Tree Figure 4: The architecture of the static analysis framework accessing the corresponding models. engine, the AST2EOL layer uses the AST and the EOL metamodel to translate the AST to an EOL model. The To support accessing metamodels at design-time, we intro- EOL Variable Resolver and the EOL Type Resolver, both duced M odelDeclarationStatements, which are flexible to make use of the EOL Visitor and the Metamodel Connec- support models defined in different modelling technologies. tivity layer (which is used to read metamodels) to establish A model declaration defines the model’s name, aliases, the a fully type-resolved EOL model. modelling technology (driver) that the model conforms to, and a set of driver-specific parameters. The listing below is The static analysis infrastructure can be easily extended. As an example of M odelDeclarationStatement; it declares a proof of concept, we have also implemented all of the afore- model named library with alias l and its driver to be EM F , mentioned facilities for the Epsilon Transformation Language. it then specifies the EMF-specific namespace URI (nsuri) We extended the EOL metamodel to create an ETL meta- of the model so that the analyser knows how to locate and model, with the ETL metamodel, we created the ETL visitor access its metamodel. facility; we extended the AST2EOL to create a AST2ETL facility; we extended the EOL variable resolver and type re- 1 model library alias l driver EMF {nsuri = "http:// solver to create ETL variable and type resolvers. The EOL library/1.0"}; and ETL static analysers can be found under the Epsilon Labs open-source project [1]. To facilitate uniform analysis of the structural information of models of diverse modelling technologies, the static analysis 4. SUBOPTIMAL CODE DETECTION framework needs to convert type-related information from Rule-based model transformation languages usually rely on different modelling technologies into a common representa- query or navigation languages for traversing the source mod- tion. Instead of inventing a new representation, we have els to feed transformation rules with the required model ele- decided to use EMF’s Ecore. As such, the static analysis ments. In [11], the authors suggest that in complex transfor- framework provides a modular architecture where pluggable mation definitions, a significant part of the transformation components are responsible for transforming different types logic is devoted to model navigation. In the context of large- of model declarations into Ecore EPackages. For different scale MDE processes, models can contain several millions of modelling technologies: elements. Thus, it is important to retrieve desired elements in an efficient way. On top of the static analysis framework, we have built a facility which is able to detect sub-optimal • For EMF models, return the registered EPackage by performance patterns when navigating and retrieving model looking up the metamodel nsURI property of the model elements. This facility performs pattern matching to detect declaration. potential computationally heavy code in EOL (and poten- • For plain XML, construct an EPackage by analysing tially all Epsilon languages). It does so by matching patterns the contents of a sample model file specified by respec- defined in the Epsilon Pattern Language (EPL) [8] against tive the model declaration parameter. fully resolved EOL abstract syntax graphs. The structure of this facility is depicted in Figure 5. The We have developed drivers for EMF models and plain XML SubOptimalDetector has a EOLM odel as input to perform files, and a common interface which allows new drivers for the detection; it makes use of the EP LEngine of the Ep- different modelling technologies to be integrated with the silon platform to derive Abstract Syntax Trees, it has a set static analysis framework. By accessing models/metamod- of defined EP LP atterns (.epl scripts) using EPL, and a els, the type resolver is able to resolve types with regards to logging facility (LogBook) to keep the warning messages it models/metamodels. generates for pattern matches. The variable resolver and type resolver constitute the in- In this section, we present the sub-optimal detection facility. frastructure of the static analysis framework for the Epsilon We provide several examples that illustrate potential sub- languages. The infrastructure is depicted in Figure 4. The optimal performance patterns in the context of large scale EOL Abstract Syntax Tree layer is provided by the EOL model manipulation. We then present and explain a sub- Figure 5: The structure of the sub-optimal performance detection facility optimal performance pattern defined in EPL. It should be question. It is also the case for the selectOne operation in noted that this facility targets EOL programs, however, it line 3, which can be rewritten as: can be easily extended to cope with programs written in other Epsilon languages as discussed earlier. 1 var aBook = a.books.first(); The examples we present are all based on a simple Library metamodel illustrated in Figure 6. The Library metamodel 4.2 Compound select operations contains two simple metaclasses, Author and Book. An Au- Another computationally-heavy pattern is the presence of thor has a first name, a surname and a number of published compound select operations on the same collection. Book s where a Book has a name and an Author. The asso- ciation between Author and Book is bidirectional, they are 1 var authors = Author.all.select(a|a.first_name = books and authors respectively. 2 ’William’).select(a|a.surname = ’Shakespeare’); Listing 1: a potential performance overhead using compound select operations Listing 1 demonstrates such operations. In line 1, all of the Authors are retrieved first, then a select operation is per- Figure 6: The Library metamodel formed to select all Authors whose first names is W illiam, then another select operation is performed to select all Authors whose surname is Shakespeare. The complexity of this op- 4.1 Inverse navigation eration is n2 given that n is the number of Authors in the model under question. However, the condition of both the A frequent operation in EOL is to retrieve all model elements select operations can be put together to form a single select of a specific type by using the .all property call which can operation. And the statement above can be written as be a computationally heavy operation to perform as models grow in size. By analysing the metamodel of the model 1 var authors = Author.all.select(a|a.first_name = under question, bidirectional relationships between model 2 ’William’ and a.surname = ’Shakespeare’); elements can be used to avoid such heavy computations. 1 var a = Author.all.first; the complexity of this operation is therefore n as the collec- 2 var books = Book.all.select(b|b.author = a); tion of the Authors is only traversed once. 3 var aBook = Book.all.selectOne(b|b.author = a); The listing above demonstrates a potential performance bot- 4.3 Select operation on unique collections Performing select operations on unique collections (sets) can tleneck. In line 1, an Author is retrieved from the model. sometimes be inefficient depending on the condition of the In line 2, all instances of type Book are retrieved and then select operation. a conditional select is performed to find the books that are written by Author ’a’. However, since the relationship be- 1 var authorOne = Author.all.first; tween Author and Book is bidirectional, this can be replaced 2 var authorTwo = Author.all.last; by the (more efficient) statement: 3 var bookOne = authorOne.books.first; 4 var bookSet : Set(Book); 1 var books = a.books; 5 bookSet.addAll(authorTwo.books); 6 bookSet.select(b|b = bookOne); Thus the complexity of the operation all is reduced from n Listing 2: Select operation on unique collection to 1 given that n is the number of Books in the model under Figure 7: The model representation for Book.all.select(b|b.name = a) Listing 2 demonstrates an inefficient and computationally Listing 4 demonstrates another example of sub-optimal EOL expensive select operation. In Line 1 and 2, two Authors are code. retrieved from the model; in line 3, a Book is retrieved from authorOne’s publications; in line 4, a Set called bookSet is 1 var anEpsilonBook = Book.all.select(b|b.name = 2 "EpsilonBook").first(); created and in line 5, all of the Books that authorT wo pub- lished are added to bookSet. In line 6 the select operation Listing 4: Select an element in a collection iterates through all of the books in the bookSet and find the ones that match the bookOne. However, the bookSet is a unique collection, which means that all of the elements in it In line 1, a select operation is performed on all of the in- only appear once. Therefore, it is not necessary to perform stances of Book to filter out the books with the name ’Ep- a select operation but rather a selectOne operation, as the silonBook’, then a f irst operation is performed to select the select operation would return at most one result eventually. first one of the collection returned by select. This can be The complexity of the select operation is n given that n more efficiently re-written as: is the number of books that authorT wo published; If the select operation is replaced with selectOne, the complexity 1 var anEpsilonBook = Book.all.selectOne(b|b.name = of it would be 1 for the best case scenario and n for the worst 2 "EpsilonBook"); case scenario (n/2 for the average case). to avoid traversing all of the instances of Book. 4.4 Collection element existence In some cases, checking existence of an element inside a col- lection can be written in inefficient ways. 4.6 A sub-optimal performance pattern 1 if(Book.all.select(b|b.name = "EpsilonBook") In this section we present a sub-optimal performance pattern 2 .size() > 0) { which is written in the Epsilon Pattern Language (EPL). To 3 "There is a book called EpsilonBook".println(); understand how this pattern works, it is first important to 4 } understand what is contained in an EOL model for a certain EOL program. Listing 3: Collection element existence 4.6.1 Understanding an EOL model Listing 3 demonstrates such a scenario. In line 1, the con- Figure 7 illustrates a fragment of an EOL model which rep- dition of the if statement retrieves all instances of Book, resents the statement below. then selects the ones with the name EpsilonBook, and cal- culates the size of it then evaluates if the size is greater 1 Book.all.select(b|b.author = a); than 0. This operation eventually checks for the existence of a book named EpsilonBook. Thus, this operation can be more efficiently re-written as: Firstly, invocations of the select() operation in the EOL metamodel are represented by the F OLM ethodCallExpression 1 Book.all.exists(b|b.name = "EpsilonBook") (FirstOrderLogic method call) metaclass; it has a name (an instance of N ameExpression) and an iterator (an instance of V ariableExpression). In this case, the name is ’select’ 4.5 Select the first element in a collection and the iterator is ’b’. The select operation has a condition, in this case, it is an 12 lhs : PropertyCallExpression instance of EqualsOperatorExpression. The lhs (left hand 13 from: condition.lhs side) of it is an instance of P ropertyCallExpression, whose 14 guard: lhs.resolvedType.isTypeOf(ModelElementType), 15 target (an instance of NameExpression) is ’b’ and property 16 rhs : NameExpression (an instance of NameExpression) is ’author’; the rhs (right 17 from: condition.rhs hand side) of it is ’a’ (an instance of NameExpression). Both 18 guard: rhs.resolvedType.isTypeOf(ModelElementType), the lhs and rhs of the EqualsOperatorExpression have re- 19 solvedTypes, in this case, they are both Author (instances 20 lhsType : ModelElementType of M odelElementT ypes). 21 from: lhs.resolvedType, 22 rhsType : ModelElementType 23 from: rhs.resolvedType The target of the F OLM ethodCallExpression is an in- 24 guard: lhsType.ecoreType = rhsType.ecoreType stance of P ropertyCallExpression with its target as Book 25 { (an instance of NameExpression) and its property as all (an 26 match { instance of NameExpression). The types of these expres- 27 var r = getReference(lhs.target.resolvedType. sions, altogether with some irrelevant details are omitted ecoreType, lhs.property.name); 28 if(r.upperBound = 1 and r.eOpposite <> null and for the purpose of the discussion. r <> null) 29 { 30 if(r.eOpposite.eType = lhs.target.resolvedType 4.6.2 The EPL pattern .ecoreType) In Listing 5, we define an EPL pattern to match occurences 31 { of the pattern described above. In lines 2-6, a guard is de- 32 return true; fined to look for a F OLM ethodCallExpression the name 33 } of which is either ’select’ or ’selectOne’; the type of the 34 } condition should be EqualsOperatorExpression; its target 35 return false; 36 } should be an instance of P ropertyCallExpression; and the 37 } property of the P ropertyCallExpression should be ’all’. 38 39 operation getReference(class: Any, name:String) In lines 8-10, a guard is defined to look for an instance of 40 { EqualsOperatorExpression in the condition of the FOL- 41 for(r in class.eReferences) MethodCallExpression found previously, the lhs of which 42 { 43 if(r.name = name) should be an instance of P ropertyCallExpression. 44 return r; 45 } Lines 12-14 specify that the resolvedT ype of the lhs should 46 return null; be an instance of M odelElementT ype. In lines 16-18, it 47 } specifies that the resolvedT ype of the rhs should be an in- stance of M odelElementT ype. In lines 20-24, it specifies Listing 5: EPL pattern for inverse navigation that the type of the lhs and the rhs should be the same. Lines 26-37 perform the match of the pattern. This part 4.6.3 The Java pattern firstly fetches the ERef erence from the lhs of the condition Our original attempt to construct the sub-optimal perfor- (in this case, ’b.author’, it is an ERef erence because as mance detection facility was to define patterns using Java, previously discussed, all metamodels are converted to EMF we defined a method in Java to achieve the same function metamodels for uniformity). The EReference is then in- described above. The equivalent Java implementation is 76 spected; if it is not null and it has an eOpposite reference, lines of code with a long chain of If statements which makes the pattern continues to check if the type of the eOpposite it very difficult to comprehend. With the EPL approach, of the reference is the type of the rhs of the condition (in the patterns are more comprehensible. Developers can con- this case, ’author’). tribute to the pattern pool by defining their own EPL pat- terns and registering them with the framework through ap- In lines 39-47, a helper method is defined to help look for an propriate extension points. ERef erence given an EClass and a name; its implementa- tion is straightforward. 5. TOOL SUPPORT 1 pattern InverseNavigation The static analyser proposed in this paper is a pragmatic 2 folcall : FOLMethodCallExpression static analyser. The flexibility of EOL allows its users to 3 guard: (folcall.method.name = ’select’ or folcall. method.name = ’selectOne’) write code with optional typings that always work at run- 4 and folcall.conditions.isTypeOf( time. Reporting errors on such cases are not desirable for EqualsOperatorExpression) EOL, especially on legacy EOL code that is proven to work 5 and folcall.target.isTypeOf(PropertyCallExpression) with extensive testing. Thus the design decision was to al- 6 and folcall.target.property.name = ’all’, low such behaviour and delegate the resolution to the EOL 7 execution engine. We applied the static analyser on a large 8 condition : EqualsOperatorExpression 9 from: folcall.condition EOL program (Ecore2GMF.eol) that underpins the Euge- 10 guard: condition.lhs.isTypeOf( nia tool [10] for evaluation. We allow optimistic typing - PropertyCallExpression) when Any type is encountered in assignments, operation 11 calls and property calls, we provide a warning message to Figure 8: EOL Editor Screen Shot notify the user that there might be potential type incom- Acceleo [4] provides static analysis mechanisms for syntax patibility issues at run-time. With this configuration, anal- highlighting, content assistant, and model related error de- ysis on Ecore2GMF.eol which consists of 1212 lines of code tection. However, to the best of our knowledge, it does not generates 126 warning messages. This result shows that the support modelling technologies other than EMF. static analyser supports plausible legacy code. At the same time, it provides reasonable warning messages when optional Xtend [3] also provide static analysis facilities which are used typing is used. to detect syntax and built-in type-related errors, model re- lated type information validations are not included. After evaluating the static analyser, we evaluate the sub- optimal performance detection facility. Figure 8 provides a In [15], a static analysis tool is proposed to detect errors in screenshot of the editor we implemented by extending the model transformations written in the Atlas Transformation existing EOL Eclipse-based editor. The lines of code with Language (ATL), the tool presented is used to convert an warnings represent matches of the patterns discussed above. ATL program into a model, but no validation algorithms are The implementation of the editor is able to extract and dis- implemented on this tool to our best knowledge. play the warning messages generated by the detection facil- ity. The sub-optimal performance detection facility is not The latest release of ATL IDE [5] provides a static analy- only able to detect patterns that incur performance over- sis facility, it resolves the types of variables including built- heads, but also provide suggestions on how to rewrite the in ATL types and types related to metamodels. The ATL code. An example warning message is shown in line 8, the IDE also provides code-completion of operation calls and warning message suggests to rewrite the operation as: metamodel element navigations. However, the static analy- sis is not responsible to provide any errors on type incom- 1 Author.all.select(a|a.first_name = "William" and a. patibilities as it adopts an optimistic and flexible approach. surname = "Shakespeare") The ATL platform also provides limited support for multiple modelling technologies other than EMF. The rest of the patterns function as expected. In [11], ways of deriving optimisation patterns from bench- marking OCL operations for model querying and navigation are proposed and several optimisation patterns are identi- 6. RELATED WORK fied, including short-circuit boolean expressions, opposite There are several automated analysis and validation tools for relationship navigation, operations on collections, etc. model management programs. In [14] the authors propose a generic static analysis framework for model transforma- tions specified in VIATRA2 Textual Command Language 7. CONCLUSIONS AND FUTURE WORK (VTCL [2]). The latest static analysis framework detects In this paper we have reported on our work on designing and common errors and type related errors regarding models. developing a static analysis framework for the core language However, the VIATRA2 framework provides limited sup- of Epsilon (EOL). The focus of our report is mostly on the port for other metamodelling technologies as it uses its own sub-optimal detection facility of the static analysis frame- modelling language (VTML) and store the metamodels in work. However, it is to be noted that the static analysis the model space. Additionally, VTCL is not as flexible as framework is able to detect various type-related errors that EOL; it does not provide optional typing mechanisms as may occur using EOL. The static analysis framework follows EOL does. a pragmatic approach so as not to compromise the flexibility of the Epsilon languages. As a result, it can generate false development. Software, IEEE, 20(5):42–45, 2003. negatives (problems that exist but cannot be detected by [13] D. Steinberg, F. Budinsky, E. Merks, and the static analyser). To minimise the number of false neg- M. Paternostro. EMF: eclipse modeling framework. atives, a more strict coding style is encouraged - to avoid Pearson Education, 2008. the use of Any type as much as possible, so that the static [14] Z. Ujhelyi, A. Horváth, and D. Varró. A generic static analyser can perform more accurate analysis. This is clearly analysis framework for model transformation a trade-off to make; to obtain better error reporting, devel- programs. Technical report, Technical report, opers need to write more boilerplate code with explicit type Budapest University of Technology and Economics, casting, while to obtain better flexibility, developers need 2009. to bare with the fact that the analyser may produce false [15] A. Vieira and F. Ramalho. A static analyzer for model negatives that emerge at run-time. transformations. In 3rd International Workshop on Model Transformation with ATL, Zurich, Switzerland, It should be noted that the sub-optimal performance de- 2011. tection facility is only one application of the static analysis framework for Epsilon. In the future, we plan to look into facilities such as program comprehension, metamodel cov- erage analysis, impact analysis, etc. We will also look into the possibility of pre-loading models and look for more fine- grained performance patterns for EOL programs. 8. REFERENCES [1] Epsilon labs. https://epsilonlabs.googlecode.com/ svn/trunk/StaticAnalysis/. [2] A. Balogh and D. Varró. Advanced model transformation language constructs in the VIATRA2 framework. In Proceedings of the 2006 ACM symposium on Applied computing, pages 1280–1287. ACM, 2006. [3] P. Friese and B. Kolb. Validating Ecore models using oAW Workflow and OCL. Eclipse Summit Europe, 2007. [4] J.-M. Gauthier, F. Bouquet, A. Hammad, F. Peureux, et al. Verification and Validation of Meta-Model Based Transformation from SysML to VHDL-AMS. In MODELSWARD 2013, 1st Int. Conf. on Model-Driven Engineering and Software Development, pages 123–128, 2013. [5] F. Jouault, F. Allilaire, J. Bézivin, and I. Kurtev. ATL: A model transformation tool. Science of computer programming, 72(1):31–39, 2008. [6] A. Koenig and B. Moo. Templates and duck typing. Dr. Dobbs, June, 2005. [7] D. Kolovos. An extensible platform for specification of integrated languages for model management. PhD thesis, University of York, 2008. [8] D. Kolovos, L. Rose, R. Paige, and A. Garcıa-Domınguez. The Epsilon Book. Structure, 178, 2010. [9] D. S. Kolovos, R. F. Paige, and F. A. Polack. The Epsilon Object Language (EOL). In Model Driven Architecture–Foundations and Applications, pages 128–142. Springer, 2006. [10] L. M. Rose, D. S. Kolovos, and R. F. Paige. Eugenia live: a flexible graphical modelling tool. In Proceedings of the 2012 Extreme Modeling Workshop, pages 15–20. ACM, 2012. [11] J. Sánchez Cuadrado, F. Jouault, J. Garcı́a-Molina, and J. Bézivin. Deriving ocl optimization patterns from benchmarks. Electronic Communications of the EASST, 15, 2008. [12] S. Sendall and W. Kozaczynski. Model transformation: The heart and soul of model-driven software