# How to Select a UML Modeling Tool for Agile Modeling or MDD

Selecting the best Unified Modeling Language (UML)  tool for your Agile Modeling or Model-Driven Development (MDD) project can be difficult, even if you are a skilled visual modeler and an expert software developer. UML is a powerful, but formidable, technical language to master, and the “Muddle-Driven Marketecture” vendor hype and tool featuritis associated with commercial UML tools can overwhelm even savvy developers. Software developers who want to transition to MDD technologies need to climb two steep learning curves to reap the benefits of MDD: 1) achieving fluency in UML 2.x as a lingua franca for technical communication; and 2) learning how to drive the “clickology” of a UML modeling tool, many of which have mediocre (or worse) user interfaces.

## Background: The Importance of Tool Selection Due Diligence

Since Model-Driven Development project stakes are high in terms of both time and budget, it behooves you and your team to choose your UML modeling tool wisely. While the efficient use of your MDD team’s time is of paramount importance, it is also noteworthy that the prices of commercial UML modeling tools vary by more than an order-of-magnitude ($$\mathcal{O}(10)$$). The prices for UML commercial modeling tools with comparable features range from ~$300 to$10K+, which is greater than an $$\mathcal{O}(10)$$ difference, where modeling tool quality is not always directly proportional to price. (Indeed, a case can be made for inverse proportionality between tool quality and price—see Nyrbok’s Laws of Software.) Since many software developers also need to consider the associated training and coaching (consulting) costs for the UML tool they choose, keep in mind that more expensive tools can also be more difficult to drive. So do you want to blow your UML tool and training budget on a $10K/seat UML modeling tool that drives like a rough-handling semi-trailer truck, or a$300 UML tool that drives like a nimble sports car? For a 10+ person MDD team with tough deadlines and a tight budget, you likely need to make a smart tool choice.

\begin{align} U & \propto \frac{k}{{F \times C}}, \\ P & \propto {F \times S}, \\ Q & \propto \frac{U}{P}, \\\text{where}~F &=\text{number of Tool Features,}\\ C &=\text{average #Clicks per Feature},\\ S &=\text{Sales & Marketing budget},\\ U &=\text{Usability}, \\ P &=\text{Price}, \\ Q &=\text{Quality}. \\ \end{align}

— Nyrbok’s Laws of Software: Usability, Pricing, and Quality

For example, consider a 20-person MDD project with a $200K budget for UML modeling tools and training. Will the project team be better off spending$200K for 20 licenses at $10K/seat with$0K left over for basic training, or spending $6K for 20 licenses at$300/seat with \$194K left over for advanced training and expert coaching? The answer, of course, depends upon many factors other than price. In addition to the advanced features frequently hyped by high-cost UML tool vendors to justify their prices (notably model simulation and executability capabilities), you also need to consider more mundane, but essential features, such as usability (a.k.a. ease-of-use) and standards compliance. After all, what good is a pricey executable UML modeling tool if its user interface is so counter-intuitive that your software developers revert to Visio drawings + Excel spreadsheets for their project deadline deliverables? (This may help explain why the Visio drawing tool remains our planet’s most popular “modeling tool.”)

Given the importance of UML modeling tool selection for your Model-Driven Development project, we recommend that medium-to-large size projects (10+ software developers) conduct a bona fide trade study for their UML tool selection process. For smaller projects with smaller teams (< 10 software developers), you may want a less formal and more “Agile” (as in Agile Development and Agile Modeling)  tool selection process. In any case, you need to perform some basic due diligence for UML modeling tool selection, lest you squander your project budget and blow your delivery schedule. (Caveat emptor applies here, as elsewhere!) Here are the basic steps that your UML modeling tool selection process should follow:

## Specify objectives and requirements for your UML tool

You should begin by specifying clear and precise objectives and requirements for your UML modeling  tool. Have you defined a pragmatic objective for your UML tool consistent with the practical goals of your MDD project? An example of a pragmatic and measurable objective is: “The project’s UML modeling tool will be able to specify the following software development artifacts: Software Requirements Specifications, Business Process Workflows, Software Design Specifications, …” You should also specify specific functional and non-functional requirements for your UML tool. Your functional requirements should define the essential and advanced features of an acceptable UML tool.

An example of an essential functional requirement is: “The project’s UML tool must be able to draw all 14 diagram types as specified and illustrated in the OMG UML v. 2.x specification.” An example of an advanced functional requirement is: “The project’s UML tool must be able to automatically generate software documentation and software code as follows ….”  Your non-functional requirements should specify usability and performance requirements, along with metrics for measuring them. An example of a usability requirement is: “The project’s UML tool User Interface (UI) must provide context sensitive help that explains all common modeling functions and how to achieve common modeling tasks.” An example of a performance requirement is: “The UML tool’s team modeling capability must be able to support up to 100 total users and 50 concurrent users, while maintaining a UI response time limit of 1 second for common editing operations and a UI response time of 10 seconds for model repository check-out/check-in operations.”

## Define evaluation criteria

After you have specified your requirements your should define objective evaluation criteria for determining which UML tools satisfy those requirements. Determine a balanced set of tool characteristics that are consistent with your requirements, and define objective criteria for measuring those characteristics, including clear thresholds beyond which a candidate UML tool is deemed unsatisfactory. For example, consider the following UML modeling tool evaluation criteria, which are elaborated up in the related How to Define UML Tool Evaluation Criteria article: Usability (Ease-of-Use), Functionality (Drawing, Round-Trip Engineering), Standards Compliance, Interoperability, Technical SupportTeam Modeling Support and Value.

## Assign relative weights to evaluation criteria

After you have specified your selection criteria you should assign numerical weights to them to quantify their relative importance. The assignment of relative numerical weights to your criteria allows you to tailor your tool selection to specific team and project needs, and it can also reduce evaluator bias. For example, consider weighting the criteria in the evaluation criteria example above as follows:

$$Score_ {tool} = \overline{x} = \sum_{i=1}^{n} w_i * c_i$$

where Tool Evaluation Score ($$Score_ {tool}$$) is the weighted mean ($$\overline{x}$$) of the evaluation criteria.

Note that the same evaluation criteria e.g., (c1 = Usability, c2 = Features: Drawing, c3 = Features: Round-Trip Engineering, c4 = Standards & Interoperability, c5 = Technical & Team Modeling Support, c6 =Value) can be weighted differently for different team and project needs. For example, a small Agile Modeling team supporting an Agile development method such as Scrum with no need to generate software code from its models might assign the following weights to the evaluation criteria: (w1 = 20%, w2 = 20%, w3 = 0%, w4 = 20%, w5 = 20%, w6 = 20%). In contrast, a large Model-Driven Development team seeking to generate production software code from its models might assign the following weights:  (w1 = 20%, w2 = 15%, w3 = 25%, w4 = 15%, w5 = 10%, w6 = 15%).

## Identify candidate UML tools

You are now ready to identify candidate UML modeling tools to thoughtfully evaluate. It’s important to realize that you are not expected to evaluate all the UML tools in the universe whose vendors claim UML standards compliance. Indeed you will soon realize, if you haven’t already, that since there is no UML reference implementation or test suite for testing UML standard compliance, it is relatively easy for tool vendors to take implementation shortcuts (e.g., not updating UML v. 1 constructs and terminology to UML v. 2) that may fail to meet your requirements. First you should compile a “long list” of UML candidate tools by starting with those that you may already know about or have been recommended to you, and extend it via professional networking and Google research. Then apply the UML tool requirements that you have previously applied to quickly filter out non-contenders. For example, if your tool requirements include “… shall automatically generate documentation in HTML and RTF formats …” and a candidate tool does not include support for this function, it should immediately be dropped from your list. In most cases, if you have done a good job specifying your requirements, your “long list” should reduce into a manageable “short list” of five or fewer candidate UML tools.

## Evaluate candidate UML tools

Now you can take your “short list” of candidate UML tools and perform a hands-on evaluation of each of them, systematically applying your weighted evaluation criteria. In order to perform this evaluation fairly and consistently across competitive modeling tools, use the same UML example model for test driving each tool. The UML example model that you choose should be of moderate complexity (say 100+ Classes with Properties and Operations, plus Sequences/Activities that use the Classes for Lifelines/Swimlanes and Input/Output parameters). Your UML example model should thoroughly exercise all the UML diagram types defined in the latest UML specification. If you don’t have your own UML moderate-complexity example yet, use the examples in one of the better UML text books as as a neutral starting point.

## Select UML tool

If you have followed the preceding steps carefully to this point, you will likely end up with two or three UML tools that are fairly close in their cumulative evaluation ratings. No worries; this is to be expected. At this point, since it’s likely you’ve learned a lot about UML modeling tools by your evaluation process to date, you should review your requirements and weighted evaluation criteria, and tune them based on what you have learned. In most cases, this will suffice to make a final UML modeling tool selection.