Fog Creek Software
Discussion Board


In your software developer experience, did you see the benefits of using UML even for small projects?

Monday, August 16, 2004

To this day I still have no idea what UML is, short of what the acronymn actually stands for.  I do notice, however, that most job postings I see require or request it, so I suppose I should pick up a book.

Monday, August 16, 2004

Yes, 'UMLStudio' is a nice package for $500.00 that gives you relatively free-form UML diagrams, AND it will generate code templates from your C++ class diagrams.  AND it will re-ingest your code and update the UML class diagrams from it.  Very neat.

As such, for smallish projects (1500 SLOC to 10,000 SLOC) I find the class diagram and sequence diagram useful for providing a high-level summary into the code.

The class diagram documents the objects and their dependency on each other.  The sequence diagram documents the time-sequence of the dependencies.

For small projects, the other UML diagrams have less utility.  For me, at any rate.

Monday, August 16, 2004

I think UML eases any kind of serious architecture work.

The UML a produce these days looks very different from what i may have produced 4 years ago let alone 18 months ago.

UML allows you to make clear the extension points of your design. It also opens up possibilities of code generation.

If you do not switch between languages and do not have to communicate at diff scales, the utility may diminish.

Monday, August 16, 2004

"UML?" - No thanks ;-)

Monday, August 16, 2004

All that you wanted to know about UML, but were afraid to ask...

Courtesy: Joe Bloggs

Sathyaish Chakravarthy
Monday, August 16, 2004

Muppet, so you will have an idea what UML is-

UML is a set of standard ways of drawing some of the diagrams common to object oriented programming.  It tells you where to draw squares, where to indicate methods, what kind of arrows to use to indicate inheritance, how to show the workflow.

To the OP, I think doing some diagrams, especially class diagrams, is useful even on small object oriented projects.  You might as well use the UML notation because a lot of tools will then help you draw your pretty pictures, and many people will be able to read them more easily without having to ask "hey what does the squiggly arrow between the two clouds mean?"

name withheld out of cowardice
Monday, August 16, 2004

UML is the devil!

The learning curve is as steep as Mt Everest.  Those that firmly believe in it are either teching it, or selling it.  Everybody else has realized you can do effective modeling without such bulkiness.

It's a sure-fire way to turn a 6 month project into a 12 month project.

I wouldn't recommend spending a lot of time on it.  Just learn what it is and what it does, and move on.

Anonymous Troll
Monday, August 16, 2004

My new position requires UML proficiency.  Thankfully, they are being quite patient with me while I pick it up. 

UML goes hand in hand with design patterns. The main problem is getting useful examples.

I still haven't found a decent example of a Use Case Diagrams.  In fact, the new company doesn't even use them - they use what I would call "use case outlines".  Which I find much more useful and easier to write and manage.

Bottom line:  Many companies only bother to document the external (customer required) interface documentation. Our shop documents every internal object and interface with a design and implementation document. We staff for it and we schedule accordingly.

What a relief to be able to find your environment documented and to not be guessing as to how that "thing" works and to have to reverse engineer someone else's code every time you need to write a new object.

Now software design feels like hardware design.  This is the discipline we used to establish back in the days when I did ASIC's.  Each module got design and implementation documents. No one questioned it because they knew it had to work first time.

With software, people think they can just "whip something off".  And you know what, they can.  Then the prototype becomes a product and then the features start to rush in like a hurricane.

As a developer, you were a willing accomplice, thinking "yeah, we need to get this done, but we'll refactor it and do it right later".  That NEVER happens (almost).  You have now enabled (in the 12 step addiction "enabler" sense) your organization into an abusive state which will never get undone.  Why? Because cleaning up the code base and documentation never has a "business case".  The business case only becomes evident when the code pile blows up.  Like raddioactive waste, simmering and bubbling until that last ciritical glob gets tacked on by some unwitting stooge and <KABOOM>.  Or, your best developers pack their bags in disgust and leave.  Why does that never make it into the business model?  Deal with it Jones.

Was I ranting? Hmmm.

UML provides a decent framework for describing object interaction.  You need some good examples to see the need (something which I think current literature is mostly lacking).

Fowler's UML distilled is a good book (the only one I've found of use), but spends too much time talking about process and why UML is good (would you be reading the book if you were not open to the idea).  Too much time on use cases.

What it needs are more examples and counter-examples with C++ or Java classes to illustrate meaning.  However, if you get the opportunity to work in a place that uses UML, you'll see lots of good examples of how it can be used to your advantage.

Necessity is the muther of invention.  Until you see the need, you'll not value the invention.

Monday, August 16, 2004

UML's sequence diagrams are useful for projects of all sizes, because they embody information that is extremely difficult to deduce by reading code.  For small projects you can figure out the static class hierarchy by looking at class declarations, but to understand the interaction of objects you need something more, such as UML.

I *strongly* recommend "UML Distilled" by Martin Fowler.  It's a short book that describes both *how* to use UML and *why* it's useful in various situations.  It's the most intelligent computer book I'ver ever ready (yes, even more than Design Patterns).

Monday, August 16, 2004

Martin, is that you?

Monday, August 16, 2004

One of the problems, one of the many problems, I see with the way UML and CASE tools are implemented in some development teams are that its treated, by management at least, as a replacement for developing, that the round trip possibilities of going from Use Case to Class design, to editing and then back to Use Case is in itself sufficient to produce quality software.

Instead of looking at the Holy Grail of tweaking a diagram and having the object spat out automatically I believe that UML should be used as a notation for straightforward communication and development between developers and up and down the management chain.

Because of this, good Use Cases should be simple and straightforward to read.  There should be no more than one Use Case per page and the complications should be outlined with swim lanes and the like rather than overcomplicating Use Cases.

Great software was never written because of UML.

Bad decisions may have been circumvented because of UML and good ideas proven with its use.

Simon Lucy
Monday, August 16, 2004

It is a tool to help you conceptualize the task at hand before writing code. It is not a silver bullet, despite what the consultants and booksellers claim.

If you use it as a Big-M Metholodolgy, it will be an albatross around your neck (like the above poster said: turn a 6-month project into a 12-month project). If you use it as a small-m methodology, you will pick and chose what parts are useful, and what isn't.

Monday, August 16, 2004

Schaum's Outline of UML is ironically one of the cheapeset yet one of the best UML books I encountered.

As far as tools go:

If you can justify the spend :Powerdesigner, if you can not justify the spend Enterprise Architect (Sparx)

OO is supposed to use uniform paradigm for analysis, design, implementation. Use cases are supposed to be classes. The idea is to factor common steps into included/uses use cases (composite pattern) and variation into extends use cases (ala template method pattern). In this way the use cases are an algebra that span all possible scenario's. The people involved in the requirements part of SDLC seldom grog OO so Use case reduce to verbose template completion.

Tuesday, August 17, 2004

Two very valuable resources to check out:

and the "What about UML and Architecture" section in the new Crystal Clear book.  (

John Rusk
Tuesday, August 17, 2004

Make that

John Rusk
Tuesday, August 17, 2004

Yeah, it is useful. Paper and pen are all that's necessary though.

Tuesday, August 17, 2004

I want to use it to document existing code: to make it easier for managers, new programmers, existing programmers, and QA to know what the software "is"; so I'm currently evaluating reverse-engineering tools.

> UML's sequence diagrams are useful for projects of all sizes, because they embody information that is extremely difficult to deduce by reading code.

I think (I may be wrong) that a "sequence digram" is merely a call stack: the subroutines that are called from some top-level method or event.

Christopher Wells
Tuesday, August 17, 2004

For a reverse engeneer tool i can recommend together from Borland.
I have toyed with it and the thing does what it is supposed to do : Generating class diagrams, sequence diagrams, collaboration diagrams, etc.

Tuesday, August 17, 2004

A sequence diagram can be a call stack. 

It can also describe protocols,  transactions and state.

A sequnece diagram can also describe muti-threaded resource locking/sharing.

Tuesday, August 17, 2004

> For a reverse engeneer tool i can recommend together from Borland. I have toyed with it and the thing does what it is supposed to do : Generating class diagrams, sequence diagrams, collaboration diagrams, etc.

I've been trying it out today: and it does (generate sequence diagrams from reversed code).

Yesterday I evaluated tools from Microgold, Sparx, Metamill, and Visual UML, which don't (many of them can generate class diagrams, but leave you to build the sequence diagrams yourself).

Together for MS VS .NET has a few bugs and missing features; but I'll continue to try it ... the only other product that I've heard of (that can reverse C# at all) is Rational's XDE.

> A sequence diagram can also ...

Thanks for the clarification, hoser.

Christopher Wells
Tuesday, August 17, 2004

*  Recent Topics

*  Fog Creek Home