Customer Reviews

Fundamentals of Object-Oriented Design in UML

5 star:		(20)
4 star:		(3)
3 star:		(0)
2 star:		(3)
1 star:		(0)

 

 

The Unified Modeling Language or UML forms a natural relationship with object-oriented programming or OOP. Using the metalanguage, UML, in simultaneous combination with the descriptive language, OOP, is now considered to be the optimal way to build large systems. Furthermore, iterating through several versions is generally conceded to be superior to the previous practice of completing one stage before proceeding to the next. Therefore, it is natural for one to study the two simultaneously, and in an incremental manner. However, that is not an easy task, as the UML is large and OOP is clearly a paradigm shift from previous ways of building software. Page-Jones navigates his way through the myriad complexities of the two very well, doing a superb job of introducing both.
The emphasis is necessarily on the principles of OOP rather than the UML, as that is the true point of the book. It would have been easy to lose that focus, but the UML is reserved for its proper place as the descriptor. All of the basic principles of OOP are presented in a wry style with plenty of humor. The tone was set in the beginning where he makes a bovine metaphor describing the ways one can approach the process of building systems. When it comes time to milk a cow, do we tell the milk to exit the cow or the cow to release the milk? In modeling, both approaches can be considered equally valid until proven otherwise.
Each chapter terminates with a series of problems, where the solutions are verbal or in simple pseudo-code. The solutions are detailed, providing solid reinforcement of the topics. If you are new to OOP or simply need a tune-up, then this book is definitely worth reading. It is quite likely that it will be on my list of top ten books for the year.

Who should read this book: Senior Programmers and Systems Analysts.

This book can be very valuable anyone who builds Object-Oriented computer programs, and anyone building computer programs either is or soon will be using Object-Oriented tools. Although it focuses on the Unified Modeling Language, a standard for most Computer-Aided Software Engineering tools, I found the real value of the book to be in the lucid explanations of principles of good software analysis and design, even more than in the nuts and bolts of UML. Dr. Page-Jones' style continues to combine well-researched information with down-to-earth pragmatism and a delightfully irreverent tone towards those who take this business (or themselves) way too seriously.

Who am I? I am a computational physicist turned systems analyst, with almost 20 years experience developing complex codes for scientific modeling and analysis, now working on real-time defense systems. I have been technical lead and mere contributor, subcontractor and lead contractor. My passion is for tight modular designs that facilitate high-reliablility code.

Part I, Introduction, gives excellent working definitions of the main concepts generally considered part of "Object Orientation" in a way that should be useful even to those beginning to use an OO language, and a historical perspective that helps explain why some issues are still messy.

Part II gets into the "nuts and bolts" of UML itself, of necessity illustrating many key concepts along the way. Even if you never use a CASE tool, the ability to discuss design issues using accepted "standard" diagrams will help you think through the key issues, communicate your ideas more clearly, and ultimately develop better designs. Better designs will not only avoid headaches in the implementation, but also guide the coding effort by making it clearer what the goals are.

Part III, the Principles of Object-Oriented Design, is worth the price of the book all by itself. Meilir's style helps you get through the big words by reminding you that that they are generalizations of common sense. For example, "connaissance" is basically old-fashioned "coupling": the more Module X's correct execution depends on details in Module Y, the more chances for mistakes. The OO quality of "encapsulation" helps you minimize it, whatever you call it. The old-fashioned concept of "coherence" becomes "cohesion": if everything a module does supports a well-understood single purpose, it is less likely there will be confusion or duplication. Do you hate a utility because you need to know so many stupid implementation details to use it properly? Don't lamely whine "I just don't like it!" when you can impress everyone by showing that it has an unjustifiably high "encumbrance."

The book is full of sound principles illustrated with real-world examples. If your gut has ever told you a proposed action was a bad idea, but you didn't know how to express your misgivings, the sound principles in this book will help you put your finger on what is wrong and why. Even if you don't care to use the impressive academic-sounding terms for them, the principles will help you become a more effective, persuasive member of your team. And even if you ARE the whole "team," they will keep you out of trouble.

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.

The major portion of my information technology career of fourteen years has been based in structured design and programming. I've spent the last few years programming in Visual Basic, which is object-based. I've also done a modicum of programming with object-oriented languages (C++ and Java). I jumped into OO programming before taking any design courses (sound familiar?) and eventually felt compelled to remedy the situation by reading a book on OOD. Meilir Page-Jones' book was not a disappointment. I believe that designers and programmers of all experience levels can benefit from reading his book. Newcomers will get the right introduction to OOD while experienced developers will be challenged to reexamine their approach to software construction.

"Fundamentals of Object-Oriented Design" is composed of three parts. In part 1 the author provides an overview of Object-Oriented Design (OOD) by defining key terms and then providing a brief summary of the evolution of software development. This orientation prepares the reader for the rest of the discussions in the book. Part 2 is a summary of the most often used portions of UML syntax. It's not intended to be an exhaustive description. He leaves out those parts of the language that are used infrequently. Part 3 is a compendium of principles of object-oriented design.

The salient benefits of the book are the clear, cogent arguments Mr. Page-Jones articulates in support of the principles he espouses, which are rooted in a very practical approach toward software development. Among other things, you can use most of the principles as bases for code reviews. He also peppers the discussions with entertaining anecdotes, realizing that this heavy stuff needs periodic comic relief. His definitions of OO terminology are concise and he avoids unnecessary abstractions.

I recommend that you add this book to your reference library. There are many zealots for OOD and this book helps to put things in their proper perspective.

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.

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.

Written with style, clariity and a sprinkling of humour, this is an excellent introduction to both OO concepts and UML. It is vastly more readible than the competion (e.g. Fowler). and lends itself well to teaching yourself OO/UML. The exercises and answers at the end of each chapter are particularly useful in this respect.

Be warned - it gets tougher as it goes along, but that's because the stuff he's putting across IS tough.

All in all, highly recommended.

This book is just what I was looking for! I am an experienced programmer, but have not worked in Object Oriented techniques before. This gave me the ability to acquire the new concepts and the new jargon, by showing how they were similiar and evolved from concepts I learned in structured programming and design. (The new ideas did not spring out of nowhere...) This book was not too low (what is a program? a program is...) and not too high (Realization is different from dependency, generalization and association...) but just right.

This is a book more about object-oriented design then UML. The first section covers the absolute basics of what OOD is. The middle portion teaches the reader how to use UML to depict their designs. The final section is a set of instructive essays, warning the reader of the problems and pitfalls that often occur in OOD, and how to avoid them.

Page-Jones has an excellent sense of humour, and his engaging style makes this an incredibly enjoyable book to read. You won't even notice that you're actually learning something! I also like the fact that he doesn't use a single programming language for his examples, instead trying to be generic, or alternatively, giving examples from C++, Java, Eiffel, and Smalltalk in turn. This makes the book accessible for all OO designers.

I wouldn't recommend this book to an experienced OO designer who wishes to learn UML. That's not the intended audience. For a new comer, who wishes to learn good design techniques from the start, this is the book for you.

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!