Unified Modeling Language

Use UML when the initial design is put together in collaboration with your team members. Do not fill the models with details, if it is not necessary for everyone's understanding of the design. Prove the correctness of the design with code and throw the initial models away.

Use UML when you need to document important relationships found in the code. This is typically done in the design documentation to illustrate and clarify specific parts of the system.

UML is very good for the visualization of code structure and relationships. These properties are often difficult to see when looking at a set of source code files. Use UML to distill the information available in the code and present it in a form that makes the program construction easier to understand. This should be done with the help of automation and tools as much as possible.

The problem with UML is that it is used as a programming language, when it is not a useful programming language at all. UML is a language for visualization of program structure.

UML is normally used for the design of a program. Class diagrams are drawn, methods are specified, sequence diagrams produced, state charts constructed. The mental activity performed here is programming. Why is so much effort spent on programming, when the result can neither be executed, nor be verified for correctness? An object oriented programming language is much more suitable to design the system in, as the result is executable and can be verified to be correct.

The failure of UML to be useful as an initial design language is something I have observed in a number of projects I have participated in. The process ususally proclaims that the system should be designed in UML first, then be implemented. Despite the fact that the project is populated with dedicated people that believe in the process, they still don't manage to create an initial UML model. Just because someone says UML is useful for the design of a system, doesn't make it so. The UML diagrams are always drawn after the code is finished, and this is exactly what UML is good for, to visualize a working system.

Taken to the extreme, the only thing you verify by designing your system in UML is wether it is possible to describe it with UML or not. UML can not tell you if it is a good or bad design, neither can it tell you if the system works as specified in the requirements specification.

The design activity as such is important, if you by design mean the construction of a well structured program. Just make sure you choose the correct language for the task and make sure the result of the activity is useful.

Executable UML exists, and I have nothing against it in principle, as long as you are aware of that it is nothing more than a new programming language, equal in power to any other object oriented language available. It is not a killer abstraction that is useful for every programming problem available. Would you use UML as the scripting language in Rational Rose? Why doesn't even Rational believe in UML as the ultimate language for all purposes?

Make sure that you don't depend on one single vendor as the tool supplier for executable UML. Even worse, you may lock your code into a proprietary format that is useless outside the tool. The options you are given to access the program is either point and click or a weak scripting language. Why limit your options for automatic code manipulation so much?

Another caveat with graphical programming languages are that the amount of information that can be displayed on screen at the same time is low. The amount of information may not be sufficient to make the programmer efficient, if he must swap between pages all the time to find important information.