scispace - formally typeset
Open AccessBook

MDA Explained: The Model Driven Architecture¿: Practice and Promise

TLDR
Insight is given in what MDA means and what you can achieve, both today and in the future, thereby raising the level of maturity of the IT industry.
Abstract
From the Book: For many years, the three of us have been developing software using object oriented techniques. We started with object oriented programming languages, like C++, Smalltalk, and Eiffel. Soon we felt the need to describe our software at a higher level of abstraction. Even before the first object oriented analysis and design methods, like Coad/Yourdon and OMT, were published, we used our own invented bubbles and arrows diagrams. This naturally led to questions like "What does this arrow mean?" and "What is the difference between this circle and that rectangle?". We therefore rapidly decided to use the newly emerging methods to design and describe our software. During the years we found that we were spending more time on designing our models, than on writing code. The models helped us to cope with larger and more complex systems. Having a good model of the software available, made the process of writing code easier and in many cases even straightforward. In 1997 some of us got involved in defining the first standard for object oriented modeling called UML. This was a major milestone that stimulated the use of modeling in the software industry. When the OMG launched its initiative on Model Driven Architecture we felt that this was logically the next step to take. People try to get more and more value from their high level models, and the MDA approach supports these efforts. At that moment we realized that all these years we had naturally walked the path towards model driven development. Every bit of wisdom we acquired during our struggle with the systems we had to build, fitted in with this new idea of how to build software. It caused a feeling similar to an AHA-erlebnis: "Yes, this is it," the same feeling we had years before when we first encountered the object-oriented way of thinking, and again when we first read the GOF book on design patterns. We feel that MDA could very well be the next major step forward in the way software is being developed. MDA brings the focus of software development to a higher level of abstraction, thereby raising the level of maturity of the IT industry. We are aware of the fact that the grand vision of MDA, which Richard Soley, the president of the OMG, presents so eloquently, is not yet a reality. However some parts of MDA can already be used today, while others are under development. With this book we want to give you insight in what MDA means and what you can achieve, both today and in the future. Anneke Kleppe, Jos Warmer, and Wim Bast Soest, the Netherlands January 2003

read more

Citations
More filters
Journal ArticleDOI

MDA-based visual modeling approach for resources link relationships using UML profile

TL;DR: This investigation demonstrates how users can use the UML profile to provide a conceptual and visual modeling for XLink applications, and automatically generate different XLink-based documents for various domains.
Book ChapterDOI

Aligning Business Models with Requirements Models

TL;DR: This paper offers a systematic approach to automatically generate goal- oriented models from value models by both defining conceptual mappings between value models and goal-oriented models and using model-driven techniques to define automatic transformations between both types of models.

Ontologías y MDA: Una Revisión de la Literatura.

TL;DR: This documento presenta una clasificacion sobre los puntos of conexion entre MDA y ontologias, a partir del analisis de los trabajos desarrollados en this campo.
Proceedings ArticleDOI

Improving Process Robustness through Domain-Specific Model Transformations

TL;DR: This paper presents an approach for automatic two-way synchronization of domain-specific process models with BPMN diagrams, which ensures that changes to processes executed through the BPMS are valid with respect to their domain representations, minimizing the potential for runtime problems that are difficult to understand.