On his bliki, Martin Fowler eloquently describes the three different modes in which UML can be used: UML as sketch, UML as blueprint and UML as programming language. Let’s revisit the different modes from the perspective of tools for the job.
UML as sketch
Description: In this mode, UML is essentially a tool for conceiving and communicating ideas between team members. As such, there is no need for completeness or validity of the object models, and actually any information not essential for communicating the idea at hand is intentionally omitted for conciseness and clarity. UML as sketch is increasingly popular, even at shops where model-driven development is considered an abomination.
Tools for the job: developers don’t need special tools for using UML as a sketching tool, paper and pen or a whiteboard are great. The only flaws are when you would like to archive a drawing or send it to others by email. In that case, Visio (or any other generic diagram editor) is a common choice. Another less known option is Whiteboard Photo, that allows you to take a snapshot of your hand drawings (on a whiteboard or on paper) and have them automatically translated into great looking clean 2-D charts.
UML as blueprint
Description: in this mode, the focus is on having UML models used as an input to the implementation phase, and thus need to be valid and complete from the point of view of structure. Behavioral aspects are described in textual form (such as in use case descriptions) or by means of diagrams depicting scenarios (such as sequence or collaboration diagrams) and are inherently informally and incompletely described. The models can be submitted as input to code generation but the generated code has to be enhanced by hand to cover the behavioral aspects.
Tools for the job: generic tools won’t cut it here – you will need diagram editing tools that support all (or most) of UML diagrams, and (if you are taking the code generation route) persist your models in a format that your code generation tools can understand. Most UML tools out there support (or intend to support) this.
UML as programming language
Description: In this mode, UML models must be complete both structurally and behaviorally as they must be simulatable and serve as input to code generation (by the way, Fowler really misses the point when he argues that a graphical language such as UML is not appropriate for fine grained behavior specification – who said UML is graphical anyway?).
Tools for the job: there are only a few tools currently in the market that support this mode, they tend to target embedded software development, and I bet you will not find how much they cost on their websites unless you call them.
Corcova Libra will support this, and when made available will visibly sport a reasonably fair price on our web site. Also, Libra will aim at mainstream business application developers, instead of focusing on specific vertical markets.
UML as sketch is cool and useful, but from the point of view of software engineering (our focus here) is meaningless.
UML as blueprint is increasingly practiced in shops where (partial) code generation has been adopted. It has benefits over writing the entire code by hand, but it still requires all the interesting code to be written manually, and there are a lot of issues with that.
Finally, UML as programming language (in other words, full blown model-driven development) is the most interesting of the three modes, even if there is a lot of skepticism and misinformation towards it. I will talk about that in an upcoming post.