The book is written in a casual style, clearly intended to be an easy introduction to the subject, so the author's intention is not so different from other "how-to" books in computing technologies. And yet this book has something different: the author is a person with a clear view and understanding of layered reality of computing and technologies. He is modest but he sees clearly and widely. Such writers are rare.
As a book, what is best about it may be, in addition to the author's vivid understanding of computing reality and its environments, the fact that the author keeps the potential ---- the invisible but clearly directed potential, or vision, of MDA in his mind throughout his writing, especially in its initial part (Part One and Two). And I think that all the more because of that, the author may be somewhat frustrated in the present state-of-the-art understanding of MDA architecture, apart from (naturally) being unsatisfied with concrete realisation of what we have understood well so far. This is particularly visible when he discusses the stages where we wish to add more and more constraints to models in order to make it come closer to executable specifications, or programs, beyond static structure. And this tone of honesty is also a good point of this book.
From our concern, there is a major, but necessarily inevitable, lack of treated topics in this book --- a discussion on concurrency and interaction. Why inevitable? Because these are the very elements for which software methodologies are not yet well-understood, lacking a conceptual basis.
But concurrency and interaction are sheer necessity when we design a large information system , building which is quite like building a sky scraper. Frankel said (Chapter 1, Page 27):
....Yet virtually all attempts to build high-rises succeed. Now imagine that we constructed such buildings without detailed architectural blueprints and engineering specifications. What would the success rate be?And then continues with a hilarious paragraph:
Michi Hennig ... pointed out that the software book racks [in the bookshop] are filled with titled such as Teach Yourself C++ in 14 Easy Lessons, Java for Morons, CORBA For Dummies, Complete Idiot's Guide to WIn32, and so on and so forth. He challenges us to imagine how odd it would seem to come upon books with titles such as Brain Surgery in 14 Easy Lessons, Air Traffic Control for Morons, Bridge Design for Dummies, or Complete Idiot's Guide to Contrat Law.And he observes that, in spite of the need to produce a high-quality software, it is still hard for the "culture of rigour" to take hold in computing: he blames this to, as one of the reasons, constant changes ("volatility") in technology. Frankel then introduces UML and associated ideas and how they can be used, with many vivid examples, in model development, whose underlying tone may be summarised in his thesis that, in MDA, we focus on models as "development artifact" instead of models as "design artifact". I also appreciate very much his emphasis on the need for using assertions, or Design-By-Contract, as extensively as possible throughout the development stages (it looks the current DBC technology is somewhat limited: we shall discuss this point in our later posts).
We said that it is essential for us to consider concurrency and interaction when we architect a huge software system. If so, how can we develop software if we are without models which specify essential structures of concurrency and interaction? But what does this term "structures" mean in this context? What aspects of concurrency and interaction should we model? And using which methods?
To answer these questions, I wish to put forward several theses, some of which are:
(1) In sequential programs, a model wishes to hide interaction since they are often just implementation. In concurrent programs, interaction is the target of modelling: it is not part of implementation.
(2) State machine cannot by itself cleanly model practical interaction for concurrent processes.
(3) Sequential or concurrent, abstract behaviour is the target of modelling: abstract behaviour is not part of implementation if our viewpoint is in that level. And this abstract behaviour consists of at least two parts, "structural" part and "dynamic" part, the former articulating invariant part of the whole behaviour (such as signature) while the latter representing variable part of the whole behaviour.
There are other basic themes which we shall treat such as those concerning infrastructural elements in concurrency: Frankel does not try to be pure in his book, referring to and admitting the importance of many ephemeral technological elements while not losing his central vision. That freedom gives this book a real charm. So we should discuss about the environment whenever necessary.
