Alternative UML Modeling Tools - Product Information

Want to challenge Rational Rose? Take care of the basics! In this review, we take a preliminary look at four alternatives: Argo UML, Objecteering, Together, and Visio.

THE DE FACTO STANDARD TOOL FOR UML (Universal Modeling Language) modeling is Rational Rose from Rational Software Corp., Cupertino, Calif. However, Rose has a number of deficiencies, some of which were pointed out in a previous article (see Software Magazine, April/May 2000). Chief among them is that Rose is not even close to being a faithful implementation of the UML specification.

The fact that UML is an international standard owned and managed by the Object Management Group (OMG) opens the door to competition to Rose. This article is a preliminary survey of some alternative UML modeling tools.

My approach to examining these tools is based on a simple premise: If a tool doesn't provide good support for the basic function of producing UML class models, then additional features such as code generation, reverse engineering, support for different viewpoints, etc., are of much less value. Thus, this review focuses almost exclusively on support for class models.

Evaluation Criteria

This article does not examine whether the tools support extremely rudimentary functions, namely the ability to represent classes, attributes, operations, and relationships; a tool that does not support these would not be worthy of mention here. Rather, it discusses aspects of class modeling that are often glossed over but should not be. Some criteria concern what may seem to be rather arcane aspects of positioning diagram elements. However, when a tool falls short in. these areas it is extremely frustrating to a modeler striving to produce readable, intellectually manageable models.

Note that because the UML tool market is relatively new, the products in it are changing--and improving--very quickly. Therefore, we suggest that readers use the information provided here as a general guide, and defer any final product selection decisions until they contact the vendors involved to determine the true current--and upcoming--features and pricing of their respective products.

The table, "How the Tools Stack Up," compares support for key features across the four tools reviewed here, along with Rational Rose. We don't recommend trying to make a summary assessment by simply adding up the numbers in the columns because some criteria are more important than others.

It should also be noted that all of the tools reviewed here support all of the standard UML diagrams, except for Argo UML, which does not yet support sequence diagrams.

Class Modeling Fundamentals

Faithful Implementation of UML Properties. The UML specification defines the properties of classes, operations, attributes, associations, dependencies, etc. For example, you should be able to specify whether or not a class is abstract, whether it is a root in the class hierarchy, and whether it is a leaf in the hierarchy. For an operation you should be able to specify, among other things, whether it is a query (i.e., whether it has side effects), what its concurrency characteristics are, etc. The properties that must be supported are laid out very clearly in the OMG specification as a formal metamodel.

Flexibility of Class Box Size. It is important to be able to control the size of a class box in order to make diagrams readable. If a tool tries to control the size without allowing its best guess to be overridden, it can drive a modeler crazy.

Flexibility of Lines. Lines used to depict inheritance, associations, and dependencies must be flexible. It should be easy to make a line perfectly straight. It should be possible to change a line's orientation; i.e. whether it is horizontal, vertical, diagonal, or multisegment.

Flexibility of Position of Association End Names and Multiplicity Labels. The modeler must be able to control the placement of names of association ends (sometimes erroneously called "role names") and multiplicity labels (such as 0..1, 1..*, etc.) relative to the association line. Again, it is fine for a tool to make an educated guess to provide a default placement, but it must be easy to override.

Preservation of the Position of Association End Names and Multiplicity Labels. Some tools allow you to control the placement of end names and multiplicity labels, only to completely trash your hard positioning work when you move the line or move one of the class boxes to which the line is attached. The tool must do a good job of remembering the position of the end name or multiplicity label relative to the association line.

Moderate Binding of Relationship Lines. It should not be easy to inadvertently detach a relationship line from the model element participating in the relationship. The line should bind tightly enough to the participants so that accidental detachment does not commonly occur. On the other hand, it should be possible, when necessary, to detach a line from one participant and reattach it to another model element. UML relationships include association, dependency, and generalization (a.k.a. subclassing or inheritance).

Distinguish Between Removing an Element from a Diagram and Deleting it From the Model. The modeler must be able to remove an element from a diagram without deleting it from the model altogether. For example, a modeler may decide not to show a particular class or association on a diagram because it is shown on other diagrams and/or because the diagram in question focuses on other aspects of the model. Being forced to show an element when it is not of interest leads to hopelessly cluttered diagrams that are difficult to comprehend. A good modeling tool will allow the modeler to remove an element from a diagram without deleting it from the model.

Another example of this requirement is that the modeler should be able to control whether each end name and multiplicity label is displayed on the diagram. Control should be on a per-item basis. Opting not to show a particular item should not remove it from the model.

Restoration of Relationships in New Diagrams. When constructing a new diagram using model elements already contained in other diagrams, it must be possible to show the relationships among those elements. The modeler should be able to specify exactly which of these relationships should be visible.

Two or More Instances of the Same Class on one Diagram. It is nice to be able to place two instances of the same class on one diagram because sometimes that can avoid the clutter of having relationship lines going from one end of the diagram to another.

Option to Depict Bidirectionally Navigable Associations via Arrows at Both Ends. UML has an ambiguity about the meaning of an association line between two classes with navigability arrows at neither end. It can mean either that both ends are navigable or that neither end is navigable. Thus, when looking at such a line on a class diagram, it is not possible to distinguish between these two cases. Usually you have to drill down into a properties dialog for the association in order to determine whether both or neither ends are navigable.

UML has an alternate notation for bidirectionality: an arrow on both ends of the association line. This allows the modeler to make it visually clear that the association is navigable in both directions. This feature should be an option that can be turned on or off on a case-by-case basis, because sometimes the clutter produced by the two arrows is not worth the benefit. It may be helpful to be able to show the arrows on one diagram and not on another, even for the same association.

N-Ary Associations. UML supports associations among more than one class, often called n-ary associations. Unfortunately, many UML tools do not support this. In my experience n-ary associations are important, particularly in business modeling.

Flexibility in Depicting Inheritance. UML notation has two basic ways of depicting inheritance (technically called generalization). Figure 1 demonstrates one of these ways.

Figure 2 demonstrates an alternate way to depict inheritance. This alternate notation is quite important for producing readable models.

Multiple Subclass Partitions. While some UML users consider the alternate subclassing notation of Figure 2 merely a convenient shorthand, it has more powerful uses. Figure 3 partitions Account in two orthogonal ways. This model says that you can have objects that are instances of one class from each partition; namely, a minor trust savings account, a minor trust checking account, an adult savings account, and an adult checking account. SavingsAccount and CheckingAccount both have the same discriminator named "usage," while MinorTrustAccount and AdultAccount have the discriminator "competency.

Multiple, orthogonal subclass partitions are very useful, particularly in conceptual modeling, such as modeling a business.

Dependencies Involving Model Elements Other than Classes or Packages. In UML, any model element can participate in a dependency relationship. Model elements include classes, associations, attributes, operations, etc. Unfortunately, most tools allow only classes and packages to participate in dependency relationships.

For example, I may want to show that a class traces back to an attribute, as expressed in Figure 4. This kind of trace dependency is commonly used to show how elements in a technology-specific model trace back to elements in a platform-independent model (sometimes called an analysis model).

Another common requirement is for an exception to have a dependency on the operation that raises it.

Design-by-Contract. Design-by-contract is an approach to OO software that focuses on the contract that an object or component undertakes to honor. The contract is specified not only by defining classes, class attributes, and operations, but also by specifying invariants for the classes and pre- and postconditions for the operations. Invariants are assertions that must always be true in order for an instance of the class to be well formed. The preconditions of an operation are assertions that must be true in order for the operation to execute. Postconditions are what must be true when the operation completes. Design-by-contract is increasingly understood to be crucial for constructing highly reliable software.

UML supports invariants and pre-and postconditions. It does this by providing the general notion of a constraint. Constraints are assertions that can be declared for any model element, not only for classes and operations. UML also defines the Object Contraint Language (OCL), which is a formal assertion language that can be used to write assertions in terms of a model's properties. A tool could theoretically use OCL to generate validation code; however, this is an area of advanced research. It is logically straightforward, though, for a tool to verify that OCL expressions refer to properties that actually exist in the model.

UML Profiles. It should be possible to define stereotypes and tagged values for any model element. It should also be possible to control, on a case-by-case basis, whether and how the stereotype of a model element is displayed on a particular diagram.

Ideally, a tool will provide a way to specify a reusable set of stereotypes and tagged values, which is what UML calls a profile.

Basic Features of Good Desktop Software

Help Index and Search. The accessibility of help information is greatly enhanced by indexing and search capabilities. When a tool adopts HTML as its help platform, the indexing and search capabilities are often much less powerful than what users of Windows desktop applications or JavaHelp might expect.

Undo. The ability to undo the last action is a significant productivity booster. A good implementation of undo allows undoing more than just the last action and, after undo, allows the actions to be redone one at a time.

Diagram Export. It should be possible to export a diagram by copying it to the clipboard or to a file in a standard format that other applications can read.

Comparing the Field VISIO 2000. MICROSOFT CORP., REDMOND. WASH.

When I first fired up the Visio UML modeling tool I got really excited. The developers of the UML stencil for Visio actually studied the UML specification and covered nearly all of the UML'S properties and capabilities.

Unfortunately, the designers of the UML stencil made a fundamental mistake. They failed to give the modeler control over crucial aspects of modeling, which I described above as flexibility criteria. You can't size a class box. You have no choice about whether a line is diagonal or rectangular. In some situations the line will be diagonal, period, and in some cases it will be rectangular, whether you like it or nor.

Regrettably, you have no control over the placement of association end names and multiplicity labels. This sometimes leads to absurd results where you can't tell which association a name or multiplicity label is tied to. Sometimes the automatic placement logic puts the item right on top of the class box, where it is not readable.

It's a shame, because not only does Visio implement UML quite faithfully, it also has many basic characteristics of good software. It has a very professional help system with indexing and searching. It has multiple levels of undo and redo. In the Windows environment in which I was operating, it has the ultimate support for diagram export: It is an in-place OLE server.

Significant shortcomings are the complete lack of support for subclass partitions, the restriction that only classes and packages can participate in dependency relationships, and very loose binding of relationship lines. The two-arrows notation for bidirectionally navigable associations is supported, but this notation is mandatory.

The modeler can enter constraints for any model element through the UI. However, there is no specific support for OCL. You can enter an OCL expression, but it's just an opaque string as far as Visio is concerned.

TOGETHER 4.0. TOGETHERSOFT CORP., RALEIGH, N.C.

Together is probably one of the better-known entrants in this field. (I used the Java version.) The salient characteristic of Together is that it is quite strongly tied to code. The model is actually saved as code, and Java coding concepts surface in the properties dialogs. Together can be used for conceptual modeling, but it is clearly oriented toward models that transform directly to code and for managing round-trip engineering between model and code.

Class box and line flexibility are good. The modeler can control the location of association end names and multiplicity labels, but the program does not do a good job of preserving these locations when the modeler moves the association lines or the classes to which they are attached.

Together is not adequately faithful to the UML specification. The properties dialogs are missing significant items and the properties of associations are not as well-aligned with UML as they should be. Specification of navigability of associations is accomplished via a "direction" property, which can be used to specify navigation in one direction but not both. This is a consequence of Together being strongly oriented toward implementation modeling. The program forces you to break a bidirectionally navigable association down into two associations that are navigable in opposite directions, because this simplifies code generation.

The tool distinguishes between removing a class from a diagram and deleting it from the model. However, there is no way to remove an association from a diagram without deleting it from the model (I am told this will be addressed in the future).

Relationship management could stand some improvements. There is no support for the alternate subclass notation of Figure 2, let alone for multiple subclass partitions. Dependencies can only involve packages and classes, although Together does have some nice features for managing the display of dependencies. Relationships are restored among pre-existing elements in new diagrams by default.

Together's support for design-by-contract is good. It allows declaration of invariants for classes, and pre- and postconditions for operations. This covers the most important aspects of design-by-contract. However, Together does not support constraints for other model elements. There is no explicit support for OCL.

Support for UML profiles is powerful but not very accessible. Stereotypes can be assigned to any model element through the UI, but tagged values are supported only by way of modifying config files or writing code.

Together's help is indexed and can be searched. Multilevel undo and redo is well implemented. There is no diagram export to the clipboard but you can export a diagram to a graphics file, which is perfectly acceptable. Together is not an OLE server.

Together is a strong contender if your main purpose is to write implementation models from which code can be generated.

OBJECTEERING 4.3.1.A. SOFTEAM [*]. FRANCE

Objecteering is a full-featured tool with code generation, reverse engineering, and workgroup features. Modeling with Objecteering's Softeam is straightforward and reasonably flexible. Coverage of UML properties is uneven. However, the modeling UI is pretty intuitive overall. Class boxes can be sized as expected and line flexibility is good. The modeler can control the placement of association end names and multiplicity labels, and the program maintains the placement quite well as the other elements around them are moved. Unfortunately, the end names and multiplicity labels cannot be omitted from a diagram altogether, although in general the program makes a clear distinction between removing an element from a diagram and deleting it from a model.

Objecteering does the best job I've seen of managing the propagation of associations into new diagrams. It does not restore all relationships on the diagram by default. (For complex models, restoring all by default can often create a mess in your new diagram because you then have to painstakingly remove the unwanted lines.) With Objecteering, if you want the relationship in your diagram, you drag it to the diagram from the explorer. The explorer gives you a nondiagrammatic view of the model elements and their properties.

The same element cannot appear more than once on a diagram. The two-arrow notation for bidirectionally navigable associations is supported, but is not optional. N-ary associations are well supported. Relationship line binding is appropriately moderate. Classes and packages are not the only model elements that can participate in dependency relationships; however, dependencies are supported for other elements only in highly restricted ways. The alternate subclassing notation is supported, but it is not possible to model multiple subclass partitions, which is a regrettable deficiency.

Design-by-contract support is quite strong. The program supports the specification of invariants for classes and also of pre- and post-conditions for operations. You can also specify constraints on relationships, although it does not directly support declaring a constraint on an association end. The tool does not have any intelligence about OCL, as it views constraints simply as strings.

Objecteering has the most complete support for UML profiles I've seen. You can assign stereotypes and tagged values to any model element through the UI and you can set up a project whose purpose is to define a reusable profile.

Objecteering's help system is HTML-based and suffers from the typical shortcomings described in the evaluation criteria. The index is just a set of links to major topics, and there is no search capability. On the other hand, Objecteering has excellent execution of multiple levels of undo and redo. Diagram export works by copying a metafile to the clipboard, and this works fine, but Objecteering is not an OLE server. The program's menus are nonstandard and thus it is sometimes not easy to figure out how to do simple things. Also, you can't close one project and open another without shutting the program down and restarting it.

In sum, Objecteering is a serious entry into the field and deserves to be considered.

ArgoUML VERSION 0.8. TIGRIS.OR6

ArgoUML is an interesting entry into the UML arena. It is a very active open source project. It has features for adding "to-do" comments at certain points in models and a way for modelers to define different viewpoints. It also verifies OCL constraint expressions against the model that contains them. Thus, ArgoUML is very promising. However, it is not polished enough for an enterprise modeling and development team to use it for serious, large-scale projects. In fairness, note that this is a very early version--less than 1.0.

The dialogs for the different kinds of model elements, such as for classes, are missing many of the UML properties. Therefore, ArgoUML cannot at this point be considered a faithful implementation of UML.

Class boxes may be sized very flexibly, and line drawing is flexible as well. Unfortunately, the modeler has no control over the placement of association end names and multiplicity levels. This lack of control can lead to some ridiculous results, as is the case with Visio. This deficiency alone disqualifies ArgoUML from being practical for use on a large scale in the corporate world.

The tool does distinguish between removing an element from a diagram and deleting it from the model.

ArgoUML does not allow a preexisting class to appear on a new class diagram that is part of the same model. Thus, the question as to whether it restores relationships between elements on new diagrams is moot.

Associations between two elements that are navigable in both directions are depicted by the absence of arrows. There is no option to use the alternate two-arrow notation. N-ary associations are not supported.

Argo does not support the alternate notation for showing a group of subclasses with one inheritance triangle as described above (see Figure 2). Therefore, it cannot depict multiple subclass partitions.

The tool appears to support the participation of elements other than classes in a dependency. However, the appearance is deceiving. It permitted me to draw a dependency line from a class to an attribute. However, when I saved the model and reopened it later, the dependency line stopped at the edge of the class box. Apparently ArgoUML records that the participant is the class within which the line terminated.

Relationship lines bind tightly to the relationship participants so that the modeler can't unintentionally detach a line. The tool seems at first to allow relationship lines to be unattached, but here again, appearances are deceiving. Detachment and reattachment to a new participant are not recorded when you save the model.

Most model elements can be nominally stereotyped. You can enter a stereotype for a class or association in the class or association properties pane, respectively. However, the stereotype simply does not appear on the diagram. You can enter a stereotype for an association, but the tool doesn't display it or store it in the model. Stereotypes for some other kinds of model elements don't work properly either. Tagged value support is implemented fairly well. The properties pane for each kind of model element has a dialog tab for tagged values that preserves the names and values entered. There is no way to predefine a set of stereotypes and tagged values that would constitute a reusable UML profile.

Argo has an HTML-based "tour" but not a full-blown, integrated help system. It has menu options for undo and redo, but I experimented by deleting a dependency relationship from my model and undo was not enabled thereafter. There is no diagram export.

Ready for Prime lime?

It appears from our preliminary look that Objecteering and Together are ready for prime time. However, in order to challenge Rose's market dominance, a tool must be much better than Rose. Since Objecteering and Together handle the basics reasonably well, you would have to evaluate the advanced features to determine whether they have risen to that level.

David Frankel is chief scientist at Genesis Development Corp., West Chester, Pa., an Iona Technologies' Company. He is a member of the OMG Architecture Board, and co-chair of the OMG's Business Object Initiative Working Group.

(*.)Disclosure: The author's company is a partner with Softeam, the vendor of Objecteering, in a European Community funded project.

References: Unified Modeling Language (UML,) Specification, Version 1.3, June, 1999. Http.//cgi.omg.org/cgi-bin/doc?ad/99-06-08

COPYRIGHT 2000 Wiesner Publications, Inc.
COPYRIGHT 2000 Gale Group