Preface
Software development is an enormously complex intellectual activity. It is a relatively young discipline that is still rapidly evolving. It isn’t done very well because everyone is still trying to figure out how to do it.
Nonetheless, there has been substantial improvement over the years in the way software is developed. A number of design methodologies have evolved to facilitate various aspects of software design. One was the Structured Design methodology, which provided a very intuitive approach that matched up well with the hardware computational models of Turing and von Neumann.
The Problem
While Structured Design was clearly superior to the ad hoc approaches that preceded it, it had an Achilles heel: the software tended to be difficult to modify when customer requirements changed over time, especially in large applications. At the same time, applications were rapidly growing in size and complexity. In addition, new languages, technologies, operating systems, data storage paradigms, UI paradigms, hardware, and whatnot were arriving on the computing scene with alarming speed. Yet business conditions were driving the need for faster time-to-market and reduced cost of software products.
The Hope
Consequently, a number of new design methodologies appeared that captured hard-won lessons about good and bad practices. They also presented revolutionary views of computing. One of those was the Object-Oriented (OO) paradigm, with the primary goal of ensuring that large applications are maintainable over time as requirements inevitably change during the software product’s life cycle.
This book is about practicing a particular software design methodology, Model-Based Development (MBD), which is strongly based upon Shlaer-Mellor.1 Employing the OO paradigm in general and MBD in particular should lead to more robust and maintainable large applications.
This Book
Although the book employs UML as a notation, that is quite peripheral. There are plenty of good books that describe how to express a software design in UML, so UML syntax will not get much mention here. Similarly, this book follows a particular design methodology for MBD, but that is primarily to provide context for the real purpose of this book:
The primary goal of this book is to describe why OO methodologies in general and MBD in particular advocate a particular way of doing things.
There is no single right way to design and develop all software. Too much depends upon the particular development environment, which includes everything from business goals through tools to group culture. In the end, a shop has to decide what set of tools will be most effective in its environment. To do that the decision makers need to understand why the MBD set of methodological tools works in many common situations. More to the point, the practitioners need to understand the fundamentals well enough to adapt them to particular situations.
Practicing OO design requires a unique mindset that is not intuitive in the world of hardware computational models. Rather than focusing on particular notations and methodologies, this book is really about how to think about software design. To that end, this book spends substantial time on the thought processes behind good software designs—even to the point of deliberately providing poor preliminary designs to demonstrate that the approach is self-correcting.
To achieve such understanding it is necessary to describe how traditional (pre-OO) approaches to software development failed in some ways and how the OO paradigm addressed those shortcomings. While Structured Development brought substantial order to the chaos of pre-1970 software development, it was not a panacea, and by the ’80s it became clear that software still had serious maintainability problems that the OO paradigm addressed.
Similarly, one cannot describe why a methodology works well without discussing at least some of the underlying theory. Nonetheless, this is a book by a software developer for software developers, so a conscious effort has been made to describe theoretical issues in practical terms without mathematical rigor.
Because this book is primarily about building abstract OOA models, don’t count on seeing a lot of OOPL code. As the methodology name suggests, the emphasis in this methodology lies in abstract modeling rather than writing traditional source language code. In effect, when a translation-quality OOA model is developed the model is the code. To put it another way, the notation of OOA modeling is UML augmented with an MDA-compliant Abstract Action Language (AAL). That notation is a 4GL2 rather than a 3GL, but the model will be just as executable as any 3GL program. While the model is implementation independent, it is a complete, precise, and unambiguous specification of the solution for functional requirements.
As a final note, we would point out that the practical development experience of the author is measured in decades rather than years. This is definitely not a theoretical book, despite the emphasis on explaining why things are done. It is based upon what works in the real world.
Road Map
The subject matter of this book is limited to application development at the OOA level. This book is organized into three main sections. Part I provides historical perspective and an introduction to basic OO principles. The introduction includes a discussion of the problems with structured development that the OO paradigm sought to correct. Part II is about construction of a static structure for the problem solution. This section represents the largest differences between the OO paradigm and other approaches since it is where the OO paradigm’s unique view of problem space abstraction is primarily manifested. Part III describes the dynamic aspects of the solution, particularly the rather militant use of finite state machines to describe behavior.
Intended Audience
This book is primarily targeted at people with little OO experience. It is assumed that the reader has some cursory knowledge of UML.3 The book also assumes that the reader has some software development experience, on the order of a couple of class projects in C. It assumes that the level of experience includes a general knowledge of computers and programming, essentially enough to be familiar with common acronyms like KISS.4
A secondary audience is the large number of converts to the OO paradigm from traditional procedural development environments. Many of these developers leapt directly into writing code in an object-oriented programming language (OOPL) since they already had substantial programming experience (i.e., believing that if one has seen one programming language, one has seen them all). Sadly, such converts have written huge volumes of bad OO code because no one told them why Object-Oriented Analysis and Design (OOA/D) is very different from Structured Analysis and Design (SA/D). If you are one of these, you will have to forget everything you ever learned about designing software and start with a clean slate.
The Role of Translation
A key characteristic of MBD is that it is one of a family of methodologies based on translation. That is, the methodology is compliant with the approach where a solution is modeled abstractly in a notation like UML and then a full code generator is employed to produce an implementation from that model automatically. Translation has some obvious advantages because it represents a logical extension of automation in the computing space that enhances productivity, enables economies of scale, and improves reliability. The downside is that it is not easy to do; the optimization problems faced for a model compiler are orders of magnitude more complex than those facing a 3GL compiler. Nonetheless, there are several commercial code generators available that provide 100% code generation for translation-based methodologies.
Although most of the translation approaches predate the Object Management Group (OMG) itself, they have been greatly facilitated by the Model-Driven Architecture (MDA) initiative formalized by OMG. MDA has provided a much-needed standardization for plug-and-play tools and a conceptual framework for full code generation. Getting from an abstract, implementation-independent model to 3GL code or Assembly is a nontrivial task, especially in today’s complex IDEs. That task greatly benefits from the formalism and concepts of MDA.
However, MBD is not tied to translation. The models produced in MBD are essentially the same as those that would be produced during OOA in traditional development and then manually elaborated to produce OOD models and 3GL code. The MBD models just happen to be more rigorously constructed than typical OOA models because code generators are quite literal-minded—they do what one says, not what one meant. There is nothing to prevent the developer from manually performing the conversion.