Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Book Reviews

Java Modeling In Color With UML 59

Posted by timothy from the color-commentary-on-color-modeling dept.
Jason Bennett took a look at the triply-authored Java Modeling in Color with UML. What he came away with ... well, that's for you to find out, but computer book writers everywhere ought to be grateful that Slashdot book reviewers are not granted the power of the emperor's thumb.

Java Modeling in Color with UML
author Peter Coad, Eric Lefebvre, and Jeff De Luca
pages 218
publisher Prentice Hall
rating Far belo
reviewer Jason Bennett
ISBN 0-13-011510-X
summary Peter Coad's attempt to integrate another dimension to modeling

Background

Back in my wild college days (ok, so maybe they weren't that wild ...), my introduction to object-think and object-speak came through two main conduits: Smalltalk, and Peter Coad. His Object-Oriented Programming helped teach me how to think natively in objects, and gave me my share of vending-machine problems. When I learned that he had come out with a new book, I knew I had to get it and see how his views had developed in the era of Java and UML. This was not what I had in mind.

The Scenario

This book is mainly divided into three parts. Part one is composed of chapter 1, where the authors describe the concept of modeling with color. It's an excellent idea, really, color coding class design to distinguish the parts the objects play. Color coding has the advantage of adding another dimension of information to a diagram without clogging the diagram with more words. The chapter also includes a discussion of the "domain-neutral component," the fitting together of archetypes into standard patterns. This is the basis for part two, comprised of chapters 2-5. Part two is basically a series of object models strung together with a bit of text to describe each of them. Various views of the model, including UML activity diagrams, are shown. Finally, part three is composed of chapter 6, where the authors describe the concept of Feature-Driven Development, that is developing software in narrow slivers, thus maximizing deliverables and customer satisfaction.

What's Bad?

A dangerous question to ask about this book. I approached this book looking for something that would teach me about patterns, what they do, some examples, and ways to use them in my work. What I got was a pattern dictionary with no instruction in their use. Since I get paid to design and write Java, and since I have some formal training in OO, I like to think that I have some sort of clue about this stuff. Unfortunately, this book still didn't make any sense to me, and still didn't seem useful at all. Why do I want 20 pages of manufacturing models? How did they come about? Why would I want to do it that way? How else could I do it? What the heck is going on with this model? It's like trying to expand your vocabulary by reading the dictionary, with no example sentences to guide you.

The other parts are mildly interesting, but not special in and of themselves. The color idea is nice, if you design like Coad. If you don't, I have to wonder how usful they would be. Feature-driven development has been expressed in other ways before, but this book does not address a major problem with the concept: how can you develop narrowly when you need a broad backing for the application? In other words, it's all well and good to get one feature out at a time, but if you have to write half the middle-tier and all the back-end for that one feature, have you really bought yourself anything? I don't mean to settle the debate here, only point out that an entire book could be written on that concept (and in the case of Extreme Programming, has been), and one chapter does not do it justice. In many ways, it seems tacked on.

What's Good?

Well, as I said, the first and last chapters have some promise. If you read the comments on Fatbrain and Amazon, the opinions seem to be strongly divided. People either love or hate this book. If you need these models, and can intuit a lot from the diagrams, this book could be very useful to you. If you're anything less than an expert, though, I doubt what you will be able to get much from this book.

So What's In It For Me?

I'm currently ordering Applying UML and Patterns, as that has been highly recommended to me as an intro patterns book. I'll let you know how that turns out. I do believe in the pattern concept, as that is exactly how the other engineering disciplines work. I truly hope we can make it work for software engineering.

Table of Contents

  • Preface
  • About the Authors
  1. Archetypes, Color, and the Domain-Neutral Component
  2. Make of Buy
  3. Sell
  4. Relate
  5. Coordinate and Support
  6. Feature-Driven Development
  • Appendix A: Archetypes in Color
  • Appendix B: Modeling Tips
  • Appendix C: Notation
  • Index

This book is available at Fatbrain.
This discussion has been archived. No new comments can be posted.

Java Modeling in Color with UML - AWAITS LINK More

Java Modeling in Color with UML - AWAITS LINK

Comments Filter:
  • I don't know about take off, but if they include it free with Visual Studio which I believe they plan to do, I'd be tempted to give it a try to build some simple dev tools I've wanted.

    Not free per se, but part of the bundle and intended to replace their, um, "Java" implementation.
  • GOF = "Gang of Four"

    Gamma, Vlissides, Johnson and Helm

    The book is called Design Patterns : Elements of Reusable Object-Oriented Software [aw.com].
  • Our dept. actually had Peter Coad come up and give us a seminar. It was actually really cool. His idea of adding colors to plain UML is nice and easily adds another dimension of description to plain diagrams. It also gets you thinking in terms of descriptors, and actions, and business processes, etc. He just seems like a really cool guy. And his Together products are really sweet. Except for the latest one where I can't figure out how to create a global class diagram for a package hierarchy.
  • whether the author of the review has read the Gang of Four "Design Patterns". It's a book that also generated a lot of heat when it was published.

    If the reviewer hasn't read the GoF this is the place to start when we're talking patterns. Every book like this should be jugded against the GoF 'bible'. In my opinion.

  • Re:Unfair review? (Score:3)

    by Coz ( 178857 ) on Thursday July 27, 2000 @06:41AM (#900933) Homepage Journal
    Well, I've read it - I own it. I've met and talked with Mr. Coad hisownself, and used his tool... the tool's better than the book. Hereafter is my opinion of the book, as an OO designer/developer of several years' experience:

    Chapter 1 is the concept he's describing, modeling in color. Coad defines four archetypes, and associates a color with each. He gives examples of how to classify your classes according to these archetypes, and works into thinking in terms of them. He then introduces another abstraction, the "domain-neutral component," which is a large diagram template which can be customized to fit your particular situation(s). I had a bit more of an issue with this one. It seems useful, but I'm not sure that it doesn't stunt your thinking.

    Chapters 2-5 are examples, in gory detail. He and his coauthors have defined 61! different domain-neutral components (which I honestly would call domain specializations of his overall Domain-Neutral Component). It's a catalogue, with fair descriptions, but I wouldn't put this into the category of Design Patterns, quite... I'm really not sure how to classify these things. (Have to think about that some more.) If you're familiar with OO, reading through this will educate you on the thought processes used to generate these things, and if you happen to have a problem that has pieces that fall into these 61 bins, you're set!

    Chapter 6 is a departure. Feature-Driven Development is a "how to build what you've designed" process, and really doesn't fit the tone of the rest of the book. I found it useful (as I've posted elsewhere), but it's a jarring departure from the monotony of reading the catalogue of components. Well worth reading on its own - but not worth the cost of the book.

    Appendices have large (readable) versions of the archetypes, and modeling tops.

    Now - a bonus tip from Me to You. Go to Coad's company's web site ( Togethersoft [togethersoft.com] ) and download their modeling tool (IMHO, beats the tar out of Rational Rose). Then, ask them nicely for a 30-day evaluation license, and do their tutorials. The tool does these components, and GOF Patterns, and lots of other fun things, and has a tutorial and examples of the Modeling in Color (although not Feature-Driven Development) from much of the book. Save your cash and do it in software :-).

  • The idea of using color to add another dimension to UML models is not that profound. I've been using color in ERD diagrams to subdivide data domains years before I used UML. Who couldn't figure out for themselves that color is a great way to subdivide Classes by Stereotype,et. al.?

    I think the academic pressure to create something novel is what has fueled this UML-addon nonsense, things like JUML and others.

    -ryan

    "Any way you look at it, all the information that a person accumulates in a lifetime is just a drop in the bucket."

  • I've done about a dozen Slashdot book reviews. I can say that as they are voluntary, they tend to be about books that are well worth reading, otherwise I wouldn't be reading them. Therefore, they do tend to get a higher rating and the review is more about explaining what about the book is good, rather than that it is good. On the other hand, occasionally I've read poor books, and when I have reviewed them, I've given them low ratings. It's just that I've read less poor books.

    --
    Marc A. Lepage (aka SEGV)

  • Here's what UML in Color is about... (Score:3)

    by gwonk ( 23993 ) on Thursday July 27, 2000 @08:52AM (#900936)

    UML in Color is about the four archetypes of classes. These archetypes are Moment-Itervals (Something happening in time), Person/Place/Thing (Something in space), Role (an iteraction between a M-I and a PPT, and Description (meta data on a group of PPT objects).

    The color helps to distinguish between each of the various archetypes (Pink for MI, Green for PPT, Yellow for Roles, and Blue for Descriptions). With the colors, UML diagrams become much more readable. Normally you end up with a backbone of pink MIs, representing the transactions that the system has to perform. The handfull of PPT objects interact along the way via the yellow Roles they can fulfill. Blues pop up when there are several PPTs that share the same characteristics. It works remarkably well.

    While I found that the subject of the book (the archetypes and using color to represent them) very enlightening, the presentation was poor. The whole book comes accross as two or three magazine articles mashed together with a catalog of class diagrams. The most important information in the book is in the first chapter or two. Coad had posted most of it on the web at one point, I don't know if they are still there. Try at http://www.togethersoft.com

    There does seem to be a paradigm switch involved. I found the technique immediately helpful. Others have a much harder time seeing how the archetypes are applicable to their problems (sometimes it is not). If you are an Object-Oriented designer, read the first chapter and file it away into your set of techniques. You can never have too many tools.

    gwonk
  • Speaking of Fowler, his _Analysis Patterns_ book is another must-have. I also find his _UML Distilled_ pretty handy.
  • I bought 'Java Design' a while ago, and cannot say I care too much for it. There was too many abstract use cases that seemed removed from the java language. I had already had about a year programming java experience and had taken some OO theory/design courses while in college. Even though one of my favorite professors is doing is sabbatical @ Object Int'l, I'm tired of Peter Coad writing about how things should be. Bruce Eckel's 'Thinking In Java - 2nd Ed.' rocks on the other hand!!! That'll teach you to think and code at the same time.
  • Yeah, you probably are. I'm color blind too, and this color modeling crap always bothered me since i first saw it. It doesn't take a genius to figure out most coders are male, and that a good number of males (more than female) are color blind. I've been subscribing to the Coad Letter for a while, which finally sprang back to life a couple of months ago, full of these color diagrams. If they just made a damn bit of effort to do things like use a dark green instead of a bright yellow-green i could probably tell the difference between their choices of yellow and green just by shade, but noooooooo! There is probably other colors that are too close to each other in shade for me to differentiate, but how the hell could i know, i'm frigging color blind! Damned Coad letter....
  • This is a good introductory book, but not necessarily to using patterns. It is a great introduction to OOA&D, and might get you started with understanding how patterns are used, but that's not really its focus. Maybe it's enough, though. I just wanted to say that it might not be exactly what you think.

    I personally think the GOF book is a great introduction to patterns, but maybe the non-catalog text is too short ...
  • When will you understand?

    The day we will understand is the day a mindless idiots like you do actually produce the unit tests, the documentation and the clean refactoring in your code, instead of just hacking together a big lump of unreadable crap and claiming you are doing XP when in fact you're far from it.

    Does that answer your question?
  • Its definitely true that you get more out of UML the more diagrams you use, and I think we agree that its a reasonable way to communicate a view of a project.

    There's an AC post attached to mine that should really have been moderated up, pointing out that Christopher Alexander (on whose architecture work Design Patterns are based) made a distinction between formal and functional description, where the formal description describes what was done, and the functional description says why. I think this is important here: UML is a formal description. It needs to be accompanied by functional description to make useful sense.
  • For a detailed review of Craig Larman's book see our page at:
    http://www.objectsbydesign.com/books/applying_uml. html.
    This book teaches how to use UML as part of a coherent object-oriented process .
  • There used to be a link around here somewhere for people who wanted to do book reviews. Where is it?
    --
    Give us our karma back! Punish Karma Whores through meta-mod!

  • Slashdot should do an "Ask Peter Coad anything" (Score:4)

    by HowdyDoody ( 27071 ) on Thursday July 27, 2000 @06:01AM (#900945)
    Peter Coad loves to talk objects with anyone and is excellent at explaining himself. He had a 1999 JavaOne talk dedicated to this "UML Modeling in Color" idea and it was very informative and approachable.

    Slashdot should conduct an "Ask Peter Coad anything" interview and give him the chance to clarify stuff in his book.

  • Interesting idea, but how practical is it? (Score:3)

    by spankfish ( 167192 ) on Thursday July 27, 2000 @06:03AM (#900946) Homepage
    I'm pretty sure that the book's author isn't the first person out there who has suggested color-coded object modelling, but given that most system design documentation out there is going to be read on paper, what's the point?

    Also, since most IT development people are male, we have a much higher percentage of color-blind people amongst us than the general population. I personally know three other developers just in my circle of peers who are completely, if not partially color-blind.

    It's fine if you can read and understand a diagramming method, but what about the person who ineviably must follow in your footsteps? We ought to try to always consider the person following in our footsteps, because most of the time, we are following someone else ourselves.

    I saw this written somewhere: "I always try to write my code as if the guy who has to maintain it is a psychotic axe-murderer who has my name and address." - the same approach should be taken to documentation.

    --

  • Nope, pre-Noahian makes more sense, in reference to one Noah Webster, who created a dictionary full of (to the rest of the English-speaking world) spelling errors.

    Case in point, "colour" vs "color".

    Nothing to do with the flood at all.

  • I believe the word you were looking for in your red-text-on-green-paper dictionary was "antediluvian"

    Rich

  • Favorite design books (Score:3)

    by bharlan ( 49602 ) on Thursday July 27, 2000 @07:03AM (#900949) Homepage
    For pure object-oriented design, I like "Design Patterns" by Gamma et al (Addison Wesley), and "Object-Oriented Design Heuristics" by Riel (Addison Wesley). Gamma et al (known as The Gang of Four) make a definitive inventory of patterns that EVERYONE must know. Riel's book does a better job of explaining where the patterns came from.

    For UML, I prefer the UML Modeling Language User Guide by Booch, Rumbaugh, and Jacobson (Addison Wesley). More than other references, this book stresses constructs that you are likely to use most often.

    The ideas in "Refactoring" by Fowler (Addison Wesley) seem almost entirely self-evident. Nevertheless, by reading this book, I improved my coding habits immediately. This book shows how to evolve a design as you code.

  • IMHO, the GOF book is THE reference for patterns, but it's not easy, especially for beginners. Folks need a good grounding in OO concepts and implementation to be able to understand what's going on. Other folks have come out with other "Patterns" books, esp. Mowbray and friends - check them carefully and assess whether they talk about what you think they talk about ("Antipatterns," especially, is more of a "examples of bad software process" book, (again IMHO)).

    I have yet to see an "Intro to UML and Patterns" book that I liked... any suggestions?

  • Most main company developers have a subscription to MSDN, and MSDN contains full versions of most Microsoft development software. (IE, OSes, development tools, Office, etc.). These developers basically get these tools for free - since the company they work for is the one paying the $2000+ subscription fee. If they find that C# works for them, then they'll use it. If not, they won't. If companies find that they have reasons to develope in C#, then it'll take off, just like any other language. Actually, given the fact that VBScript is being used, I'd say any MS language has an unfair advantage... :)

    (Note to moderators: yes, this is offtopic to the article - but it's ontopic in the thread. Read posts' threads before marking posts as "offtopic.")

  • I very much liked Riel's book - didn't agree with all of his heuristics, but it was valuable brain training. There's more to the Heuristics book than just "where the patterns come from" - it catalogues and defines lots of pitfalls of OO design. Patterns + Heuristics = Better Design.

    I must be doing something right - I have all of those books except "Refactoring" on my bookshelf now (and it's been in my group's reference section).

  • Re:Fascists (Score:1)

    by Anonymous Coward
    The score won't go above 0 for 3 reasons

    1. The post isn't worth a moderation point.
    2. The moderators don't want to waste a point on this comment (see above) because it's a privilage to be honored a moderator and they want to use their moderation points on posts really worth a damn.
    3. It's really a terrible comment to expect awarded a point.
  • So what is color modeling? The review seemed to indicate that there might be something to this idea but didn't give out much details, or even a brief description, what it is.

    I have my crayons right here with my UML diagrams. Should I just start slapping colors around everywhere, or is there a sort of a systematic way of adding colors?

    Are different patterns displayed in different colors? Different class types? What?

  • Yeah, the Together products seem sweet but jeez...They're incredibly expensive.
    I know, I know: "You get what you pay for" and "A craftsman doesn't scrimp on his tools", etc but still...$7200 for "Together Control Center" and something like $5400 for the next step down?
    I always know I'm not going to be thrilled with the price of a tool when I can't find it listed on the website. Do they think I'll be so impressed by the download that I won't care when I find out what it costs? Or that if I knew up front, I wouldn't download it (maybe there's some truth to that one).
  • I've heard Coad give his 1-hour talk on this, and used his tool (Together [togethersoft.com], which makes Rational Rose look very obsolete). It can add some context to UML diagrams, and we were able to communicate pretty well with a graphics-brained UI designer using the color models.

    I own this book, and I was honestly disappointed. I'd like to see this combined with "Java Design" and given some more fundamentals-of-OO/UML, maybe a sprinkling of component-based architecture, and then I think he'd have a heck of a book. On its own - it's thin.

  • As the UML v1.1 was released (Sept. 97), software engineers thought that it was the end of the "yet another methodology" syndrome. I'm sad to say that it was false.

    Maybe you should consider adopting the oldest and most successful engineering methodology: mathematics.

    See, for example, Bird & de Moor's Algebra of Programming [amazon.com] for a programming-oriented text, and Lawvere & Schanuel's Conceptual Mathematics: A First Introduction to Categories [amazon.com] for a very readable introduction to basic modern algebra (all you need to know for the latter is high-school mathematics).

  • And an archetype is ...?
  • I saw this written somewhere: "I always try to write my code as if the guy who has to maintain it is a psychotic axe-murderer who has my name and address." - the same approach should be taken to documentation.

    My first out-of-college job was writing Ada on an Air Force contract, where the requirement was to write code that could be maintained by airmen with a 7th grade reading level. Ever tried to describe generics to someone at the 7th grade reading level? How about nexted SQL selects? Some parts of our software had three and four times the lines of comments as lines of code (plus all the USAF's required MIL-STD 2167A documentation).

  • The book is called: Applying UML and Patterns - An introduction to Object-Oriented Analysis and Design by Craig Larman. It helped me alot.. Keep in mind though..that it's just one of the many methods how to design a Object-Oriented program...

  • why this book is a bad thing (Score:3)

    by sl956 ( 200477 ) on Thursday July 27, 2000 @07:32AM (#900961)
    As the UML v1.1 was released (Sept. 97), software engineers thought that it was the end of the "yet another methodology" syndrome. I'm sad to say that it was false.
    Instead of it, we have now a "yet another book about the UML" syndrome, and it is worse: It was easy to say: "I'm using the foo methodology" (Booch, OMT, Objectory, Coad&Yourdon, Shlaer&Mellor, Martin&Odell...). It is now very difficult to explain: "I'm using the UML notation (as the UML is only a notation and not a method[ology]) with the foo development process (Coad's Feature Driven Process, Rational "Unified" Process, CISI Process...)".
    The main problem is: each author uses the UML notation in his own way, especially the methodologists who jumped lately in the UML bandwagon. They cannot agree even on the use of the core concepts of the UML.

    Fortunately, the Software Process Engineering Management [omg.org] Request For Proposition of the OMG and the UML Profiles mechanisms (see this OMG white paper [omg.org] ) should address this concern: It should allow to describe a development process in a little more rigorous way than the current informality and to precise the particular usage of each construct of the UML notation (or extensions of this core notation) in the context of a given development process.

    A book exposing Coad's point of view on the UML will be a "good thing"(tm) only when we'll have such conceptual tools at our disposal. Before this moment, it only adds to the confusion of the newcomers to the UML.

    I approached this book looking for something that would teach me about patterns
    Concerning the patterns, I think that the "Design Patterns" book (ISBN: 0-201-63361-2) of the so-called "Gang of Four" (Gamma, Helm, Johnson & Vlissides) is still the best book about patterns you can read. Each pattern is described by an OMT class diagram and C++ code but the translation into UML and Java is mostly straightforward.
  • Good recommendation on Design Patterns. Another book, "Applying UML and Patterns" (ISBN 0-13-748880-7) by Craig Larman, is also great. It's a fantastic introduction to both UML and patterns, and the examples use Java.

    I usually recommend the two hand-in-hand. You can never read enough good stuff about patterns, they're the point of OO. :)

  • Here's a white paper which summarizes the UML color modelling ideas, complete with some colored UML diagrams: Developing a UI Design from a UML Color Model [uidesign.net]

  • Gotcha :) My mistake.

    Rich

  • So much for the notion that the Slashdot book reviews always give good scores!
    Christopher A. Bohn
  • This is one of those books which really should come with a prerequisite reading list. This book is not meant for someone trying to start learning about patterns. The reviewer should come back to it after reading Java Design (also by Coad) as well as at least one pattern book. I would recommend Mark Grand's Design Patterns in Java as a good place to start. The reviewer may also want to pick up some generic OO Design books.

    The splintering of reviews on Amazon further reflects this required background. See the reviews of Coad's Java Design on Amazon for a further example of a mis-marketed book.
  • er, make that array elements...
  • I'm colour[0]-blind[1]. Am I stuffed?

    FatPhil

    [0] And stuck in the Pre-Noahian Era
    [1] Red-Green Anomolous Dichromat, to be specific
  • At the same time, I'm not sure there's a whole lot of value in reading about a book that you shouldn't buy.

  • This book goes best w/"Java Design" (Score:3)

    by uglyhead69 ( 186990 ) on Thursday July 27, 2000 @05:37AM (#900970) Homepage
    The author has a very good point about this book. It has absolutely no context on its own. However, If read and used in conjunction with "Java Design" also by Peter Coad et al, the design patterns described begin to be meaningful.

    "Java Design" has the added advantage of some very amusing diagrams.
  • ...how do you reconcile this with the fact that, in the end, it all seems to boil down to things like "colour palettes"?
  • Counter argument:
    Reading about a book you shouldn't buy is of serious value for the following reasons:


    1) Either you will agree with the review and possibly save some money by not buying the book or disagree with the reviewer and discard his/her other book reviews. In either case you learn something about the reviewer which might be helpful later on.


    2) If you need a book on a subject and there isn't a well trumpeted best book for the subject (like UNIX Network Programming by Stevens), removing the bad books from the list of books on the subject makes finding a book that suits your purposes easier.


    3) Some of these books on programming are just plain crap and for the cost of many books (usually between $30 - $60 (O'Reilly being an exception - their books are usually less expensive)), we deserve more for our money. Who knows, maybe publishers will learn to put out better books.


    4) Finally, knowledge is never wasted.

  • If someone would have given Judge Kaplan this book, it would have been clear that programming is an artistic expression.
  • [...] C #, that new Microsoft language. Is this thing going to take off?

    I don't know about take off, but if they include it free with Visual Studio which I believe they plan to do, I'd be tempted to give it a try to build some simple dev tools I've wanted. They don't give away VB or I'd probably write it in that. Not that I have any love for either of these languages, but for free (gratis) I'll use 'em...
  • <rubs eyes>
    I thought you were subtracting arrays.
  • Not to point out the obvious, but "Design Patterns" by Gamma et al. is an equally appropriate place to start.
  • The GOF book is great, but I would like to see it revised to b based more on Java and not so much on SmallTalk. I would also recommend getting it on CD (as I did). The CD is unabridged and very easy to search and navigate.
  • <rant length=short>
    The GOF book is THE pattern book. Everything else doesn't come even close.
    </rant>
    Seriously, I think it's the best intro pattern book out there. Check it out.
    --
  • Seconded. He really is very good at explaining things in person (although he's expensive as hell). I've used Feature Driven Development (chapter 6 of the book) - I thought it was useful, it made our bean-counters happy (we had easily identifiable earned-value milestones, and suitable checkpoints), was understandable by both techies and management, and it integrated well with our company's Official Software Development Process. Don't use it for design - use it for implementing the design.
  • Naturally, all reviews end up being the reviewers opinion, even some may claim otherwise. So from that point it may have been a valid review.

    However I think it would have been more interesting to read a review by someone that is knowledgeable about UML modelling and patterns. I got the feeling that there was some bitterness behind the review which made it less objective than they usually are.

    I haven't read the book however, so I will not comment on it. Furthermore I found the UML Modelling book I have read (Using UML, Perdita Stevens, R. Pooley.) incredibly dull, although the concept is neat.
  • My experience with UML is that the diagrams do not serve much useful purpose on their own

    This is true, and they never meant to be sufficient by themselves either. All models need a verbal explanation as well. But in some cases it's easier to explain things when you can display a model of what you're trying to explain.

    Models themselves aren't sufficient and a purely verbal explanation can sometimes be very hard to grok if you don't have the visualization. Remember that a picture can tell more than a thousand words. Verbal explanation combined with UML models (and that means you use different views to your model, not just the plain ole class diagram) can make the specs sometimes almost bearable to read.

  • Re:Experiences with UML (Score:3)

    by fidget ( 46220 ) on Thursday July 27, 2000 @07:35AM (#900982)
    My experience with UML is that the diagrams do not serve much useful purpose on their own

    When most people talk about using the UML, they are referring to a class diagram. That, in itself, only begins to describe the project: it is enough for someone to go code up the data and members of the various classes, and not much more.

    However, if you use the sequence, interaction, instance, and use cases, you get more brushstrokes on the canvas, and the thing actually begins looking like a real project.

    I guess the idea I'm trying to get at is that each diagram attempts to communicate a different relationship. Some overlap, but for the most part it's true.

    Some examples:

    • class: great for a basic introduction of the coding structure; good to give to the junior on the team for skeletal implementation, and to communicate general characteristics of the classes
    • instance: good to imply memory and disk usages, and to indicate threading or parallel processing
    • interaction: good to illustrate the flow of messages and the players involved in normal traffic handling
    • sequence: another message flow illustration, but this time quasi time-based. Great for illustrating lifelines, spotting redundancies, and demonstrating need for object reuse
    • use-case: my least favorite, but most useful when communicating the 'why' of the project. This kind is ideally suited to communicating to a suit or markettroid what niche or need your product is likely to fulfill. It is also somewhat useful in outlining support cases and identifying early the minimum requirements for such.

    Dont underestimate the use of pictures. If they are truly worth a thousand words apiece, then imagine how much happier someone is going to be to look at the diagrams instead of reading ream upon ream of dry detail-filled dead tree pieces.

    Even so, UML won't present a complete view of the project -- and people won't understand it just by looking at the "pretty pictures." However, if it manages to clearly convey even 80% of the scope of the project (which I feel is an attainable goal given intelligent application of the UML), just think about how many fewer questions you'll have to answer later.

    -f

    IMHO, IANAL, and all the standard disclaimers.

  • Color UML diagrams. Just what we needed. This sounds like an idea from someone who does too much PowerPoint. The next step will be UML with little images in each box. It might be good for impressing the dumber suits, but not during actual design and implementation.

    UML is a way to obtain an overview of a system. A few pages of UML are useful. If you're accumulating binders full of UML diagrams, it's probably not doing much for you.

  • I recommend this book "Java Design Patterns. A Tutorial" by James W. Cooper. This book describes in a great detail design patterns in Java and their use, it also has UML diagrams for all of them. Those of us who are familiar with 'Gang of Four' and their "Design Patterns" book would find this really usefull. Enjoy!

  • Experiences with UML (Score:3)

    by SimonK ( 7722 ) on Thursday July 27, 2000 @05:53AM (#900985)
    My experience with UML is that the diagrams do not serve much useful purpose on their own. They almost always need to be accompanied by a verbal explanation of the problem being solved and the type of solution employed before they start to make sense. Possibly this is why this book does not go across very well. I do not see the addition of colour helping very much.

    At best these kinds of diagrams and things are an aid to communication, but they are not a substitute for it, and they certainly are not a substitute for design. There seems to be quite a common belief that the existence of UML diagrams somehow implies that the design they represent is well thought through, or even coherent. It does not.

  • Sorry for posting this article here. There's something wrong with Slashdot. I did make a reply on the Java article, not on the security.


  • What is the GOF book?


    Refrag

Slashdot Top Deals

"I am, therefore I am." -- Akira

Close