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 Article

The webSA approach: applying model driven engineering to web applications

TL;DR: This paper combines WebSA with the OO-H method, a Model Driven Development made up of a set of UML architectural models and QVT model transformations, to tackle the design of a running example such as the Travel Agency system.
Dissertation

Diagram predicate framework: A formal approach to MDE

Adrian Rutle
TL;DR: This thesis is all about formalisation of MDE-concepts in a diagrammatic specification formalism which is called Diagram Predicate Framework (DPF), a formal diagrammatic approach to (meta)modelling and model transformation based on category theory.
Proceedings ArticleDOI

WSDL automatic generation from UML models in a MDA framework

TL;DR: Using an extension of UML language for representing the Web services Description Language standard, the MIDAS-CASE subsystem proposed supports the modeling of Web services in extended UML and the automatic generation of the respective WSDL description for the Web service modeled.
Book ChapterDOI

Extending the UML 2 activity diagram with business process goals and performance measures and the mapping to BPEL

TL;DR: The UML 2 Activity Diagram is extended with process goals and performance measures to make them conceptually visible and a mapping to BPEL is provided to make the measures available for execution and monitoring.
MonographDOI

Automated Defect Prevention