The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

does anybody use UML in open source?

My company sent me on a 5 day OO design workshop.  Lots of talk of UML, proper OO design, etc.  My learning style basically consists of looking at something that was done right, gleaning the good bits and reapplying them in my own projects.

That lead me to ask the instructor "do you know of any good examples of applications in the open source world that follow this design process- heavy specification beforehand and extensive UML modeling that is based heavily in the problem domain that actually matches a good maintainable working codebase?".  His reply was a bit disconcerting "no, most good examples of OO design occur in software development houses who don't release their code."

I was already a bit skeptical of all this UML hooey, but I'm willing to give it a shot.  But I find it very hard to believe that if it's worth a damn that no open source projects would implement it.

My question to y'all: do any of you know of any open source projects that are of decent size and show the benefits promised by good OO design where I can go and download both the code and extensive UML diagrams that match it? 

There must be something out there...
adam Send private email
Friday, September 16, 2005
ARGOuml is a nice CASE tool for UML, which is also OpenSource.

Also, a while back when I asked a similar question, most people said  to use "Paper and Pencil", and for very small projects, this, to me, is the most cost effective and flexible fashion to do this.
Arafangion Send private email
Friday, September 16, 2005
Starting in the late 1990s I became curious how the UML CASE tool vendors (including Rational, TogetherSoft, and others) built their own UML tools. So I started to communicate with some of the developers or managers of these tool projects. When I posed my standard question, "Did you use the UML and your UML tool to create its next release?" the answer"in every case" was "We didn’t" and typically a fleeting facial impression which suggested either embarrassment or "Are you crazy?!?"
Jan Derk
Friday, September 16, 2005
If you want to learn something from open source, read this:

And, of course, this:
Berislav Lopac Send private email
Friday, September 16, 2005
Don't make too close a coupling between 'good OO design' and 'using UML'. The former happens a lot; the latter less so. It's entirely possible to come up with a wonderful object model without ever having heard of UML. My position (which is based on a solid foundation of ignorance) is that UML is little more than a *formalization* of the boxes-and-lines approach that everyone seems to instinctively use when given a pencil and a blank piece of paper and asked to come up with an object model.

In short: You can (and lots of people do) do good OO without doing proper UML.
Larry Lard Send private email
Friday, September 16, 2005
Exactly.  UML is like XML in many ways - more complex than the solutions that everyone was rolling for themselves before it came along, and widely perceived as too cumbersome, the advantage it provides is nothing to do with "power" or "expressiveness" and _everything_ to do with standardisation.

One or two core programmers controlling design (typical OSS project) -> can get by with custom solution or informal spec -> UML may not be useful.  Numerous architects and hordes of programmers (typical industrial project) -> needs formal specifications in a standard format to ensure efficient and accurate implementation -> UML can be very useful.

(Which leads us to a slightly different question: what do the handful of industrial-scale OSS projects, like KDE and, use for THEIR specifications?)
Friday, September 16, 2005
Before getting into UML too heavily, this is a good read:

Only advice I could give is that UML use cases aren't.  Drawing a picture helps, but don't rely on it.  (Class diagrams are pretty useful, though.)
Matt Brown
Friday, September 16, 2005
UML is a vestige of the Big Four ( Five, Six, whatever number is left) and their massive ERP projects of the 90's.

If the system wasn't on time and within budget it wasn't their fault. Obviously all the documentation and "the process" showed they knew what they were doing!

The classic description of the motivation of OS projects is a developer has an itch. In this scenario there is no reason to pump up billable hours with worthless activity.
Phil C
Friday, September 16, 2005
UML is a tool. I have many notebook pages that over the last year I've filled with sequence diagrams and class diagrams.

Do not bother with a UML Case "tool". That, I think, is a huge waste of time.

Instead, use the UML tools to design with and work out your analysis of others designs that you're debugging.

The whole use case thing is far over done in the UML world. An text based outline I have found to be the most useful of how use cases should be thought through. Little pictures of stick men are just plain stupid.

UML class diagrams are useful for dependency understanding.
Sequence diagrams for threading and resource problems. Protocols analysis too.

Finally, never hesitate to make up your own diagrams when necessary. The end product is not UML but software that can be maintained and is bullet proof.
hoser Send private email
Friday, September 16, 2005
Open source projects don't (usually) have to demonstrate or communicate design to anyone so _designing_ with UML is rather pointless. However, _documenting_ with UML is just as useful as in any other project. Whether anyone actually does that is another question. :)
Chris Nahr Send private email
Friday, September 16, 2005
"Do not bother with a UML Case "tool". That, I think, is a huge waste of time."

I have the opposite experience. I have so many times fumbled with pen and papers, drawing and scratching class boxes and redrawing relationship lines for a half an hour, until I fired up some simple UML tool and created a diagram in minutes.

Tools work good with my thinking process, where I create and scrap classes and properties in seconds, and I can easily enter and delete them on screen. A paper just ends up filled with a lot of crossings, scratchings and illegible handwriting.

My favorite UML tools are the free OODesigner (it used to be available at but seems to have dissapeared) for quick sketches, and the commercial but inexpensive Sparx Enterprise Architect ( ) for more complex design and documentation.
Berislav Lopac Send private email
Friday, September 16, 2005
Exactly. If you use some sort of integrated software designing tool, such as Rational Rose (and I'm probably get flamed for suggesting this ;)), you can achieve so much more in far less time than with pen and paper... just think about use cases and flow charts, next to UML.

Anyway, I can only recommend learning more about UML... in many ways, it helped me design software a lot better.
Leon Mergen Send private email
Saturday, September 17, 2005
Hmmm, interesting. Enterprise Architect keeps coming up as a good peice of software. Thanks for that, I may give it a try.
hoser Send private email
Saturday, September 17, 2005
It looks like OODesigner has moved to SourceForge:
EKB Send private email
Saturday, September 17, 2005
I see a common confusion between modeling languages such as UML and Methodologies (with a big M :). I find UML most useful for communication, as a set of tools that ease the job of explaining or comprehending something. It's definitly worthwhile to spend some time in order to understend it, specially since it's so easy (pick up Fowler's UML Distilled book).
OTOH, I am not a fan of diagram and design intensive methodologies nor of sofisticated code generation CASE tools (the latest rendition is MDA).
AllMighty Send private email
Sunday, September 18, 2005
As an advocate of XDUF (exteme design up-front) I ask myself what do I do first in global enterprise system design? Is it the objects? Is it the events? No, system and program design are about logic. Logic is what users want computers to do for them. UML notation was formulated to separate out the mish-mash of objects, events, decisions, actions, datastores etc and logic represented in a single type of diagram: the Data Flow Diagram; a failed attempt to try to capture all aspects of a system in a single visual tool.

If you don't have a decision tree then your program has no logic and you can look up the information in a dead book.

I start with statecharts and any attempt to abolish UML (like the UN) will end up reintroducing the defects of DFDs. This has the advantage of reducing the objects to those needed by Decision-Led Design.
PS The most frequent obstacle I come across is the almost ubiquitous MS(tm) Word template using tables so no one can amend them without extreme hassle. Wiki syntax is very efficient and flexible.
PPS OSS documentation shows the defects of XP and 'gentleman hacking' wrt scalability.
Jim Stuttard Send private email
Tuesday, September 20, 2005
For those who believe in a “pipe dream” of auto-generated code from UML/MDA you can skip the rest of this comment so that I don’t waste your time.

The best approach I know of is to use <5% of UML features, good naming conventions, and a whiteboard.  For example in a class diagram there should only be boxes with class names, lines for associations, lines with open arrows for inheritance, and some cardinality on associations (“1” adds no value).  Occasionally, I find it acceptable to include how an association is made (list, hash, etc) and to place the name of the attribute near the end point of an association when it adds value.  I use “[]” or “attributeName[]” to show a list and “{key}”  or “attributeName{key}” for a hash.  I rarely use the long form and as I stated earlier this information is only occasionally used when it adds value.

For those who feel they need more elaborate class diagrams I say add doc strings to your code and use auto-generated documentation.  Using good doc string conventions will provide all the information available on a standard UML class diagram plus additional information not found on them.  Best of all it’s less of a hassle to maintain as when you change the code you modify doc strings as necessary.
John M. Camara Send private email
Monday, October 10, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz