What do you think?
Rate this book
Addison-Wesley Object Technology Series
Object-Oriented Analysis and Design with Applications
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!
720 pages, Hardcover
First published September 1, 1990
108 people are currently reading
1,459 people want to read
About the author
Grady Booch
31Ìýbooks56ÌýfollowersGrady 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.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 29 of 29 reviews
September 3, 2015
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
The first part of the book (Concepts) includes four chapters
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:
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:
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.
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
ConceptsIn 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.
Method
Applications
The first part of the book (Concepts) includes four chapters
1. ComplexityChapter 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.
2. The Object Model
3. Classes and Objects
4. Classification
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;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.
-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 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.
October 22, 2012
The o-o bible according to my colleagues, so I worked through it and it did indeed have the whiff of being definitive. The revamped third edition has the advantage over the second in being generously illustrated with metaphors using cats and vegetables. A man after my own heart.
July 11, 2012
Too big and too academic
June 15, 2016
This book is not about OO design itself as much as about UML.
January 18, 2015
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.
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.
September 16, 2011
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
required
1) modularity
2) abstraction
3) encapsulation
4) hierarchy
optional
1) typing
2) concurrency
3) persistence
February 17, 2019
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.
December 29, 2019
A great overview of Object oriented software ontology
May 9, 2020
Antigo. Muito antigo para os padrões de hoje.
Mas mais atual do que se imagina.
Sem palavras para elogiá-lo!
Mas mais atual do que se imagina.
Sem palavras para elogiá-lo!
July 16, 2024
Too detailed for my taste. First few chapters were quite enlightening though.
November 23, 2024
Fairly outdated, especially with regards to web, and reads a lot like an advertisement for UML.
June 21, 2015
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.
Want to read
April 20, 2012The 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.
Also couldn't hurt for me to learn a bit more about object oriented programming, gotta know your 4 paradigms and all.
February 2, 2008
This book will BLOW YOUR FUCKING MIND
January 5, 2011
Great Book! Must read 4 all
March 9, 2012
The start of my career in object-oriented programming.
Shelved as 'maybe-someday'
March 6, 2016Clear and useful. This is work, though, not pleasure.
August 19, 2012
Fascinating.
November 26, 2014
The book that taught many of us object oriented design and programming.
November 6, 2014
One of my favourite book. The first few chapters are absolutely astonishing!
More about this book - (rus).
More about this book - (rus).
April 10, 2015
unable to finish
Want to read
April 8, 2015Wish to start it, from the basic level.
This entire review has been hidden because of spoilers.
August 24, 2015
i want to read
March 29, 2018
Read this a long time ago. Probably still useful.
August 16, 2016
a good book for understanding object oriented programming. it's an academic book, so sharpen your pencil..
December 5, 2016
object oriented programming with lots of details, could be good book for someone who already knows the oop concepts a little
Read
June 8, 2013kll
Read
April 3, 2015يسبيبيبسيبسيب يس بي سي بسي بسي ب
Displaying 1 - 29 of 29 reviews
Can't find what you're looking for?
Get help and learn more about the design.