Model-Driven Software Development E-Book

Markus Völter

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Serie: Wiley Series in Software Design Patterns
• Sprache: Englisch

Seitenzahl: 666

Veröffentlichungsjahr: 2013

Beschreibung

Model-Driven Software Development (MDSD) is currently a highly regarded development paradigm among developers and researchers. With the advent of OMG's MDA and Microsoft's Software Factories, the MDSD approach has moved to the centre of the programmer's attention, becoming the focus of conferences such as OOPSLA, JAOO and OOP.

MDSD is about using domain-specific languages to create models that express application structure or behaviour in an efficient and domain-specific way. These models are subsequently transformed into executable code by a sequence of model transformations.

This practical guide for software architects and developers is peppered with practical examples and extensive case studies. International experts deliver:
* A comprehensive overview of MDSD and how it relates to industry standards such as MDA and Software Factories.
* Technical details on meta modeling, DSL construction, model-to-model and model-to-code transformations, and software architecture.
* Invaluable insight into the software development process, plus engineering issues such as versioning, testing and product line engineering.
* Essential management knowledge covering economic and organizational topics, from a global perspective.

Get started and benefit from some practical support along the way!

Leseprobe

Contents

Cover

Half Title page

Title page

Copyright page

Foreword

Part I: Introduction

Chapter 1: Introduction

1.1 The Subject of the Book

1.2 Target Audience

1.3 The Goals of the Book

1.4 The Scope of the Book

1.5 The Structure of the Book and Reader Guidelines

1.6 The Accompanying Web Site

1.7 About the Authors

1.8 About the Cover

1.9 Acknowledgments

Chapter 2: MDSD – Basic Ideas and Terminology

2.1 The Challenge

2.2 The Goals of MDSD

2.3 The MDSD Approach

2.4 Basic Terminology

2.5 Architecture-Centric MDSD

Chapter 3: Case Study: A Typical Web Application

3.1 Application Development

3.2 Architecture Development

3.3 Conclusion and Outlook

Chapter 4: Concept Formation

4.1 Common MDSD Concepts and Terminology

4.2 Model-Driven Architecture

4.3 Architecture-Centric MDSD

4.4 Generative Programming

4.5 Software Factories

4.6 Model-Integrated Computing

4.7 Language-Oriented Programming

4.8 Domain-Specific Modeling

Chapter 5: Classification

5.1 MDSD vs. CASE, 4GL and Wizards

5.2 MDSD vs. Roundtrip Engineering

5.3 MDSD and Patterns

5.4 MDSD and Domain-Driven Design

5.5 MDSD, Data-Driven Development and Interpreters

5.6 MDSD and Agile Software Development

Part II: Domain Architectures

Chapter 6: Metamodeling

6.1 What Is Metamodeling?

6.2 Metalevels vs. Level of Abstraction

6.3 MOF and UML

6.4 Extending UML

6.5 UML Profiles

6.6 Metamodeling and OCL

6.7 Metamodeling: Example 1

6.8 Metamodeling: Example 2

6.9 Tool-supported Model Validation

6.10 Metamodeling and Behavior

6.11 A More Complex Example

6.12 Pitfalls in Metamodeling

Chapter 7: MDSD-Capable Target Architectures

7.1 Software Architecture in the Context of MDSD

7.2 What Is a Sound Architecture?

7.3 How Do You Arrive at a Sound Architecture?

7.4 Building Blocks for Software Architecture

7.5 Architecture Reference Model

7.6 Balancing the MDSD Platform

7.7 Architecture Conformance

7.8 MDSD and CBD

7.9 SOA, BPM and MDSD

Chapter 8: Building Domain Architectures

8.1 DSL Construction

8.2 General Transformation Architecture

8.3 Technical Aspects of Building Transformations

8.4 The Use of Interpreters

Chapter 9: Code Generation Techniques

9.1 Code Generation – Why?

9.2 Categorization

9.3 Generation Techniques

Chapter 10: Model Transformations with QVT

10.1 History

10.2 M2M Language Requirements

10.3 Overall Architecture

10.4 An Example Transformation

10.5 The OMG Standardization Process and Tool Availability

10.6 Assessment

Chapter 11: MDSD Tools: Roles, Architecture, Selection Criteria, and Pointers

11.1 The Role of Tools in the Development Process

11.2 Tool Architecture and Selection Criteria

11.3 Pointers

Chapter 12: The MDA Standard

12.1 Goals

12.2 Core Concepts

Part III: Processes and Engineering

Chapter 13: MDSD Process Building Blocks and Best Practices

13.1 Introduction

13.2 Separation Between Application and Domain Architecture Development

13.3 Two-Track Iterative Development

13.4 Target Architecture Development Process

13.5 Product-Line Engineering

Chapter 14: Testing

14.1 Test Types

14.2 Tests in Model-Driven Application Development

14.3 Testing the Domain Architecture

Chapter 15: Versioning

15.1 What Is Versioned?

15.2 Projects and Dependencies

15.3 The Structure of Application Projects

15.4 Version Management and Build Process for Mixed Files

15.5 Modeling in a Team and Versioning of Partial Models

Chapter 16: Case Study: Embedded Component Infrastructures

16.1 Overview

16.2 Product-Line Engineering

16.3 Modeling

16.4 Implementation of Components

16.5 Generator Adaptation

16.6 Code Generation

Chapter 17: Case Study: An Enterprise System

17.1 Overview

17.2 Phase 1: Elaboration

17.3 Phase 2: Iterate

17.4 Phase 3: Automate

17.5 Discussion

Part IV: Management

Chapter 18: Decision Support

18.1 Business Potential

18.2 Automation and Reuse

18.3 Quality

18.4 Reuse

18.5 Portability, Changeability

18.6 Investment and Possible Benefits

18.7 Critical Questions

18.8 Conclusion

18.9 Recommended Reading

Chapter 19: Organizational Aspects

19.1 Assignment of Roles

19.2 Team Structure

19.3 Software Product Development Models

Chapter 20: Adoption Strategies for MDSD

20.1 Prerequisites

20.2 Getting Started – MDSD Piloting

20.3 MDSD Adaptation of Existing Systems

20.4 Classification of the Software Inventory

20.5 Build, Buy, or Open Source

20.6 The Design of a Supply Chain

20.7 Incremental Evolution of Domain Architectures

20.8 Risk Management

A: Model Transformation Cod

A.1 Complete QVT Relations alma2db Example

A.2 Complete QVT Operational Mappings alma2db Example

References

Index

Model-Driven Software Development

Copyright © 2006 John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England

Telephone [phone]

Email (for orders and customer service enquiries): [email protected]

Visit our Home Page on www.wiley.com

All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms of a licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1T 4LP, UK, without the permission in writing of the Publisher. Requests to the Publisher should be addressed to the Permissions Department, John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex PO19 8SQ, England, or emailed to [email protected], or faxed to ([phone].

Designations used by companies to distinguish their products are often claimed as trademarks. All brand names and product names used in this book are trade names, service marks, trademarks or registered trademarks of their respective owners. The Publisher is not associated with any product or vendor mentioned in this book.

This publication is designed to provide accurate and authoritative information in regard to the subject matter covered. It is sold on the understanding that the Publisher is not engaged in rendering professional services. If professional advice or other expert assistance is required, the services of a competent professional should be sought.

Other Wiley Editorial Offices

John Wiley & Sons Inc., 111 River Street, Hoboken, NJ 07030, USA

Jossey-Bass, 989 Market Street, San Francisco, CA 94103-1741, USA

Wiley-VCH Verlag GmbH, Boschstr. 12, D-69469 Weinheim, Germany

John Wiley & Sons Australia Ltd, 33 Park Road, Milton, Queensland 4064, Australia

John Wiley & Sons (Asia) Pte Ltd, 2 Clementi Loop #02-01, Jin Xing Distripark, Singapore 129809

John Wiley & Sons Canada Ltd, 22 Worcester Road, Etobicoke, Ontario, Canada M9W 1L1

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

Library of Congress Cataloging-in-Publication Data Stahl, Thomas (Tom)   Model-driven software development : technology, engineering, management / Thomas Stahl and Markus Völter, with Jorn Bettin, Arno Haase, and Simon Helsen ; foreword by Krzysztof Czarnecki ; translated by Bettina von Stockfleth.    p.cm.   Includes bibliographical references and index.   ISBN 0-470-02570-0 (pbk. : alk. paper) 1. Computer software—Development. I. Völter, Markus. II. Title.   QA76.76.D47S697 2006   005.1—dc22

2006007375

British Library Cataloguing in Publication Data

A catalogue record for this book is available from the British Library

ISBN-13: 978-0-470-02570-3 ISBN-10: 0-470-02570-0

Foreword

by Krzysztof Czarnecki

Modeling is a key tool in engineering. Engineers routinely create models when analyzing and designing complex systems. Models are abstractions of a system and its environment. They allow engineers to address their concerns about the system effectively, such as answering particular questions or devising required design changes. Every model is created for a purpose. A particular model may be appropriate for answering a specific class of questions, where the answers to those questions will be the same for the model as for the actual system, but it may not be appropriate for answering another class of questions. Models are also cheaper to build than the real system. For example, civil engineers create static and dynamic structural models of bridges to check structural safety, since modeling is certainly cheaper and more effective than building real bridges to see under what scenarios they will collapse.

Models are not new in software development. Over the past few decades, the software industry has seen numerous analysis and design methods, each with its own modeling approaches and notations. More recently, we have witnessed the remarkable progress of Unified Modeling Language (UML), which now has a larger market penetration than any single previous modeling notation. Still, analysis and design models rarely enjoy the same status as code. The reality of most software projects is that models are not kept up-to-date with the code, and therefore they become obsolete and useless with time.

Model-Driven Software Development (MDSD) puts analysis and design models on par with code. Better integration of such models and code should significantly increase the opportunity to effect change through the models, rather than simply modifying the code directly. MDSD encompasses many different techniques across the entire spectrum of software development activities, including model-driven requirements engineering, model-driven design, code generation from models, model-driven testing, model-driven software evolution, and more.

The Model-Driven Architecture (MDA) initiative by the Object Management Group (OMG) has also certainly contributed a great deal to the recent surge of interest in software modeling and model-driven techniques. But the effects of that initiative have been both good and bad. On the positive side, I’m glad that modeling has been moved into the center of interest and that organizations are now trying to figure out how their current practices can be leveraged through model-driven techniques. At the same time, the marketing hype around MDA has tended to create some unrealistic expectations. Putting all this hype aside, I do think that MDSD has great ideas to offer, many of which can be put to work in practical situations today. Realizing these potentials requires a solid understanding of current MDSD technology, its applicability, and its limitations.

The authors of this book are at the forefront of MDSD research and practice. Markus and Jorn have organized and participated in a series of MDSD workshops at several OOPSLA conferences. Simon has participated in OMG’s standardization efforts on model transformation. All the authors are pioneering this technology in practice in several domains, ranging from enterprise applications to embedded software in both small and large organizations, such as b+m, Siemens, and BMW.

I’m very pleased to introduce this book to you. In my view, this is one of the rare books in the model-driven space that talks not only about the vision, but also about what is possible today, and how to do it. After a minimal but necessary dose of basic concepts and terminology, the authors cover a wide range of MDSD technology topics such as metamodeling, component architectures and composition, code generation, model transformation, MDA standards, and MDSD tools. I particularly like the hands-on approach that the authors have taken. They illustrate available tools and techniques through concrete modeling examples and code snippets, and they give numerous practical tips and ‘mind-the-gap’ hints. In addition to the technology topics, the authors also present a comprehensive treatment of essential software engineering aspects such as testing, versioning, process management, and adoption strategies, as they apply to MDSD. The content is topped off with two case studies, that were inspired by realistic applications from the authors’ collective experiences.

The authors present a broad perspective of MDSD that goes beyond MDA to cover a range of related approaches including software product lines, domain-specific languages, software factories, and aspect-oriented and generative programming. As in any young, dynamic, and still evolving field, the abundance of competing ideas, concepts, and parallel terminologies in today’s model-driven space can be bewildering. As a result, the authors had to do a lot of ‘sifting through the mud’ to give us a clear and balanced picture of the entire model-driven field. In this book, they have done just that, tremendously well.

I invite you to explore this new and exciting field, and this book is a great place to start!

Krzysztof CzarneckiWaterloo, January 2006

Part I

Introduction

Chapter 1

Introduction

1.1 The Subject of the Book

This book is about Model-Driven Software Development, or ‘MDSD’. A less precise but common name for this discipline is Model Driven Development (MDD). Maybe you wonder why we decided to write such a book. We believe that Model-Driven Software Development is quite important, and will become even more so in the future. It is the natural continuation of programming as we know it today.

The application of models to software development is a long-standing tradition, and has become even more popular since the development of the Unified Modeling Language (UML). Yet we are faced with ‘mere’ documentation, because the relationship between model and software implementation is only intentional but not formal. We call this flavor of model usage model-based when it is part of a development process. However, it poses two serious disadvantages: on one hand, software systems are not static and are liable to significant changes, particularly during the first phases of their lifecycle. The documentation therefore needs to be meticulously adapted, which can be a complex task – depending on how detailed it is – or it will become inconsistent. On the other hand, such models only indirectly foster progress, since it is the software developer’s interpretation that eventually leads to implemented code. These are the reasons why – quite understandably – many programmers consider models to be an overhead and see them as intermediate results at best.

Model-Driven Software Development has an entirely different approach: Models do not constitute documentation, but are considered equal to code, as their implementation is automated. A comparison with sophisticated engineering fields, such as mechanical engineering, vividly illustrates this idea: imagine, for example, a computer-controlled mill that is fed CAD1 data that enables it to transform a model into a physical workpiece automatically. Or consider an automotive production line: your order for a car that includes custom features is turned into reality. Here, the actual production process is mostly automated.

These examples demonstrate that the domain is essential for models, just as for automated production processes. Neither the customer-oriented ‘modeling language’ for car manufacture – in this case, an order form – nor the manufacturer’s production line are able to build prefabricated houses, for example.

MDSD therefore aims to find domain-specific abstractions and make them accessible through formal modeling. This procedure creates a great potential for automation of software production, which in turn leads to increased productivity. Moreover, both the quality and maintainability of software systems increase. Models can also be understood by domain experts. This evolutionary step is comparable to the introduction of the first high-level languages in the era of Assembler programming. The adjective ‘driven’ in ‘Model-Driven Software Development’ – in contrast to ‘based’ – emphasizes that this paradigm assigns models a central and active role: they are at least as important as source code.

To successfully apply the ‘domain-specific model’ concept, three requirements must be met:

Domain-specific languages are required to allow the actual formulating of models.

Languages that can express the necessary model-to-code transformations are needed.

Compilers, generators or transformers are required that can run the transformations to generate code executable on available platforms.

In the context of MDSD, graphical models are often used, but this is neither mandatory nor always suitable. Textual models are an equally feasible option. Typically, these models are translated into programming language source code to enable their subsequent compilation and execution.

1.1.1 MDA

If you are familiar with the Object Management Group’s (OMG) Model Driven Architecture (MDA), you might think that this sounds a lot like MDA. This is correct to a certain extent. In principle, MDA has a similar approach, but its details differ, partly due to different motivations. MDA tends to be more restrictive, focusing on UML-based modeling languages. In general, MDSD does not have these restrictions. The primary goal of MDA is interoperability between tools and the long-term standardization of models for popular application domains. In contrast, MDSD aims at the provision of modules for software development processes that are applicable in practice, and which can be used in the context of model-driven approaches, independently of the selected tool or the OMG MDA standard’s maturity.

At present (2005) the MDA standardization process is still in its fledgling stages, which means that, on one hand, some aspects of the original MDA vision must be omitted, while others need be interpreted pragmatically to get practicable results. On the other hand, a practical methodological support for MDA is not necessarily the OMG’s main focus. This is in part also reflected by MDA’s goals.

In this book we take a closer look at the relationship between MDA and MDSD. For now, it is safe to state that MDA is a standardization initiative of the OMG focusing on MDSD.

1.2 Target Audience

Specific concepts, terminology and basic ideas must be understood by all those involved in an MDSD project, otherwise it cannot be completed successfully. The introductory chapters of this book are therefore mainly dedicated to these aspects.

1.2.1 Software Architects

Three aspects concerning MDSD are relevant for the software architect:

First, the approach requires a clear and concise definition of an application’s architectural concepts.

Furthermore, MDSD often takes place not only as part of developing an entire application, but in the context of creating entire product lines and software system families. These possess very specific architectural requirements of their own that the architects must address.

In addition, a totally new development approach must be introduced to the project. This is due to the separation of models and modeling languages, of programs and generators, of respective tools and specific process-related aspects.

All these issues will be discussed in this book.

1.2.2 Software Developers

When dealing with a software development paradigm, it almost goes without saying that the role of the software developer is pivotal. To some extent, MDSD implies more precise and clearer views of aspects such as the meaning of models, the separation of domain-specific and technical code, the relationship between design and implementation, round-trip problems, architecture and generation, framework development, versioning and tests. When applied correctly, MDSD will make the software developer’s work much easier, help to avoid redundant code, and enhance software quality through the use of formalized structures.

1.2.3 Managers and Project Leaders

Economic considerations such as the cost-value ratio or the break-even point underlie the decision to use Model-Driven Software Development. There is no ‘free lunch’: model-driven software comes with a price, too. There are many project contexts for which a model-driven approach can be recommended, but there are some circumstances under which we would advise against it. Even though the focus of this book is technical, we will take into account organizational and economic aspects that are relevant from the project’s or company’s viewpoint.

A model-driven approach also impacts project organization and team structure as well as the software development process. We will address this as well.

1.3 The Goals of the Book

The goal of the book is to convince you, the reader, that MDSD is a practicable method today, and that it is superior to conventional development methods in many cases. We want to encourage you to apply it sooner rather than later, since MDSD is neither merely a vision nor dry theory. To this end, we want to equip you with everything you need. If you already practice MDSD, this book might offer you some advice or provide further insight into specific topics or fields.

More specifically, we pursue a number of ‘subgoals’ - independent of the book’s structure – that we want to elaborate briefly here.

First, we introduce the theoretical framework for MDSD, its basic concepts and terminology. We also touch on related topics and approaches, such as OMG’s Model Driven Architecture (MDA). We also want to provide hands-on help for specific MDSD-relevant issues. Among these are metamodeling (with UML and MOF2), code generation, versioning, testing, as well as recommendations for choosing the right tools. Organizational and process-related issues are also very important to us. Additionally, we want to argue for MDSD from an economical standpoint.

Although it is impossible to work without at least some theoretical basis, the book first and foremost aims to provide practical support, as well as taking a more detailed look at some of the relevant theoretical issues mentioned above. Best practice, as well as the dissemination of concrete experiences are important to us, as well as, in part, personal opinions. A number of case studies from various domains supplement the more detailed parts of the book.

We also wish to answer prevailing questions and address current discussions, so an outlook on trends and visions in the MDSD context completes the book.

1.4 The Scope of the Book

This is not an MDA book. We describe the basic concepts and terminology of the OMG MDA standard as well the underlying vision, and we also offer a synopsis of the current state of standardization (see Chapter 12). However, the book represents our own views and experiences. Secondary literature about MDA can be found in sources such as [Fra02], as well as in the OMG specification itself.

Our book does not intend to define a cohesive, heavyweight MDSD development process. Instead, we report on best practices that lend themselves to being used in agile processes, as described by Crystal [Coc01], and in the context of product line development for the construction of customized development processes (see Section 16.2).

1.5 The Structure of the Book and Reader Guidelines

This book describes the model-driven approaches which the authors have successfully applied in practice for many years. We look at the subject-matter from a technological as well as from an engineering and management perspective, as you will see from the book’s structure.

Part 1 – Introduction

. This part contains the introduction you are reading, plus an explanation of the most important basic ideas behind MDSD, and the basic terminology derived from the MDA. We then proceed to address the architecture-centric flavor of MDSD, which is ideally suited for a practice-oriented introduction. We convey the concrete techniques based on a comprehensive case study from the e-business/Web application field, followed by a more comprehensive MDSD concept formation building on the points made. This chapter is extremely important, particularly because the rest of the book is based on the terminology defined here. This is also where you can find the conceptual, artifact-related definition of MDSD. The first part of the book is completed by a classification of and distinction between related topics such as agile software development.

Part II – Domain Architectures

. Domain architecture is the core concept of MDSD. Among other aspects, it contains the domain’s modeling language and the generation rules that are supposed to map the models to a concrete platform. This part of the book covers best practices for the construction of such domain architectures. The chapter on metamodeling forms its basis, followed by a detailed examination of the special role of the target architecture in the MDSD context. The three following chapters take a more detailed look at building transformations, including a description of code-generation techniques and QVT-based model-to-model transformations (QVT is the OMG’s standard for model-to-model transformations). A short comparison with interpreter-based approaches is also included. For building domain architectures, generic tools are best used, so the chapter on tool architecture and selection provides some background for this. Finally, we take a deeper look at the MDA standard in the last chapter of Part II.

Part III – Processes and Engineering.

In the third part of the book we deal with process-related aspects of MDSD and engineering issues that assume specific characteristics through MDSD. Here at last it should become clear that MDSD is not just a technology. We present a number of best practices that can be combined into a practical and pragmatic development process, look at architecture development, and take a glimpse into product-line engineering. Following that, we tackle testing and versioning issues. We finally look at two case studies, one from the embedded domain, the other from the world of enterprise systems.

Part IV – Management

. The last part of the book is aimed primarily at IT managers and project leaders. It can largely be read independently from the rest of the book. We take a closer look at economic and organizational aspects and discuss adoption strategies. The first chapter of this part includes a FAQ

3

section of MDSD-related questions.

We have taken the utmost care in structuring this book so that its didactic effect is optimal when read sequentially in spite of its cyclic dependencies. However, since we address a divergent audience, some readers might initially wish to read the book selectively. In this context, please note that readers whose interest is primarily technical and who already possess some MDA knowledge can start directly with the case study in Part I, continue with Chapter 4, then immerse themselves in the technical issues addressed in Parts II or III before moving on to the rest of the book.

If you want to know what the economic advantages of MDSD are before learning about MDSD in more detail, please read Chapter 18 first. To gain a better understanding of it, we recommend that you also read Chapter 2.

1.6 The Accompanying Web Site

Some topics dealt with in this book are undergoing rapid evolution, while others could only be touched upon due to space limitations. The book’s accompanying Web site can be found at http://www.mdsd-book.org. You can find up-to-date information there, as well as interesting links that we update on a regular basis.

1.7 About the Authors

Thomas Stahl works as chief software architect at b+m Informatik AG, where he is responsible for project-centric architecture management, including reusable software assets. He creates software architectures and frameworks and accompanies their use in both large and small projects. He also works as a consultant. His main focus is currently the field of Model-Driven Software Development, in which he has significant and practical long term experience. The creation of a good MDSD-generator framework was a pioneering effort. It is a popular Open Source project (http://www.openArchitectureWare.org) and is supported by a very active developer community. Besides his project-related work in several domains, Thomas writes articles for IT magazines and speaks at software conferences. He spends his spare time, among other things, as an active musician. He can be reached at [email protected]

Markus Völter works as an independent consultant in software technology and engineering. His work focuses on software architecture and Model-Driven Software Development, as well as on middleware. Markus has extensive experience with these topics in many sectors, including the automotive industry, science, health care, telecommunications, and banking, as well as Web-based systems and telematics. He has worked and consulted for many leading enterprises, mostly but not exclusively in Germany, in projects ranging from three to 150 developers. Markus is also a regular speaker at international software conferences, as well as an active member of the international patterns community.

In addition to this book and its German predecessor, Markus has also co-authored two patterns books, Server Component Patterns and Remoting Patterns, both published in Wiley’s Software Design Pattern series. He has also contributed to a German book on software architecture. As with Tom Stahl, Markus is also a contributor to the openArchitectureWare framework. When not working, Markus spends his time in his sailplane. He can be reached via http://www.voelter.de or at [email protected].

1.8 About the Cover

When we discussed the cover we thought that we wanted something that resembled the concept of ‘model-driven’ in some way. So, showing ‘something’, as well as a ‘model of something’ was the idea. We thought about buildings or machines. Then we thought about using an aircraft, since Markus’ hobby is flying. After a couple of draft covers we agreed on the final one. This shows an Alexander-Schleicher ASW 27 – one of the highest-performance racing-class gliders – as well as a technical drawing of the same plane. The picture shows Markus’ own plane with the German registration D-6642. If you are interested in more information about this aeroplane, you might want to visit the manufacturer’s site at http://www.alexander-schleicher.de. A huge collection of photos of this and other such aircraft can be found at http://www.voelter.de/flying/pictures.html and http://www.schogglad.de. Have fun.

1.9 Acknowledgments

Writing a book like this is more challenging than you might think. Without the support of a large number of people its completion would have been even more of a challenge, which is why want to thank the following people.

First of all, there are our contributing authors, Jorn Bettin, Arno Haase, and Simon Helsen. Jorn contributed mainly to the book’s section about management, helped us with terminology issues, and provided valuable input regarding the structuring of this work. Simon provided us with a unique insight into QVT and the processes and institutions behind it. We could not have written the QVT chapter without this vital input. Arno added to the book by looking into how interpreters fit into the MDSD world. Of course we also want to thank Krzysztof Czarnecki for writing a great foreword.

We wish to thank Bernd Oesterreich for discussions as well as for the material that found its way into the first case study in the book. We also thank Peter Roßbach for the interesting discussion about MDSD, particularly from the test perspective.

We – and especially Simon – also want to thank Sreedhar Reddy and Mariano Belaunde for their feedback on the QVT chapter. Gabor Karsai and Akos Ledeczi provided support in the context of MIC and GME – thanks for that! Thanks also to Juha-Pekka Tolvanen for providing us with screenshots for MetaEdit+.

Furthermore, we very much wish to thank our reviewers for fruitful discussions and useful feedback regarding many details, and also for input regarding the structuring of this book. The reviewers were, in alphabetical order, Frank Derichsweiler, Wolfgang Görigk, Michael Kircher, Michael Kunz, Wolfgang Neuhaus, Jürgen Rühle, Martin Schepe, Klaus-Dieter Schmatz, Eberhard Wolff, and Ghica van Emde Boas.

A very big thanks goes to our copy-editor Steve Rickaby of WordMongers. As with Markus’ previous books, he has done a wonderful job of polishing the manuscript with regards to language, as well as other (small and not-so-small) issues.

We also want to thank Rene Schoenfeldt, who was our editor for the original German edition of the book. He is a great to work with. The same is true for the people at Wiley for this English edition: specifically we want to thank our editor Sally Tickner.

Thomas wishes to expresses his gratitude to Markus for the extensive amount of work and time he has spent on the updates that went into the English edition. He also most profoundly wants to thank his wife Anja and his children, who gave him the support he needed and greatly helped him with their considerateness.

3 FAQ: Frequently asked questions

Chapter 2

MDSD – Basic Ideas and Terminology

This chapter introduces the most important basic concepts of Model-Driven Software Development, as well as the motivation for them. We prefer the abbreviation MDSD for Model-Driven Software Development over the less-precise variant ‘MDD’ (Model Driven Development). The first abbreviation has become more popular in the software modeling community over the past two years.

The Object Management Group’s Model Driven Architecture (MDA) is both a flavor and a standardization initiative for this approach. Our focus here is its practicability in software projects. In many respects our concepts and experiences are congruent with those of OMG’s MDA vision, but in other respects they differ. We point out the latter and discuss them. Apart from this, the MDA terminology, due to its standardization and pervasiveness, is extremely useful for providing an introduction to this topic, and this is exactly how you should approach the second part of this chapter: MDA provides the basic terminology for MDSD. The chapter’s third part introduces the concepts that have been missing until then and which are required to understand the case study.

2.1 The Challenge

In the twenty-first century software is all around us. The software industry has become one of the largest on the planet, and many of today’s most successful businesses are software production companies or offer services in the software field.

Software is today a relevant part of the machinery of all technology-based and many service-based businesses. High software development costs have significant economic impact, and bad software design, which impairs the productivity of users, can have even more serious consequences.

Many manufacturers of business software are so involved in dealing with the constantly-changing implementation technologies that productivity effort and risk management fall behind. Neither off-shoring, nor the newest generation of infrastructure software such as integrated development environments (IDEs), EAI1 or BPM2 tools and middleware, are much use here. In most cases, productivity problems are the result either of insufficient consistency or openness in the application architecture, or of inadequate management or dependencies between various software components and unsuitable software development processes.

2.1.1 Historical View

The nineteen-nineties were mainly influenced by two software development paradigms. At the beginning of the nineties, these were Computer Aided Software Engineering (CASE) and fourth-generation languages (4GLs). In the second half of that decade, Object-Orientation entered the mainstream.

CASE methods and the corresponding tools were expensive, and proprietary approaches collided with a growing awareness of open standards. Many companies had bad experiences with some manufacturers, so eventually not only the tools but also the model-based software development approach were dumped. Object-orientation did not keep all of its promises, but it did become the foundation of component technologies, and object-oriented languages successfully replaced the previous generation of programming languages.

With the departure of 4GLs and CASE, OO modeling tools became the center of tool manufacturers’ attention, resulting in the Unified Modeling Language (UML) notation standard and in tools based on a ‘round-trip’ philosophy. This enables smooth switching between UML models and the corresponding implementation code. Superficially, UML tools impress with their ability to keep models and code synchronized. However, on closer inspection one finds that such tools do not immediately increase productivity, but are at best an efficient method for generating good-looking documentation3. They can also help in understanding large amounts of existing code.

2.1.2 The Status Quo

The boundaries between modern UML tools and Integrated Development Environments (IDEs) are disappearing. For example, some UML tools have ‘comfortable’ code editors and integrated compilers, while traditional IDEs are equipped with UML modeling components. Software development tools, meanwhile, provide increasingly smart wizards that support users in the application of design patterns, the creation of user interfaces, and the generation of code skeletons for use with popular frameworks.

Although this approach constitutes an improvement compared to older UML tools that were only able to generate empty class skeletons, they strongly resemble CASE tools, as they are similarly inflexible. If, for example, a design pattern changes, today’s UML tools are unable to transfer the effects automatically and iteratively to the source code of an application system without losing the abstraction.

Eventually, the weaknesses of mainstream IDEs and UML tools led to the formation of the OMG’s MDA initiative. Appropriate tools allow users to define precisely how UML models are to be mapped to combinations of company-specific implementation technology. Unfortunately, in this context some traditional CASE tool manufacturers have spotted a second opportunity to offer their tools in a new package, as commercial MDA products. The tools cannot however be customized to meet individual requirements or customer needs, as they still adhere to the ‘one size fits all’ dogma. Most tools listed on the OMG’s Web pages, however, actually deserve the label ‘MDA tool’. In parallel with the progress in the field of software development tools, a significant evolution has also taken place in the field of software development methods, which has hardly been addressed yet in MDA.

The rapid adoption of agile approaches demonstrates an increasing resistance to traditional software development methods, which usually require a large amount of manually-created prose text documents. Today it is openly acknowledged that traditional methods required the production of such documentation, but in practice this cannot be reconciled with the market’s demand for lower software development costs. Admittedly, agile methods such as Extreme Programming (XP) [Bec00] alone do not offer sufficient guidance for the creation of high quality software, and they do not scale to more complex projects. The odd misbelief that they can compensate for a development team’s lack of analytical abilities or software design experience is particularly problematic.

2.2 The Goals of MDSD

Before we proceed to discuss the concepts and terminology of MDSD, we want to make a few comments on the goals of MDSD. However, we can only touch on how these can be achieved here.

MDSD lets you increase your

development speed.

This is achieved through automation: runnable code can be generated from formal models using one or more transformation steps.

The use of automated transformations and formally-defined modeling languages lets you enhance

software quality

, particularly since a software architecture – once it has been defined – will recur uniformly in an implementation.

Cross-cutting

4

implementation aspects can be changed in

one

place, for example in the transformation rules. The same is true for fixing bugs in generated code. This

Separation of Concerns

[Lad03] promises, among other things, better maintainability of software systems through

redundancy avoidance

and

manageability of technological changes

.

Once they have been defined, architectures, modeling languages and transformations can be used in the sense of a software production line for the manufacture of diverse software systems. This leads to a higher level of

reusability

and makes expert knowledge widely available in software form.

Another significant potential is the improved

manageability of complexity through abstraction

. The modeling languages enable ‘programming’ or configuration on a more abstract level. For this purpose, the models must ideally be described using a problem-oriented modeling language.

MDSD offers a

productive environment

in the technology, engineering, and management fields through its use of process building blocks and best practices. It thus contributes to meeting the goals described here.

Finally, based on the OMG’s focus and history, the organization’s primary motivations for MDA are

interoperability

(manufacturer-independence through standardization) and

portability

(platform-independence) of software systems. These goals that can be met only if a standardization – such as the OMG’s MDA effort – is achieved. The same motivation has already led to the definition of CORBA

5

. To achieve these goals, the OMG aims at separating the specification of a specific functionality from its implementation on a specific platform. The MDA serves the purpose of providing guidelines and standards that should lead to a corresponding structuring of system specifications in the form of models.

Most of the goals presented here are not new. On the contrary, they represent something like the IT industry’s ‘Holy Grail’: no-one is inclined to believe in beneficial promises anymore, and rightly so. But if you take a look at the history of IT or computer science, you can see that an ongoing evolution is taking place. High-level languages, object-orientation and component systems were milestones on the road toward meeting these goals – and MDSD is another. This paradigm takes us a small – or even a big – step closer to these goals.

2.3 The MDSD Approach

Each software has its inherent construction paradigms, expressed in the source code – an inner structure. How sound and how pronounced this structure is directly influences development speed, quality, performance, maintainability, interoperability, and portability of the software. Those are extremely important key economic factors.

The problem is that it is difficult to recognize the actual construction paradigms on a programming language level, because their abstraction level is much lower. To put it differently, the much-treasured inner structure is present in a cloudy, distributed, and of course also a strongly individualized form. It is no longer directly represented in the system itself. Its quality varies, depending on the skills and interpretation of the developers.

The idea of modeling is not exactly new, and is used mostly for sophisticated development processes to document a software’s inner structure. Developers then try to counteract the inevitable consistency problems with time-consuming reviews. In practice, these reviews and also the models are among the first victims when time presses - from a pragmatic point of view, even rightly so. Another approach is ‘round-trip’ or reverse engineering, which most UML tools offer, which is merely source code visualization in UML syntax: that is, the abstraction level of these models is the same as for the source code itself6. Visually it may be clearer, but the essential problem remains the same.

Model-Driven Software Development offers a significantly more effective approach: Models are abstract and formal at the same time. Abstractness does not stand for vagueness here, but for compactness and a reduction to the essence. MDSD models have the exact meaning of program code in the sense that the bulk of the final implementation, not just class and method skeletons, can be generated from them. In this case, models are no longer only documentation, but parts ofthe software, constituting a decisive factor in increasing both the speed and quality of software development. We emphasize ‘model-driven’ as opposed to ‘model-based’ to verbally highlight this distinction.

The means of expression used by models is geared toward the respective domain’s problem space, thus enabling abstraction from the programming language level and allowing the corresponding compactness. All model-driven approaches have this principle in common, regardless of whether the domain is labeled ‘software architecture’, ‘financial service systems’, ‘insurances’, or ‘embedded systems’. To formalize these models, a higher-level Domain-Specific Modeling Language (DSL) is required. From this ‘bird’s eye view’, it doesn’t matter whether this is a UML-based language or not.

Besides formal and abstract models, ‘semantically rich’, domain-specific platforms make up the second foundation pillar: prefabricated, reusable components and frameworks offer a much more powerful basis than a ‘naked’ programming language or a technical platform like J2EE. First and foremost, this means that the generator, which is supposed to transform the formal model, will be simplified once the generated code can rest on APIs of significantly higher quality. The introduction of reusable frameworks, super classes, and components to avoid code redundancy is not a new idea, but in the context of MDSD they serve additionally to intercept the model transformation half-way in the form of a well-formed platform, which causes a significant complexity reduction of the code generators7.

Figure 2.1 shows the relationships in application development with MDSD.

Figure 2.1 The basic ideas behind Model-Driven Software Development.

Let’s take a look at an existing application or a reference implementation (the upper left corner of the diagram). These are unique items with individual structures. We can restructure the code of these application in our minds so that three parts can be separated8 (the lower left corner): a generic part that is identical for all future applications, a schematic part that is not identical for all applications, but possesses the same systematics (for example, based on the same design patterns), and finally an application-specific part that cannot be generalized. At this point, we won’t make any statements about the significance of each part: in extreme cases, the application-specific part can even be empty. Model-Driven Software Development aims to derive the schematic part from an application model. Intermediate stages can occur during transformation, but in any case DSL, transformation, and platform will constitute the key elements. They must only be created once for each domain, for example ‘enterprise software architecture’ or ‘inventory system for insurance’ (lower right).

2.4 Basic Terminology

This section introduces the most important concepts and terms of the MDA standard, to establish the basic terminology for MDSD.

Domain-related specifications are defined in Platform-Independent Models (PIMs). To this end, a formal modeling language is used that is specific to the concepts of the domain to be modeled. In most cases, one would use UML that has been adapted via profiles to the respective domain, not least because of its tool support (see Section 6.5). These domain-specific descriptions are completely independent of the later implementation on the target platform. Such target platforms can be, for example, CORBA, J2EE, .NET or proprietary frameworks/platforms. Figure 2.2 illustrates this basic principle.

Figure 2.2 The basic principle of MDA.

Via model transformation, usually automated with tools, Platform-Specific Models (PSMs) are created from the Platform-Independent Models. These Platform-Specific Models contain the target platform’s specific concepts. The implementation for a concrete target platform is then generated with another tool-supported transformation based on one or more PSMs (see Figure 2.3).

Figure 2.3 PIM, PSM and transformation.

It is important to note that a PIM and a PSM are relative concepts – relative to the platform. In the example shown above, the EJB-PSM is specific to the EJB 2.0 platform, yet it is independent regarding its concrete, application server-specific realization.

Let’s look at another example. Figure 2.4 shows a small part of a PIM. It shows a class model with two domain classes: Customer and Account. Both classes have the «Business Entity» stereotype, and both have an attribute that is assigned the stereotype «UniqueID». The method findByLastName features the stereotype «Query» under Customer.

Figure 2.4 An example that illustrates the relationship between PIM, PSM and code.

The annotation of stereotypes on UML model elements allows us to change or specify the meaning of an element. A class with the stereotype «Business Entity» is not just a simple class, but is rather a self-contained entity in business applications. What this means in practice is determined by transformations that define how a stereotype such as «Business Entity», for example, is mapped to an existing platform such as J2EE.

Such an extension of the standard language vocabulary of UML through stereotypes is called a (UML) profile. It is a standard mechanism specified by the OMG to ensure openness, and is used here to define a formal modeling language. This formalization is mandatory for transforming a UML model into an MDA model. The concepts «Business Entity», «UniqueID», and «Query» are completely independent of the target platform. Dependency occurs through the transformation from PIM to PSM. Here, we find the stereotypes that are specific to J2EE: «EJBEntityBean», «PrimaryKeyField», and «EJBFinderMethod». These are also originally concepts that acquire their meaning through transformations, in this case transformations into the Java programming language.

The transformation eventually turns the PSM into source code, in which the concepts described here can be found in their concrete manifestation.

2.4.1 An Overview of MDA Concepts

The Model

A model is an abstract representation of a system’s structure, function or behavior. MDA models are usually defined in UML9. In principle, the MDA formally considers even classic programming languages as MDA modeling languages that in turn maintain relationships with a platform. Without a doubt this is correct, but we think that this approach occasionally hampers the elucidation of concepts, so from now on we will keep the terms model and modeling language clearly separate from the terms program and programming language.

UML models are not per se MDA models. The most important difference between common UML models (for example analysis models) and MDA models is that the meaning (semantics) of MDA models is defined formally. This is guaranteed through the use of a corresponding modeling language which that is typically realized by a UML profile and its associated transformation rules. We discuss these mechanisms in greater detail later in this chapter. All in all, this means that the mapping of a model to an existing platform is clearly defined.

The Platform

At first the MDA says nothing about the abstraction level of platforms. Platforms can build on each other, for example an Intel PC is a platform for Linux. Similarly, CORBA, J2EE, or Web Services are possible platforms for an e-business system, and C++ is a possible platform for CORBA. A well-defined application architecture, including its runtime system, can also be a platform for applications. We consider the latter idea to be one of the key concepts for Model-Driven Software Development and discuss it in greater detail later on.

UML Profiles

UML profiles are the standard mechanism for expanding the vocabulary of UML. They contain language concepts that are defined via basic UML constructs such as classes and associations, stereotypes, tagged values, and modeling rules (constraints) – see Figure 2.5.

Figure 2.5 Use of a UML profile.

A UML profile is defined as an extension of the UML metamodel. A metamodel defines, among other things, the basic constructs that may occur in a concrete model. Conceptually, a model is an instance of a metamodel. Accordingly, the UML metamodel contains elements such as Class, Operation, Attribute, or Association. The metamodel concept is one of the most significant concepts in the context of MDSD. For this reason, we dedicate a whole chapter to it, Chapter 6. However, at this stage we are content just to gain an intuitive understanding. The relationship between the metamodel and profile is clarified in Figure 2.6, using a simplified example – a UML profile for Enterprise Java Beans (EJB).

Figure 2.6 UML metamodel and UML profile for EJB (section of).

In the UML profile, the standard UML concepts Attribute, Class and Operation are supplemented by the specific concepts PrimaryKeyField, EJBEntityBean and EJBFinderMethod. In addition, a new UML 2.0 language construct, an extension, is used. This is indicated by the filled-in inheritance pointer. To avoid confusion, we made these larger.

Additional extensions are defined through tagged values and modeling guidelines in the form of constraints. A constraint is usually annotated as a comment for the respective model elements: we use the formal constraint language OCL here. Tagged values are rendered as attributes of the stereotype.

A UML profile therefore offers a concrete notation for referencing metamodels from a model, and determines whether a certain model is ‘well-formed’, that is, valid or not. In short, it defines a formal modeling language as an extension of UML.

Further details of these relationships are elaborated on in Chapter 6.

PIM and PSM

The separation of Platform-Independent Model (PIM) and Platform-Specific Model (PSM) is a key concept of the OMG’s MDA. The background to this is as follows: concepts are more stable than technologies, and formal models are potentially useful for automated transformations. The PIM abstracts from technological details, whereas the PSM uses the concepts of a platform to describe a system (see Figure 2.7). The reverse route – the extraction of a PIM from a PSM – is extremely hard to automate, and in some cases impossible. That usually requires manual, intellectual work, which is somewhat awkwardly termed Refactoring in the MDA specification. (The meaning of Refactoring leans more toward equivalence transformations – see [Fow99].)

Figure 2.7 The relationship between PIM, PSM and platform.

Transformations

Transformations map models to the respective next level, be it further models or source code. In terms of the MDA, transformations must be definable flexibly and formally based on an existing profile. This is a prerequisite for the desired automation of the transformation via generators.

Most of the currently-available MDA/MDSD tools define their transformation rules not between two metamodels, but instead for example use templates for the direct generation of source code, without the programming language’s metamodel being formally known to the generator. However, generators exist that attach the transformation rules to the UML profile or, respectively, its corresponding metamodel. Such approaches are absolutely workable in practice, and are described in Chapters 3 and 9. The advantage of a transformation based on two metamodels (source and target) is mostly the elegant mapping from one metamodel to another. We doubt whether this paradigm is feasible for the generation of source code in practice, however.

Current generators solve this problem in a different way, through the use of proprietary transformation languages. In this context, JPython, TCL, JSP, XSLT, or custom script/template languages are used10. The generator templates defined with these languages principally work like macros and use the models as input data. As a consequence, at present no interoperability for model transformations exists: standardization is on its way, however – see Section 10.5.

Chapter 12 provides a deeper insight into the MDA standard.

2.5 Architecture-Centric MDSD

In this section we want to supply the foundations that can enable you to understand the later case study: one flavor of MDSD that is termed Architecture-Centric MDSD (AC-MDSD). The approaches described here have evolved in the course of many years’ practical experience with many projects, and particularly focus on practical usability.

2.5.1 Motivation

In contrast to the primary goals of the OMG for MDA, interoperability and software portability, AC-MDSD aims at increasing development efficiency, software quality, and reusability. This especially means relieving the software developer from tedious and error-prone routine work. Today developers are confronted with extremely complex software infrastructures: application servers, databases, Open Source frameworks, protocols, interface technologies and so on, which all need be connected to create robust and maintainable high-performance software. Due to increasing complexity in this field, the discipline of software architecture assumes more and more importance.

The existence of a software infrastructure also implies the existence of corresponding infrastructure code in the software systems using it. This is source code, which mostly serves to establish the technical coupling between infrastructure and applications to facilitate the development of domain-specific code on top of it. The J2EE/EJB programming model is a prime example in this context: home and remote interfaces, Bean classes, descriptors – technical code that admittedly contains domain-related information such as method signatures, but which also exhibits a high degree of redundancy. After they have built four or five Enterprise Beans manually, if not before, a J2EE developer will long for a generator to create this type of infrastructure code – and can get this kind of support, typically in the shape of a preprocessor or an IDE wizard.

At best, some infrastructure components will bring their own ‘helpers’ for the generation of their own infrastructure code. The problem here is that these tools do not ‘know’ each other, which is why they fall short of the possibility of a holistic and architecture-centric approach, as we will see in the case study.

Ergo, the goal of AC-MDSD must be integrated automation of infrastructure code generation and, as a consequence, the minimization of redundant infrastructure code in application development.

When we talk about infrastructure code, we are not talking about peanuts: measurements [Chapter 18] show that between 60% and 70% of modern e-business applications typically consists of infrastructure code.

2.5.2 Generative Software Architectures

As the adjective architecture-centric already implies, software architecture plays the central role in the MDSD flavor discussed here. Actually, a holistic, generative approach for the creation of infrastructure code can only work on the basis of a thoroughly worked-out and formalized software architecture.

You can imagine this as follows: the more and the better a software architecture has been elucidated, the more schematic the source code of applications using this architecture will become. If the architecture’s definition consists only of slides representing the system infrastructure (databases, application server, mainframes, networks and so on) and maybe additionally the most important layers, it is likely that two developer teams will realize the same application in entirely different ways – including the implementation of the software architecture: two unique applications will be created.

If we assume however that a team of architects does some groundwork and develop some sort of technical reference implementation that shows the concrete realization of the most important software architectural aspects at the source code level, application developers can use this reference as a blueprint. Since the same technical realizations – notwithstanding domain variations – recur in development practice (for example use of a specific interface technology or an MVC pattern), the majority of the workload would be copy and paste programming. Of course, this sort of programming is much more efficient than individually thought-out code created from scratch.

In essence, the more of a software architecture’s definition has been fleshed out in source code, the more schematic and repetitive the application development process will become. Schematic programming means mostly copy and paste, followed by modifications that depend on the domain context. This part of the work is clearly non-intellectual. If we pursue this train of thought, it is not too far-fetched to leave the tedious and error-prone copy/paste/modify job to a generator, which ultimately leads to a generative software architecture. Here, all implementation details of the architecture’s definition – that is, all architectural schemata – are incorporated in software form. This requires a domain model of the application as its input, and as output it generates the complete infrastructure code of the application – the very code that otherwise would need to be generated via a tedious copy/paste/modify process. To this end, the model only needs to have specific annotations that reference the architectural concepts defined as part of the generative software architecture.

Usually an architecture-centric UML profile is used for modeling in AC-MDSD. Thus a formal, architecture-centric application design is created. The model-to-code transformations are defined typically in the form of generator templates, so that the complete infrastructure code can be generated automatically from the architecture-centric design model. It is important to note that the model must already contain all relevant information for the generation of the infrastructure code – it is just a lot more abstract and more compact than the expanded code. The templates can use the entire infrastructure’s power and base the generated code on this platform, as described in Section 2.3, simplifying the templates. Since the generation of the code is motivated by technical and architectural concerns, a ‘semantic gap’ remains: developers must manually create the application’s actual domain code, that is, the actual, domain-specific functionality that is not infrastructure code.

There are various techniques for the integration of generated and manually-created code. We look at them in detail in Chapter 8 and Chapter 9. Figure 2.8 illustrates these correlations. They are explained further in the next chapter’s case study, using a practice-oriented, realistic example.

Figure 2.8 The principle of architecture-centric MDSD.

A generative software architecture is a powerful means to achieve the goals we listed in Section 2.2. Its most important advantages are higher development speed and software quality, better maintainability, and practical reusability – reusability within one application, but of course even more beyond the boundaries of a single application. A generative software architecture can support an entire group or family of architecturally-similar applications – a software system family. In effect, AC-MDSD deals with the creation of generative software architectures for software system families, instead of creating unique products.

2.5.3 Architecture-Centric Design

The defined design language (typically a UML profile) contains the software system family’s architecture concepts in the shape of a ‘platform-independent’11 abstraction. Designers use this design language to create the domain’s application design in the form of PIMs. Other than when dealing with the OMG–MDA vision, they will in most cases deliberately forego the transformation of these PIMs into explicitly visible, platform-dependent UML models (PSMs) when working with AC-MDSD.

Practical project experience has hitherto proved that this simplification is usually more useful than the additional degrees of freedom gained with PSMs. As a consequence, one need not control, manipulate, and enrich the various intermediate transformation results with specific information12. This not only allows for a more efficient development, but also avoids potential consistency problems: a manual change of an intermediate model might result in an inconsistency with higher abstraction levels that is not automatically correctable.

Similarly, we forego reverse engineering from the source code to the PIM, which in general is not feasible anyway. A model that has been created ‘backwards’ from source code is naturally as little abstract as the source code itself. Only its presentation is different, perhaps providing better understandability for some purposes. For specific arbitrary sections of source code, a PIM from which the program could be derived via transformation13 may not exist – especially if the PIM modeling language focuses on a specific domain such as software architecture for e-business systems. In the context of MDA specifications, this fact is more or less ignored by the OMG however.

Some members of the MDSD tool-builders community anticipate tool-supported wizards or some similar solution that will at least enable semi-automated reverse engineering. In our opinion this is a concession rather than a goal-oriented concept14 – at least where newly developed software is concerned. Admittedly, this view may first be perceived as being disadvantageous, depending on your personal work preferences, but in truth it is an advantage, as we will learn later on. Basically, AC-MDSD builds on forward engineering.

This forward-engineering based, generative approach allows us to derive conclusions about generated applications from the ‘hard facts’ of architecture-centric models. A generative architecture can guarantee a loose coupling of components or the absence of access paths between different application layers. For example, it can ensure that a presentation layer, such as a Web user interface, cannot access a database’s SQL interface directly.