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.
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:
Thanks, Timothy David Ryan
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 ELSA AG Engineering Consumer Communications Germany
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 Teradyne/ATD MS NR22-11 600 Riverpark Dr. N. Reading, MA 01864 lahman@atb.teradyne.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):
Thank you for listening, Carl Babel
Another criteria worth consideration and not mentioned in your article might be cost. Thanks, Chris Males cmales@yahoo.com
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? Cheers PS nice page. Paul Sorenson Software Development Manager Invetech Pty Ltd
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
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
Hi, 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. Regards, Juha-Pekka Tolvanen MetaCase Consulting Ylistonmaentie 31 FIN-40500 Jyvaskyla FINLAND E-mail: jpt@metacase.com WWW: http://www.metacase.com |
|
Copyright © 1999 Objects by Design, Inc. All rights reserved.