Lessons Learned from Building Model-Driven Development Tools
Total Page:16
File Type:pdf, Size:1020Kb
Noname manuscript No. (will be inserted by the editor) Lessons Learned from Building Model-Driven Development Tools Richard F. Paige1 and D´anielVarr´o2 Department of Computer Science, University of York, UK. e-mail: [email protected] Department of Measurement and Information Systems Budapest University of Technology and Economics, Hungary. e-mail: [email protected] The date of receipt and acceptance will be inserted by the editor Abstract Tools to support modelling in system and of MDD tools. The principles will be distilled from an software engineering are widespread, and have reached analysis of the development of two MDD tools that are a degree of maturity where their use and availability used in practice: VIATRA and Epsilon. These tools are are accepted. Tools to support Model-Driven Develop- used in industry, on real projects, and have developed ment (MDD) { where models are manipulated and man- in very different ways. Arguably, some of the lessons aged throughout the system/software engineering lifecy- learned from the development of these tools can inform cle { have, over the last ten years, seen much research the development of new MDD tools, and can also be and development attention. Over the last ten years, we used to support the evolution of existing tools. Our ob- have had significant experience in the design, develop- jective is not to propose the \ideal" MDD tool; such a ment and deployment of MDD tools in practical settings. tool is unlikely to exist. However, the principles under- In this paper, we distill some of the important lessons pinning the development of MDD tools that are widely we have learned in developing and deploying two MDD used in practice can help in assessing existing tools, and tools: Epsilon and VIATRA. In doing so, we aim to iden- in improving them. tify some of the key principles of developing successful To elicit and present the lessons learned, the paper MDD tools, as well as some hints of the pitfalls and risks. will summarise the development of Epsilon and VIA- TRA, starting from initial use cases and system require- ments, leading to an initial tool architecture. Evolution- ary steps (e.g., refactorings) will be discussed and pre- 1 Introduction sented, along with the triggers { which included both re- quests for new functionality, as well as requests related to The last ten years have seen the development of nu- non-functional characteristics such as performance and merous tools for supporting Model-Driven Development scalability { that led to these refactorings. (MDD): the manipulation and analysis of structured de- The paper is structured as follows. Section 2 de- scriptions. MDD tools such as ATL [23], xText [42], Ep- scribes the development and evolution of Epsilon and silon [16], VIATRA [5], ATOM3 [15], KerMeta [29], Ac- VIATRA, focusing on initial motivation and scenarios, celeo [1], FUJABA [13], MOFLON [3], GReAT [2] and as well as some of the most important evolutionary steps. many others have been developed and deployed in a vari- Section 3 distills some of the key take-home messages ety of software and systems engineering contexts. Many from these developments. We conclude in Section 4. of these tools are the result of research and development on specific industrial use cases; others are the result of theoretical and conceptual research. Some are now be- 2 Evolution of MDD Tools ing applied on large-scale software engineering projects and are being turned into products. As such, the field of This section presents the development and evolution of MDD tool development has reached a sufficient level of two MDD tools: Epsilon and VIATRA. Both Epsilon and maturity for its results to be assessed, and distillation of VIATRA are predominantly textual tools, featuring tex- lessons learned from the development of these tools can tual languages for specifying and executing MDD tasks. take place. Each part describes the tool as it currently exists, then This paper aims to identify some of the principles talks about its development cycle. The development of underpinning the design, implementation and evolution Epsilon starts with an initial use case, and then moves to 2 Paige and Varr´o a discussion of refactoring stages, including both techni- [35]) and unit testing of model management operations cal refactorings (i.e., to improve performance) and con- (EUnit). ceptual refactorings. The development of VIATRA starts The core language in Epsilon is EOL; all other lan- from model transformation requirements, including sig- guages in Epsilon reuse EOL in some way, as it pro- nificant requirements for performance, and then broad- vides the conceptually common features required for ma- ens its scope to include other MDD tasks. nipulating and analysing models. In particular, it sup- ports navigation of models (via OCL-like expressions and queries), modification of models (via assignment 2.1 The design and evolution of Epsilon statements), and multiple-model access capabilities. How- ever, EOL was { at least conceptually { not the first lan- guage to be developed; it emerged from the development 2.1.1 Epsilon Epsilon [16] is a tool for model manage- of a different Epsilon language, as we now discuss. ment, specifically for analysing and manipulating models in specific ways. More precisely, it is a set of textual task- 2.1.2 Initial use case and architecture The use case that specific model management languages, and a framework triggered the development of Epsilon was one of model for implementing new model management languages by merging. Model merging is the process of combining two exploiting the existing ones. It is a component of the or more source models (possibly from different modelling Eclipse Model Framework Technology (EMFT) project. languages) into a target model (which may conform to From a user's perspective, Epsilon provides a set of a completely different metamodel than the source mod- inter-related and largely interoperable languages that els). The model merging scenarios that were of interest can be used to implement and execute various model were two-fold: management tasks. The current architecture of Epsilon is illustrated in Figure 1. { support for version control on models, including com- bining different versions of models, identifying differ- ences, etc. { support for merging behavioural models (e.g., state Model Migration (Flock) Unit Testing (EUnit) machines, sequence diagrams). Our research suggested that the process of model merg- Model Refactoring (EWL) Model Validation (EVL) ing could be separated into four stages: 1.A comparison phase, where correspondences between Model Comparison (ECL) Model Merging (EML) equivalent elements of source models are identified; 2.A conformance checking phase, where corresponding M2M Transformation (ETL) M2T Transformation (EGL) elements identified in the previous phase are exam- ined to identify conflicts that may render merging impossible. This phase was particularly important Epsilon Object Language for version control, i.e., when merging models of the same metamodel. Epsilon Model Connectivity 3.A merging phase, where corresponding and conform- ing elements are combined; and EMF driver MDR driver XML driver Z driver 4.A reconciliation phase, where any inconsistencies in- troduced in the merging phase are resolved. What is revealing about this separation is that each Fig. 1 Epsilon model management platform phase { comparison, `checking', merging { is an oper- ation that we might want to apply to models. Indeed, it was this observation that suggested that model merging Epsilon consists of a set of textual languages (each itself was a composite operation that can be applied to including parsers, editing tools, and interpreters/virtual models { that is, merging was constructed from other machines), a connectivity framework (more on that later), model management operations. and some additional tools to help ease development. Each This raised the question what did model management language has further development tools (e.g., syntax- operations have in common? To this end, we investi- aware editors). Each language aims to support a par- gated model transformation, merging, constraint check- ticular model management task. More specifically, there ing (e.g., via OCL) and model-to-text transformation, is a language for direct manipulation of models (EOL) and identified a small set of features that all these oper- [26], as well as languages for model merging (EML) [24], ations have in common: model comparison (ECL) [25], model-to-model transfor- mation (ETL) [27], model validation (EVL) [28], model- { navigating models; to-text transformation (EGL) [36], model migration (Flock) { accessing multiple models simultaneously; Lessons Learned from Building Model-Driven Development Tools 3 { evaluating expressions on models; 2.1.3 Conceptual refactoring After designing and im- { modifying models plement EOL and EML, and fulfilling our initial require- We also noticed that different MDD tools tended to ments and use cases, we took a step back and studied reimplement many of these common features using non- the core features of EML. In particular, we observed two standard syntaxes, thus rendering interoperability of tools recurring patterns in the logic of the merging programs more difficult (in part because syntax transformation that we were writing in EML: would have to take place) We argued [26] that there was { Significant parts of the EML programs focused on substantial value in encapsulating these features so that writing the expressions that would compare the mod- they could be reused in different operations that required els. In many places, these expressions would be re- them. This was the genesis of the core language of Ep- peated. A reusable operation concept was added to silon { EOL { and the conceptual architecture depicted EOL to simplify EML programs, but even with this in Figure 1. there was still substantial opportunities for reuse of In parallel with this conceptual process, we obtained comparison logic that was not supported by EOL (or (from our collaborators who provided the initial use case) EML).