MDA explained : the model driven architecture : practice and promise

cover image

Where to find it

Library Service Center — Request from Storage

Call Number
QA76.76.D47 K546 2003
Status
Available

Summary

This text introduces model driven architecture (MDA), a framework that stresses the importance of models in the software development process.

Contents

  • Introduction
  • Who Should Read This Book
  • How This Book Should Be Used
  • Typeface Conventions
  • Information on Related Subjects
  • Book Support and Example Implementation
  • Acknowledgments
  • 1 The MDA Development Process
  • Traditional Software Development
  • The Productivity Problem
  • The Portability Problem
  • The Interoperability Problem
  • The Maintenance and Documentation Problem
  • The Model Driven Architecture
  • The MDA Development Life Cycle
  • Automation of the Transformation Steps
  • MDA Benefits
  • Productivity
  • Portability
  • Interoperability
  • Maintenance and Documentation
  • MDA Building Blocks
  • Summary
  • 2 The MDA Framework
  • What Is a Model?
  • Relationships between Models
  • Types of Models
  • Business and Software Model
  • Structural and Dynamic Models
  • Platform Independent and Platform Specific Models
  • The Target Platforms of a Model
  • What is a Transformation?
  • Transformations between Identical Languages
  • The Basic MDA Framework
  • Examples
  • Public and Private Attributes
  • Associations
  • Summary
  • 3 MDA Today
  • OMG Standards
  • OMG Languages
  • OMG Language and Transformation Definitions
  • UML as PIM Language
  • Plain UML
  • Executable UML
  • UML-OCL Combination
  • Tools
  • Support for Transformations
  • Categorizing Tools
  • Development Processes
  • Agile Software Development
  • Extreme Programming
  • Rational Unified Process (RUP)
  • Summary
  • 4 Rosa's Application of MDA
  • Rosa's Breakfast Service
  • The Business
  • The Software System
  • Applying the MDA Framework
  • The PIM and PSMs
  • The PIM to PSM Transformations
  • The PSM to Code Model Transformations
  • Three Levels of Abstraction
  • The PIM in Detail
  • Summary
  • 5 Rosa's PIM to Three PSMs
  • The PIM to Relational Transformation
  • The PIM to EJB Transformation
  • A Coarse Grained EJB Model
  • The Transformation Rules
  • The PIM to Web Transformation
  • The Transformation Rules
  • The Communication Bridges
  • Summary
  • 6 Rosa's PSMs to Code
  • Relational Model to Code Transformation
  • EJB Model to Code Transformation
  • Some Remarks on EJB Code
  • The Transformation Rules
  • The Web Model to Code Transformation
  • The Structure of the Web Code
  • The Transformation Rules
  • Summary
  • 7 More on Transformations
  • Desired Features of Transformations
  • Controlling and Tuning Transformations
  • Manual Control
  • Conditions on Transformations
  • Transformation Parameters
  • Additional Information
  • Traceability
  • Incremental Consistency
  • Bidirectionality
  • Implications on Transformations
  • Transformation Parameters
  • Persistent Source-Target Relationship
  • Transformation Rules as Objects
  • Summary
  • 8 Metamodeling
  • Introduction to Metamodeling
  • The Four Modeling Layers of the OMG
  • Layer M0: The Instances
  • Layer M1: The Model of t

Sample chapter

For many years, the three of us have been developing software using object-oriented techniques. We started with object-oriented programming languages like C++, Small-talk, 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 Object Modeling Technique (OMT) were published, we used our own invented bubble and arrow 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. Over 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 Unified Modeling Language (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 (MDA), 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 been naturally walking the path toward 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-experience: "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 into what MDA means and what you can achieve, both today and in the future. Anneke Kleppe Jos Warmer Wim Bast Soest, the Netherlands, March 2003 032119442XP04072003 Excerpted from MDA Explained: The Model Driven Architecture - Practice and Promise by Anneke G. Kleppe, Jos Warmer, Wim Bast All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.

Other details