Object-Oriented Analysis and Design with Applications

Addison-Wesley Object Technology Series

by Grady Booch, Robert A. Maksimchuk, Michael W. Engle

Grady Booch and his co-authors draw upon the rich and varied results of object-oriented software development projects and offer improved methods for their analysis and design, lightly making use of UML notation. Booch illustrates essential concepts, explains the method, and shows successful applications in a variety of fields. Booch also gives pragmatic advice on a host of issues, including classification, implementation strategies, and cost-effective project management. A two-time winner of Software Development's coveted Jolt Cola Product Excellence Award!

Genres: Programming, Computer Science, Software, Technical, Technology, Computers, Nonfiction

720 pages, Hardcover

First published September 1, 1990

About the author

Grady Booch is an American software engineer, best known for developing the Unified Modeling Language (UML) with Ivar Jacobson and James Rumbaugh. He is recognized internationally for his innovative work in software architecture, software engineering, and collaborative development environments.

Reviews

[Alejandro Teruel]

Grady Booch is a well-known and highly respected software engineer who was one of the founders of the Unified Modelling Language (UML) used to develop object-oriented software. The first edition of this book predates UML, but both the second and the third edition are based on UML.

In spite of Booch´s credentials and the fact that this book won an important award, I do not find this book very convincing or clear and would certainly not recommend it as an undergraduate textbook. To me, this book has the feel of having grown out of a collection of simplified case studies loosely tutored by Booch, prefaced by class notes and previous writings quickly cobbled together and in desperate need of masterful editing.

The book is organized into three main parts

Concepts
Method
Applications

In my opinion, Applications is, hands down, the best part of the book and Concepts the worst. Having taught introductory object-oriented analysis and design courses for many years, I must admit that it is extremely hard to write a good textbook for this subject. You run the risk of falling into vague generalities on the one hand, and on the other, going into too much excruciating and painful detail. Unfortunately by postponing badly needed software examples until the third part of the book, the first two parts of the book were practically condemned to blow away into thin generalities.

The first part of the book (Concepts) includes four chapters

1. Complexity
2. The Object Model
3. Classes and Objects
4. Classification

Chapter one starts at a very general level and runs on for some five pages on the structure of plants and animals, the structure of matter and the structure of social organizations, before turning to the complexity of software and superficially touching some key aspects of software development: the complexity of its application domains, the difficulty of managing software development, software´s flexibility and so on. This chapter reads very much like a general introduction to systems engineering and tries, unsucessfully in my opinion, to provide a motivation and a narrative of how general system ideas eventually trickle down into algorithmic and object-oriented decompositions. Too many important terms and concepts are mentioned almost in passing without anchoring them deeply enough to make them intelligible and usable in a software development context.

Chapter 2 (The Object Model) introduces such key concepts as abstraction, encapsulation, modularity, persistence, coupling, cohesion and typing with lots of hand waving, vague definitions and the occasional conceptual error. If you are an undergraduate student unfamiliar with these terms, you will find this chapter confusing; if you have some grasp of these concepts, I would recommend you skip this chapter.

By chapter 3 (Classes and objects) and 75 pages into the book, the authors finally seem to be ready to come to grips with more substantial stuff, but again they shy away into the realms of the abstract and some humorous if not always pertinent drawings.. One would certainly expect one the founders of UML to provide a thoughtful, clear and precise introduction to UML class diagrams and the key relationships between classes, but unfortunately this is not the case, and again the reader must be satisfied with a rather vague and slipshod introduction.

Thus we move into the second part of the book (Method) which is divided into three chapters, one on notation, one on process and one on pragmatics. The chapter on notation, which runs to about 100 pages, is an ok introduction to the 13 kinds of UML diagrams -to be honest I prefer Fowler´s UML Distilled or Miles and Hamilton´s Learning UML 2.0.

The chapter on process distinguishes between agile processes and plan-driven processes and winds up adopting -unsurprisingly- a lightweight version of RUP. The book then distinguishes, rather confusingly between a development macro-process and a micro-process. The macro-process´s activities (requirements, analysis and design, implementation, test, deployment, project management, configuration and change management, and environment) are fit into inception, elaboration, construction and transition phases. A micro-process model is presented only for architectural and component analysis and design, its activities consist of identifying (object-oriented) elements, defining the collaboration between elements, defining the relationship between elements and defining the semantics of the elements (their attributes and behaviour). Thus, after 273 pages of introductory material, the book finally tackles the main subject of it´s title, object-oriented analysis and design. The book follows Krutchen´s well known 4+1 architecture view model, consisting of a requirements or use case view view, a logical view, an implementation view, a process view which describes the independent threads of control and a deployment view. The complete dearth of examples again hampers understanding, forcing most readers to attempt to fast forward into the applications and then come back to these chapters in order to make sense of such recommendations as: “Consider the presence of a semantic relationship between any two elements and establish an association if such a dependency exists”. The part of the book devoted to method draws to an end with a chapter on pragmatics. Very few of the pragmatics are specifically related to analysis and design, and unfortunately the book again balloons up into generality on such topics as software development management, staffing, documentation and so on. Even the sections which are clearly important for analysis and design, such as Quality Assurance and Metrics manage to be singularly unhelpful. For example, the authors state that:

Our primary focus here is on product metrics (sometimes called design metrics) that help the development team assess the artifacts of their analysis and design efforts.

but defining the metrics and omitting guidelines or rules of thumb as to what the measures mean, hardly helps such assessment. The developers may come up with a number for, say, weighted methods per class (supposing one manages to come up with a reasonable weight scheme -another important omission) or the depth of an inheritance tree, but is that number telling him he has a good or a bad design on his hands? Booch et al stay mum on the subject, both in this chapter and in the applications sections where few if any metrics are reported. It is all well and good to say that in an inheritance tree, “...the more children a class has, the greater its impact on the software system´s design”, but is this a positive or a negative impact? And adding that the greater impact is “...due to the reuse it produces” only further muddies the waters. Thus, ending what ought to be a key section on evaluating object-oriented analysis and design by stating:

There is still disagreement about how object-oriented design principles contribute to software quality; consequently, there is still much debate about what constitutes an appropriate set of object-oriented metrics.

is a cop-out and further adding

We believe the metrics presented here provide a reasonable set of measures to assist the architect and component leads in assessing the quality of their object-oriented design.

requires a blind leap of faith on the reader´s part.

So after painfully slogging through 330 pages we finally reach the best part of the book, which describe the analysis and design of five applications:

- A satellite-based navigation system;
-A train traffic management system;
-A simple cyptoanalysis application for deciphering single substitution cyphertexts;
-Software for a weather monitoring station;
-An employee vacation tracking system.

In spite of the RUP-like framework, the analysis and designs lack unity, to me they show all the signs of having been tackled by different teams. Thus some of the case studies focus on the problem domain, while others (notably the vacation tracking system) focuses, in the inception phase, on a specific application environment, thus it starts by stating the design will implemented using Java, Java Server Pages (JSP), Tomcat,, J2EE, EJB ...that is to say, doing exactly the opposite of what has preached in the rest of the book by practically starting to the development from what appears to be more of a deployment, than a use case point of view. It is somewhat of a mystery to me why the applications are presented in the aforementioned order, since the most complex system is presented first and the simplest (the weather monitoring station software) almost last.

In my opinion, there are many moot design decisions in most, if not all the case studies. For example, in the arguably simplest case study, the weather monitoring station there is a deep and narrow inheritance tree which derives temperature sensors and pressure sensors from trend sensors. This seems to place the cart before the horse, surely sensors do not capture trends, they capture point data. And surely it is overkill to define a pressure sensor as a subclass of a trend sensor which, in turn is a subclass of a historical sensor, which in turn is a subclass of a calibrating sensor?

The train traffic management system is the case study that best states non-functional requirements, while the cryptoanalysis application makes a fine class project. Both the cryptoanalysis application and the vacation tracking systems more interesting aspects include the challenge of implementing rule-based systems. A blackboard-based approach is suggested for the cryptoanalysis framework while a more ad-hoc approach is proposed for the vacation tracking system. The satellite navigation system is the most complex but most original of the applications in an exciting but, for most students, little known domain.

I particularly enjoyed each application´s section on post-transition in which the proposed architecture is “tested” by studying what changes would be required in order to add a a couple or so very reasonable new requirements. The one exception is the very poor corresponding section for the vacation tracking system.

If you are interested in object-oriented analysis and design, by all means study the five applications carefully but take into account that, in my opinion, there are far better books on object-oriented analysis and/or design techniques by Martin Fowler, Robert C. Martin, Eric Evans and Craig Larman, amongst others.

[Gediminas]

Influential when it came out, much less relevant nowadays

Rating this book in 2025 is difficult. I'm sure it was an influential book when it first came out, and it provides an interesting historical perspective, but at the same time, I feel it offers little to software engineers of today (especially so given the length of the book).

First, let's observe that the object-oriented (OO) approach for designing and implementing software has been a victim of its popularity - many people think they are using it, but few really understand and practice it. From that observation follows a natural question - could this book help understand the OO approach? To some extent yes, though I'd recommend other alternatives more.

This book speaks about modeling the domain as objects that hide (encapsulate) complexity - so the foundation is right. Another good thing - about 1/4th of the book is dedicated to "Applications" - 5 case studies (each taking ~30 pages!) that each present a problem and then show how it could be solved using OO approach. I enjoyed this part of the book the most, and think it has lasting value, because: 1) I don't think newer books generally have such extensive case studies, and 2) it does make you think - if you had to design it today with modern techniques and technologies being available - would a different design be better and how?

At the same time, I felt that those examples were lacking in their demonstration of handling object persistence and presentation, and implementing those concerns while preserving encapsulation is, I think, one of the hard parts of building OO applications.

So if you are interested in learning more about OO approach, I would probably recommend Object Thinking (for the philosophical aspects of OO) and Domain-Driven Design: Tackling Complexity in the Heart of Software (for a more practical/applied interpretation, though tread carefully here, as DDD may also be suffering from some of this 'victim of its popularity' fate as OO).

As for this book, I would recommend it if you're looking for a historical perspective from the times when UML and processes like RUP were a big thing. For example, while those "old times" are often associated with waterfall-like development, for me it was interesting to see that the need to be both iterative and incremental in designing and building software was also well understood back then.

Also, if you decide to try it yourself, make sure to get the latest (third) edition, as it differs significantly from the second one.

[Alexey]

Too big and too academic

[Max Sakalouski]

This book is not about OO design itself as much as about UML.

[Said A]

I picked up this book because of many recommendations that suggested that it would improve one's OO understanding, etc. Probably that's why I was quite disappointed when I read more than half of it and did not find much for myself. Probably, it would have been a good book in the early years of OO idea, but not now.

I prefer short to the point and pragmatic explanations. The books spends several pages on something that could have been explained in a paragraph. That's why I was going to give it a 3 starts at most.

However, once you finish the 3rd section of the book (application examples), you more or less get a confidence in your own skills of problem decomposition using OO ideas. For that, I guess the book deserves 4-.

PS. My disappointment might have been caused by the hype around the book. If you are planning on reading this book, make sure you don't expect much of it. Especially, if you have programming experience in OOP language.

[Tim Colgan]

This is the bible on OOD. Particularly like Booch's definition in terms of the four required and three optional aspects of object oriented systems:

required
1) modularity
2) abstraction
3) encapsulation
4) hierarchy

optional
1) typing
2) concurrency
3) persistence

[James]

While Booch and company deserve credit for developing many of these concepts, their writing is overly academic. Gamma's Design Patterns book is a better read. I've owned and read both the first and third editions.

[Nathan Ormond]

A great overview of Object oriented software ontology

[Rodrigo Vieira]

Antigo. Muito antigo para os padrões de hoje.
Mas mais atual do que se imagina.

Sem palavras para elogiá-lo!

[Pranjal Singh]

Too detailed for my taste. First few chapters were quite enlightening though.

[Ivan Krsnik]

Fairly outdated, especially with regards to web, and reads a lot like an advertisement for UML.

[Manny Tingplants]

An excellent overview of how to approach (and survive) complicated programming problems. Very much oriented toward project planning and problem analysis; nothing very language specific. A great read for anyone with some programming experience who needs to know how to manage increasingly complex projects. Booch coined the term "Object-Oriented" decades ago, and he (and his coauthors) clearly know something about it.

[Eric]

The main reason I'm interested in one day reading this is that (from the Smug FP discussion), I hear that this is a sort state-of-the-art in good communication. Something useful for the FP community?

Also couldn't hurt for me to learn a bit more about object oriented programming, gotta know your 4 paradigms and all.

[Charles]

This book will BLOW YOUR FUCKING MIND

[Andrey]

Great Book! Must read 4 all

[Timothy Culp]

The start of my career in object-oriented programming.

[Bob]

Clear and useful. This is work, though, not pleasure.

[Jeff Kirschenbaum]

Fascinating.

[Steven]

The book that taught many of us object oriented design and programming.

[Christophe Addinquy]

ma note de lecture en français ici

[Sergey Teplyakov]

One of my favourite book. The first few chapters are absolutely astonishing!
More about this book - http://sergeyteplyakov.blogspot.com/2... (rus).

[Jose Sanz]

unable to finish

[Anushri]

Wish to start it, from the basic level.

[Udhya]

i want to read

[Frank Palardy]

Read this a long time ago. Probably still useful.

[Sreekanth K]

a good book for understanding object oriented programming. it's an academic book, so sharpen your pencil..

[faisul]

object oriented programming with lots of details, could be good book for someone who already knows the oop concepts a little

[Muthukumarsekar]

kll

[Amr Ragab Siam]

يسبيبيبسيبسيب يس بي سي بسي بسي ب