Home Books Software Projects Forums

Choosing a UML Tool
Reader Criteria

Thank-you to our readers who have sent us the following excellent criteria for evaluating UML tools. Your input is quite valuable. If you rely on UML tools for software development, we believe you should have a say in what you like or don't like about this class of applications.

Reader Criteria
Mon, 11 Feb 2002 13:23:42 -0500
"Ryan, Timothy D." <tdryan@tasc.com>

I am trying to use UML tools to generate and manage Business Processes rather than to generate software.

I would like to be able to:

  • Generate 'instantiated' Object Models from my Class Diagram.
  • Set actual cardinalities for my instantiated examples (versus cardinality 'ranges').
  • Independently set the attribute values of each of the instantiated objects.
  • Generate an XML file from the instantiated Object Models (versus XML Schemas from Class Models)
It should be noted that UML is beginning to have a wider reach than just SW development and that the above functionality is required for many of those purposes.

Timothy David Ryan

Another requirement on UML tools
Thu, 18 Jan 2001 13:55:19 +0100
"Dietmar Petras" <Dietmar.Petras@ELSA.com>

Assume a C++ class "C" with two base classes "A" and "B". More abstractly speaking: "C" implements the interfaces of both "A" and "B". In an overall class diagram, the box of "C" will show all attributes and operations derived and overloaded from "A" and "B". Such a diagram is mandatory but may be overloaded and difficult to unterstand.

Therefore two more diagrams may be useful:

* One that shows the collaboration of classes involved in that part of the functionality of "C" that only use the interface "A". This diagram may contain a box of class "C" that only shows the relevant operations, most from interface "A", maybe some more, but nearly none of interface "B".

* A second that shows the collaboration of classes involved in that part of the functionality of "C" that only use the interface "B". This diagram may contain a box of class "C" that only shows the relevant operations, most from interface "B", maybe some more, but nearly none of interface "A".

The requirement on the UML tool is that it allows to show in a class box only a randomly selectable subset of operations of a class. Most tools (e.g. Together) allow to hide all private operations or all attributes, etc. But not all allow a random selection like Rational Rose (Options->Select Compartment List).

Dr. Dietmar Petras, Senior Expert,
Group Leader Software Engineering
Engineering Consumer Communications

Comments on web site
Tue, 15 Feb 2000 10:28:29 -0600
"H. S. Lahman" <lahman@atb.teradyne.com>

Let me preface my comments by saying that I believe sites such as yours provide a valuable service for the OT industry. Though my comments are critical, the intent is to be constructive in covering holes.

I was disappointed to note that the list of OO CASE tools did not include any of the Shlaer-Mellor CASE tools that use UML as a notation. Some web references are: www.kc.com, www.projtech.com, and www.pathfindersol.com. I also believe the SES's ObjectBench has been converted to support UML as well, but I am not sure of that.

I was also disappointed that the page on "Choosing a UML Modeling Tool" did not deal with some of the most important features for an OO CASE tool:

(1) An abstract action language, such as that being jointly proposed to OMG by Rational, Project Technologies, Kennedy-Carter, at al. Some tools, such as System Architect and Rose RealTime, provide a C++ based action language but an abstract language is preferable because it maintains a level of abstraction consistent with OOA that is independent of the computing platform. An abstract action language also allows the OO model to be reused with different OOPLs.

(2) The modeling tool should support an executable subset of UML that allows full model simulation prior to committing the models to code. This simulation should include model level animation and allow the same test suite used for the simulation to be used for testing the final code. Having a common test suite ensures that the models remain in synch with the code during maintenance (if full code generation is not provided).

(3) The modeling tool should support full code generation (as opposed to just header files and .cpp stubs). While this is not a modeling tool requirement per se, the ability to talk to a back end that does provide code generation is such a requirement. [Note that to do this the modeling tool has to have the ability to check the model for UML features that are not executable (i.e., ambiguous combinations of UML constructs) and the tool must have some sort of action language. Note also that, contrary to you comment under auto-generation, several tools have supported this for a decade or so: all Shlaer-Mellor tools plus ObjectTime, System Architect, Rhapsody, and ObjectBench.]

(4) Related to (3) is the notion that a modeling tool should be interoperable with other tools. The three obvious legs on the OO development stool are: modeling tool, model simulator/debugger, and code generator. Clearly these should be plug & play together. However, real development environments also require interoperability with other tools, such size estimators (e.g., estimation based upon class model object counts), project management tools (e.g., those in the Management Tools section), and documentation tools. The current generation of tools does a poor job of this, but that is no excuse to ignore the requirement.

(5) Support for translation. For those users who port the same application to several platforms the ability to create platform independent models is extremely important. Such models are unchanged across platforms and are implemented by applying a platform-specific translation engine to them. This requires a one-time investment in a translation engine for each platform but the payoff lies in being able to translate many application models on the platform and to do only a single OO model of each application.

(6) Unambiguous instance identification in models. The rap on OMT and similar notations was that there was no mechanism for unambiguously defining which instances were involved in a particular relationship at run time. This leads to awkward situations where one gets to a different set of instances if a relationship loop is navigated clockwise or counterclockwise. Such ambiguity prevents code generation and simulation. UML supports a form of referential identifiers to address this problem but they are rarely used. The modeling tool should enforce their use for those interested in producing unambiguous models for simulation or code generation. (Note that, though tedious, models can be simulated manually if they are an executable subset.) That is, the modeling tool should offer the option of using an executable subset of UML and, if selected, the tool should enforce the use of referential identifiers.

(7) There should be a published meta model for the modeling tool. This is essential for interoperability and translation.

(8) Enforcing a methodology. The tool should enforce a particular methodology (hopefully selectable) as much as possible. For example, some methodologies, such as ROOM and Shlaer-Mellor, use a subset of UML so the modeling tool should flag use of non-subset constructs as an error.

Personally I think this is the most important feature for a tool. Trying to do OO without a coherent methodology is an invitation to failure.

H. S. Lahman
MS NR22-11
600 Riverpark Dr.
N. Reading, MA 01864

Tool selection criteria
Thu, 11 Nov 1999 11:02:07 -0800
"Babel, Carl" <CBabel@nlc.com>

Thank you for your excellent web site. Your work has helped me tremendously. Your tool selection criteria list is superb! This is a super-set of the technical points that I've sub-consciously been applying as I've evaluated vendors' products.

A few suggestions for additional criteria (novice's viewpoint):

  • Price. This criteria is most important for shops with immature OOSE capabilities. Companies that are committed to OOSE recognize the value of the tool(s), have supporting data to justify the cost, and consider it a necessary ongoing cost of doing business. Often, development teams considering adopting OOSE (especially when promoted from the ground, up) are extremely sensitive to the per-seat costs.

  • CAD correctness. This is about the general mechanics of the tool during diagramming. A good example is the tool behavior during auto-placement / rubber-banding. For example, when a user is building a Use-Case diagram, and has multiple use cases for a single actor, does the tool provide any automatic alignment capabilities? Can it do automatic proportional alignment? Do the links automatically adopt symmetrical distribution and spacing? While this criterion may not be huge in the grand scheme of things, a poorly designed tool can give you "mental carpal tunnel syndrome", and you just won't like using it.

  • Overall fit and finish. I realize that this can be very subjective, but I think its needed. This can probably include CAD correctness as well. It applies to all GUI programs. This addresses the consistency of the program, its intuitiveness, its adherence to the native platforms GUI standards, etc. Is there good online help? Is there a tutorial? Does the program start with a reasonable set of defaults? Does it include example projects?

  • Evaluation product. Closely related to price, is the capabilities of the evaluation project. Please (vendors), do not send me a product that cannot save the project, or cannot print. I can't do or share any reasonable evaluation with this. My preference is to get a fully capable tool that is time limited. Handicapped (excuse me, capability challenged) eval's that limit the number of objects, etc. are okay, but these should definitely include example projects and tutorials that fit within the imposed constraints.

Ah, but I ramble. ;-)

Thank you for listening, Carl Babel

Tool evaluation criteria
Thu, 04 Nov 1999 14:05:00 -0500
Chris Males <cwm@swl.msd.ray.com>

Another criteria worth consideration and not mentioned in your article might be cost.

Chris Males

UML Tool Features
Thu, 23 Sep 1999 10:14:38 +1000
Paul Sorenson <pms@invetech.com.au>

Dear uml-tools,

You mentioned printing and export facilities but I don't think you explicitly mentioned object linking/embedding. Whereas this might be more specific to a particular OS, at the end of the day our CASE models generally need to be referenced in other tools, such as requirements management tools or word processors. Some tools do this very badly and others not at all.

A second thing is more a UML issue which affects tools. We develop real time software and while UML state diagrams might be nice, I am not sure that the semantics are defined well enough to make code generation of the dynamic aspects of the model useful (compare this with say SDL). So when will we have integration of UML with SDL?


PS nice page.

Paul Sorenson
Software Development Manager
Invetech Pty Ltd

Re: ergonomy for UML tool criteria
Thu, 24 Jun 1999 10:49:29 +0200
Noelle Adam <Noelle.Adam@irisa.fr>
Irisa - Campus de Beaulieu - RENNES

About UML tools :
Things that are important to everyone (as for any software, in fact):
-Ergonomy, ease of use, good learning curve
-Stability, overall quality ( no crashes, no lethal bugs, not too many non-lethal bugs and annoying features) in your own environment.
-Availablity, price, free bug fixes or releases

Things that may be (or not ) important to you :
-UML completeness, conformance, possiblity to incorporate UML additions and changes as coming
-Design patterns in the editor
-Possiblity to edit and add your custom symbols in the editors
-Interoperability with other tools ( databases, IDE, libraries, compilers)
-Methods support
-Team or single user projects
-Animation of dynamic diagrams
-free T-shirt :-)

All those things (to add to what you've said) are to be tested against your specific needs.

IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France

ergonomy for UML tool criteria
Tue, 22 Jun 1999 13:17:20 +0200
Noelle Adam <Noelle.Adam@irisa.fr>
Irisa - Campus de Beaulieu - RENNES

The ease of use for the GUI of the tool is for me an important criteria. One should be able to concentrate on what to do, not how to use the tool. When I was testing tools, one drove me half crazy because I had to find "the right pixel" to click on to create links, had no possibility to edit directly on the schema but only with popups and so on. Took me so long to enter my schema that I didn't test the other parts.
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France

Wed, 05 May 1999 17:30:30 +0300
Juha-Pekka Tolvanen <jpt@metacase.com>


Thanks for great pages on the criteria for UML tool selection. Although the list is comprehensive I would like to add one important criteria: Support for UML extensions.

Extensions mean company/project/product specific additions to the "standard" UML. These are emphasized e.g. in UML conferences where almost half of the presentations deal with extending UML to meet better requirements in a specific area (distribution, real-time, embedded etc). Also the book (Booch et al. 1999) notifies extensions especially if they are specific for certain OOPs.

Hence, modeling tools should also support extensions; not only for adding new concepts/symbols, but also rules, checkings, and code generators that apply the extensions. Because full UML is not required in most cases, modeling tools should also allow to make subsets of the UML (lite UML like proposed by amigos).

See e.g. www.metamodel.com for extensions or modifications of UML or any other method.

Juha-Pekka Tolvanen

MetaCase Consulting
Ylistonmaentie 31
FIN-40500 Jyvaskyla
E-mail: jpt@metacase.com
WWW: http://www.metacase.com