Complexity in UML Modeling

I just saw a question on linked-in and thought I would answer it with my 2 cents:

The Question:
Top 10 concepts/ things designer/ modeler finds it difficult to model using UML 1.x/ 2.x standards. This doesn't includes complexity/ easiness of using specific tools. Eg. modeler may find it difficult to model concurrency/ scheduling/ priority/ activites in a loop etc.
My Answer:

Well, I don't have 10, but I can give you the biggest drawback (as I will call it) regarding UML modeling in general. Contrary to many-an-architect's efforts, software has always been fluid. Changing requirements and design have been with us since the dawn of the first computer program. We have evolved a great deal with the processes that we use to create software - from Waterfall to agile - we have always had to find new and better ways to handle changes.

UML is a wonderful tool in conveying the intent, design, and operation of the software we are architecting. The drawback with it is the same as the software we are writing - how to handle changes. A UML diagram is good only for the moment that it is drawn. Once the design or code has been refactored, the diagram is useless.

Do we stop using UML?? By no means - I think we need to use it for what it is best at - conveying architecture and design while the software is being built. OK...what do I mean by that? Here are some concrete examples:

Use cases - with the intent of documenting the requirements - we should expect it to be fluid over time. Can (and should) change - make sure that your tool can baseline your requirements and gives you the ability to document them over time.

Class, object, state diagrams - useful for showing the current relationships of the objects being used - likewise can be used during a code/design session to help convey ideas. Shouldn't put one of these into a design document because it WILL change upon the refactoring of the system. Best used as a tool during the design and code phase for collaboration between developers or helping a developer/architect to "visualize" the object relationships. If the development IDE can generate these - then all the better - don't spend your time trying to manually keep up with these.

Sequence, collaboration, activity - shows the actions going on between the objects over time. Once again - only accurate for the moment it is printed. I have used many of these on a white board explaining the operation of a process or system, and have published a few of them too. Once again - if your IDE can generate one, then great. Don't spend your time manually keeping up with them - you'll be chasing your tail.

Component and deployment diagrams - don't change as quickly and can convey the overall architecture. I would say these are easier to keep up with manually because of the nature of the information they are conveying.

Overall - my favorite use of UML diagrams are (as mentioned above):

1. On a white board to convey an idea and/or architecture. Good for getting the ideas across, using them for the design or code and then throwing them away.
2. If you have an IDE or tool that can auto generate UML diagrams for you, then I've used them to auto-generate models so I could understand new code as I am coming up to speed with an existing application.

Anyway...that is my 2-3 cents worth. I'd be interested in hearing what others have to say.