Most Helpful Customer Reviews
|
|
8 of 9 people found the following review helpful:
5.0 out of 5 stars
Definitely worth reading., December 27, 1999
The UML books cover too many notation options. The individual authors -- Rumbaugh, Booch, Jacobson -- all have worthwhile contributions to OO, but the Fusion method takes the best parts of each and puts them together. One glaring shortcoming: some notation that the authors call the Life-Cycle Model. It's academic junk. No one uses it. This means that you don't want to follow their method blindly. (I didn't care much for their Visibility Graphs, p. 80, either.) One strength of the book is that they present a Fusion Process Summary in Appendix A that ties things together nicely, including a useful diagram of the entire method. Even if you use UML, you need to pick out what parts of UML you will use. I recommend using the Fusion method -- minus the Life-Cycle Model (p.31) -- and do it with the UML notation. The book, UML Distilled, gives a nice summary of UML notation and terms. The Fusion Method is excellant for object oriented design.
|
|
|
3 of 3 people found the following review helpful:
4.0 out of 5 stars
Strong method, fair description, July 14, 1998
By A Customer
The OO method described is more complete than any I have used. It does have some weaknesses, namely in parallel (multi-threaded) development. But it is a complete method. It is not simply a notation without process, or process without notation.On the down side, the book is dense, contradicts itself (e.g., the notation described in the appendix isn't used in the main text), short on examples, and somewhat short on how to use parts of the method. But it's worth it simply for the method itself.
|
|
|
5.0 out of 5 stars
Oldie but goodie..., July 3, 2009
I owned and read Object Oriented Software Construction, version 1 and 2, The Booch Method, 1 and 2, and OMT. It was not until I got this book in the mid 90's that I finally saw a clear distinction between analysis and design.
This book had a significant and positive impact on my appreciation of formal approaches and their use in software development. OK, now I'm a proponent of much lighter-weight design with TDD or BDD, but at the time, this was a great book.
I really liked the strong separation of design and analysis. I loved the use of sequence diagrams to show system level interaction. These scenarios worked well for my understanding of building a system.
The process did not have a state diagram, as it was forbidden by HP at the time, so instead there was a (Backus-Naur Form) BNF-esque or regular expression-like syntax for taking scenarios and turning them into valid sequences of system interactions (their name escapes me, but the approach is still well embedded in my brain).
This was a great book.
The one thing that sort of frustrates me is that I strongly believe that the Unified Process and the Unified Modeling Language actually took a lot from this process but did not offer much in the way of referencing it.
This work was in a sense somewhat derivative of Booch and Rumbaugh. However, it brought those two processes together into a cohesive whole that neither had achieved until later when they created the UP.
That the process lacked use cases was maybe unfortunate, but the system sequence diagrams along with their take on representing valid interaction patterns, made this a nearly complete whole that simply worked very well.
|
|
|
Most Recent Customer Reviews
|
See all Editorial Reviews
