|
|
24 of 24 people found the following review helpful:
4.0 out of 5 stars
***** content, *** presentation - Some brilliant stuff here, February 24, 1999
I have just completed this text, having read every word on every page. Now it is my time to give back to the authors; I take this review quite seriously. First, a little context (which most reviewers feel obliged to omit): I am 23, a consultant, and have designed and coded on 3 major systems (10,000+ lines of code, up to 9 months in duration). I have not yet independently led a project, but I will, this year. So I am ahead of the curve in time, but still young with much to learn.I have owned this book for approximately 7 weeks. I have given this 800-page book between 1-4 hours of care, 5-6 days a week since its arrival. In total, I would guess 50-60 hours of reading spent (not counting the 80+ hours of spacing out/absorption). I am versed in UML, Design Patterns, OMT, and all major technologies (excluding SmallTalk). This book has just jumped to the top of my all-time-favorites list... and I almost gave up after the 3rd chapter. These authors have discovered some key insights that will build upon the calculus of software... if the presentation were tighter, the book would be tied with Design Patterns and the UML guides in importance to our community. Put another way: if the book were more of a encyclopedia and roadmap, and less of a dissertation, the authors could have made a heck of a lot more money. But the brilliance of this book's content (read: the great clarity of insight held by its authors) cannot and will not be denied. Part of the blame for the excessive read-time was mine, part was the editor's. I have read enough books like these to know that most sentences contain pearls of wisdom, not BS. But I found myself stumbling on paragraphs of definition and example that were built on concepts that are quite difficult to absorb. The book contains only a sparse TOC and glossary, so cross-references are between general sections... very tough to get back on your feet if you slip on Catalysis' sometimes-vague, 'concrete-free' content. My recommendation to readers is to just keep on plugging... the authors usually ram a problem from three or four different angles. (My recommendation to the authors is to develop a full Catalysis glossary with every major term and at least one strong supporting example.) I nearly gave up after chapter 3, after being slammed by Catalysis' version of OCL invariant/constraint rules, which are meant to provide models with precise language (needed badly!). Knowing 4 programming languages didn't help; I hadn't read OCL, so attribute parameters, set notation, strange message syntax, _and_ Catalysis extensions left me bloody. I'm glad I didn't stop reading; the notation in the rest of the book was much more readable after the first battle. But this is the book's most glaring weakness. Catalysis depends on this precision, but there is no good guide for building Catalysis invariants that I can use out in the field (have to use the appendix, the UML OCL spec, and a bunch of bookmarks throughout Catalysis' chapters). Chapter 6 made the whole book worth reading. Being able to map from a business model to code while not throwing out all efforts from analysis and design phases? I had no idea this was possible before reading about Catalysis refinement. Worth the entire book. After Chapter 6 and the early precision-syntax wars, I realized how important this book was becoming to me. Chapter 9 tied together packages, patterns, and collaborations into a very strong argument for building frameworks (a method that will be worthwhile for businesses to explore). Chapter 10 on components is brilliant, especially to those who wish there was a cleaner component middleware on the market; here's a good start (I would read a whole book on this if the authors would write it). Having all diagrams based on UML allows you to focus on the methodology and not the tiny details (although the authors really blew it using bold type borders for minor concepts - it overrides an important aspect of UML). The last four chapters present dozens of Catalysis "business/software patterns" that, although quite helpful, don't really map cleanly to the foundation in the first 12 chapters (and the first 12 chapters never refer to these patterns). This is symptomatic of the book's lack of cross-referencing, and, in fact, symptomatic of a bigger problem... Finishing the book, I realized that I still hadn't been presented with a 'roadmap' of the Catalysis way. How do I explain the system to my boss, and how do I direct the team (other than give them a copy of the book)? The Catalysis process is not a rigorous methodology, it is a wise man in text form. Pearls abound, but a bit of digging is required. It is a challenge and a reward, just as any good book should be. This doesn't mean there isn't room for improvement. Given a knife (and a nice advance) I think I could cut Catalysis down to 200 pages of essentials, and if I can do it... A cliff-notes Catalysis would be a roadmap and an encyclopedia. This current Catalysis book can be the bible, but we need the commandments first - Catalysis as-is is not rigorous enough for us to be able to quote chapter and verse in preaching, in practice, and in defense. I believe that Catalysis being published under the Addison-Wesley series (same cover as UML guides) gives it the exposure it needs, and the fact that a design/development engineer (me) can work through this book proves that this methodology can reach the masses. It deserves to be read. But the process can be slimmed down.
|
by Yun-Tung Lau
See all Editorial Reviews
