The goal of this research has been to lower the threshold for adopting model-driven engineering, or at least some of its principles, into ordinary daily
software engineering. Of course, this work has very little impact alone, but we believe it takes a step in the approximately right direction.
The research has been motivated by the author’s beliefs that
• model-driven engineering is primarily about an organization learning, discovering, understanding and defining how they develop and how they want to develop certain kind of software and only secondarily about tooling or code generation;
• tools should support the existing way of working, not force a new way of working on the user;
• design tools should not prevent reasonable user actions just because they have not been foreseen; and
• a tool should rather solve one recognized and understood sub-problem well and degrade gracefully than solve all the sub-problems poorly and not allow the user to intervene.
These beliefs have only been strengthened in the course of the research.
Model-driven engineering requires skills from at least the areas of process engineering, language design, generative programming as well as software engineering, and is very demanding. It is very difficult, if not impossible, to get everything right on the first try. In all of the empirical studies even the modeling languages underwent changes. Since the early guesses are almost guaranteed to be wrong, it would be foolish to restrict the application de-signers’ actions to exactly those that have been guessed. This only leads to inflexible tooling that forces the user to either accept the tool-dictated way or dump the tool.
We followed the strategy of reducing the penalty of guessing wrong. Short iterations reduce the wasted effort and time before a guess is corrected. More importantly, preplanned interaction and free model editing add flexibility to the model transformation. This means that the user can, in a way, choose to use only the working part of the model transformation and work around the bad guesses. The flexibility reduces the time the model transformation is useless because of a bad guess, and mitigates the penalty.
To summarize, we think there is a need for model-driven engineering in software engineering, as long as it is understood as an approach and not from an overly technical tool-oriented perspective. Tools—programs, languages, methods, models—are needed, but they need to take a role supporting the main goal of process improvement. We demonstrated that interactive model
transformations can be created with relatively small effort and yet yield ben-efits in situations where even estimating the effort to produce a fully auto-matic complete transformation was impossible. The low-hanging fruits seem to hang much much lower than the highest ones.
Bibliography
[1] N. Aizenbud-Reshef, B. T. Nolan, J. Rubin, and Y. Shaham-Gafni.
Model traceability. IBM Systems Journal, 45(3):515–526, 2006.
[2] C. Alexander, S. Ishikawa, and M. Silverstein. A Pattern Language:
Towns, Buildings, Construction. Oxford University Press, 1977. ISBN 0-1950-1919-9.
[3] F. Altheide, H. D¨orr, and A. Sch¨urr. Requirements to a framework for sustainable integration of system development tools. In Proceedings of the third European Systems Engineering Conference, pages 53–57, Toulouse, France, 2002.
[4] K. Beck. Implementation Patterns. Addison-Wesley Professional, 2007.
ISBN 0-321-41309-1.
[5] J. B´ezivin, N. Farcet, J.-M. J´ez´equel, B. Langlois, and D. Pollet. Reflec-tive model driven engineering. In P. Stevens, J. Whittle, and G. Booch, editors, UML 2003 – The Unified Modeling Language, Modeling Lan-guages and Applications, volume 2863 of Lecture Notes on Computer Science, pages 175–189. Springer, 2003.
[6] J. B´ezivin and F. Jouault. Using ATL for checking models. In G. Karsai and G. Taentzer, editors, Proceedings of the International Workshop on Graph and Model Transformation (GraMoT 2005), volume 152 of Elec-tronical Notes in Theoretical Computing, pages 69–81. Elsevier, 2006.
[7] J. Bosch. Design & Use of Software Architectures. Pearson Education Limited, Harlow, UK, 2000. ISBN 0-201-67494-7.
[8] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, editors. Pattern Oriented Software Architecture Volume 1: A System of Patterns. John Wiley & Sons Ltd., Baffins Lane, Chichester, England, 2001. ISBN 0-471-95869-7.
[9] CMT. Home page of European Workshop on Composition of Model Transformations, 2006. On-line at http://ew-cmt.ewi.utwente.nl/.
[10] E. F. Codd. A relational model of data for large shared data banks.
Communications of the ACM, 13(6):377–387, 1970.
[11] T. Connolly and C. Begg. Database Systems: A Practical Approach to Design, Implementation, and Management. Pearson Education Limited, Essex, UK, third edition, 2002. ISBN 0-201-70857-4.
[12] J. S. Cuadrado and J. G. Molina. Approaches for model transformation factorization and composition. In A. Vallecillo, J. Gray, and A. Pieran-tonio, editors, Theory and Practise of Model Transformations, volume 5063 of Lecture Notes on Computer Science, pages 168–182, Z¨urich, Switzerland, 2008. Springer.
[13] C. J. Date. An Introduction to database systems. Addison Wesley Long-man, Inc., Boston, MA, USA, 7th edition, 2000. ISBN 0-201-38590-2.
[14] J. de Lara and H. Vangheluwe. AToM3: A tool for multi-formalism and meta-modelling. InFASE ’02: Proceedings of the 5th International Conference on Fundamental Approaches to Software Engineering, pages 174–188, London, UK, 2002. Springer-Verlag.
[15] J. Dick. Rich traceability. InProceedings of the 1st International Work-shop on Traceability in Emerging Forms of Software Engineering, Ed-inburgh, Scotland, September 2002. On-line athttp://www.soi.city.
ac.uk/~zisman/WSTPapers/Dick.pdf.
[16] Eclipse. Eclipse - an open development platform, 2007. On-line at http://www.eclipse.org/.
[17] Eclipse. Model Development Tools (MDT), 2009. On-line at http://
www.eclipse.org/modeling/mdt/?project=uml2tools.
[18] R. T. Fielding. Architectural styles and the design of network-based software architectures. PhD thesis, University of California, Irvine, 2000.
ISBN 0-599-87118-0.
[19] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design patterns: ele-ments of reusable object-oriented software. Addison-Wesley Professional, 1995. ISBN 0-201-63361-2.
[20] B. Hailpern and P. Tarr. Model-driven development: The good, the bad, and the ugly. IBM Systems Journal, 45(3):451–461, 2006. ISSN 0018-8670.
[21] I. Hammouda, J. Koskinen, M. Pussinen, M. Katara, and T. Mikkonen.
Adaptable concern-based framework specialization in UML. In Proceed-ings of ASE 2004, pages 78–87. IEEE Computer Society, September 2004.
[22] F. Jalili and J. H. Gallier. Building friendly parsers. InProceedings of the 9th ACM SIGPLAN-SIGACT symposium on Principles of programming languages, pages 196–206. ACM, 1982.
[23] P. J¨arvinen. On research methods. Opinpajan kirja, Tampere, Finland, 2004. ISBN 952-99233-1-7.
[24] S. Kent. Model Driven Engineering. In M. Butler, L. Petre, and K. Sere, editors, Integrated Formal Methods, Third International Conference, IFM 2002, Turku, Finland, May 15-18, 2002, Proceedings, volume 2335 of Lecture Notes on Computer Science, pages 286–298. Springer, 2002.
[25] A. Kleppe, J. Warmer, and W. Bast.MDA Explained: The Model Driven Architecture: Practice and Promise. Addison-Wesley, 2003. ISBN 0-321-19442-X.
[26] D. Kolovos, L. Rose, and R. Paige. The Epsilon Book, 2010. On-line at http://www.eclipse.org/gmt/epsilon/doc/book/.
[27] D. S. Kolovos, R. F. Paige, and F. A. C. Polack. The Epsilon Transfor-mation Language. In A. Vallecillo, J. Gray, and A. Pierantonio, editors, Theory and Practise of Model Transformations, First International Con-ference, ICMT 2008, Z¨urich, Switzerland, July 2008, Proceedings, vol-ume 5063 ofLecture Notes on Computer Science, pages 46–60. Springer, July 2008.
[28] I. Kurtev. Application of reflection in model transformation languages.
In A. Vallecillo, J. Gray, and A. Pierantonio, editors,Theory and Prac-tise of Model Transformations, volume 5063 of Lecture Notes on Com-puter Science, pages 199–213, Z¨urich, Switzerland, 2008. Springer.
[29] M. Laitkorpi, P. Selonen, and T. Syst¨a. Towards a model-driven process for designing ReSTful web services. In Proceedings of the 7th Interna-tional Conference on Web Services (ICWS 2009), pages 173–180. IEEE Computer Society, July 2009.
[30] A. MacDonald, D. Russel, and B. Atchison. Model-driven development within a legacy system: An industry experience report. In Australian Software Engineering Conference, Nordic Journal of Computing, pages 14–22, 2005.
[31] S. Mellor and A. Watson. Roles in the MDA process, 2006. On-line at http://www.omg.org/registration/Roles_in_MDA1.pdf.
[32] T. P. Moran and J. M. Carroll. Design rationale: concepts, techniques, and use. Lawrence Erlbaum Associates, 1996. ISBN 0-8058-1566-5.
[33] H. A. M¨uller, J. H. Jahnke, D. B. Smith, M.-A. Storey, S. R. Tilley, and K. Wong. Reverse engineering: a roadmap. In ICSE ’00: Proceedings of the Conference on The Future of Software Engineering, pages 47–60.
ACM Press, July 2000.
[34] OMG. MDA guide version 1.0.1, 2003. On-line at http://www.omg.
org/cgi-bin/apps/doc?omg/03-06-01.pdf.
[35] OMG. Model Driven Architecture (MDA), 2007. On-line at http://
www.omg.org/mda/.
[36] F. A. Pieter Van Gorp and D. Janssens. Traceability and fine-grained constraints in interacitve inconsistency management. In T. N. J. Oldevik and J. Aagedal, editors,Second ECMDA Traceability Workshop, Bilbao, Spain, 2006.
[37] L. Richardson and S. Ruby. ReSTful Web Services. O’Reilly Media, 2007. ISBN 978-0596529260.
[38] G. Rozenberg, editor. Handbook of graph grammars and computing by graph transformation: volume I. foundations. World Scientific Publish-ing Co., Inc., River Edge, NJ, USA, 1997. ISBN 98-102288-48.
[39] M. Siikarla, J. Peltonen, and J. Koskinen. Towards unambiguous model fragments. In Selected papers of the fourth nordic workshop on UML and software modelling (NWUML’06), June 12-14, 2006, volume 13 of Nordic Journal of Computing, pages 180–195. Publishing Association Nordic Journal of Computing, 2006.
[40] R. Silaghi, F. Fondement, and A. Strohmeier. “Weaving” MTL model transformations. In U. Aßmann, M. Aksit, and A. Rensink, edi-tors, Model Driven Architecture, European MDA Workshops: Foun-dations and Applications, MDAFA 2003 and MDAFA 2004, Twente,
The Netherlands, June 26-27, 2003 and Link¨oping, Sweden, June 10-11, 2004, Revised Selected Papers, volume 3599 of Lecture Notes in Com-puter Science, pages 123–138. Springer, 2005.
[41] M. Staron. Adopting model driven software development in industry – a case study at two companies. In O. Nierstrasz, J. Whittle, D. Harel, and G. Reggio, editors, Model Driven Engineering Languages and Sys-tems, volume 4199 of Lecture Notes on Computer Science, pages 57–72, Genova, Italy, 2006. Springer.
[42] G. Taentzer. AGG: A graph transformation environment for modeling and validation of software. In J. L. Pfaltz, M. Nagl, and B. B¨ohlen, editors, Applications of Graph Transformations with Industrial Rele-vance, Second International Workshop, AGTIVE 2003, Charlottesville, VA, USA, September 27 - October 1, 2003, Revised Selected and In-vited Papers, volume 3062 ofLecture Notes in Computer Science, pages 446–453. Springer-Verlag, 2004.
[43] The Middleware Company. Model driven development for J2EE utilizing a model driven architecture (MDA) approach, 2003. On-line athttp://
www.omg.org/mda/mda_files/MDA_Comparison-TMC_final.pdf.
[44] W. M. P. Van Der Aalst, A. H. M. Ter Hofstede, B. Kiepuszewski, and A. P. Barros. Workflow patterns. Distributed and Parallel Databases, 14(1):5–51, 2003.
[45] P. van Gorp and D. Janssens. CAViT: a consistency maintenance frame-work based on visual model transformation and transformation con-tracts. In J. Cordy, R. L¨ammel, and A. Winter, editors,Transformation Techniques in Software Engineering, number 05161 in Dagstuhl Semi-nar Proceedings, pages 372–377, Schloss Dagstuhl, Germany, 2005. IEEE Computer Society.
[46] D. Varr´o. Model transformation by example. In O. Nierstrasz, J. Whit-tle, D. Harel, and G. Reggio, editors, Model Driven Engineering Lan-guages and Systems, volume 4199 ofLecture Notes on Computer Science, pages 410–424, Genova, Italy, 2006. Springer.
[47] D. Varr´o and Z. Balogh. Automating model transformation by example using inductive logic programming. InSAC ’07: Proceedings of the 2007 ACM Symposium on Applied Computing, pages 978–984, New York, NY, USA, 2007. ACM.
[48] W3C. Web Application Description Language, 2009. On-line athttp://
www.w3.org/Submission/wadl/.
[49] D. Wagelaar. Composition techniques for rule-based model transforma-tion languages. In A. Vallecillo, J. Gray, and A. Pierantonio, editors, Theory and Practise of Model Transformations, volume 5063 ofLecture Notes on Computer Science, pages 152–167, Z¨urich, Switzerland, 2008.
Springer.
[50] M. Wimmer, M. Strommer, H. Kargl, and G. Kramler. Towards model transformation generation by-example. In Proc. of the 40th Annual Hawaii International Conference on System Sciences, page 285b. IEEE Computer Society, 2007.
Appendix A: Model Transformation Language Syntax
transformation = namespace def+ (pattern def | rule def)+ namespace def = NS ID ”{” TYPE ID (”,” TYPE ID)* ”}”
pattern def = ”pattern” PATT ID ”{” decision def* graph ”}”
rule def = ”rule” RULE ID ”{” lhs ”=>” rhs ”}”
lhs = graph (”nac” graph)*
rhs = graph
graph = (structural | attribute | pattern |distinct | inline)+ structural = node (edge node)* | node MERGE node pattern = PATT NODE ID ”:” PATT ID
node = node def | node ref node def = NODE ID ”:” TYPE ID
node ref = NODE ID | PATT NODE ID ”.” TASK ID edge = OUT EDGE | IN EDGE
OUT EDGE = ”-->” | ”--#?{id}-->”
IN EDGE = ”<--” | ”<--#?{id}--”
MERGE = ”+>” | ”<+”
attribute = node ref ”{” keyval list ”}”
keyval list = keyval ((”,” | ”;”) keyval)*
keyval = ATT ID ”=” value | ATT ID ”in” attr ref attr ref = node ref ”.” ATT ID
distinct = ”distinct” ”{” node ref (”,” node ref)* ”}”
inline = <Java code injection >
decision def = DEC GROUP node def (”,” node def)* ”;”
DEC GROUP = ”decision”| ”context”| ”visiting” COMMENT = ”//.*”
Whitespace, line breaks and comments can appear between any tokens.
[I] M. Siikarla, K. Koskimies, and T. Syst¨a. Open MDA using transfor-mational patterns. In U. Aßmann, M. Aksit, and A. Rensink, editors, Model Driven Architecture, European MDA Workshops: Foundations and Applications, MDAFA 2003 and MDAFA 2004, Revised Selected Papers, volume 3599 ofLecture Notes in Computer Science, pages 108–
122. Springer, 2005. c Springer-Verlag Berlin Heidelberg 2005
Open MDA Using Transformational Patterns
Mika Siikarla, Kai Koskimies, and Tarja Syst¨a Tampere University of Technology, Institute of Software Systems,
P.O.Box 553, FI-33101 Tampere, Finland {mika.siikarla, kai.koskimies, tarja.systa}@tut.fi
http://practise.cs.tut.fi
Abstract. No generally accepted understanding on the characteristics of MDA transformation mechanisms exists. Various approaches to sup-port such transformations have been proposed. In this paper, we discuss general requirements for MDA transformation mechanisms. We claim that, above all else, transformation mechanisms should be open, i.e. clear, transparent and user-guided. We propose a new concept, a transforma-tional pattern, as a basis of an MDA transformation mechanism. We exploit existing tool support for this concept and show a small example of how it can be applied. Finally, we analyse the ability of the proposed technique to fill the requirements.
1 Introduction
A clearly identified long-term trend in software engineering is the introduction of higher and higher abstractions from which actual implementations are derived.
OMG’s Model-Driven Architecture (MDA) initiative [1] is a recent manifesta-tion of this trend. A key idea in MDA is that system development should be based on high-level, platform independent models (PIM) from which lower level platform-specific models (PSM) and eventually implementations are derived with the support of transformation tools.
Although the vision behind MDA is generally accepted, the required tool technology is just taking its first steps. Some early tool support exists (e.g., ArcStyler [2]), but the underlying concepts and paradigms of the tools are far from well understood, if even existing.
Obviously, there are many ways to specify and execute transformations from one model to another. A straightforward approach to specify the transformations in an executable form would be a script language with access to a model repos-itory and appropriate navigation and query capabilities. Then, transformations could be realized simply as scripts.
The real challenge of MDA transformation tool support is not in devising the computational vehicle, but rather in the collaboration of the designer and the tool. A simple black-box approach (e.g. a Python script) would hide the relationship between the source and the target model from the designer, making it very difficult to work with the result. If the path from a platform independent model to executable implementation were completely automated, this would
U. Aßmann, M. Aksit, and A. Rensink (Eds.): MDAFA 2003/2004, LNCS 3599, pp. 108–122, 2005.
c
Springer-Verlag Berlin Heidelberg 2005
Open MDA Using Transformational Patterns 109 not be a problem, but we argue that this is an unrealistic idea, at least in the near future. Typically, the designer has to examine the result, understand it, and apply further transformations or modifications on some parts of the result.
Thus, we propose that an MDA transformation tool should be open in the sense that it allows the designer to be involved in the transformation process.
In this paper we will first discuss the required properties of an MDA trans-formation mechanism in more detail. As a potential approach to satisfy these requirements, we introduce the concept of a transformational pattern, which we believe can serve as the basis of open MDA transformations. This concept is an application of a generic pattern facility originally developed for supporting framework specialization [3]. We demonstrate the use of this technique by show-ing how a J2EE model can be generated from a platform-independent UML model for a Web Services application. Based on this example, we briefly analyse the extent to which this approach meets the requirements. Finally, we discuss related work and the future directions of our work.
2 MDA Transformation Mechanics
We see the primary role of a transformation as documenting the relations be-tween different models of the same system. With this added information ex-pressed in computer readable form, the models can be kept synchronized and a change in one model does not render all other models obsolete. This is absolutely vital for MDA. The description of these relations, i.e. therecord of transforma-tionaccording to [4], contains unique information about the system, and should therefore be considered a model itself.
Another important, although secondary, role is to support the designer in de-riving one model from others, by alleviating the burden of at least the repetitious and trivial tasks. In some very specialized cases, such as a specific product-line, it might be possible to achieve fully automated transformations. However, it seems overly optimistic to expect fire-and-forget solutions for all possible situations any time soon. The intermediate, or derived, models do therefore contain more information than just what is derived. They have value as original artefacts and should not be considered as mere documentation.
In our view, transformation definitions are software artefacts. They are sub-ject to evolution the same way design models or program files are. We expect, for example, that a set of model transformations can be given for a product-line platform to be used for the derivation of the designs for individual software products. Such a set of transformations is an integral part of the product-line and goes through changes and versions together with the other assets belong-ing to the product-line. It is likely, in fact, that the transformation mechanisms themselves need maintenance and evolve as the subject system does.
We raise openness as the most important property that is required of an MDA transformation mechanism. The designer should participate in the trans-formation process, guiding it with her decisions, rather than receive the results of a black-box operation as an outsider. The mechanism itself should be trans-parent, allowing the designer to follow how the models are being manipulated.
110 M. Siikarla, K. Koskimies, and T. Syst¨a
The meaning of every step in the transformation process should be clear. When using a clear and transparent machinery, the designer is better equipped to make decisions affecting the transformation. She can be trusted to make an educated choice between possible courses of action even during the transformation.
We argue that the open approach is safer, allowing the designer to understand the resulting model and modify it, if needed. In the black-box case modification of the result is risky, because the designer does not understand the purpose of different parts of the result, and therefore cannot judge the relationship elements in the target and source models. Note, that a part not dependent on the source model can be altered without compromising the relationships between the mod-els. In the absence of fully automated transformations, it would be unreasonable to completely forbid modifications of the resulting model.
In some cases, where no single transformation process can be found for a cat-egory of systems, it is still possible to find transformation principles that apply to each of the systems. E.g. software products developed from the same product-line, or systems belonging to a particular application domain, might form such categories. The transformation mechanism should supportcustomisable trans-formations that contain the common principles and provide variation points for customisation. Unlike with direct editing of the result, some customisation needs are foreseen and built into the transformation.
It is possible that some part in the target model resulting from applying a transformation is not considered acceptable for the particular application. In-stead of trying to guess what changes in the source would lead to the desired result, it should be possible to change the result directly and produce a source model corresponding to the modified result. In cases where the source or
It is possible that some part in the target model resulting from applying a transformation is not considered acceptable for the particular application. In-stead of trying to guess what changes in the source would lead to the desired result, it should be possible to change the result directly and produce a source model corresponding to the modified result. In cases where the source or