Rating: 
Summary: Excellent OO introduction
Review: After going through a lot of books on subjects, this is one I like to return to. It is excellent book on Object Orientation. Books has a load of fun examples that are as paractical as can be in a book. It also has examples of a bad design, errors etc. The UML part is good, but what makes this book different is OO part, I wish that part was longer. You will find out why coupling is bad, why classes should belong to single domain, how to compare different designs, what are the most common errors in inheritance... Highly recomended!
Rating:
Summary: Wonderful introduction
Review: As an experienced programmer looking to develop skills in software design and analysis, I found this book an excellent starting point. The first half of the book discusses the basics of UML, giving both the reasons for a given diagram and several examples each time. The second half discusses design principles - there is little UML used, as it's largely theory, with a few concrete examples of dos and don'ts. I found both sections extremely readable, never patronizing but striking a good balance between a conversational tone and academic rigor. All in all, I found this book a pleasure to read, and it got me quite excited about UML and OOD. I heartily recommend this as an introduction to the subject.
Rating:
Summary: A wealth of valuable and easy-to-understand material
Review: Essential reading for anyone who wants to conduct quality object-oriented analysis and design. Thoroughly explains and demonstrates diagrams that can be used as quality deliverables used to make the developers of the object-oriented appliction's job easier. The only thing missing is a comprehensive cased study/complex real world example.
Rating:
Summary: A wealth of valuable and easy-to-understand material
Review: Essential reading for anyone who wants to conduct quality object-oriented analysis and design. Thoroughly explains and demonstrates diagrams that can be used as quality deliverables used to make the developers of the object-oriented appliction's job easier. The only thing missing is a comprehensive cased study/complex real world example.
Rating:
Summary: Instructive, Thoughtful, and Compelling
Review: Fundamentals of Object-Oriented Design in UML is a friendly book. I enjoyed it. Meilir Page-Jones maintains a wry sense of humor while threading through the intricacies of OO development in a clear, instructive fashion. The book really does have something for new and experienced programmers alike. The first two sections of the book are most accessible to those with little programming experience. These sections introduce object orientation and provide a review of the most useful Unified Modeling Language notations while illustrating their use in software design work. But throughout the book the author examines critical principles in such a way that the most experienced software designers will be challenged to reconsider assumptions and habits and to look more critically at their work. The third section of the book is not completely accessible to readers without substantial development experience but even so has enough to offer that it should not be skipped by the newcomer to coding. In my opinion this book is more about design than UML. If you want an introduction to UML it might make more sense to read Sams Teach Yourself UML in 24 Hours. The introduction to UML in Page-Jones' book is good enough to be your first look at UML but it is not comprehensive and it is oriented to illustrating design principles. This is an excellent book to start with and I would recommend reading it before anything else on UML. And I cannot imagine a better book for introducing object-oriented design. The author has a long track record in structured design and he frequently relates OO to SD concepts. The book is language independent but weighted toward C++. I only speak Java and had a little trouble with the concept of parameterized classes because they don't exist in my frame of reference but this was a very minor problem.
Rating: 
Summary: Beginners stuff
Review: I am quite familiar to object oriented analysis and design , design patterns, and would like to learn UML, that's the objective I bought this book. I found that this book was very poor to meet my objective. I don't learn UML idioms, something that I really like to. What I really learn from this book is how to draw some UML diagrams. I think this book assumes that you have minimal or no object oriented analysis, design, and programming. Maybe it is helpful for you if you would like to start to learn OO design. If you would like to apply the UML and design pattern, try Craig Larman Applying UML and Patterns book.
Rating:
Summary: Good Beginning for Object Oriented Design "Virgins"
Review: I borrowed this book from a co-worker a couple of weeks ago and I could not put it down. Mr. Page-Jones breaks down the concepts very plainly and succintly with excellent examples. All the sections were clear and it provides very helpful hints on designing good applications with some real world examples. I really enjoyed his sense of humor and candor throughout the book. An educational and entertaining book. A must for newbie's to object oriented design
Rating:
Summary: Practical OO programming with UML
Review: I must say immediately that OOD is a great weak point in my armoury. I do my designs largely by refactoring as I build from my business level objects. I also re-use the architectural level objects I developed in this way in earlier projects. I still tend to do the UML after I have done the programming, if then. The book that has helped me a great deal to get things right despite my pragmatic approach is Meilir Page-Jones's recent book "Fundamentals of Object-Oriented Design in UML" (Addison Wesley ISBN 0-201-69946-X). This book brings up to date Page-Jones earlier book "What Every Programmer Should Know About Object-Oriented Design" (Dorset House ISBN 0-932633-31-5). The biggest differences are that in Fundamentals he uses a subset of UML instead of his own notation, and he has a good chapter on component or interface design. Both books have lots of examples and exercises, which I hear is a good thing. The first part of Fundamentals introduces OO. The second part discusses the parts of the UML that are relevant to OOD. He does not discuss Use Cases as being beyond the scope of the book. Instead, he has chapters on Class Diagrams, Object Interaction Diagrams, State Diagrams, and Architecture and Interface Diagrams. The third part of the book is the really useful part. Here Page-Jones discusses good designs and how to achieve them. I cannot recommend this book too highly.
Rating:
Summary: Not a complete OO or UML fundamentals book
Review: Object-orientation is often criticized for lacking a theoretical foundation. While patterns proliferate, principles remain elusive. But the pursuit is on, and Mr. Page-Jones leads the hunt with this fine work. He catalogs attributes of object-oriented design by which we may intelligently discuss their quality: connascence, encumbrance, cohesion, type conformance, contravariance, covariance, closed behavior, ideal states, ideal behavior, and others. Patterns and anti-patterns are also exhibited, but the distinctive feature is the presentation of principles that all patterns must obey. Each chapter begins with an overview and ends with a summary followed by exercises with answers. Be sure to read them all. The exercises are interesting, and the "summaries" sometimes (Chapters 5 and 6, for example) introduce new concepts. The glossary is excellent. The bibliography is unfortunately not annotated. Some passages are over-peppered with footnotes, especially when their point is merely humorous. Overall the footnotes are valuable and the humor is appreciated. The text takes care to reference backward and forward to related topics, helping readers to trace their own threads. Some readers want more details about UML. Part II clearly describes a basic subset of UML probably sufficient for 90% of business scenarios, but many of the fine points are omitted. Part III treats the reader to a series of thought-provoking discussions of the qualities of good software design. Some of the thoughts provoked involve differences of opinion that this reader would like to describe below. Before doing so, however, he must emphasize first just how valuable he found the time spent considering the ideas of Mr. Page-Jones and how strongly he advises others to spend their own time in a like fashion. This reader was taken aback by the following advice: "Even when designing non-distributed applications, you should try to split a large class (one like Customer . . .) into several 'aspect' classes, using the composition construct to link their objects. For example . . . CustomerFinancials, CustomerShipping, and CustomerProfile. An object of class Customer would contain references to the objects of all three (p. 204)." There could be in some cases justification for such splitting, but none is offered here. The point of the classes is to represent subjects in the business domain, not to categorize their attributes by their primary use. (And what's the difference between a Customer and a CustomerProfile anyway?) The composition construct is intended to represent composites from the business perspective, not at the level of the meta-data. While it might be true that the DATA ABOUT the Customer is composed of financial attributes and shipping attributes, it is not true that the Customer ITSELF is a composite of things called "shipping" and "financials." The advice makes the classes model the data about the customer instead of modeling the customer itself. Another similar pollution of the business perspective occurs in a class diagram showing class ResourceType as aggregate of ResourceInstance, accompanied by the explanation, " . . . all three class diagrams deal with types, each of which aggregates a bunch of instances (p. 391)." Now, a "type class" always has the potential to be used to define aggregates of the objects of the "instance class." Whether it is in fact so used in a given business depends on the existence of a business operation appropriate for every object of the "type class" and affecting every object of the "instance class". But what operation can we define for class ResourceType equally appropriate for Employees, Rooms, and Whiteboards--and affecting every instance of one of them? Operation PAINT might apply to Rooms, but not to Employees. FIRE to Employees but not to Rooms. Even ERASE would not apply to every Whiteboard simultaneously. If the business does not have aggregate operations on objects of a type, then the type should not be modeled as an aggregate. Every association having a maximum multiplicity of 1 for one class and * for the other is not an aggregation. This reader read with great sympathy while Mr. Page-Jones bashed the "know how" cliché of object-oriented design, as in "a document should know how to print itself (p. 250)." In a subsequent footnote, he continues in the same vein: "I find this anthropomorphic view of object orientation to be specious and irrelevant (p. 251)." It is difficult for this reader to understand how it can be a "lie (p. 247)" to say that a non-commissioned salesperson has a commission payment of $0 while it is not a lie to say that a non-dog-owner owns zero dogs (p. 251). Designers often treat an object "having zero" as belonging to a different class when it can be very truthfully represented as merely being in a different state of the same class. The situation gets further complicated when special names have arisen for the objects having zero (non-commissioned), for the objects having more than zero (dog-owner), or for both. The same problem occurs with the distinction between objects "having just one" and objects "having more than one" (single-family vs. multi-unit, for example). Why does RectangleInFrame not inherit from Frame, asks Exercise 2 at the end of Chapter 13? The facile answer, "A rectangle is not a frame (p.344)," implies that software representations should never abbreviate the reality represented in order to realize a cost-saving simplification. Clearly, the case is otherwise. Why, even in the example that is the subject of this exercise we see some important--and justifiable--abbreviation: objects in the Rectangle class are represented with attributes recording their location in a coordinate system, even though location is not strictly speaking an inherent property of a rectangle. There might be circumstances where a shortcut permitting RectangleInFrame to inherit from Frame would be equally justifiable. Questions like this are better answered by describing the trade-off between accuracy of representation and complexity of implementation. The book raised other minor quibbles and qualms, but mostly it left an abiding respect for the conciseness and the rigor of its design principles. Every software developer should learn them and apply.
Rating:
Summary: Object-orientation with Principle
Review: Object-orientation is often criticized for lacking a theoretical foundation. While patterns proliferate, principles remain elusive. But the pursuit is on, and Mr. Page-Jones leads the hunt with this fine work. He catalogs attributes of object-oriented design by which we may intelligently discuss their quality: connascence, encumbrance, cohesion, type conformance, contravariance, covariance, closed behavior, ideal states, ideal behavior, and others. Patterns and anti-patterns are also exhibited, but the distinctive feature is the presentation of principles that all patterns must obey. Each chapter begins with an overview and ends with a summary followed by exercises with answers. Be sure to read them all. The exercises are interesting, and the "summaries" sometimes (Chapters 5 and 6, for example) introduce new concepts. The glossary is excellent. The bibliography is unfortunately not annotated. Some passages are over-peppered with footnotes, especially when their point is merely humorous. Overall the footnotes are valuable and the humor is appreciated. The text takes care to reference backward and forward to related topics, helping readers to trace their own threads. Some readers want more details about UML. Part II clearly describes a basic subset of UML probably sufficient for 90% of business scenarios, but many of the fine points are omitted. Part III treats the reader to a series of thought-provoking discussions of the qualities of good software design. Some of the thoughts provoked involve differences of opinion that this reader would like to describe below. Before doing so, however, he must emphasize first just how valuable he found the time spent considering the ideas of Mr. Page-Jones and how strongly he advises others to spend their own time in a like fashion. This reader was taken aback by the following advice: "Even when designing non-distributed applications, you should try to split a large class (one like Customer . . .) into several 'aspect' classes, using the composition construct to link their objects. For example . . . CustomerFinancials, CustomerShipping, and CustomerProfile. An object of class Customer would contain references to the objects of all three (p. 204)." There could be in some cases justification for such splitting, but none is offered here. The point of the classes is to represent subjects in the business domain, not to categorize their attributes by their primary use. (And what's the difference between a Customer and a CustomerProfile anyway?) The composition construct is intended to represent composites from the business perspective, not at the level of the meta-data. While it might be true that the DATA ABOUT the Customer is composed of financial attributes and shipping attributes, it is not true that the Customer ITSELF is a composite of things called "shipping" and "financials." The advice makes the classes model the data about the customer instead of modeling the customer itself. Another similar pollution of the business perspective occurs in a class diagram showing class ResourceType as aggregate of ResourceInstance, accompanied by the explanation, " . . . all three class diagrams deal with types, each of which aggregates a bunch of instances (p. 391)." Now, a "type class" always has the potential to be used to define aggregates of the objects of the "instance class." Whether it is in fact so used in a given business depends on the existence of a business operation appropriate for every object of the "type class" and affecting every object of the "instance class". But what operation can we define for class ResourceType equally appropriate for Employees, Rooms, and Whiteboards--and affecting every instance of one of them? Operation PAINT might apply to Rooms, but not to Employees. FIRE to Employees but not to Rooms. Even ERASE would not apply to every Whiteboard simultaneously. If the business does not have aggregate operations on objects of a type, then the type should not be modeled as an aggregate. Every association having a maximum multiplicity of 1 for one class and * for the other is not an aggregation. This reader read with great sympathy while Mr. Page-Jones bashed the "know how" cliché of object-oriented design, as in "a document should know how to print itself (p. 250)." In a subsequent footnote, he continues in the same vein: "I find this anthropomorphic view of object orientation to be specious and irrelevant (p. 251)." It is difficult for this reader to understand how it can be a "lie (p. 247)" to say that a non-commissioned salesperson has a commission payment of $0 while it is not a lie to say that a non-dog-owner owns zero dogs (p. 251). Designers often treat an object "having zero" as belonging to a different class when it can be very truthfully represented as merely being in a different state of the same class. The situation gets further complicated when special names have arisen for the objects having zero (non-commissioned), for the objects having more than zero (dog-owner), or for both. The same problem occurs with the distinction between objects "having just one" and objects "having more than one" (single-family vs. multi-unit, for example). Why does RectangleInFrame not inherit from Frame, asks Exercise 2 at the end of Chapter 13? The facile answer, "A rectangle is not a frame (p.344)," implies that software representations should never abbreviate the reality represented in order to realize a cost-saving simplification. Clearly, the case is otherwise. Why, even in the example that is the subject of this exercise we see some important--and justifiable--abbreviation: objects in the Rectangle class are represented with attributes recording their location in a coordinate system, even though location is not strictly speaking an inherent property of a rectangle. There might be circumstances where a shortcut permitting RectangleInFrame to inherit from Frame would be equally justifiable. Questions like this are better answered by describing the trade-off between accuracy of representation and complexity of implementation. The book raised other minor quibbles and qualms, but mostly it left an abiding respect for the conciseness and the rigor of its design principles. Every software developer should learn them and apply.
| 
