Reviews for MDA Explained: The Model Driven Architecture: Practice and Promise (Addison-Wesley Object Technology)

1. Good, but Dated Introduction to MDA

   Rated 3 out of 5 stars, April 12th, 2007

   "MDA Explained" is an easy to read introduction to model-driven architecture (MDA). The book does however seem a bit dated. It does not take into account service-oriented architecture and how it enables execution of higher-level business models. Still, it is well worth the few hours it will take to read and if you anyway are not in a position where you are concerned about how your system fits in with the business, it might be all you need.
   
   The book is of interest by managers wanting to know what MDA, developers wanting to use MDA in developing applications and to aspiring MDA specialists. The introduction tells you what chapters are of interest to you. The book consists of an overview of MDA, a case study of MDA in action and some information on developing MDA tools.
   
   Model-driven architecture is an approach to development championed by the Object Management Group (OMG), the people behind UML. The realisation that it is useful to work on multiple levels of abstraction when solving a computing problem is the foundation of MDA. We already do this without thinking much about it when we program in high-level languages. Our source code is just a model of the actual program - an abstraction of the machine code in the executable to be generated by the compiler.
   
   MDA practitioners work with models divided into three level of abstraction above the source code, they are in descending order of abstraction:
   1. the computationally independent model (CIM) which describes the business independent of computer systems,
   2. the platform-independent model (PIM) which describes a computer system independent of technical architecture, and
   3. the platform-specific model (PSM) which describes how the computer system is to be implemented using the chosen technical architecture.
   
   Typically, you will have different people working on different levels of abstraction. The business analyst will concentrate on the CIM - drawing up models of the organisation, business processes, terms and rules. These serve as input for the system analyst who develops the PIM, which describes the behaviour (use cases) and structure (classes) of the system. Then, the system designer models how to implement a system satisfying the requirements documented in the PIM with the chosen technical architecture. The PSM captures this technical design.
   
   The problem is apparent; we have many different people thinking differently about the problem that must somehow communicate in a way that reduces the chance of misunderstandings and requirements falling through the cracks.
   
   Using standardised, formal models and tools that can validate them is a step in the right direction. The models give us a common, precise language, which reduces the chance for misunderstandings. Having tools validating the models help further. They ensure consistency and improve completeness. However, using standardised models at the various levels is still not what is meant by model-driven architecture.
   
   For MDA to be in place you must have tools in place to transform a model on a higher lever of abstraction to a model on a lower one. Just as a compiler takes your source code and transforms it into machine code. You should have transformation tools in place to transform your PIM into a PSM, and PSM into source code. Unlike what is the case with modern compilers, these transformation tools cannot currently do the whole job for you. You have to adjust and complete the model yourself, but since the information captured at the higher-level models has already been put into yours, there is less room for errors.
   
   The latter transformation, from PSM to PIM, is nothing new. It is what CASE-tools and modern IDEs have been doing for quite a while. The PIM to PSM transformation is appealing, as it would bridge the functional/technical gap.
   
   Interestingly, the book dismissed the idea of having a transformation tool that takes the CIM and generates a PIM. It is here I believe the book shows its age, it was first published in 2003 and four years is a long time in IT. In the meantime, we have had the advent of SOA, which has allowed us to execute at least parts of the CIM through for instance business process management and business rules management. Just as part of the code generated in the final transformation from PSM to source code is SQL to be executed on an RDBMS, you can go from the CIM to BPEL code to be executed on a business process management system. The OMG shows an interest in modelling on the business level and is in the process of developing a suite of standard models for the CIM.
   
   As you probably have gathered I do not subscribe to the idea that MDA is DOA because of SOA. A revised edition of this book taking into account recent development would be compelling reading. As it stands it is merely interesting.

2. Not recomended

   Rated 2 out of 5 stars, November 12th, 2003

   This book was not worth the money or the time spent reading it.

3. A vision of the future?

   Rated 4 out of 5 stars, October 12st, 2003

   If you are interested in Model Driven Architecture (MDA) but you don't have a clear grasp of what it is or where the designers of MDA see it heading then you might want to pick up this brief, well-written description written by three authors who are well acquainted with MDA.

   MDA is the concept of using models developed using a modeling language (UML) to generate real applications. This book can be seen as a high level overview of MDA and at 150 pages it is a fairly easy and quick read. The authors show both what is available today (not too much) and what might be available in the future (perhaps all applications will be generated from models). The authors do try to make the book practical by showing how you can use modeling tools to at least build skeletons of code that can be the start of code development. MDA brings a new set of acronyms but this book explains each of them without too much pain.

   So how much of what is discussed here is needed by a typical developer or designer? Probably not too much. But if you want to keep your eye on the future of IT then this book is well worth the read. Perhaps one day writing code will be thought of the same way we think of writing machine language. When that happens you will be able to say you knew it was coming.

4. What a great book!

   Rated 4 out of 5 stars, September 12th, 2003

   This book is very well written and covers MDA from all aspects. There is an example built from ground up which helps the reader understand what MDA is about. If you have previous development experience, it is prefered to know Object Oriented Programming and UML, then this book can help you understand the philosophy of MDA. The only reason this books takes 4 out of 5 is that MDA is brand new and it has some cons which of course are reflected on this book, such an example is the transformation language which isn't standardized.