Towards a model driven Modelica IDE

Roland Samlaus1 ClaudioHillmann1 BirgitDemuth2 MartinKrebs2

Fraunhofer Institute for Wind Energy and Energy System Technology1

Technische Universität Dresden, Institut für Software- und Multimediatechnik2

Abstract

Model Driven Software Development evolved into acommon way of creating software products. Describ-ing software in a more abstract way simplifies andspeeds up the development process and generated codeturns out to fulfill high quality standards. As a subcat-egory of model driven development Domain-SpecificLanguages concede to express problems in a domainspecific way. By defining a languages grammar, aneditor that provides basic support for developers canbe generated automatically. This paper describes howthese concepts are utilized for the creation of a Model-ica Integrated Development Environment (IDE). Help-ful functionality is implemented in a model driven wayto maximize assistance during the development pro-cess. Thus the developer receives a tool that allowsto survey large scale projects and provides functional-ity that is well known in other popular programminglanguages. Furthermore an approach for semanticalverification of Modelica documents during the devel-opment process is presented. This allows to detect andcorrect errors early.

Keywords: Modelica, IDE, OCL, verification

1 Introduction

In the last years the importance of Modelica in the fieldof engineering increased significantly. Many compa-nies utilize the language for modeling and simulationof physical systems. Thus the support for developersbecame a vital issue to enable the survey of extensiveprojects. One approach is the development of librariesas done by the Modelica community. Libraries providecommon functionality that can be easily reused and ex-tended and thereby increase the speed of developmentand ensure high quality of the resulting models.

An additional approach is the usage of developmenttools. These support the engineer during the imple-mentation of big physical systems (e.g. Dymola1 and

1http://www.dymola.com

OpenModelica2). Although the above mentioned toolsturned out to be very helpful, supplementary featuresare desired to ease the handling of complex models.This topic is well known in the software engineeringcommunity as well. Therefore we aim at transferringmain features to the Modelica world. The structureof our Modelica Integrated Development Environment(IDE) and how it was created by model driven tech-nologies is explained in section 2.

Besides the goal to facilitate daily work for engi-neers with Modelica, the quality of the outcome hasto be addressed. Regarding this purpose the developerhas to be encouraged to create syntactically and se-mantically correct documents. While the syntax canbe checked easily, semantic correctness may be hardto prove because semantic constraints may demand ex-tensive calculations. This issue is addressed in sec-tion 3 and our approach of utilizing Object ConstraintLanguage (OCL) for verification of Modelica modelsis stated.

In section 4 some components of the IDE e.g. theeditor and views are presented. Finally a summary andfuture work will conclude this paper in chapter 5.

2 The MDSD approach

Model Driven Software Development (MDSD) is anapproach that eases the development process by pro-viding a higher abstraction level of the software thatis being developed. Compared to pure code-based de-velopment, the architecture can be described in a moreconceptual and structured way. A common way is todesign the structure and behavior of software with thehelp of Unified Modeling Language (UML) diagrams.But graphical representation is not the only popularway of an abstract description. In the MDSD commu-nity the usage of Domain-Specific Language (DSL)sbecame more and more important.

DSLs allow the definition of problems in a domainspecific way and therefore provide an easy way to ex-

2http://www.openmodelica.org

press ideas to the domain experts. This can be donegraphically as well as in a textual syntax. The Model-ica language can also be seen as a textual DSL, sinceit allows the developer to describe physical systems.

As Eclipse builds the basis for our IDE it is evidentto use Eclipse Modeling Framework (EMF) as plat-form for our models. All data being processed by EMFare based upon ECore that is more or less aligned onObject Management Group (OMG)s Essential MetaObject Facility (EMOF) 3 standard. All generated ob-jects extend a basic interface that allows interoperabil-ity between objects of different meta-models. Moredetails about the functionality of Ecore can be foundon the EMF website 4.

The project structure of the IDE has been definedwith the help of EMF tools. Several ways [8] ofdescribing an Ecore-based meta model are available,like Java annotations or XML, whereas the usage of aUML-like graphical editor might be the most appeal-ing way for developers. The Modelica DSL was cre-ated with Xtext5, an Open Source framework for thedevelopment of DSLs. It also uses the functionalityprovided by EMF and therefore enables to easily inter-act with our data models as described in Section 2.2.

In the next sections the creation of the ModelicaDSL is described and the underlying data structure ex-plained. Figure 1 gives an overview of the used tools.

2.1 Metamodeling of Modelica with Xtext

For the textual syntax definition of Modelica we usethe tool Xtext, that is part of the Eclipse ModelingProject. Xtext’s syntax for defining language gram-mars closely resembles the Extended Backus-NaurForm (EBNF) notation. Based on this grammar severalcomponents are generated automatically. A Tokenizersplits the given text documents into parts that can beinterpreted by a parser. The parser that is generatedby the parser generator framework ANTLR [3][10]creates an Abstract Syntax Tree (AST) and a Con-crete Syntax Tree (CST) of the given text document.Thereby we get an editable tree-like data structure thatcan be processed by additional software components.The AST represents the structure of a Modelica doc-ument. Additionally the CST keeps all informationabout the concrete representation inside the documente.g. literals and white spaces. Based on the grammar,syntax highlighting and basic code completion for thegenerated editor is provided. The parser recognizes

3http://www.omg.org/4http://www.eclipse.org/modeling/emf/5http://www.eclipse.org/Xtext/

syntactical errors and displays them inside the editorand in a separate problems view. The view containsdetailed descriptions of the errors and allows to jumpinto the erroneous area of the document.

Eclipse Platform

Eclipse ViewsEclipse

Modeling Framework

Eclipse Text Editor

Xtext Modelica Editor

EclipseOCL

Modelica GUI Components

Modelica IDE

Figure 1: Overview of tools used in the Modelica IDE

Additional to these basic tools, other componentsare generated that use the AST, for example an outlineview that represents the inner structure of opened doc-uments, i.e. inner classes, sub-packages and compo-nent declarations. One of the main amenities of Xtextis the integrated resolution of references. Based on thismechanism, the developer can jump to class defini-tions to investigate implementation details. Referencesare also used as types for component declarations or asextended classes. The references connect ASTs of dif-ferent documents and thereby form a kind of overlaygraph. If referenced objects cannot be found, the af-fected part of the document is again marked with anerror.

However, because of the complex structure of Mod-elica documents and for performance reasons, specialindex and linking mechanisms had to be implemented.Based on the index information additional help func-tions were created, e.g. the proposal of classes that canbe referenced at a certain position inside the document.

The usage of Xtext for grammar definitions iscovered below by a small example. Listing 1 de-picts Modelica’s grammar definition for the elementImportClause.

An import clause starts with the keyword``import'' followed by an optional abbreviationdefinition. Optional rules are defined by a questionmark. In many Modelica documents SIunits areimported with the definition of an abbreviation:``SI = Modelica.SIunits;''. This allows towrite shorter expressions when using type definitionsfrom the SIunits package.

" i m p o r t " ( ab b r e v =Name "=" ) ?r e f e r e n c e =[ A b s t r a c t C o n t e n t ]w i l d c a r d ?= " .∗ " ? comment=Comment ? ;

Listing 1: Import clause definition in Xtext

The next rule defines a reference to anAbstractContent. AbstractContent is an-other grammar rule that represents different kindsof Modelica class contents, e.g. the standard classstructure or an extends clause. For more details onthe Modelica class structure see [9]. In Xtext squarebrackets define references to other objects. This is aXtext specific feature that is not defined in EBNF. Ageneric linking mechanism is provided that resolvesthe reference by searching for an AbstractContent

whose name attribute of type String matches thegiven input.

Import clauses are not restricted to import singleModelica classes but also a set of sub-classes insidea package. This is indicated by the use of a wildcard “*”. Using a reference to AbstractContent

does not respect the fact that only packages can be re-ferred to when using wild cards. In this definition wedo not distinguish between Modelica classes, models,packages and so forth on the syntax level. Thereforethe correctness of the rule has to be regarded by thesemantics of Modelica. This is surveyed in section 3.Finally an optional comment adds additional informa-tion about the import for developers.

Altogether the grammar definition consists of over100 rules. Performance issues during parsing pre-vented us from reusing the language definition fromthe Modelica language specification [9], so that wewere forced to create an optimized version. More-over, the complexity of the resulting AST would havemade it difficult to modify or investigate the parse re-sults. As an example, the definition of expressions hasbeen simplified. We do not distinguish between logicalexpressions, terms, or factors but only define a singletype of expression. If needed, the type can be derivedby investigating the operator of an expression. Thisenabled us to reduce the number of rules to 4 com-pared to 12 defined in the Modelica language specifi-cation [9].

2.2 Project structure definition with EMF

For the sake of reuse, Modelica documents should bestructured in projects. When defining e.g. a wind en-ergy plant, every component like Tower, Nacelle orRotorBlade ought to be encapsulated in its own unit.If the components are divided into different projects,

they can be interchanged easily. This helps the devel-oper to survey the structure of the designed physicalsystems. Furthermore, the reuse of functionality fromlibraries like the Modelica Standard Library is essen-tial.

Separating components into projects requires amechanism that enables linking between models in-side separate projects. A WindTurbine e.g. reusesthe component Tower for the definition of a new windturbine. Therefore a link between the wind turbine’sdefinition and the document where the tower is de-fined in has to be established. This ensures the exis-tence of the reused component and enables the userto quickly display the tower’s definition. In order tobe able to find this kind of references quickly, metadata must be provided that holds additional informa-tion about the class structure and location of Model-ica files. This data structure is defined with EMF. Thecentral data in this structure is called ModelResource.A ModelResource can contain source folders. AllModelica source files contained in these source foldersbelong to the same ModelResource. When a sourcefile is parsed, the internal structure is analyzed andstored in an index file. These files are again cou-pled to the ModelResource. Hence ModelResourcesknow the name space of all contained models andallow quick linking by the use of qualified names.Qualified names distinctly address a component in-side a name space like in Modelica.SIunits.Angle

whereas Modelica and SIunits represent packagesand Angle is a type definition inside this package.

At first sight the proposed project structure looksquite similar to the one Eclipse uses for plug-inprojects. In fact many concepts are reused but alsoaltered to meet our requirements (see figure 2). Us-ing ModelResources instead of projects as manage-ment unit allows to have several name spaces insideone project. This is important when simulations areperformed. The source files of several simulations canbe kept in the same project and allow to keep trackof source code changes between different simulations.In the project based approach it would be impossi-ble to keep multiple class definitions with the samequalified name. To enable linking, every experimentgets its own ModelResource that knows the files usedfor simulation. The ModelResource mechanism isalso used to enable referencing other projects in theworkspace. Projects can be exported as compressedand possibly encrypted libraries. The meta data arekept inside the archive, therefore no further analysisof the contained source files is needed when libraries

are reused. The creation of libraries serves two pur-poses: First it allows to assemble specific function-ality into one library that can be shared among usersor maybe even sold to customers; Secondly, using li-braries speeds up the development process becausehandling of a huge number of source files can lead toa slow development environment and an increasing re-action time of the systems on user interaction.

Using EMF turns out to be very helpful, because thedata defined in EMF automatically has a persistencemodel. Also references between EMF-based files areresolved automatically. Furthermore it provides a sys-tem for change notification that allows to react on anychanges of the meta data.

Figure 2: Data structure of the Modelica IDE

3 Verification of Modelica documents

Enhanced verification of code is desired during devel-opment to immediately ensure the correctness of thecreated models. Two kinds of verification can be dis-tinguished - dynamic and static verification.

3.1 Dynamic versus static verification

Dynamic verification of Modelica models is, at themoment, a difficult topic because for this issue mod-els have to be interpreted on instances. For instance,to ensure that a parameter does not exceed a specifiedvalue, the equations altering the variable must be cal-culated. But currently these calculations are done bytranslation of Modelica source code to a different pro-gramming language like C++ and execution of the re-sulting program code. That means no interpreter work-ing directly on Modelica source code is available butthe code is transformed to another kind of program-ming language and then executed.

The same problem is faced when trying to debugModelica code like it is done in other object orientedlanguages, e.g. Java. It may be possible to implement

an interpreter for basic Modelica language constructsand simple models that do not contain any equations.But at the moment there is no solution available thatsolves Differential Algebraic Equations (DAE)’s dur-ing development time.

The MDSD-community is, by the way, facing thesame problem. Instead of generating code that has tobe executed, interpreters are often desired that createfunctionality based on objects. Therefore solving theproblem of interpreting models directly could solvethe problem of debugging and verification as well asreduce the required time during development.

However static verification is currently done for awide range of models (e.g. Modelica, UML, Java, . . . ).Several techniques are available for the verification ofmodels. One could write Java-Code or utilize special-ized languages like Check, that is delivered with theXtext-Framework. In our IDE we use OCL [2] whichis a standard language of the OMG. It is spread in re-search and industry and thus is typically to be under-stood by many developers. The static verification ofModelica with OCL is presented in the next section.

3.2 Static verification with OCL

In the Modelica specification the semantics of the lan-guage is verbally specified. We interpreted the Model-ica semantics as Well-Formedness Rules (WFR)s andfound 201 WFRs which we translated into OCL con-straints. The WFRs differ from each other in termsof complexity. Some constraints are quite easy to de-fine and the execution time is short. Others are com-plex and often recursive. The complexity and recursiv-ity is conditional upon the underlying Modelica meta-model and OCL as a language that specifies naviga-tion paths through a model. This can cause the veri-fication to take a long time because large parts of theAST have to be considered during the interpretation ofthe constraints. In the following OCL will be shortlyintroduced. Then the definition of some WFRs is ex-plained.

3.2.1 OCL

OCL is a language that allows the definition of con-straints on objects. Originally it was designed to en-able more precise UML diagram definitions. LaterOCL has been extended to a query language and isgenerally in metamodeling. Figure 3 displays a sim-ple example of an UML class where the attribute age

inside the class Person is constrained. The invariant

ensures that the age is higher than 17 to fulfill the re-quirement of being an adult.

Figure 3: A simple OCL example

Besides invariants OCL also allows to define queriesto collect objects. Furthermore the definition of new orderived model elements (attributes, associations, oper-ations) is allowed and helpful to reuse common func-tionality. OCL also defines a standard library that pro-vides basic functionality like operations on collections(e.g. checking if a set is empty). The language de-scription and examples can be found in the OCL spec-ification [2].

3.2.2 Modelica and OCL

As mentioned above, OCL is not restricted to be usedfor UML diagrams but can principally be applied toarbitrary object structures [5]. The only restrictionis, that the interpreters need to be able to handle theconstrained model. This usually means that the metamodel of the restricted language must be available andthe interpreter must be able to read the data format. Aswe use Xtext for the definition of our Modelica lan-guage, the resulting AST is based on Ecore. Hencean Ecore based OCL interpreter is needed. Thereforetwo popular OCL interpreters that fulfill this require-ment were evaluated for verification, Eclipse OCL6

and Dresden OCL7 [13].The basis for the verification of Modelica code is

the AST of a Modelica document. It is created by theparser that Xtext generates based on the grammar def-inition. Thus the AST represents the structure of theModelica document and can be used to check whetherthe structure is correct. OCL constraints are definedand evaluated on the AST.

The OCL constraints were used to measure the per-formance of both tools mentioned above. Furthermorethe constraints were analyzed to find time consumingrules. This is important when dealing with user inter-faces because users do not accept lags when editingdocuments because of verification tasks that are per-

6http://www.eclipse.org/modeling/mdt/?project=ocl7http://www.reuseware.org/index.php/DresdenOCL

non-recursive recursiveconstraints constraints

constant time x -linear time x x

quadratic time x xexponential time - x

Table 1: Classification of OCL constraints by theircomplexity

formed in the background. Two categories with dif-ferent complexity and calculation times were detected(Table 1).

Short examples for non-recursive constraints will il-lustrate the definition of Modelica WFR in OCL. List-ing 2 represents a constraint that can be evaluated inconstant time:

inv p r e d e f i n e d _ s t r i n g _ t y p e :name <> ’ S t r i n g ’

Listing 2: Non-recursive OCL with constant time con-straint

Each component declaration in Modelica has aname. In our grammar this is reflected as a ruleComponentName with the attribute name. BecauseModelica reserves some names for components (i.e.String), these names are not allowed for newly de-fined components. The OCL invariant given in List-ing 2 ensures that the name String is not assignedto a component. As no other objects have to be con-sidered, the calculation depends only on the objectComponentName resulting in a constant calculationtime.

A linear non-recursive constraint is defined in List-ing 3:

c o n t e x t Componentinv component_name_type :not componentnames−> e x i s t s (name = s e l f . t y p e . name )

Listing 3: Non-recursive OCL constraint with lineartime

Figure 4 shows the result of our validation in theeditor and the problems view.

Components in Modelica classes must not havethe same name as their type. It is e.g. prohib-ited to define a component Angle Angle;. Theconstraint in Listing 3 checks whether a name ex-ists (componentnames->exists()) that is equal thename of the components type (self.type.name).The calculation time coheres directly with the num-

Figure 4: Displaying verification errors

ber of instances that are defined in the component andthus increases linearly.

Another problem is the test for uniqueness whichresults in quadratic calculation time. If uniquenessof element names in an enumeration shall be ascer-tained, all elements have to be compared with eachother (as long as the model elements are not stored in arelational database). Thus the calculation time growsquadratically to the number of elements. The corre-sponding OCL constraint is defined in Listing 4:

c o n t e x t E n u m e r a t i o n L i s tinv u n i q u e _ e n u m _ l i t e r a l s :e n u m e r a t i o n l i t e r a l s −>i s U n i q u e (componentname . name )

Listing 4: Non-recursive OCL constraint withquadratic time

Most of the OCL constraints defined for the verifi-cation of Modelica documents are of recursive naturebecause most WFRs originate in restrictions on inher-itance structures. As a result many parts of the modelhave to be considered for verification. Although theeffort of calculating non-recursive rules may result inquadratic time as seen above, recursive rules are evenworse.

For complexity reasons, only one recursive con-straint with exponential time is explained in this pa-per (Listing 5). The Modelica specification definesthe rule: “The type prefixes flow, input, and output

shall only be applied for a structured component, if noelements of the component have a corresponding typeprefix of the same category.” [9] The function defini-tion in Listing 5 returns a Boolean value that indicates,whether a Modelica class contains a component def-inition with the prefix flow, input, or output (thecollection of components is defined in another func-

tion collectIOComponents()). Not only the ana-lyzed class has to be considered for this constraint,but all super classes from which the instance inher-its. This requires the invoking of the same func-tion containsIOPrefixes() recursively and resultsin the complexity O(nr) where n describes the numberof super classes and r the recursion depth.

c o n t e x t A b s t r a c t M o d e l i c a C l a s sd e f : c o n t a i n s I O P r e f i x e s ( ) Boolean =

c o l l e c t I O C o m p o n e n t s ()−> s i z e >0or

c o l l e c t E x t e n d s C l a u s e s ()−> e x i s t s (c o n t a i n s I O P r e f i x e s )

Listing 5: Recursive OCL constraint with exponentialtime

Because of the complexity of the resulting con-straints not all WFRs from the Modelica specifica-tion have been implemented yet. In a first version ofthe Modelica IDE (Section 4 we decided to integrateEclipse OCL because of its better interpreter perfor-mance. In addition to the rules from the specification,further constraints may be helpful for daily work. E.g.,warnings could be displayed if to many subclasses ina document exist or the package structure is too deep.This functionality may be integrated in a later versionof our IDE.

4 Modelica IDE

In this section the main parts of our IDE, which sup-ports the developer in the creation and manipulation ofmodels are presented. First the features of the gener-ated and enhanced Modelica editor are presented (Sec-tion 4.1), then it is explained how additional viewssimplify the development process (Section 4.2).

4.1 Editor

Modern Modelica IDEs support the user in the devel-opment process by providing editors and related toolsthat ease the handling of big projects. Editors pro-vide syntax highlighting to emphasize language spe-cific keywords and to reveal the structure of the writtencode, making it easier for the developer to understandthe code. Highlighting and the recognition of syntacti-cal errors is provided by Modelica specific lexers andparsers that can either be hand written or generated bytools like ANTLR as described in Section 2.1. Fur-thermore semantical highlighting may be provided butshould only be checked where the calculation can bedone quickly. In Figure 5 the simple data type Real

(gray, italic) is highlighted semantically while all otherdecorations are provided by the generated lexer. Codefolding allows to reduce the complexity of the dis-played code, e.g. by hiding annotations that containarbitrary information. With the integrated mouse-overhelp, details about utilized classes that are defined ascomments in the declaration can be explored by thedeveloper.

Figure 5: Xtext Modelica editor

Based on the index data, code completion supportsthe developer in choosing sub-components of classes.This is helpful during the definition of import clausesor components and helps to speed up the developmentprocess significantly.

Error markers for non-existent referenced classesare automatically created. This is an advantage com-pared to editors like the ones integrated in Dymola, orModelica Development Tooling 8 because developersimmediately recognize these kind of failures. A quickfix using a comparable mechanism as code completiontries to provide a suitable solution.

4.2 Views

The Modelica IDE has several views that display ad-ditional information on the projects data. The mainview is the Eclipse project explorer that has been ex-tended to fulfill the needs of a Modelica IDE. The con-tained packages and classes of Modelica files as wellas the package structure of referenced libraries are dis-played as shown in Figure 6. Each of these classescan be inspected in the editor whereas library docu-ments are opened read-only to avoid the modificationof the source code. References inside the documentsare linked to allow quick browsing through the sourcecode and the exploration of class declarations. The

8http://www.ida.liu.se/ pelab/modelica/OpenModelica/MDT/

Eclipse outline view displays the inner structure of theopened document. All actions that are triggered in theuser interface are implemented as Open Services Gate-way initiative (OSGi) 9 events. Together with an Xtextbased DSL that was specified for scripting purposes,we are able to record these actions and save them in afile. The engineer can edit or create a script documentfor automatic execution of actions. This includes thesimulation of models with the coupled solvers Dymolaand Mosilab [1].

Figure 6: Modelica Project Explorer

5 Conclusion and future work

With the help of MDSD techniques we were able toimplement a Modelica IDE in a short period of time.Generated code ensures high quality products and re-duces the implementation time by automatic creationof frequently used components like data structures andserialization mechanisms. Since the generated code isbased on the same data description (Ecore), interoper-ability is guaranteed. Therefore augmenting the gener-ated editor with additional functionality became easy.

The introduced IDE enables the Modelica developerto create models fast and easy. The verification andreferencing mechanisms ensure correctness through-out the development process. The views on the Mod-elica data structure help surveying large projects. En-capsulating source code into libraries speeds up theuser interaction and encourages the developer to create

9Open Services Gateway initiative, http://www.osgi.org

models as components. This helps in creating frame-works that can be shipped and reused as libraries.

During the development some performance issuesarose that should be considered in the future. This be-came evident when the Modelica Standard Library wasimported as a source project. The low performance ofparsing all library files is engendered by the complexModelica grammar that causes a lot of back-trackingduring parsing. Allowing the use of a different parsergenerator than ANTLR to generate a LR(k) parser

might help solving this issue. Also future modifica-tions of the grammar definition might speed up pars-ing, e.g. by defining a unique start and end termi-nal sign for annotations. In many documents the per-centage of annotations compared to executable code isvery high. These parts of code should only be parsedif they are needed for example when visualizing themodels. Thus a second optimized parser could be in-troduced for annotations.

Performance issues are a big problem in our ap-proach. Comparing the parser generated by Xtext withthe one of the Modelica SDK[11] [12] which is basedon the same parser generator technology (ANTLR)might be useful in finding the reasons for these prob-lems. Furthermore the mechanisms of verificationshould be compared regarding completeness and per-formance.

A nice feature to have is an editor that allows the de-veloper to compose models from components graphi-cally, like Dymola does. As we use Ecore as basisfor our data, the Graphical Modeling Project Graph-ical Modeling Project (GMP)10 might be a suitablesolution for this task. However, the embedding ofgraphical information inside annotations of the Mod-elica documents instead of separate files might causeproblems when using GMP. In our opinion, layout in-formation and executable code should be separated asboth are independent concerns.

Furthermore, the refactoring of Modelica modelsshould be addressed in the future. Many of the refac-torings introduced in [7] would be helpful in Model-ica, as it is suitable for most object oriented languages.In [6] an impressive way of source code refactoring byrole definitions is explained and demonstrated basedon EMFText11. At the moment serializing with Xtextis error-prone and therefore prevented us from inte-grating the refactoring tool into our project. Thiswill be done as soon as the serialization problems aresolved.

10http://www.eclipse.org/modeling/emf/11http://www.emftext.org/index.php/EMFText

References

[1] J. Bastian, O. Enge-Rosenblatt, P. Schneider:MOSILAB - a Modelica solver for multiphysicsproblems with structural variability. Conferenceon Multiphysics Simulation - Advanced Methodsfor Industrial Engineering, January, 2010, Bonn,Germany

[2] The Object Management Group(OMG): OCL 2.2 Specification. 2010,http://www.omg.org/spec/OCL/2.2

[3] T.J. Parr, R.W. Quong: ANTLR: A Predicated-LL(k) Parser Generator. Software | Practice andExperience 25(7) (1995) 789-810

[4] F. Budinsky, S.A. Brodsky, E. Merks: EclipseModeling Framework. Pearson Education, 2003

[5] M. Seifert, R. Samlaus: Static Source CodeAnalysis using OCL. In: Proceedings of theWorkshop OCL Tools: From Implementation toEvaluation and Comparison, OCL 2008, Satel-lite event of the 11th International Conference onModel Driven Engineering Languages and Sys-tems (MoDELS 2008), September 28 - October3, 2008, Toulouse, France

[6] J. Reimann, M. Seifert, U. Assmann: Role-BasedGeneric Model Refactoring. In: Lecture Notes inComputer Science (LNCS 6395) - Model DrivenEngineering Languages and Systems, Springer,2010, 78-92

[7] M. Fowler: Refactoring: Improving the Designof Existing Code, Addison-Wesley, Boston, MA,1999

[8] D. Steinberg, F. Budinsky, M. Paternostro, E.Merks: EMF: Eclipse Modeling Framework,Addison-Wesley, 2009

[9] Language Specification, Modelica - A Uni-fied Object-Oriented Language for PhysicalSystems Modeling Version 3.1, May, 2009,https://www.modelica.org

[10] T. Parr: The Definitive ANTLR Reference:Building Domain-Specific Languages, Prag-matic Bookshelf, May, 2007

[11] M. Tiller: Parsing and Semantic Analysis ofModelica Code for Non-Simulation Applica-tions, In: Proceedings of the 3rd International

Modelica Conference, November 3-4 2003,Linköping, Sweden

[12] P. Harman, M. Tiller: Building Modelica Toolsusing the Modelica SDK, In: Proceedings 7thModelica Conference, September 20-22 2009,Como, Italy

[13] M. Krebs: Verifikation von Modelica-Programmen mit OCL, Diploma thesis, TUDresden 2010