Fog Creek Software
Discussion Board

Limitations of UML

So Rational pitches UML as the solution to all your spec problems. But specs were written well before UML was invented.

What do you think are the limitations of UML? Do you feel that it has solved most of your problems?

Kelly Scott
Thursday, October 17, 2002

UML is just a notation, not a spec.
It only helps because it gives us an unambiguous graphical vocabulary.

However, IME, it just too complicated for use in a customer spec. It is useful only between developer and alike

(sorry for my bad english)

Robert Chevallier
Thursday, October 17, 2002

I think that use cases can be good when doing joint development and you need to flush out exactly what the user does/needs.

Although specs have been layed out before without using UML I still say it is essential to developers using OOP these days. Go pick up a patterns book and you see UML. Look in the specs for an app and usually you'll see UML. It's great for describing and API, sequences, and systems.

Ian Stallings
Thursday, October 17, 2002

Personally, I really like UML although it seems to have some limitations when it comes to modelling data relationships.

For database modelling EAR seems to be the way to go. We use it extensively in our CompSci course.

Anyone know if UML can be used for this?

Thursday, October 17, 2002

Specs exist in the problem space, while UML relates to the solution space.
Moreover, UML represents just a snapshot of one solution.

The mapping between these two spaces is a very important phase of design, and it's not mechanical.

The bad thing about UML (when used as part of methodology, not just notation)
is that, in practice, many architects jump ahead and start with UML class diagrams
even before the proper analysis in problem space.

The good thing is that UML is just a notation for diagramming, which became more or less standard.
So, when you need to explain your existing system to someone else, you can use UML and don't explain
what are those funny boxes and arrows. I remember the time when first Booch book came out and
we started to use the old "cloud" diagrams. It was good for internal design, but not appropriate
for external presentations or articles - we had hard time explaining all the details of the notation.
Now everybody seems to have at least general understanding of UML diagrams, so it's really a univeral language.

But, again, UML is not a substitute for specs, design documents or source code.

Igor K.
Thursday, October 17, 2002

The graphical language might be unambiguous (sp?), but the semantics are about as ambiguous (or even more ambiguous) as a text spec. And it's semantics that matter.

Ori Berger
Thursday, October 17, 2002

UML is just a notation to comunicate by standard means.

From experience I can say that crappy projects used UML to communicate crappy ideas, and good projects used UML to communicate good ideas. I have seen many good projects that never made use of UML. And I have seen UML so hideous that makes you wonder what was the point in the first place.

I find UML to be useful if you work in a distributed dev team, or if you do work with a customer's dev team then UML is useful to specify system contracts.

Frankly I think that you would be better off printing stickers and sticking them to the dev team monitors, something that reads "think! then compute"... it can save you heaps of cash on CASE tool licenses. ;)

Oh! one more thing... people often forgets about it, but pen & paper are a perfectly valid transport for UML. :)

Beka Pantone
Friday, October 18, 2002

This is a periodic kind of question.

UML is a reasonable documentor and using activity diagrams, swimlanes and such its not a bad way to work out the wrinkles in a design.  It isn't a panacea though.

For data modelling I use ORM (Object Role Modelling), not only because it lets me design databases whilst modelling real world information but also because I can use it with the client and they can understand it.

ORM is conceptual, its about facts.  You then have the tool convert that conceptual model into a logical model (like an ER diagram) and from there you can generate your physical database.

Simon Lucy
Friday, October 18, 2002

Having given quite several UML courses, being busy writing specs and as a developer, I can say that UML doesn't makes it for the customer (Indeed ORM is better for the application domain study, doesn't has the problems with attributes and can be made with the customer).

UML is not very strong for GUI stuff and the behavior descriptions lead to spaghetti diagrams.

So, the current state of affairs is

- "custom" UML on the whiteboard,  a digital cam for taking shots for design stuff,
- MS word for the specs (or DocBook with developers) and
- tools like WBS Chart Pro ( and PERT Expert for chaining tasks.

A 500+ spec with only UML wouldn't say much to anyone. Plain text rules as UML diagrams are only a map to find out your way in the territory.

Former UML evangelist, now back to real work
Friday, October 18, 2002

BTW, Microsoft Visio Modeler is a free ORM tool that rocks !

Former UML evangelist, now back to real work
Friday, October 18, 2002

Are you sure Visio is FREE???? Where is this? How come it cost us many hundreds of $$$ for our 5 licences?

Sunday, October 20, 2002

VISIO MODELER (ORM), not VISIO the drawing tool.

Former UML evangelist, now back to real work
Sunday, October 20, 2002

Oh, I see. It is a seperate tool.

Sunday, October 20, 2002

Visio Modeler was the last iteration of the Infomodeler product. Microsoft released it unsupported but free some time ago. I do not know wether it is still downloadable. I has been replaced by the Visio ORM stuff in VS.NET EA.

Just me (Sir to you)
Wednesday, October 30, 2002

I just saw you can still download it at

Just me (Sir to you)
Thursday, October 31, 2002

*  Recent Topics

*  Fog Creek Home