Customer Reviews

UML Applied: A .NET Perspective

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

 

 

A curious thing about the title is its mention of .NET. Strictly, UML is independent of any environment or operating system or language. Those are implementation level details. But here, Shoemaker brings .NET into his UML discourse to show how UML can be well integrated with a .NET development process. And indeed, that is part of the book's value.

Having said this, most of the book can be read, ignoring .NET. So those of you into C++ or Java can still gain from the book. He gives lengthy, detailed explanations of defining and refining requirements. And then mapping these to components and interfaces and using these results to design architecture and components. Not a book for the impatient. Shoemaker takes time to carefully expound on the basic ideas. If you're new to UML, a deliberate slow reading might be best, to gain the most from what he is saying.

Another virtue of the book is that apart from the .NET details, it can be used years from now. (Barring any major advances in our understanding of the design process.) It is not one of those computer books that you have to replace in 2 or 3 years time.

The critics of this book seem to be most negative about Mr Shoemaker's failure to link Dot Net and UML. While it is true that there is not a great deal in the book about this specific topic, that is certainly the top half of the glass. The bottom half is the Five-Step-UML and requirements gathering with UML.

The Five-Step-Process, DRADR (define, refine, assign, design, reiterate) has been used by this writer with great success and is worth the price of the tome by itself. In studying and obtaining a certification in UML many books and articles have been perused but this was the first found that took UML beyond a set of thirteen diagrams to an executable process. Not only is the process defined but also detailed to the point where a process template has been developed from the ideas outlayed.

It is a cliche that the down fall of most failed business process projects, including many SDLC projects, is the failure to properly elicit, define, analyze and communicate process requirements. This fact makes Mr. Shoemaker's three chapters, five, six and seven, on requirement gathering, categorization, analysis and refinement a trove of process knowledge.

I have several UML Books.
If the other books had done their job, I would not have had to buy this one,

This is the ONLY one that get's the point across without making you nod off. It's hard to put down. Probably because I finally found someone who can clearly explain this stuff.

The author has experience TEACHING this class and has learned from the students in how to do just that.

What's with the reviewer making fun of stick figures?
That's UML from the three amigos, not this author.

This is a UML book not a dot net book.

-Little UML that makes sense, even less .NET (not to mention the links between UML and .NET - 10% of this book?)
-Too much UML and modeling process freestyling.
-Can you take an author seriously if he keeps on quoting large blocs of text from other books and weblogs and particularly the ones from the Gilbert comic strip? How about one that not only uses "stick-man" symbol, but also provides his own personal "stick-pet" symbol?
-the whole book seems like filled with personal comments and stupid jokes.

Martin is a sharp man with great thoughts on UML... however Martin was working for us through Robert Half Consulting and left us mid project with no warning and no follow up, he just picked up and left. I think a crucial part of the development process is that your development team stays put and if someone needs to leave they give you fair warning and also give you the documentation/coding to allow you to complete your project, I am just saying...

While looking for .net enterprise dev books we bought this one and it supplements Enterprise development with vs .net, uml and msf quite well. One thing though is that it is apparent that the authors do not quite understand all topics they cover.