Model-Driven Software Development

Technology, Engineering, Management

Markus Völter, Thomas Stahl, Jorn Bettin, Arno Haase, Simon Helsen, Bettina von Stockfleth

• Éditeur: Wiley
• Année: 2013
• ISBN:
  9781118725764
• Édition: 1
• Sujet: Informatica
• Sous-sujet: Sviluppo software

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!

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 CAD¹ 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 MOF²), 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 ...

Table des matières

• Cover
• Half Title page
• Title page
• Copyright page
• Foreword
• Part I: Introduction
• Part II: Domain Architectures
• Part III: Processes and Engineering
• Part IV: Management
• A: Model Transformation Cod
• References
• Index