Fog Creek Software
Discussion Board

Views on UML?

I'm interested to know if anyone here is using UML, and if so what they think of it. It seems to have spread like a particularly invasive weed across the computing landscape, but from my admittedly limited exposure to it seems to be both horrendously complicated and yet horrendously imprecise - "industrial-strength hand-waving" as one computer scientist put it. If people here do find it valuable, I'd be interested to hear  which parts of it they use, and what they find most useful about it.

Andrew Simmons
Wednesday, July 10, 2002

I'm using it right now. I tend to use it to communicate with myself, rather than with other developers, stakeholders, etc.

I'll draw class diagrams to help me visualise the relationships between objects I have either already developed (and consider potential refactorings) or between objects I intend to develop (this provides a nice way of thinking at various levels of abstraction).

I also use activity diagrams to document workflows that don't seem obvious. Here I'll probably consult with a project sponsor/manager and ask "is this what you mean?" when I find written requirements confusing/lacking.

Tools-wise: I don't like Visio at all, but am quite happily evaluating a product called Enterprise Architect -

Walter Rumsby
Wednesday, July 10, 2002

I find it is becoming more and more a compromise between all the sources it is borrowing from, apparently more to spare the feelings of those sources than to actually contribute.

It should be concise and specialised for its purpose, in order to be manageable. But it seams to include everything AND the kitchen sink, making it difficult to determine what to use when.

It looks like the designers have gone overboard and include everything that CAN be included, just because they can. For instance inheritance seems to be applied to everything though it does not always improve things.

But, as long as you want to draw a quick diagram (sequence, class or whatever), its as useful as anything else.
And of course the goal, to set an industry standard for software diagramming, is an admirable and much needed one.

Erik van Linstee
Wednesday, July 10, 2002

It promises more than it actually delivers in practice, but as a semi-formalised (UML is a real hotch potch), diagrammatic and organisational method its ok.

Its never solved a problem for me though, unlike ORM and database design.  I find it descriptive (and so in the end not much more useful than flowcharts), rather then generative.  Its faster for me to write the details of classes and code than it is to twist my carpals filling in endless tabbed dialog boxes.

I've considered it for creating IDL files and it might well be more efficient at that, though I'd rather generate and maintain IDLs from the actual class code than try and maintain it in both directions from Rational Rose.

These could be limitations of myself rather than the tool of course, I always have this sneaking suspicion that there's some magic bullet I haven't discovered in using RR.

Simon Lucy
Wednesday, July 10, 2002

I find UML class and sequence diagrams to be useful to quickly sketch on a bit of paper while trying to think through a design for a module.

I think they are quite a good tool for helping you come up with the design and think it through, but are not good at representing the whole of the design so I treat them as a aid to come up with my design and throw the diagrams away once the design is done.

I really find that using UML properly or documenting a whole design using it to be a spectacular waste of effort.

Wednesday, July 10, 2002

I really appreciate component diagrams and sequence charts.  Why?  Same reasons I appreciated a flow chart back when everything was procedural.  Tools?  Sometimes I use a legal pad & a #2 pencil.

those who know me have no need of my name
Wednesday, July 10, 2002

URL's primary purpose is the institutionalization of architectural practices within the development organization.

For the simple minded! Translated :- universal noemenclature, by which technical information is passed around the development organization.

Why is it important ... so that everyone is speaking the same language!!! [Yes it's an interesting concept, try it sometime].

#1 reason why project fail? 
it's not a trick question

These could be limitations of myself rather than the tool of course, I always have this sneaking suspicion that there's some magic bullet I haven't discovered in using RR.

Simon Lucy


Lazy American
Wednesday, July 10, 2002

My impression of other people's impressions of UML is that it's mainly a buzzword to adhere to.  That's the hoi polloi impression.

For those who devote a few more brain cells to it, UML is a medium for universal exchange of information.  You can put a lot of things into HTML format, but not everything.  But you can put -everything- into UML.

For me, the trouble with UML is that it has no semantics, and yet claims to.

"You can define your own tags", they say.  Well, fine.  But now you have the Babel problem, where everyone's defining their own tags, and no one agrees.  That problem is detected quickly enough, of course, and people in a company will start cooperating until there's a company standard UML spec for what they do.  A little while later, groups of 2-10 companies (typically with one or two 800-pound gorillas dictating to the rest) will make a standard they agree on.

Already there will be problems in a standard between 2-10 companies.  Now try merging all of the 2-10-company groups in an industry, and you'll have holy wars up and down the business community.  There's going to be the same shenanigans happening there that there is with people defining extensions to HTML so that the browser they make will look slicker if webpages are designed specifically for that browser.  "Our UML spec for airplane parts features tags for variable-spread spectro-tactile flip-de-floops!"  "Oh yeah?  Does it allow for parts that follow the Gerke-Havell schpilko-kazoom paradigm?"  Ad nauseam.

Furthermore, there's no way to tell if the UML document you get is valid without specially written software, and that software would be obsolete just as soon as someone defines a new tag.  The best you can do is tell if every tag is properly closed, and that the tags are nested properly.  In other words, you can get syntactic validation, and that's it.  Semantic - no way.

Paul Brinkley
Wednesday, July 10, 2002


It sounds like you are referring to XML.

those who know me have no need of my name
Wednesday, July 10, 2002

Personally I still prefer the old standby - the cocktail napkin from the local bar.  Solved more problems with that than any of the so called "productivity" or "documentation" tools.

Joe AA.
Wednesday, July 10, 2002

1. Paul I think you mean XML. I could be wrong but I couldn't find anything related.

2. I'm curious how anyone here can describe a design pattern wihtout using a class diagram. I'd like to see an example if someone has one, lol.

3. I like to use UML tools that round trip, meaning I can make a change in my class model and it will update my code for me and when I update my code it can recognize that and update my models. Class and sequence diagrams are the one's I use most and they help in weeding out design problems up front and also to convey meaning to others using my code. They are merely documents that describe your design.

Ian Stallings
Wednesday, July 10, 2002

We used UML/Booch Notation for at least the 5 years that I've been here in my shop.  We often found it failed to live up to the hype for a variety of reasons.  While we did use it, we most often used the Use Case, Class, Sequence, and Activity diagrams.  Some of the tools that were employed included Visio, Rose, Visual Modeler, ArgoUML, and, of course, variations of pencil and paper.

We recently began using a slimmed down notation called "Business Object Notation (BON)" because it supports richer semantics.  While the jury is still out, my personal opinion is that it's much easier to use and understand and provides for a much richer model for a smaller investment of time.  Occasionally we supplement this with instances of David Harel's STATEMATE statecharts.  I prefer ORM for database work, although I think I'm the only one around here that uses it regularly.

Reformed UML user
Wednesday, July 10, 2002

The problem we've found is with "devoting more than a few brain cells to it".  The UML utopia is that it will serve as the communication format for all parties; especially non-IT folks.

Often the business sponsors or owners of the application are not willing to learn or use UML. This has to be at least considered as a failure of UML. It's by programmers for programmers despite claims to the contrary.

The key to UML succes is adoption by non-IT folks.  And from what I've seen, they would prefer to continue writing specs in MS Word and leave the gory details (as they perceive UML) to the developers.

Wednesday, July 10, 2002

The key is to use as much as you need.
We use only Class Diagrams and Sequence Diagrams, and very occasionally object diagrams. But we use it where, and only where, it is the easiest way to communicate the inforamtion. Of course its important that everyone on the team can read the diagrams,
but after a while it becomes second nature.

And remember its a language. It's not going to solve your problems for you.

David Clayworth
Wednesday, July 10, 2002

" I'm curious how anyone here can describe a design pattern wihtout using a class diagram. I'd like to see an example if someone has one, lol. "

I have to admit I'm sceptical about design patterns too, especially "Singleton" - my feeling is that if you only need a single instance of a class, nobody is holding a gun to your head forcing you to create more than one, so why jump through hoops to make sure it doesn't happen? Or do we need a "Doppelganger" design pattern for when you need exactly two instances, and so on ad infinitum?

But I digress. One thing that struck me about the GoF book is that two adjacent patterns (from memory it was "State" and "Strategy") were described by virtually identical UML class diagrams. Either this means that the patterns are not really distinct, or that UML class diagrams are unable to specify the meaning of a pattern precisely.

Andrew Simmons
Wednesday, July 10, 2002


If there shall be only one, why allow the possibility that more could be created?

those who know me have no need of my name
Wednesday, July 10, 2002

Pop quiz: From which book on Joel's list are the following quotes?

"The flow chart is a most thoroughly oversold piece of program documentation."

"The detailed blow-by-blow flow chart is an obsolete nuisance, suitable only for initiating beginners into algorithmic thinking."

"In fact, flow charting is more preached than practiced. I have never seen an experienced programmer who routinely made detailed flow charts before beginning to write programs."

That is more or less my opinion about UML too. But don't get me wrong. I draw/scribble all the time, but using a notepad and pencil or whiteboards instead of computerized tools. All computerized design tools are IMHO  a total waste of time. The only exception being when designing complex database structures.

Answer: The Mythical Man-Month (page 167)

Jan Derk
Wednesday, July 10, 2002

Arguments to the contrary seem to be along the lines of "Its not a magic bullet, therefore it's no good".  It's just a tool people, not a religion.  It's just another way to organize thoughts.  Like I said before, I like using a legal pad & a #2 pencil to draw my UML diagrams.  As for flow charts, I still use them on occasion to communicate about business rules with non-programmers.  The COO doesn't really give a crap who Fred Brooks is or what he thinks about flowcharts.  He just likes the fact that I can put the software design into nice, pretty pictures.

those who know me have no need of my flowchart
Wednesday, July 10, 2002

I'll add my "me too" here.

Every software project needs good communication. One of the things that needs to be communicated efficiently between programmers is design. On a micro level, that can be done with source code, but the further back you get from the source, the harder it is to explain what's going on.

Most people find it easier to understand things like sequences or object relationships if you draw a picture - you can hold a lot more of a picture in your head at once, and be able to zoom in on the details mentally as you need to.

UML is _one_ of the available tools for communicating design, and it's one of the better ones because a) There are a lot of available tools that help you draw it, and b) You're less likely to have to explain your notation than you would if you made it up yourself.

Postscript: I'm amused when people use the Singleton as the typical Design Pattern, because it's generally proof they never got past the first chapter of the GoF book. You can go your whole life without coding a Singleton, but it's almost impossible to do without Adapters, States/Strategies, Commands, Proxies and Factories even if you've not called them that. (That's the whole point of Design Patterns - giving a name and a recogniseable form to things people do all the time anyway).

Charles Miller
Thursday, July 11, 2002

"Those who know me" wrote:
<<Arguments to the contrary seem to be along the lines of "Its not a magic bullet, therefore it's no good".>>

I do agree. Far too many IT subjects are being discussed on being either good or bad. The good (not bad) developer is able to pick the parts which will help her and forgets about the rest.

<<The COO doesn't really give a crap who Fred Brooks is or what he thinks about flowcharts.>>

That's wise too. Nobody should follow any guru, be it Brooks, DeMarco or Joel, without projecting it on their own situation. A quote is never a good argument by itself. One should always try to find the arguments behind a conclusion and check if they are valid for you to.

So I'll refine my opinion a bit:
If you're working on UML, flow charts, whatever and you get the feeling that it does not make sense, then it probably doesn't. Nice pretty pencil or whiteboard drawings are generally good (again not bad) to communicate or help yourself visualize a design.

Jan Derk
Thursday, July 11, 2002

>Why is it important ... so that everyone is speaking the same language!!! [Yes it's an interesting concept, try it sometime].

Unfortunately it isn't a language but a collection of notational methodologies.  At some levels it also constrains design into the C++ (Booch, etc, etc) model of OO.  That isn't always appropriate.

Use Cases are useful, but they are a simple minded starting point.  The ideal of UML seems to be similar to flowcharting, you know what you need to model before you start.  This is never really true.

As a means of sharing already decided structures and systems its ok, but even then it can confuse as much as it clarifies.

If ORM could squeeze out class definitions I'd be a very happy person.

Simon Lucy
Thursday, July 11, 2002

I have no idea whether Paul meant XML or not, but you are not restricted to describing software systems with UML. As he says, you can use it, or parts of it, for pretty much anything. As long as everyone agrees that taht is the notation you are going to use it really doesn't matter. I had great fun designing a lift (elevator for the americans) with it, once :-) You just need lots and lots of Post-It notes...

Post-It salesman
Thursday, July 11, 2002

Simon - you're right about Use Cases IMO, they're a very simple minded starting point. They naturally lead into sequence diagrams though and I find _them_ incredibly useful

Thursday, July 11, 2002

Well they sometimes lead into sequence diagrams, or parts of them do.  And they can be useful, swimlanes too but in terms of generating classes and maintaining them I've found the tools (as opposed to the notation), less than useful.

Its not that I'm prejudiced about using a modeller to maintain designs and code, I've been an enthusiastic user of ORM since ummm I guess around ten years now.

Simon Lucy
Thursday, July 11, 2002

On UML and patterns

Yes structurally many design patterns look the same - you differentiate them by intent.

Look at for alternate schematics.

Thursday, July 11, 2002

[I have to admit I'm sceptical about design patterns too]

Give me examples of your code and I'll bet money I can find a design pattern. Patterns are just a way to communicate between developers.

IE - "I needed to have the appointment object make changes on multiple instances of the day object in our calendar so I used the visitor pattern"

Immediately the developer he's conveying this message to can understand what they are trying to accomplish or at least have a place to start. I think it's worth knowing them as a developer. It's just another tool in the toolbox.

Ian Stallings
Thursday, July 11, 2002

The USFL was not as good as the NFL.

Saturday, July 13, 2002

A URL is a Uniform Resource Locator, a standard way developed to specify the location of a resource available electronically. URLs are defined by RFC 1738, to which you can look for more definitive, technical information.

Saturday, July 13, 2002

*  Recent Topics

*  Fog Creek Home