Selecting a good book on OOA/D/P tends to be a personal choice because style can be an important bridge to understanding and author's styles vary a great deal. However, the following are the books that have stood the test of time on my own bookshelf...
Object-Oriented Software Construction by Bertrand Meyer. This book was my personal epiphany to OO development back in the early '80s. Meyer had an agenda in that the book justifies Eiffel, the OOPL he designed. Nonetheless it is a classic in the field and he does an excellent job of explaining Why we should use OO techniques.
Executable UML by Steve Mellor and Marc Balcer. This is a modern update of the Shlaer-Mellor methodology, which I've used for nearly two decades. The primary goal of the book is to define an MDA profile suitable for PIM models when doing translation, so it is a little short on practical How-To for doing OOA/D. However, Mellor is a premier modeler and the examples are excellent. Mellor was an early advocate of modeling invariants while leaving detailed differences to data and the models strongly reflect that. In other words, the models are often suitable for large scale reuse.
Executable UML: How to Build Class Models by Leon Starr. This is unquestionably the most comprehensive book on Class Modeling available. Starr deals with topics I've never seen mentioned by other authors. Though the book addresses only PIM modeling for translation methodologies, it is still the most complete text on the subject around.
Object-Oriented Software Engineering by Ivar Jacobson et al. Though a bit out of date by today's standards, it is still a classic exposition of applying use cases to OOA/D. Jacobson was the primary advocate of employing use cases in software development and has had substantial influence on both OOA/D technique and requirements specification.
Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock and Alan McKean. Wirfs-Brock's early writings were also a part of my OO epiphany. This is an updated version of her role based approach. Here stuff is important because she was a pioneer in emphasizing abstraction of responsibilities rather than just data and operations. I am a bit uncomfortable about her emphasis on requests in collaboration, but her treatment of role-based anthropomorphism is excellent.
Object-Oriented Design Heuristics by Arthur Riel. This is another classic. It is a practitioner's view of OOA/D that provides cookbook techniques for dealing with everyday design problems. It did for OOA/D what Fowler's book (below) did for OOP. Though the justifications for the techniques are a bit dated by today's standards, the heuristics themselves are timeless.
Design Patterns by Erich Gamma et al. (Aka the GoF Book, as in Gang of Four authors.) Though relatively recent, this book has become a classic. It was the first book to apply basic pattern recognition to software development. The patterns have become a lingua franca for communicating designs. Though the patterns in the book are limited to reifications of relationships that have too much dynamic complexity to express in simple associations, that covers a huge amount of ground in practical design.
Large Scale C++ Software Design by John Lakos. This was the first formal recognition of one of the root causes of software mantainability problems: physical coupling in 3GLs in general and OOPLs in particular. While the the book is concerned with C++, which is the worst offender, the ideas are readily transferable to other languages. The techniques he provides for solving the problems are dated today, but his exposition of the root causes is still among the best. He also provided quantitative data on the performance costs of dependency management.
Refactoring by Martin Fowler. This is actually a better How-To book for dependency management than Lakos' book, mainly because it is more modern and benefits for a decade of raised consciousness about physical coupling. Essentially it is a distillation of OOA/D ideas into rules, guidelines, and policies suitable for OOP. If it has a shortcoming it is that it doesn't spend much time explaining why the problems it addresses are problems.
Agile Software Development by Robert Martin. Along with Lakos, Martin was one of the first to expound about fundamental coupling problems in OOPLs and he essentially pioneered the field of dependency management. While I am on the opposite end of the development spectrum from the OOP-based agile processes that Martin advocates through the book, the Principles he describes for managing dependencies are something every developer who manually writes code in an OOPL should understand.
Object-Oriented Software Testing by Bob Binder. Probably the most comprehensive book available on the testing of OO software.
Software Metrics by Fento and Pleeger. This is a good book about the basics of software measurement.
Metrics and Models in Software Quality Engineering by Stephen Kan. This is a more theoretical book about the models used for SQA. Nonetheless it provides a good, readable explanation of a topic that most software engineers sadly do know know exists.
Applied Software Metrics by Capers Jones. Though a bit out of date now, this was a classic in the field of software metrics.
Successful Software Process Improvement by Robert Grady. This book has already become a classic in software process engineering. It is effectively a chronicle of Grady's experiences at HP that helped build HP into a legendary high-quality software shop. It is particularly noteworthy because Grady introduced many of the described practices to software engineering. The book is essentially an application of TQM to software development.
A New American TQM by Shiba, Graham, and Walden. This is a general description of Total Quality Management as currently applied in the US. Though not specifically focused on software development, I have used the tools described for nearly two decades and I can testify to how well they work. Anecdotal data point: in 1984 we were 24 months late on a 9-month project, overtime was routine, the mean time to system crash was about 40 minutes, and each subsystem of the software had ~1K customer defect reports per release. We applied TQM principles religiously for a decade. By the mid-'90s we hit one-year schedules about -5/+15% without overtime, our defect rate was down to about 0.2 defects/KNCLOC released to System Test, and we could count our customer defect reports for the whole system for a release on two hands. We got an award form the USN for 600 deployed systems that had an average MTTF of 2.7 years in 24x7 operation, including hardware failures. I cannot overemphasize how important a process like TQM is to software development.
Revolutionizing Product Development by Wheelwright and Clark. This is an excellent reading for placing software development into context with the rest of the business context. While it is mostly just relevant to the way requirements are gathered for software development, that context is particularly interesting in light of today's vogue for agile OOP-based processes that attribute great importance on the idea that requirements priorities change.
If you are wondering why my list has almost as many books on metrics and process as it has book on OOA/D/P, there is a reason. Anyone who believes that grinding out 3GL code is all that software development is about is not living in the real world. The only thing that currently breaks in the customer's world is software and that has been noticed. It is no longer possible to pass off unreliable software as something that is unavoidable because of the inherent creative content. (That is, other engineering disciplines are somehow not as creative in their design efforts as software developers.) Nor is it tenable to believe that one can achieve high software reliability through testing. (At best one can achieve 5-Sigma quality with testing; for 6-Sigma and beyond one need militant defect prevention.)
The software industry is going to have to learn what other engineering disciplines learned decades ago: reliability and scheduling are process issues that are orthogonal to the fundamental product design. Processes need to be managed, which requires data collection, metrics, and a disciplined, self-correcting process needs to be in place as a framework for design creativity. Developers can no longer afford the luxury of myopia around pure software issues. So don't kid yourself -- if you want to think of yourself as a software engineer you are going to have to know as much about the process side of things as the design side.