Take the 2-minute tour ×

In today's lecture about Modelling techniques with respect to MDD using UML the lecturer stated that it's absolutely necessary to give a (possibly) textual description about the semantics of each diagram you produce.

In my opinion it's not necessary to describe semantics of diagram elements which are already standardized by UML. I can see that it's completely appropriate if you extend the standard UML by stereotypes/tagged values for any reason.

In contrast, I think that standardization has in the ordinary case the intention to let people reason and talk about diagrams without the need to explain semantics every time. The only precondition is of course that they all rely on the same UML specification.

Another point regarding MDD is that using different semantics from time to time for the same diagram kind makes code generation and automatic model transformation difficult in the end.

  1. Am I right with this notion?
  2. Are there some inherent interpretation ambiguities in UML to make it more general usable?
share|improve this question

3 Answers 3

up vote 2 down vote accepted


Yes, there would be no need to describe the semantics of diagram elements when that semantics would be properly defined somewhere in the UML standard. The problem is that, especially with MDD, the full semantics depends on the code generation for those elements, and since there is no widely accepted standard for the UML-to-code-mapping, the UML standard does simply not define the whole semantics for it's elements. In fact, even the "UML semantics" paragraphs in the standard deals primarily with UML syntax and gives only a very informal notion about the semantics.

Of course, when doing MDD, and you have your code generators in place, you can create a meta-description just once, telling which semantics applies to you/your team/your project/your company, instead of deploying the same description with each diagram again-and-again.

Here is a scientific paper dealing with the problem that UML semantics is mostly informal. A google search for "uml semantic rules" will bring you more papers discussing that topic in-depth.

share|improve this answer

You're right that the stereotypes should need no explicit explanation (other than where they are defined, if you are using custom stereotypes for some reason); that's the point of using a stereotype. That usually does not mean you can avoid describing things though, as it is rare that software is just a coordination of stereotypes. Some description as well, on the parts that do something interesting (like issuing an ID or performing a calculation) can save a whole lot of complexity elsewhere. Note that text in a human-readable language is not the only way to do that describing; depending on what you are doing, mathematical equations, semantic annotations from an ontology, or even links to appropriate academic papers may be more suited. It all depends.

It's possible to write virtually an entire program using UML and appropriate code generation. You probably don't want to do that for anything real though, as the difficulty of managing the complexity of the size of diagrams required to describe a program of even medium size will make the use of graphical design models like UML rather impractical. UML is good for the architecture, the real purpose of which is to be shown to programmers so they understand the bigger picture, but isn't as well suited to detailed work. (I shudder to think of the complexity of my programs at the UML level if I expand everything out…)

share|improve this answer
when we're talking about MDD, the purpose of diagrams is to hold as much information as needed to generate executable code from them, isn't it? –  McMannus May 24 '13 at 9:03
@McMannus You could, but that doesn't mean that it's going to scale up to a non-trivial program without becoming an impossible mess. Which is the point: keeping the program from being an impossible mess is the most important aspect of sustainable scalable programming. –  Donal Fellows May 24 '13 at 13:54

I don't think that the point of the lecturer is that the comments should teach over and over what UML represents. Instead, I interpret your question as a special case of: Do I need to comment my code? If yes, how?.

The usual controversy is around whether your production (being code or UML) is self documenting thus needing no comments, or whether comments actually add some value to your production, or whether comments stay consistent with your production.

share|improve this answer

Your Answer


