Rating:  - The King's New Clothes
I do well appreciate how those who believe the earth is flat must feel. I believe the people have lost their senses in their enduring alacrity over the aptly-acronymned OOPS. I have read a number of books on OOPS and worked with OOPS languages, and I continue to believe it is nonsense. The gullibility of my fellow humans has most surprised me.
1/3 of OOPS is logically without foundation: "Everything is an object", the notion that object-oriented procedural systems suffice for reuse, and the notion that object-oriented procedural systems are necessary for reuse, for example. The remaining 2/3 is just old ideas, such as various diagrams, modularity, and control over others, parading in new lingo.
For all their talk of reuse, the champions of OOPS are the ones who sought to discard previously existing software and to rewrite the entire corpus in the style of OOPS. OOPS developers have brought error messages to new levels of incomprehensibility. OOPS is an obstructionist vanity that continues to impede more than it helps systems development and maintenance.
Rating:  - Very good
This book contains almost everything you have to know about UML. It's best quality is that it's a very short book and very easy to read.
Rating: - Will cover all important aspects of UML
This book is what i call, lets get Down and dirty. Its a quick and dirty way of learning UML. for practical purposes this book is highly useful, I would recommend it to anyone who wants to learn UML and start out his way...
Anirudh vyas
Rating:  - Not for the Business Analyst - Strictly for the Developer
This book was so disappointing and all over the place. It is clearly written for those that are strictly into programming and coding and have prior knowledge and understanding of object modeling. Even the diagramming was not for the beginner analyst. It's written more in theory than practical information even to get you started in defining UML and what it really is.
It would have been much more informative if author would have stated up front that you have to have basic knowledge of Object Modeling and all the terminology that is defined. Next, define UML as a set of DIAGRAMS. Nothing more and nothing less! Spend the time on the details of the diagrams and how to read them versus jumping all over the place talking in theory about sketching versus blueprinting, etc. Every area seems to be lacking details in terms of what it means in layman's terms. For example, with sequence diagrams, what does it mean to look at the behavior of several objects within a single use case? Don't go off talking about the next diagram and never addressing the sequence diagrams and objects in a Use case. Provide a Use Case and a Sequence Diagram and then explain it in terms of behavior and objects. A good analyst, whether system and/or business, thinks in terms of user functions, actions and what is expected of the system.
The books also defined terms using the term which really made it confusing. I never did figure out how to define a meta-model or how it even looks.
Is UML really a programming language starting with the diagramming approach? Should the developer be able to develop activity diagrams from use cases written by the analyst? Should be analyst be looking to develop all the diagrams and have the knowledge of Object Modeling which is really UML? A lot of questions that couldn't be addressed with this book.
Definitely not worth the price!
Rating:  - The essentials...
This book provides some brief but good background to set the context then proceeds to succinctly communicate those aspects of UML one really needs to know.
|
