Take the 2-minute tour ×
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.

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

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

closed as too broad by gnat, MichaelT, Kilian Foth, GlenH7, Bart van Ingen Schenau Feb 8 at 15:52

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the 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

5 Answers 5

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. –  user4051 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

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

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

The problem I have using UML is it's complexity. Even with the 800 page standard (which is clearly a sign of a severe problem), I find wildly different interpretations of use from one developer to another. So much so, that it can take significant time to comprehend precisely what resultant code or process is modelling. Often a much simpler diagram with comments is better as others have indicated.

Also there are some fundamental things I dislike like association in class diagram. It's often not clear what the association represents in code because people will omit them from the list of attributes. This is because the link is supposed to imply this. However,I always put list the attributes specified by the association to avoid potential confusion.

The other problem is that often the very people one might share UML with, customers and managers are not going to understand or appreciate its more esoteric features anyway. Particularly working in the mobile application development industry that was very much the case.

However, like others have said in simple form I really find class diagrams useful especially CASE tools that can generate basic structure from a class diagram. This has saved me many hours and some potential back peddling.

share|improve this answer

My two limitations would be:-

  1. Its not abstract enough -- Class diagrams are basically a list of fields and methods in a class and its probably more effort to code the class diagram than to code the class. It does highlight the relationships between classes -- but with not much more detail than reading the "import" statements from the code.

  2. They me in great detail stuff I am not interested in but miss out interesting stuff like purpose of a relationship, or, vital pieces of logic. Another poster pointed this out as the "everything is equal" problem -- you cannot highlight the important stuff.

  3. (I know I said two!) It makes developers think of "Use Cases" as diagrams of stick figures with a few labels attached, whereas real Use Cases --> free format text descriptions of what the system is supposed to do are the most useful single tool in requirements gathering.

share|improve this answer
    
1 ... 2 ... 3?? Wait a second!!?? :) –  Matt Fenwick Feb 5 at 10:52

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