Evaluating UML Modeling Tools

by Gary K. Evans

As an object modeler I am continually asked what Unified Modeling Language (UML) modeling tool, or tools, I use and recommend. I always respond that most of my modeling on projects is done on whiteboards, and for my personal work I use notecards, paper, or whatever is available at the moment - including modeling tools. I have even used a Magna Doodle® - a productive use that Ohio Art never included in their advertisements.

We do not suffer from a dearth of offerings in UML modeling tools. On the contrary we are confronted with an overwhelming number of choices. While I have my favorite offerings in this area I will not mention product names in this article. Here I just want to offer some guidelines for picking a modeling tool that will serve your project - and your budget - well.

Cost

This is always the #1 concern, and is certainly in the top 3 important issues. Modeling tools that range from capable to excellent can be found for under $300 per seat. You can also spend orders of magnitude more than that. Purchase cost is always relative to what not having the tool will cost. I strongly recommend you consider cost only after you have narrowed your choices to one or two tools that support your modeling goals. And be sure to include the Maintenance fees, which normally amount to 20% of the base product cost. The Maintenance fees are a money saver over the long-haul, assuming you want to stay with that tool and vendor for more than one release of their product.

Modeling Goals

By the way, why are you looking for a UML tool? This is serious question. If you think it will speed up your projects, you will probably be disappointed. If you think it will solve design problems, you may again be disappointed. The tool will not make your development group magically think better. But having a common tool and notation for sharing ideas - now that will bring improvement. The tool will definitely make diagrams pretty and orderly. But that is not the goal. If you want the tool to support new ways of specifying your software, and providing a way for separate teams to share information - that is reasonable.

Number of Licenses Needed

This is obviously a variable affecting cost. Recommendation: do not buy a license for every person on the project. I have had several clients who purchased expensive modeling tools for every person on the project, only to find most copies unused. Modeling is a skill, just as programming and testing are skills. Not everyone on your project will be doing modeling, and not everyone on your project should be doing modeling. Only a couple of people will have the requisite skills, but everyone needs to be able to read and understand the project models. The latter is a training issue, not a tool issue.

Code Generation

If you want to generate Java or C# code from your models, you have to be sure the tool supports code generation for that language. But is code generation really a time-saver? I have found it is not. The tool can only generate the structural code, not the application's business logic. If you are using a Test-Driven Development approach with jUnit, or NUnit, you will not write any production code until you write the unit test code. Code generation may be the can't-live-without feature you never use.

Reverse Engineering

Reverse Engineering (RE) is useful, but not for the reasons you might first think. RE is a way to convert your application code back into UML diagram form. When you perform RE, you can compare the diagrams from the current code base against the design diagrams that were used to develop that code base. Then you can see how far the code has deviated from its design inputs. You should expect some deviation, of course. We always find deficiencies in the design when we actually write the code. But you should not find that there is no recognizable similarity between the two. RE lets you "trust, but verify".

Round-Trip Engineering

Round-Trip Engineering (RTE) is a combination of Code Generation (CG), and Reverse Engineering (RE). If you use CG, RTE can assist your development effort, but beware of a potential danger. Some modeling tools allow you to control the RE aspect of RTE: they allow you to change the UML diagrams and will not migrate the model changes to the code unless you direct the tool to do so. Other tools support a "live" RTE and when you change a diagram, your code will be changed automatically. This can be a nightmare if 1) you do a lot of "what if" exploration with your UML diagrams, and 2) you do not have bullet-proof control on your source code.

IDE Integration

Tool vendors approach this differently. Some will sell you a full product that integrates only with a specific IDE. Others sell you a base product that has no integration, and you buy additional plug-ins to integrate to the IDE of your choice. Yet others sell suites that are relatively more expensive, yet integrate with multiple IDEs. IDE integration can be a tremendous benefit if you elect to use the tool's CG, RE, or RTE features. Just be sure you understand the vendor's pricing model, including the all-important maintenance fees and constraints.

Support for non-UML Diagrams

Definitely desirable, because UML is a necessary notation for object-oriented projects, but it is not sufficient. UML class diagrams can be used to specify data models, but a UML class diagram is not the same as an Entity-Relationship Diagram. The UML activity diagram can be used to specify a process flow, but a UML activity diagram is not the same notation as Business Process Modeling Notation (BPMN), or Business Process Execution Language for Web Services (BPEL).

UML 2 Support

Almost all UML tools have migrated to support UML 2 notation, and the 13 diagrams defined in UML 2. As of this writing the current released version of UML is 2.2 (www.uml.org), and the Revision Task Force is working on the definition of UML 2.3. Some Open Source tools are still at UML 1.4 notation because the OSS teams have not maintained the product for UML 2. Additionally, not all UML tools that support UML 2 support the notation the same way, or conform to the UML 2 specification faithfully. The only way to identify a tool's support for UML 2 is to use the tool fairly extensively.

Visio

Visio gets its own entry because it is so ubiquitous, and has included UML drawing support for many years. Many groups use it because they already have it and cannot get a purchase requisition approved for a mature, capable modeling tool. Visio has improved in its UML support, but only marginally. In my humble experience Visio's usability for UML modeling is rather low relative to the mature UML modeling tools on the market. Yes, Visio can draw class diagrams, and it can draw sequence diagrams, but Visio is a drawing tool, not a modeling tool, and this is not a subtle distinction. If you like Visio, then by all means use it. But I would recommend you compare its capabilities and usability to the trial versions of UML-specific tools. I believe you will benefit from this comparison.


Have a productive month,

    Gary K. Evans


Magna Doodle is a registered trademark of The Ohio Art Company.

Subscribe to our newsletter!

Send an email to
with subject = "Subscribe"

You will find all prior
Evanetics Newsletters here.

Doing more with fewer people?

Are you looking for improved efficiency, and how to accomplish more with a reduced staff? Our high-quality training can jumpstart your business and development staff. Brief, on-site coaching can transfer knowledge and best-practices to your team in a rapid, cost-effective way. Call me directly at 803-781-7628. I promise to work with you to minimize cost, and maximize benefit for you.

About Evanetics

Evanetics provides on-site consulting, training, and assessments for teams and management in Business Analysis, Object-Oriented Modeling, Project Definition, Iterative process, RUP, Agile principles and practices.

How We Can Help

Our Training Offerings

Contact Us

Phone: 803-781-7628

Shu, Ha, Ri

In his Agile Software Development book, Alistair Cockburn relates a brief story about shu, ha, and ri - three Japanese words that describe a lot about software process and individual mastery.

An individual at the shu level is a beginner. This is an assessment of skill, not of time. We all begin a new area of learning at, or near, the shu level, where we need to learn just one way of solving a problem even when many approaches exist. As a consultant and instructor, I must be very sensitive to the shu's in my care. Showing them four different ways to solve a problem or produce some result is just confusing for a shu. A shu person oftens asks for "the" answer, and obtains some comfort when provided a checklist of activities to perform in a given sequence.

A person at the ha level has attained some experience, and has begun to see the higher patterns in his or her discipline. A ha person may still use a checklist, but is willing to make decisions about the steps on that list. The ha will assess that a particular practice that seemed so very important when he was a shu, is really not necessary in the current context. The ha is readily capable of adapting a process, and working around obstacles. In other words, the ha person is willing to omit, or augment, his checklist, no longer being rigidly constrained either to its content or sequence.

The person at the ri level has attained an envied mastery of her subject area. The ri not only sees high-level patterns, but sees the simplicity joining these patterns together. While the ri person knows and understands the checklist, she goes beyond it. A ri understands her domain so well that she throws away the checklist. It is no longer necessary for guidance. All that is needed now is for the ri to know the goal to be achieved, and she will find her way without even being aware that she is making a multitude of assessments and decisions that would simply bewilder a shu.

I have found in shu-ha-ri an insight that illuminates many process issues in companies with whom I have consulted. Organizations that engage in command-and-control processes have institutionalized the shu level. Their attempt to achieve mastery through a corporate-standard checklist is an inertia that unintentionally constrains their people at the shu level. Yet agile processes like Scrum explicitly do not tell you how to solve a problem, or what documents to produce, because they can only encourage you to find your own solution - the solution that is right for your project, not your checklist.