Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 4 down vote favorite
1

I'm currently studying for an examination and one of the sample paper questions is to discuss the limitations of UML. Most of the material I'm finding on the net is relating to a specific UML implementation or language. I'm wondering from a generalists point of view what would you consider the limitations of UML to be?

share|improve this question
2  
What do you mean by "specific UML implementation or language"? UML is a language with a formal specification behind it. I think that there might be a good question here about the limitations of UML, but right now, this question is incredibly vague and open ended. – Thomas Owens♦ Apr 25 '12 at 13:51
My answer here brings up some of the limitations of UML. I voted to re-open because it is a good question. – Mike Brown Apr 25 '12 at 15:43
@MikeBrown Go for it, I re-opened the question. Not convinced it's a good question, but it only takes a great answer to convince me. – Yannis Rizos♦ May 5 '12 at 0:36

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer: please explain why you're recommending it as a solution. Answers that don't explain anything will be deleted. See Good Subjective, Bad Subjective for more information.

3 Answers

up vote 9 down vote

Difficulties I've come up against trying to use the UML:

  • as a communication tool, it's slower than ad hoc diagramming. Imagine you're stood at a whiteboard, telling another developer how a callback-based interaction works. You'd probably draw two boxes representing the caller and the callee, then talk your colleague through the process while drawing arrows every time you say "this sends message foo", and writing properties in the boxes when you say "so this returns its bar". In the UML, that needs two diagrams (a class diagram for the properties and a sequence diagram for the arrows).
  • as a model of a complicated system (the code), it's still fairly complicated. Many people have pointed out in comments that my complaint above is invalid because there's a type of diagram that can do what I want. This represents a different problem: it's hard enough to remember the details of the UML that using it as a simple model for communication purposes is difficult.
  • as a documentation tool, it can require too much upfront planning. I don't remember the specifics of my problem, but a few years ago I was documenting a package structure for a (then-unwritten) Mac application. The tool I was using to construct the UML enforced the constraints baked into the language. I think I was trying to express something like "this class will consume an interface exposed by something in this package, but I haven't decided what yet so I'll keep it at the package level. As I say, I don't remember if this was my exact task, but the constraints of the UML meant the tool wouldn't let me do it.
  • as a code generation (or code analysis) tool, its capabilities may not map exactly onto your target language. It's designed for class-based object-oriented programming languages and for compile-time method resolution. I have difficulties getting more than the simplest representation of Objective-C or Javascript out of it. Taking Objective-C as an example I've got more experience of dealing with the UML in, you can't easily express categories. The difference between a protocol (like a Java interface) and an abstract class needs to be expressed via custom sterotypes. To make an effective round-trip ObjC—UML tool means encapsulating all of these differences in a metadata schema on top of the existing language. As I say this is all dependent on the programming language you're trying to represent: C++ programmers don't have any of these problems.

Finally a minor bugbear of mine which isn't much of a limitation but does cause cognitive problems when using the UML to represent ObjC: in ObjC + and - mean class and instance methods, while in the UML they mean public and private.

share|improve this answer
It's funny that the example you give of an ad-hoc diagram describes exactly one of the existing UML diagrams : the collaboration diagram. – barjak May 5 '12 at 22:29
1  
@barjak: indeed (well, kindof, you still need to add a structure or class diagram to a collaboration diagram to show properties and interaction). The fact that I had to refer to my copy of Larman to verify what you said points to another problem: the UML is too large to retain in your head. This is a drawback for a communication tool. – Graham Lee May 6 '12 at 8:08
@GrahamLee Even though I agree with your assertions I think most of the drawbacks you listed are basically issues of the UML tools, not the UML language itself. UML tools have been for many many years trying to map class diagrams to source code and that has never worked properly. UML should be used for modeling, not for representing the source code so trying to do that will fail every time (as we've seen over and over). – Alex May 6 '12 at 13:48
@GrahamLee : no, you do not need 2 diagrams to represent the properties. A collaboration diagram is composed of boxes (that represent classes or instances) and arrows (that represent the interactions). What you may have missed is that these boxes are the same in a class diagram, in a collaboration diagram, or in a sequence diagram. You can write properties in the boxes of your collaboration diagram exactly the same way you write them in the boxes of a class diagram. – barjak May 7 '12 at 22:17
1  
I'm not sure I agree with all your answers but I think you nailed the correct answer that the OP can use on the exam. UML only supports Object-Oriented designs. – Dunk May 8 '12 at 17:30
up vote 2 down vote

Limitation 1: be quickly out-of-sync with the source

Limitation 1bis: need constant effort to keep it in sync

Limitation 2: it answers "how" it is, but not "why"

Limitation 3: lack of expressiveness:

  • it's hard to point out what's important, and what's not
  • pure text allows you more flexibility when explaining things
  • it only shows one isolated aspect at once (either the class diagrams, the uses cases, the flow, etc) but usually, what you need for a good understanding is a mix of those

Limitation 4: you can hardly express unusual concepts (reflection, first class functions, closures, pointers of pointers, annotations, dynamics...)

share|improve this answer
1  
1 and 1b go for any specification. 2: Specification answers "what" not "how". 3: You can put plain text comments on pretty much any UML element. 4: I think you want UML to be some super implementation language. It is not. – scarfridge Apr 25 '12 at 14:01
@scarfridge: 1) agreed, but somehow people usually assume that such diagrams should be in sync, unlike docs where people assume to contain outdated parts. 2) requirements == what, specifications == how. A class diagram definitely tells you "how" it is structured. 3) If a diagram is full of plain text, doesn't it show some issue? 4) I don't want that and it could never be. The thing is, that as soon as you go out of your "perfect little small object oriented world" and work with other concepts/paradigms, it quickly becomes unusable or problematic at least – arnaud Apr 25 '12 at 14:10
3  
Limitation 1: Forward engineering tools allow source to be generated from UML and reverse engineering tools allow for keeping documents in sync with the source files, and any UML-heavy environment should probably be using tools that support this. Limitation 3: Text is more ambiguous than a well-defined standard due to ambiguities that exist in most written/spoken languages. The importance of components is generally showed by the use of multiple models that focus on particular aspects of the system. – Thomas Owens♦ Apr 25 '12 at 14:11
1  
1) regenerating new diagrams from code isn't that hard, but migrating the new diagrams into all downstream users can be difficult (especially when you don't know who's consumed your earlier diagrams, embedded them in Word files, and emailed them to other teams). 2) It's not really supposed to answer "why", anymore than the blueprints for a house would answer "why" the architect wanted it that way. – FrustratedWithFormsDesigner Apr 25 '12 at 14:13
2  
1) No such tool could handle a real-life complex codebase ...and even if it could, you would get a diagram of thousands of classes where you cannot see anything. 100% useless. 3) Agreed. That's why I think that those using UML should at least use it in combination with other text explanations – arnaud Apr 25 '12 at 14:13
show 2 more comments
up vote 1 down vote

Just an observation: People don't share their UML Models as freely as they share their code.

Even if they did, there would be compatibility issues of the software tools used (there is no exchange format, XMI is insufficient)

Regarding diagram types. In computer books that I happen to like, the authors seem to prefer only a simplified diagram type ("Head First Design Patterns" use only simplified class diagrams; "Portlets in action" almost exclusively uses sequence diagrams). Other diagram types seem to be much less frequently used in the computer literature. Let alone other UML constructs such as the "object constraint language".

share|improve this answer
+1: (Simplified) Class Diagram and Sequence Diagrams are the ones to learn, as they are usuable for whiteboard discussions. Use Case Diagrams have some value as well: they make nice front covers that clients seem to love. – Sjoerd May 8 '12 at 21:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.