Model-Driven Software Development
123
Model-Driven
Software Development
With 195 Figures and 5 Tables
Library of Congress Control Number: 2005927903 ACM Computing Classification (1998): D.2.2, D.2.11
ISBN-10 3-540-25613-X Springer Berlin Heidelberg New York ISBN-13 978-3-540-25613-7 Springer Berlin Heidelberg New York
This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilm or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable for prosecution under the German Copyright Law.
Springer is a part of Springer Science+Business Media springeronline.com
© Springer-Verlag Berlin Heidelberg 2005 Printed in Germany
The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.
Cover design: KünkelLopka, Heidelberg Typesetting: Camera ready by the editors
Production: LE-TeX Jelonek, Schmidt & Vöckler GbR, Leipzig Printed on acid-free paper 45/3142/YL - 5 4 3 2 1 0 Editors
Sami Beydeda
Federal Finance Office (Bundesamt für Finanzen) Friedhofstr. 1
53225 Bonn, Germany [email protected] Matthias Book
Volker Gruhn
Chair of Applied Telematics/e-Business Department of Computer Science University of Leipzig
Klostergasse 3
04109 Leipzig, Germany
One of the basic principles of software engineering is abstraction, which mainly refers to separation of the essential from the non-essential. In terms of software de- velopment, the essential usually refers to the functionality to be implemented and the non-essential to aspects such as the technical platform on which the software will eventually be deployed. However, non-essential aspects are not unimportant.
They also have to be considered when designing and developing a software system, but they do not have to be considered at the very first stage when more fundamental issues have to be considered.
Abstractions are provided by models. A model is mainly a representation of the essential aspects of the underlying subject and thus contains less complexity. Less complexity obviously allows the prediction of system characteristics, analyzing spe- cific properties, and also communicating with the various roles involved in the devel- opment process more easily. However, implementing a model means expressing it at a very low level of abstraction, i.e. at a level at which it is understood by a computer.
Modeling and model transformation to the required abstraction level constitute the core of model-driven development. In model-driven development, essential as- pects of software are expressed in the form of models, and transformations of these models are considered the core of software development. Models can particularly be transformed into a technical implementation, i.e. a software system. Such an ap- proach can avoid restricting oneself to a specific technology in the early stages of the development process and can ensure a consistent architecture throughout the life- cycle of a software system.
The aim of this book is to give an overview of the current achievements in model- driven development. In the introductory chapter Models, Modeling, and Model- Driven Architecture (MDA), Brown, Conallen and Tropeano first explain the ter- minology used in the following chapters of the book and introduce basic principles and methods in model-driven development. Achievements in model-driven develop- ment are then considered from a conceptual point of view in Part I of the book that comprises the following chapters:
• A Systematic Look at Model Transformations.Metzger focuses on model trans- formations and presents a classification scheme to consider the differences be- tween the modeled system, the model itself and the formalism used.
• Tool-support for Model-Driven Development of Security-Critical Systems with UML.Jürjens and Shabalin show the use of UML in model-driven development.
In particular, they give a formal semantics for a subset of UML which can be used to analyze the interaction of a system with its environment and UML spec- ifications.
• Caste-Centric Modeling of Multi-Agent Systems: The CAMLE Modeling Lan- guage and Automated Tools.Zhu and Shan introduce the CAMLE approach to model-driven development of multi-agent systems by combining graphical mod- eling with formal specification.
• Using Graph Transformation for Practical Model Driven Software Engineering.
In this chapter, Grunske et al. consider model transformations using graph trans- formation theory, in particular to specify and apply model transformations.
• A Generalized Notion of Platforms for Model Driven Development. Atkinson and Kühne consider two of the basic terms in model-driven development, plat- form and platform model. They show the origin of these terms and propose an alternative definition for them.
Part II then considers technical achievements and technical infrastructures of model- driven development in the following chapters:
• A Tool Infrastructure for Model-Driven Development Using Aspectual Patterns.
Hammouda introduces a concern-based approach to model-driven development and presents a tool, called MADE, which particularly supports model generation, checking and tracing.
• Automatically Discovering Transitive Relationships in Class Diagrams. Egyed considers the problem of abstracting class diagrams of certain complexity with tool support. The approach proposed uses a large number of abstraction rules and is used for model understanding, consistency checking and reverse engineering.
• Generic and Domain-Specific Model Refactoring using a Model Transformation Engine.Zhang, Lin and Gray propose an approach for refactoring at the model level with the use of behavior-preserving transformations. Their chapter also cov- ers a model transformation engine for refactoring various types of models.
• A Testing Framework for Model Transformations.Lin, Zhang and Gray discuss validation and verification of model transformation at the model level rather than late in the development process at the source code level. The framework pre- sented is integrated in the transformation engine presented in the previous chapter and provides means for typical testing activities.
• Parallax – An Aspect-Enabled Framework for Plug-in-Based MDA Refinements Towards Middleware. Silaghi and Strohmeier present the Parallax framework, an open and extensible tool which particularly supports configuring application designs with regard to specific middleware concerns and adapting to different middleware infrastructures.
• Evolution and Maintenance of MDA Applications.Seifert and Beneken investi- gate the life cycle of applications developed according to the model-driven devel- opment approach. They particularly focus on long-term aspects and consider the maintenance of such applications and the progress in model-driven development.
The chapters in Part III finally summarize experience gained in actual projects em- ploying model-driven development:
• Intents and Upgrades in Component-Based High-Assurance Systems.Elmqvist and Nadjm-Tehrani describe their experience using model-driven development in the area of high-assurance components, particularly components used as part of embedded systems.
• On Modeling Techniques for Supporting Model Driven Development of Proto- col Processing Applications.Alanen et al. use model-driven development in the area of protocol processing applications. They give an overview of a respective method and summarize their experience.
• An Integrated Model-driven Development Environment for Composing and Val- idating Distributed Real-time and Embedded Systems.Trombetti et al. employ model-driven development in the area of distributed real-time and embedded ap- plications. They present an integration of tool suites for model-driven develop- ment and model checking in this area.
• A Model-Driven Technique for Development of Embedded Systems Based on the DEVS formalism.Wainer, Glinsky and MacSween propose a model-driven ap- proach to the development of embedded systems with real-time constraints based on the formal technique of DEVS, and summarize their experience using this ap- proach.
• Model Driven Service Engineering.Bræk and Melby consider problems associ- ated with expressing platform-independent models and their behaviors, and also discuss how to handle implementation and platform-dependent properties. They suggest possible solutions to those problems based on their experience.
• Practical Insights into Model-Driven Architecture: Lessons from the Design and Use of an MDA Toolkit.Brown, Conallen and Tropeano finally summarize their experience in the design and use of a model-driven architecture toolkit at IBM.
Work on this book officially began in April 2004 with an email to theseworld mailing list, which was followed by individual invitations sent to the leading ex- perts of the field. Researchers and practitioners have been invited to summarize their research results and experience in model-driven development in the form of book chapters. Fortunately, we received a large number of very high-quality contributions, which shows that model-driven development will not be a short-lived hype in soft- ware engineering. We are very grateful for the contributions and would like to thank all authors for their effort.
Leipzig and Bonn, Sami Beydeda
May 2005 Matthias Book
Volker Gruhn
Acknowledgments
Inviting the leading researchers guaranteed a high quality of the individual chapters and thus of the book. However, we decided to conduct a peer review to further im- prove the chapters. The review was conducted with the support of a committee whose members reviewed the individual contributions and gave valuable remarks to revise and improve them. We would like to thank all committee members for their support;
without them, the book would not have its quality.
Committee Members
• Marcus Alanen, Johan Lilius, Ivan Porres, Dragos Truscan
Software Construction and Embedded Systems Laboratories, Turku Centre for Computer Science, Lemminkäisenkatu 14, FIN-20520 Turku, Finland
{marcus.alanen, johan.lilius, iporres, dragos.truscan}@abo.fi
• Alan W. Brown
IBM Software Group, 4205 S. Miami Blvd, Durham, NC 27703, USA [email protected]
• Rainer Burkhardt
JgenCy Project GmbH, Heidegarten 14, 98693 Martinroda, Germany [email protected]
• Alexander Egyed
Teknowledge Corporation, 4640 Admiralty Way, Suite 1010, Marina Del Rey, CA 90292, USA
• Jonas Elmqvist, Simin Nadjm-Tehrani
Department of Computer and Information Science, Linköping University, S-581 83 Linköping, Sweden
{jonel, simin}@ida.liu.se
• Leif Geiger, Albert Zuendorf
Department of Computer Science and Electrical Engineering, University of Kas- sel, Wilhelmshoeher Allee 73, 34121 Kassel, Germany
{leif.geiger, albert.zuendorf}@uni-kassel.de
• Aniruddha Gokhale
Department of Electrical Engineering and Computer Science, Vanderbilt Univer- sity, Box 1829, Station B, Nashville, TN 37235, USA
• Jeff Gray
Department of Computer and Information Sciences, University of Alabama at Birmingham, 126 Campbell Hall, 1300 University Boulevard, Birmingham, AL 35294-1170, USA
• Lars Grunske
School of Information Technology and Electrical Engineering, University of Queensland, Brisbane, QLD 4072, Australia
• Imed Hammouda
Institute of Software Systems, Tampere University of Technology, P.O. Box 553, FIN-33101 Tampere, Finland
• Jan Jürjens, Pasha Shabalin
Dept. of Informatics, Software & Systems Engineering, TU München, Boltz- mannstr. 3, 85748 München/Garching, Germany
{juerjens, shabalin}@in.tum.de
• Alpay Karagöz
Bilgi Grubu Ltd., Gumus Blk. No:3, ODTU Teknokent, 06531 Ankara, Turkey [email protected]
• Hubert B. Keller
Forschungszentrum Karlsruhe, Institut für Angewandte Informatik, Postfach 3640, 76021 Karlsruhe, Germany
• Philippe Kruchten
Dept. of Electrical & Computer Engineering, University of British Columbia, 2356 Main Mall, Room 441, Vancouver, BC V6T1Z4, Canada
• Thomas Kühne
Darmstadt University of Technology, Hochschulstr. 10, 64289 Darmstadt, Ger- many
• Michael Kunz
Stab Architektur IDG, Pohligstr. 3, D-50969 Köln, Germany [email protected]
• Andreas Metzger
Software Systems Engineering, University of Duisburg-Essen, Schützenbahn 70, 45117 Essen, Germany
• Raul Silaghi, Alfred Strohmeier
Software Engineering Laboratory, Swiss Federal Institute of Technology, CH- 1015 Lausanne EPFL, Switzerland
{raul.silaghi, alfred.strohmeier}@epfl.ch
• Niels Van Eetvelde, Pieter Van Gorp
University of Antwerp, Middelheimlaan 1, 2020 Antwerpen, Belgium {niels.vaneetvelde, pieter.vangorp}@ua.ac.be
• Dániel Varró
Department of Measurement and Information Systems, Budapest University of Technology and Economics, H-1117, Budapest, Magyar tudósok krt. 2, Hungary [email protected]
• Gabriel A. Wainer, Samuel Ajila, Yvan Labiche
Dept. of Systems and Computer Engineering, Carleton University, 4456 Macken- zie Bldg., 1125 Colonel By Drive, Ottawa, ON K1S 5B6, Canada
• Yun Yang
Faculty of Information and Communication Technologies (ICT), Swinburne Uni- versity of Technology, PO Box 218, Hawthorn, Melbourne, Victoria 3122, Aus- tralia
• Hong Zhu
Department of Computing, Oxford Brookes University, Oxford OX33 1HX, UK [email protected]
Last but not least, we would also like to thank Gerald Mücke, Matthias Pätzold and Falk Schütze for polishing the final manuscript of the book.
Introduction: Models, Modeling, and Model-Driven Architecture (MDA) Alan W. Brown, Jim Conallen, Dave Tropeano . . . 1
Part I Conceptual Foundations of Model-Driven Development A Systematic Look at Model Transformations
Andreas Metzger. . . 19 Tool Support for Model-Driven Development of Security-Critical
Systems with UML
Jan Jürjens, Pasha Shabalin. . . 35 Caste-centric Modelling of Multi-agent Systems: The CAMLE Modelling Language and Automated Tools
Hong Zhu, Lijun Shan. . . 57 Using Graph Transformation for Practical Model-Driven Software
Engineering
Lars Grunske, Leif Geiger, Albert Zündorf, Niels Van Eetvelde, Pieter Van
Gorp, Dániel Varró. . . 91 A Generalized Notion of Platforms for Model-Driven Development
Colin Atkinson, Thomas Kühne . . . .119
Part II Technical Infrastructure of Model-Driven Development A Tool Infrastructure for Model-Driven Development Using Aspectual Patterns
Imed Hammouda. . . .139
Automatically Discovering Transitive Relationships in Class Diagrams
Alexander Egyed. . . .179 Generic and Domain-Specific Model Refactoring Using a Model
Transformation Engine
Jing Zhang, Yuehua Lin, Jeff Gray. . . .199 A Testing Framework for Model Transformations
Yuehua Lin, Jing Zhang, Jeff Gray. . . .219 Parallax – An Aspect-Enabled Framework for Plug-in-Based MDA
Refinements Towards Middleware
Raul Silaghi, Alfred Strohmeier . . . .237 Evolution and Maintenance of MDA Applications
Tilman Seifert, Gerd Beneken. . . .269
Part III Case Studies
Intents and Upgrades in Component-Based High-Assurance Systems
Jonas Elmqvist, Simin Nadjm-Tehrani . . . .289 On Modeling Techniques for Supporting Model-Driven Development of Protocol Processing Applications
Marcus Alanen, Johan Lilius, Ivan Porres, Dragos Truscan . . . .305 An Integrated Model-Driven Development Environment for Composing and Validating Distributed Real-Time and Embedded Systems
Gabriele Trombetti, Aniruddha Gokhale, Douglas C. Schmidt, Jesse
Greenwald, John Hatcliff, Georg Jung, Gurdip Singh . . . .329 A Model-Driven Technique for Development of Embedded Systems
Based on the DEVS Formalism
Gabriel A. Wainer, Ezequiel Glinsky, Peter MacSween. . . .363 Model-Driven Service Engineering
Rolv Bræk, Geir Melby. . . .385 Practical Insights into Model-Driven Architecture: Lessons from the
Design and Use of an MDA Toolkit
Alan W. Brown, Jim Conallen, Dave Tropeano . . . .403 References. . . 433 Index . . . 459
Architecture (MDA)
Alan W. Brown, Jim Conallen, and Dave Tropeano IBM Software Group,
4205 S. Miami Blvd, Durham, NC 27703, USA
{awbrown, jconallen, davetropeano}@us.ibm.com
Summary. Models, modeling, and Model-Driven Architecture (MDA) are the basis for a set of development approaches known as model-driven development (MDD). Models are used to reason about a problem domain and design a solution in the solution domain. Relationships between these models provide a web of dependencies that record the process by which a solution is created, and help to understand the implications of changes at any point in that process.
In addition to creating these models, we can define rules for automating many of the steps needed to convert one model representation to another, for tracing between model elements, and for analyzing important characteristics of the models. This style of MDD is called Model- Driven Architecture (MDA). The MDA approach is being widely discussed in the software industry today as a way of increasing the quality, efficiency, and predictability of large-scale software development. In this paper we explore the role of modeling and the MDA style of MDD, and provide a useful context for understanding current product and research efforts in area of MDA.
1 Introduction
It is tempting to believe that software development is easy. You gain an understand- ing of the problem that needs to be addressed by talking with people familiar with that domain, and then design a solution to meet those needs and deploy it in the cus- tomer’s environment. Unfortunately, several issues can get in the way to make the task of software development a lot more challenging:
• We rarely, if ever, get a full understanding of the problem space. Domain experts help, but they, too, have a limited understanding of the areas they work in, view things from different perspectives, or disagree on approaches, processes, and pri- orities. So in practice, we spend a lot of time analyzing these different inputs and obtaining a common, evolving view of the customer’s domain.
• There are many constraints on the solutions to consider: for example, balancing the time and effort required to implement a system, integrating with existing applications and technologies already in place, and coordinating multiple teams producing different components of the deployed system.
• Many kinds of changes must be addressed at all stages of development: errors will be discovered, designs will be updated, requirements will be refined, priori- ties will be changed, implementations will be refactored, and so on. The dynamic nature of the development process results in a lot of time spent on understanding the impact of a change, defining a plan to address the change, and ensuring that any actions are carried out appropriately.
• A large software development task is an engineering project involving teams of people with different skills interacting over an extended period of time to im- plement a solution that can never truly be said to be “finished.” As a result, all the techniques of managing engineering projects must be taken into account:
scheduling, resource management, risk mitigation, ROI analysis, documentation, support, and so on.
Software engineers turn to many techniques to address these challenges. One of the most fundamental is the use of models and modeling. Models provide ab- stractions of a physical system that allow engineers to reason about that system by ignoring extraneous details while focusing on the relevant ones. All forms of engi- neering rely on models as essential to understanding complex real-world systems.
Models are used in many ways: predicting system qualities, reasoning about specific properties when aspects of the system are changed, and communicating key system characteristics to its various stakeholders. The models may be developed as a pre- cursor to implementing the physical system, or they may be derived from an existing system or a system in development as an aid to understanding its behavior [386].
There are many aspects of a system that may be of interest. Depending on what is considered relevant at any point in time, various modeling concepts and nota- tions may be used that highlight one or more particular perspectives, or views, of that system. Furthermore, in some instances models can be augmented with hints, or rules, that assist in transforming them. For example, it is often necessary to convert between different views of the system at an equivalent level of abstraction (e.g., be- tween a structural view and a behavioral view), and model transformations facilitate this. In other cases, a transformation converts models offering a particular perspec- tive between levels of abstraction, usually from a more abstract to less abstract view by adding more detail supplied by the transformation rules.
These ideas of models, modeling, and model transformation are the basis for a set of software development approaches that are known as model-driven develop- ment (MDD). Models are used to reason about the problem domain and the solution domain. Relationships between these models provide a web of dependencies that record the process by which a solution was created, and help us to understand the implications of changes at any point in that process.
In fact, we can be quite prescriptive in the use of models in a software devel- opment process. If we define the kinds of models that must be produced, and apply some rigor to the precise semantics of these models, we can define rules for:
• Automating many steps needed to convert one model representation to another.
• Tracing between model elements.
• Analyzing important characteristics of the models.
This style of MDD, called Model-Driven Architecture (MDA), is championed by the Object Management Group (OMG). It is based on a set of emerging standards for how to define a set of models, notations, and transformation rules. The MDA approach provides an open, vendor-neutral basis for system interoperability via OMG’s established modeling standards: Unified Modeling Language (UML), Meta- Object Facility (MOF), and Common Warehouse Metamodel (CWM). Platform- independent descriptions of enterprise solutions can be built using these modeling standards and can be transformed into a major open or proprietary platform, includ- ing CORBA, J2EE, .NET, XMI/XML, and Web-based platforms [324].
MDA styles of development are being widely discussed in the software industry today as a way of increasing the quality, efficiency, and predictability of large-scale software development [135, 115, 114]. However, few documented experiences with the use of MDA styles of development are available. In this paper we explore the role of modeling and the MDA style of the MDD development, and provide a use- ful context for understanding current product and research efforts in area of MDA.
Our work is based on a number of experiences, including creation and use of an MDA toolkit developed to extend an existing modeling workbench to support MDA styles of development for particular customer situations in which families of related software applications were being created within a single domain. We believed MDA offered the best means to capture commonalty in the problem domain, express trans- formation rules that convert the problem understanding into a candidate solution, and repeatably to generate major parts of that solution to the customers’ environment of choice [51].
2 Modeling Approaches
In the software engineering world, modeling has had a rich tradition from the ear- liest days of programming. The most recent innovations have focused on notations and tools that allow users to express system perspectives of value to software archi- tects and developers, and to express these perspectives in ways that can be readily mapped into the programming language code compiled for a particular operating sys- tem platform. The current state of this practice employs the Unified Modeling Lan- guage (UML) as the primary modeling notation [138]. The UML allows development teams to capture a variety of important characteristics of a system in corresponding models. Transformations among these models is primarily manual, although tools can be used to manage traceability and dependency relationships among model el- ements according to best practice guidance on maintaining synchronized models as part of a large-scale development effort [9].
One useful way to characterize current practice is to look at the different ways in which the models are synchronized with the source code they help describe. This is illustrated in Fig. 1,1 which shows the spectrum of modeling approaches in use by software practitioners today. Each category identifies a particular use of models
1This is based on a diagram originally created by John Daniels.
in assisting software practitioners to create running applications (code) for a specific runtime platform, and the relationship between the models and the code.2
“The code is the model”
“The model is the code” “Let’s do some design”
“What’s a Model?”
“Code and model coexist”
Code Model
Code Code
Code Visualization.
Model-centric Model only
Code Code only
Roundtrip Engineering
Model Model
Model
Fig. 1.The modeling spectrum
Today, a majority of software developers still take acode-onlyapproach (see the left end of the modeling spectrum, Fig. 1), and do not use separately defined models at all. They rely almost entirely on the code they write, and they express their model of the system they are building directly in a third-generation programming language (3GL) such as Java, C++, or C# within an integrated development environment (IDE) such as IBM WebSphere Studio, Eclipse, and Microsoft VisualStudio.3Any “model- ing” they do is in the form of programming abstractions embedded in the code (e.g., packages, modules, interfaces, etc.), which are managed through mechanisms such as program libraries and object hierarchies. Any separate modeling of architectural designs is informal and intuitive, and lives on whiteboards, in PowerPoint sides, or in the developers’ heads. While this may be adequate for individuals and very small teams, this approach makes it difficult to understand key characteristics of the sys- tem among the details of the implementation of the business logic. Furthermore, it becomes much more difficult to manage the evolution of these solutions as their scale and complexity increases, as the system evolves over time, or when the original
2Many other important life-cycle artifacts also benefit from a model-driven approach (e.g., requirements lists, test cases, and build scripts). For simplicity we concentrate on the pri- mary development artifact – the code.
3For this discussion we shall ignore the fact that the code is itself a realization of a program- ming model that abstracts the developer from the underlying machine code for manipulat- ing individual bits in memory, registers, etc.
members of the design team are not directly accessible to the team maintaining the system.
Developers can frequently gain additional insights when provided withcode vi- sualizationsin some appropriate modeling notation. As developers create or analyze an application they often want to visualize the code through some graphical notation that aids their understanding of the code’s structure or behavior. It may also be pos- sible to manipulate the graphical notation as an alternative to editing the text-based code, so that the visual rendering becomes a direct representation of the code. Such rendering is sometimes called a code model, or an implementation model, although many feel it more appropriate to call these artifacts “diagrams” and reserve the use of
“model” for higher levels of abstraction. In tools that allow such diagrams (e.g., IBM WebSphere Studio and Borland Together/J), the code view and the model view can be displayed simultaneously; as the developer manipulates either view the other is immediately synchronized with it. In this approach, the diagrams are tightly coupled representations of the code and provide an alternative way to view and possibly edit at the code level.
Further advantage of the models can be taken through roundtrip engineering (RTE)between an abstract model of the system describing the system architecture or design, and the code. The developer typically elaborates the system design to some level of detail, then creates a first-pass implementation from that code by applying model-to-code transformations, usually manually. For instance, one team working on the high-level design provides design models to the team working on the implemen- tation (perhaps simply by printing out model diagrams, or providing the implementa- tion team some files containing the models). The implementation team converts this abstract, high-level design into a detailed set of design models and the programming language implementation. Iterations of these representations will occur as errors and their corrections are made in either the design or the code. Consequently, without considerable discipline, the abstract models and the implementation models usually – and quickly – end up out of step.
Tools can automate the initial transformation, and can help to keep the design and implementation models in step as they evolve. Typically the tools generate code stubs from the design models that the user has to further refine.4As changes are made to the code they must at some point be reconciled with the original model (hence the term “roundtrip engineering,” or RTE). Tools adopting this approach, such as IBM Rational Rose, can offer multiple transformation services supporting RTE between models and different implementation languages.
In amodel-centricapproach, models of the system are established in sufficient detail that the full implementation of the system can be generated from the models themselves. To achieve this, the models may include, for example, representations of the persistent and non-persistent data, business logic, and presentation elements. Any integration to legacy data and services may require that the interfaces to those ele- ments are also modeled. The code generation process may then apply a series of pat-
4In some cases much more than code stubs can be generated depending on the fidelity of the models.
terns to transform the models to code, frequently allowing the developer some choice in the patterns that are applied (e.g., among various deployment topologies). To fur- ther assist in the code generation, this approach frequently makes use of standard or proprietary application frameworks and runtime services that ease the code gen- eration task by constraining the styles of applications that can be generated. Hence, tools using this approach typically specialize in the generation of particular styles of applications (e.g., IBM Rational Rose Technical Developer for real-time embedded systems, and IBM Rational Rapid Developer for enterprise IT systems). However, in all cases the models are the primary artifact created and manipulated by developers.
Amodel-onlyapproach is at the far-right end of the modeling spectrum. In this approach developers use models purely as thought aids in understanding the business or solution domain, or for analyzing the architecture of a proposed solution. Models are frequently used as the basis for discussion, communication, and analysis among teams within a single organization, or across multi-organizational projects. These models frequently appear in proposals for new work, or adorn the walls of offices and cubicles in software labs everywhere as a way of understanding some complex domain of interest, and establishing a shared vocabulary and set of concepts among disparate teams. In practice the implementation of a system, whether from scratch or updating an existing solution, may be practically disconnected from the models.
An interesting example of this approach can be seen in the growing number of orga- nizations which outsource implementation and maintenance of their systems while maintaining control of the overall enterprise architecture.
3 MDA Principles
There are four principles that underlie the OMG’s MDA approach:
(1) Models expressed in a well-defined notation are a cornerstone to system under- standing for enterprise-scale solutions.
(2) Building systems can be organized around a set of models by imposing a series of transformations between models, organized into an architectural framework of layers and transformations.
(3) A formal underpinning for describing models in a set of metamodels facilitates meaningful integration and transformation among models, and is the basis for automation through tools.
(4) Acceptance and broad adoption of this model-based approach requires indus- try standards to provide openness to consumers, and foster competition among vendors.
To support this approach the OMG has defined a specific set of layers and trans- formations that provide a conceptual framework and a vocabulary for MDA. No- tably, OMG identifies four layers: Computation Independent Model (CIM), Platform Independent Model (PIM), Platform Specific Model (PSM) described by a Platform Model (PM), and an Implementation Specific Model (ISM). This is illustrated in Fig.
2.
Computation Independent Model (CIM) Computation Independent Model (CIM)
Platform Independent Model (PIM) Platform Independent Model (PIM)
Platform Specific Model (PSM) Platform Specific
Model (PSM) Platform Specific Model (PSM) Platform Specific
Model (PSM)
Impl Specific
Model (ISM) Impl Specific
Model (ISM)
Impl Specific
Model (ISM) Impl Specific
Model (ISM)
Impl Specific
Model (ISM) Impl Specific
Model (ISM)
Impl Specific
Model (ISM) Impl Specific
Model (ISM) Business and Models
Analysis and Design Models
Detailed Design Models
Implementation and Runtime Models
Fig. 2.The layers and transformations of MDA
A key aspect of the MDA approach is to recognize that transformations can be applied to abstract descriptions of some aspect of a system to add more detail to that description, refine that description to be more concrete, or to convert between representations. Three ideas are important here:
• Distinguishing different kinds of models allows us to think of software and sys- tem development as a series of refinements between different model representa- tions. These models and their refinements are a critical part of the development methodology for situations that include refinements between models representing different aspects of the system, adding further details to a model, or converting between different kinds of models.
• One way to consider the models is to classify them in terms of how explicitly they represent aspects of the platforms being targeted. In all software and system development there are important constraints implied by the choice of languages, hardware, network topology, communications protocols and infrastructure, and so on. Each of these can be considered elements of the solution “platform.” An MDA approach helps us to focus on what is essential to the solution being de- signed separate from the details of that “platform.”
• The notion of what is a “platform” is rather complex, and highly context depen- dent. For example, in some situations the platform may be the operating system and associated utilities; in some situations it may a technology infrastructure rep- resented by a well-defined programming model such as J2EE or .NET; in other situations it is a particular instance of a hardware topology. Whatever we con- sider the “platform,” it is important to think more in terms of models at different levels of abstraction used for different purposes, rather than be too distracted by defining what a “platform” means.
• By thinking of software and system development as a set of model refinements, the transformations between models become first-class elements of the devel- opment process. This is important because a great deal of work takes places in defining these transformations, often requiring specialist knowledge of the busi- ness domain, the technologies being used for implementation, or both. Efficiency and quality of systems can be improved by capturing these transformations ex- plicitly and reusing them consistently across solutions. Where the different ab- stract models are well-defined, standard transformations can be used. For exam- ple, between design models expressed in UML and implementations in J2EE we can frequently use well-understood transformation patterns from UML to J2EE that can be consistently applied, validated, and automated.
Underlying these model representations, and supporting the transformations, the models are described in a set of metamodels. The ability to analyze, automate, and transform models requires a clear, unambiguous way to describe the semantics of the models. Hence, the models intrinsic to a modeling approach must themselves be described in a model, which we call a metamodel. So, for example, the semantics and notation of the UML are described in metamodels. Tool vendors turn to the standard metamodels of UML when they want to implement the UML in a standard way. For example, the UML metamodel describes in precise detail the meaning of a class, the meaning of an attribute, and the meaning of the relationships between these two concepts.
The OMG recognized the importance of metamodels and formal semantics for modeling as essential for their practical use. As a result, OMG defined a set of meta- modeling levels, and defined a standard language for expressing metamodels, the Meta-Object Facility (MOF). A metamodel uses MOF to formally define the abstract syntax of a set of modeling constructs.
The models and the transformations between them will be specified using open standards. As an industry consortium, the OMG has championed a number of impor- tant industry standards for specifying systems and their interconnections. Through standards such as CORBA, IIOP, UML, and CWM the software industry is enjoy- ing a level of system interoperability that was previously impossible, Furthermore, tool interoperation is also facilitated as a result of tool interchange standards such as MOF and XMI.
3.1 A Simple Example
In Fig. 3 we show a simplified example of a Platform Independent Model (PIM) and its transformation into three different Platform Specific Models (PSMs).
In Fig. 3 we show a simple PIM representing a customer and an account. At this level of abstraction the model describes important characteristics of the domain in terms of classes and their attributes, but without making any platform specific choices about which technologies will be used to represent them. Specific mappings, or transformations, will be defined to create the PSMs. Three are illustrated, together with the standards that are used to express the mappings. For example, one approach
XMI XSD,DTD
XMI XSD,DTD
MOF, JMI MOF, JMI
JOLAP, JDM UML4EJB…
JOLAP, JDM UML4EJB…
Mappings PIM - PSM
Platform Independent Models (PIM)
Computation Independent Business Model
Computation Independent Business Model
Customer Name : String SS# : Integer Children : Integer
Account Id : integer Name : String Balance : Float
Computation Independent Model View Computation Independent Model View
XML DTD, Schema (PSM) XML DTD, Schema (PSM)
<!Element Customer (Name*,
SS#*, Kids*)>
<!Element Customer (Name*,
SS#*, Kids*)>
Platform Specific Models (PSM)
Platform Specific Design and Implementation Model
Platform Specific Design and Implementation Model
XML Doc. (PSM) XML Doc. (PSM)
<Customer>
<Name>Joe</Name>
<SS#>1234</SS#>
<Kids>2</Kids>
</Customer>
<Customer>
<Name>Joe</Name>
<SS#>1234</SS#>
<Kids>2</Kids>
</Customer>
Java, C# (PSM) Java, C# (PSM) Class Customer
{public String name;
public int ssno;
public int children}
Class Customer {public String name;
public int ssno;
public int children}
Fig. 3.A simplified example of PIM-to-PSM mappings
is to take the PSM expressed in the UML and export it in XMI format using standard definitions expressed as XML Schema Definitions (XSDs) or Document Type Defin- itions (DTDs). This can then be used as input to a code generation tool that produces interface definitions in Java for each of the classes defined in the UML. Usually a set of rules is built into the code generation tool to perform the transformation. How- ever, often the code generation tool allows those rules to be specifically defined as templates in a scripting language.5
3.2 Summary
Following a long history of the use of models to represent key ideas in both problem and solution domains, MDA provides a conceptual framework for using models and applying transformations between models as part of a controlled, efficient software development process. The following ideas were highlighted:
• Models help people understand and communicate complex ideas.
• Many different kinds of elements can be modeled depending on the context.
These offer different views of the world that must be reconciled.
• We see commonality at all levels of these models – in both the problems being analyzed and in the proposed solutions.
• Applying the ideas of different kinds of models and transforming them between representations provides a well-defined style of development, enabling the iden- tification and reuse of common approaches.
5More detailed examples of this will be described later. However, you may wish to take a look at commercial examples of MDA in action such as IBM Rational’s Rose Technical Developer or Rapid Developer products (www.ibm.com/rational), or at open source MDA tools applying this approach (e.g., AndroMDA (www.andromda.org) or Jamda (jamda.sourceforge.net)).
• The OMG has provided a conceptual framework and a set of standards to express models, model relationships, and model-to-model transformations in what it calls
“Model-Driven Architecture”.
• Tools and technologies can help to realize this approach, and make it practical and efficient to apply.
4 Automating Generation with Patterns and Transformations
Modeling has had a major impact on software engineering, and it is critical to the success of every enterprise-scale solution. However, there is great variety in what the models represent and how those models are used. An interesting question is: which of these approaches can we describe as “model-driven?” If I create a visualization of some part of a system, does that mean I am practicing MDA? Unfortunately, there is no definitive answer. Rather, there is a growing consensus that MDA is more closely associated with model-driven approaches in which code is (semi-)automatically gen- erated from more abstract models, and which employs standard specification lan- guages for describing those models and the transformations between them.
In fact, models are the stepping stones on the path between a description of the business need and the deployable runtime components. As the system under devel- opment evolves, the models themselves become more complete, accurate, and con- sistent with each other. The focus of effort also shifts from the models at the higher level of abstraction toward those at lower levels. Ultimately these models are used to directly create the deployable components.
4.1 How Models Evolve
There are two main activities that happen with models: refinement and transforma- tion. Model refinement is the gradual change of a model to better match the desired system. The model is refined as more information is known and understood about the system. A model may also be refined for purely internal reasons (i.e., refactor- ing). As the various models evolve, dependent models will also need to change in response. By the end of each iteration of the development cycle, however, all the models should be consistent with each other.
Models are refined either manually or through some form of automation or as- sisted automation. Automation can be in the form of rules for model refinement implemented as executable patterns or assets. When a pattern is applied to a model it modifies or rearranges the model elements to resemble the pattern. The application of a pattern adds new elements or properties to the model. When a pattern is applied it may involve some user assistance – for example, prompting the developer for an existing model element to bind a pattern parameter with, or other decisions that need to be resolved for the pattern to be executed.
Model transformations, on the other hand, involve two or more models. The most typical example is a high-level abstraction model (a “Platform Independent Model”
– PIM) being transformed into a low-level abstracted and technology-dependent one
(a “Platform Specific Model” – PSM). For example, a UML PIM could represent a logical data model and consist of a number of entity classes, each with a number of persistent attributes. This model could be transformed through automation into a UML data model that captures the same underlying entities, but now from the view- point of database tables. The data model could in turn be used to directly generate SQL scripts that define the database, and could be directly executed on a specific database management system (DBMS).
Model transformations are not necessarily unidirectional. It is possible for some model transformations to be bidirectional. For example, a platform-specific UML model of several Entity JavaBean (EJB) classes could be “synchronized” with the source code implementing these EJBs. New elements (i.e., methods, attributes, as- sociations) defined in the model would generate appropriate elements in the source, and any new elements created in the source (or removed) would generate appropriate elements (or be removed) in the model.
4.2 Understanding Model Transformation
Defining and applying model transformations are critical techniques within any MDA style of development. Model transformations involve using a model as one of the inputs in the automation process. Possible outputs can include another model, or varying levels of executable code. In practice there are three common model transformations: refactoring transformations, model-to-model transformations, and model-to-code transformations.
(1) Refactoring transformationsreorganize a model based on some well-defined cri- teria. In this case the output is a revision of the original model, called the refac- tored model. An example could be as simple as renaming all the instances where a UML entity name is used, or something more complex like replacing a class with a set of classes and relationships in both the metamodel and in all diagrams displaying those model elements. This is illustrated in Fig. 4 which shows a simple refactoring transformation that extracts a class’s interface.
(2) Model-to-model transformationsconvert information from one model or mod- els to another model or set of models, typically where the flow of information is across abstraction boundaries. An example would be the conversion of one type of model into another, such as the transformation of a set of entity classes into a matched set of database schema, Plain Old Java Objects (POJOs), and XML-formatted mapping descriptor files. This conversion is illustrated in Fig.
5a through Fig. 5d. Figure 5a shows the high-level entity model as a PIM. Figure 5b shows the resulting logical data model and is considered in this context to be a PSM. Figure 5c shows the matching Java objects, and Fig. 5d shows components that represent the persistence descriptor files.
(3) Model-to-code transformationsare familiar to anyone who has used the code generation capability of a UML modeling tool. These transformations convert a model element into a code fragment. This is not limited to object-oriented languages such as Java and C++. Nor is it limited to programming languages:
Product - id : String - name : String - supplier : Supplier - price : Currency - description : String + getDescription ( ) + setDescription ( ) + getId ( ) + setId ( ) + getName ( ) + setName ( ) + getPrice ( ) + setPrice ( ) + getSupplier ( ) + setSupplier ( )
Product - description : String - id : String - name : String - price : Currency - supplier : Supplier + getDescription ( ) + setDescription ( ) + getId ( ) + setId ( ) + getName ( ) + setName ( ) + getPrice ( ) + setPrice ( ) + getSupplier ( ) + setSupplier ( )
«interface»
IProduct + getDescription ( ) + getId ( ) + getName ( ) + getPrice ( ) + getSupplier ( ) + setDescription ( ) + setId ( ) + setName ( ) + setPrice ( ) + setSupplier ( )
Before refactoring transformation After refactoring transformation
Fig. 4.An example of a refactoring transformation
configuration, deployment, data definitions, message schemas, and others kinds of files can also be generated from models expressed in notations such as the UML. Model-to-code transformations can be developed for nearly any form of programming language or declarative specification. An example would be to generate Data Definition Language (DDL) code from a logical data model ex- pressed as a UML class diagram. This is illustrated in Fig. 6, which shows the DDL generated with the example database PSM shown in Fig. 5b.
4.3 Applying Model Transformations
Having described different kinds of model transformations, we also note that in prac- tice there are several ways in which model transformations can be applied. In MDA approaches there are four categories of techniques for applying model transforma- tions:
• Manual.The developer examines the input model and manually creates or edits the elements in the transformed model. The developer interprets the information in the model and makes modifications accordingly.
• Prepared Profile. A profile is an extension of the UML semantics in which a model type is derived. Applying a profile defines rules by which a model is trans- formed.
• Patterns.A pattern is a particular arrangement of model elements. Patterns can be applied to a model and result in the creation of new model elements in the transformed model.
Contact + id : String + last : String + first : String
Address + id : String + line1 : String + line2 : String + city : String + state : StateCode + zip : String - home
1 - office 1
(a)PIM
T_CONTACT CONTACT_ID : CHAR(9) LAST : VARCHAR(30) FIRST : VARCHAR(50)
T_ADDRESS ADDRESS_ID : INTEGER LINE1 : VARCHAR(50) LINE2 : VARCHAR(50) CITY : VARCHAR(30) ZIP : CHAR(10) STATE_CODE_ID : CHAR(2) HOME : CHAR(9) OFFICE : CHAR(9)
«identifying relationship»
+ HOME_ADDRESS 0..1 1
«identifying relationship»
+ OFFICE_ADDRESS 0..1 1
(b)Database PSM
Contact - id : String - last : String - first : String + getFirst ( ) + setFirst ( ) + getId ( ) + setId ( ) + getLast ( ) + setLast ( ) + getHome ( ) + setHome ( ) + getOffice ( ) + setOffice ( )
Address - id : String - line1 : String - line2 : String - city : String - state : StateCode - zip : String + getCity ( ) + setCity ( ) + getId ( ) + setId ( ) + getLine1 ( ) + setLine1 ( ) + getLine2 ( ) + setLine2 ( ) + getState ( ) + setState ( ) + getZip ( ) + setZip ( ) - home
1
- office 1
(c)Java Objects PSM
Contact.hbm.xml Address.hbm.xml
(d)Persistence Descriptor Files PSM Fig. 5.Examples of model-to-model transformations
CREATE TABLE T_CONTACT (
CONTACT_ID CHAR ( 9 ) NOT NULL, LAST VARCHAR ( 30 ) NOT NULL, FIRST VARCHAR ( 50 ) NOT NULL );
CREATE TABLE T_ADDRESS ( ADDRESS_ID INTEGER NOT NULL, LINE1 VARCHAR ( 50 ) NOT NULL, LINE2 VARCHAR ( 50 ) NOT NULL, CITY VARCHAR ( 30 ) NOT NULL, ZIP CHAR ( 10 ) NOT NULL,
STATE_CODE_ID CHAR ( 2 ) NOT NULL, HOME CHAR ( 9 ) NOT NULL,
OFFICE CHAR ( 9 ) NOT NULL );
ALTER TABLE T_CONTACT ADD CONSTRAINT T_C_Constraint1 PRIMARY KEY ( CONTACT_ID );
ALTER TABLE T_ADDRESS
ADD CONSTRAINT T_A_Constraint1
PRIMARY KEY ( OFFICE, HOME, ADDRESS_ID );
ALTER TABLE T_ADDRESS ADD CONSTRAINT T_A_Constraint6 UNIQUE ( OFFICE );
ALTER TABLE T_ADDRESS ADD CONSTRAINT T_A_Constraint4 UNIQUE ( HOME );
ALTER TABLE T_ADDRESS
ADD CONSTRAINT T_A_Constraint5 FOREIGN KEY ( OFFICE ) REFERENCES T_CONTACT ( CONTACT_ID )
ON DELETE CASCADE ON UPDATE NO ACTION;
ALTER TABLE T_ADDRESS
ADD CONSTRAINT T_A_Constraint3 FOREIGN KEY ( HOME ) REFERENCES T_CONTACT ( CONTACT_ID )
ON DELETE NO ACTION ON UPDATE NO ACTION;
Fig. 6.An example of a model-to-code transformation
• Automatic.Automatic transformations apply a set of changes to one or mode models based on predefined transformation rules. These rules may be implicit to the tools being used, or may have been explicitly defined based on domain specific knowledge. This type of transformation requires that the input model be sufficiently complete both syntactically and semantically, and may require mod- els to be marked with information specific to the transformations being applied.
The use of profiles and patterns usually involves developer input at the time of transformation, or requires the input model to be “marked”. A marked model con- tains extra information not necessarily relevant to the model’s viewpoint or level of abstraction. This information is only relevant to the tools or processes that transform the model. For example, a UML analysis model containing entities with string types may be marked variable or fixed length, or it may be marked to specify its max- imum length. From an analysis viewpoint just the identification of the string data type is usually sufficient. However, when transforming a string-typed attribute into, say, a database column type, the additional information is required to complete the definition.
5 Summary
MDA is a work in progress. The very definition of what “MDA” means is evolv- ing. In the narrowest of contexts, it is about different abstract models of a system, and well-defined model transformations among them. In the more general sense, it is about having models at varying levels of abstraction as the basis for software ar- chitecture that ultimately drive into various implementation technologies. So at this time, there is very broad interpretation of MDA to the point that many organiza- tions and solutions claim “support” for, or “conformance” to, MDA. In this paper we emphasize MDA as an emerging set of standards and technologies focused on a particular style of software development – one that highlights the advantages of modeling at various levels of abstraction, and, most importantly, on the integration and flow of information through these models. This approach to software develop- ment allows developers to contribute to the project through the types of models that best match the type of information and decisions that they make. This approach also allows senior project members to maximize their effectiveness through their defini- tion and implementations of model-to-model transformations. Additionally, system analysts, testing, and quality assurance staff can leverage models for analysis of the system and its performance before it is complete.
6 Acknowledgements
The work reported in this paper has been carried out by a number of people, and it is our pleasure to acknowledge their contribution. The ideas discussed here reflect the thinking of a broad team at IBM including Grady Booch, Gary Cernosek, Jim
Conallen, Pete Eeles, Sridhar Iyengar, Simon Johnston, Grant Larsen, Martin Nally, Jim Rumbaugh, and Bran Selic. We also thank Mike Perrow for his helpful reviews of the paper.
Conceptual Foundations of Model-Driven
Development
A Systematic Look at Model Transformations
Andreas Metzger
Software Systems Engineering, University of Duisburg-Essen, Schützenbahn 70, 45117 Essen, Germany
Summary. Model transformations are at the heart of model-driven software development (MDSD). As a typical example, models of a higher level of abstraction are transformed into models that are closer to the target platform. However, there are also other forms of such transformations: for example, a model at a certain level of abstraction can be evolved by applying specific designs or modeling patterns.
We believe that a systematic classification of the kinds of transformations that are per- formed during an MDSD activity is of great assistance in understanding such transformations and in comprehending the sources of possible errors and difficulties. This chapter provides a systematic look at model transformations and presents a detailed classification scheme that we have found suitable. To support the soundness of this scheme, we provide examples for its application (i.e., for classifying typical transformations) and we demonstrate how such a classification can assist in understanding some of the problems that can occur within MDSD.
1 Foundation
Before the various kinds of model transformations can be discussed, the central term
“model” has to be clarified. In general, “amodelis a set of statements about some system under study” ([384], p. 27).
To enable the model users to concentrate on the significant system aspects, thus allowing them to handle complexity, any useful model will exhibit some form of abstractionfrom the system under study. One form of abstraction is the selection of relevant from irrelevant or random properties, which is known asreduction(cf. [281], p. 6). Other important forms of abstraction are generalization and classification.Gen- eralizationis a means by which differences among similar elements are ignored to form an entity in which the similarities can be emphasized ([346], p. 155).Classifica- tionis the process of identifying types, which are also known as concepts (cf. [327], p. 12-2 and [346], p. 156). Classification is the basic form of abstraction found in object-oriented or object-based modeling, where object types are the main elements of conceptual models and classes their respective realization in design models (cf.
[327], p. 12-3).
In traditional scientific disciplines models are usuallydescriptive, which means that a model can be considered a “correct” description of the system under study if all its statements are true for the system (see [384], p. 27).
In the case of software systems, a model can also be considered as thespecifica- tionof a system or rather a whole set of systems that should be built. In the context of such aprescriptive(cf. [281], p. 8) form of model application, which can be found in other engineering disciplines also, a specific system is considered as being “correct”
relative to its specification “if no statement in the model is false for the system under study” ([384], p. 27). During software development, the models are refined (i.e., the level of abstraction is reduced), whereby a subset of the initial set of systems is se- lected. If successful, this process leads to the final software product, which realizes the desired system in the end.
As is shown in Fig. 1, each model is based on aformalism(or language), which precisely defines the model’s syntax (or notation) and its semantics (or meaning).
The syntax of a formalism is made up of the concrete and the abstract syntax. The concrete syntax specifies the readable representation of the abstract notational ele- ments. The semantics consists of the dynamic and the static semantics. The static semantics, which should be more correctly called well-formedness rules (cf. [195], p. 16), is implied by the dynamic semantics and represents restrictions on the set of valid models that can be expressed using the underlying formalism.
Formalism
Concrete Syntax
Dynamic Semantics
Static Semantics bases on
represents assigns
implies restricts
Model
Abstract Syntax
System(s)
abstracts from/
meaning to specifies
Fig. 1.System, model, and formalism (adapted from [55])
With these definitions of system, model, and formalism, we can more formally describe transformations that can occur during software development. Using a modi- fied form of a formalization that was introduced by Caplat and Sourrouille in [55], we assume thatMis the model of a systemS(or a specification for a set of systems) andF is the formalism in which the model is described. Any transformationtcan then be formulated as
t:M1(S1)|F1 →M2(S2)|F2 (1) whereM1is thesourcemodel andM2is thetargetmodel of the transformation.
2 Classification of Model Transformations
Note that the transformationt that has been introduced in (1) implies neither that the source model will be modified nor that the target model will be created without modifying the source model. This characteristic should be considered as being or- thogonal to the transformation that is described byt. Typically, one would consider the transformation of the latter kind as aquerybecause it is free of side-effects (cf.
[12]).
A transformation can be monolithic(or atomic) or can be composed of many separate steps, which implies a step-wise transformation (cf. [200]).
Caplat and Sourrouille [56] further distinguish model transformations as being endogenif the formalism of source and target model is the same (F1=F2) or being exogenotherwise (F1=F2).
A further distinction between different kinds of transformations can be exercised upon the purpose of the transformation. There exist transformations that are per- formed to evolve the model and are therefore calledhorizontaltransformations. If a transformation is employed for implementing the model, i.e., for transforming the source model into a model that is closer to the run-time platform, we speak of such a transformation as beingvertical(cf. pp. 335–339 in [79]). In the first case, the for- malism of the source and target model is the same (endogen transformation), where as in the latter case the target model’s formalism contains elements that describe concepts that are closer to the final implementation platform (see p. 119 of this book for an in-depth discussion of the term “platform”). Such a vertical transformation is commonly known ascode generation, when the target model is the actual implemen- tation code (see [12]).
It should be noted that although vertical transformations are exogen transfor- mations, not all exogen transformations have to be vertical transformations. As an example, static analysis tools operate in the reverse direction. These tools usually have implementation code as an input and compute a more abstract model as an out- put. An example is the computation of the cyclomatic complexity for individual code components (see [229], pp. 348–350).
Another characterization can be performed based on the degree to which model transformations can be automated. As each model transformation represents a query and modification of models, such models have to be machine readable and modifiable for automating such activities. Only formal aspects of a model fulfill this requirement and are thus available for a manipulation through software tools (cf. [327]). Conse- quently, if the source and target models’ syntaxes are fully formalized, afully auto- matictransformation is conceivable. Otherwise, manual steps are required allowing forpartially automatedormanualtransformations only.
If a model transformation is exercised by a software tool, this transformation will always be performed in a repeatable and deterministic way. Also, if the trans- formation specification has been systematically tested (see p. 219 of this book) or formally verified (cf. [439]), the chance for introducing errors into the target model is considerably reduced compared to the manual execution of such an activity.
