1. collaborative use of the tool
Real-life projects usually require several engineers working together on the same UML mode, so the tool must have support for collaborative work. The support for collaboration can be achieved in several ways, most common being the following two: repository support
UML models are stored in a repository that provides model sharing and concurrent model development.
- integration with configuration management tools that support collaborative work
The support for sharing and concurrency is deferred to a configuration management tool. This alternative is preferred because the model is stored “close” to the code and other related artefacts (test cases, documents, etc). Additionally, the overhead required to manage the UML models repository is eliminated.
The support for collaborative use of the UML tool requires support for versioning model elements, for comparing different versions of a model element and for merging concurrent versions of the same model element.
2. integration with configuration management tools
Best practices for software development require the development artefacts (documents, code, tests, models, etc) to be stored using a configuration management (CM) tool. The level of integration may range from exporting the model in XMI format and storing the XMI under configuration management control to advanced integration that allows direct connection between UML and CM tools (usually based on plugins), including check in/check out of model elements, model synchronization between workarea and CM tool database, model elements versioning, etc.
This criterion should be analysed in conjunction with collaborative use support criterion.
3. round-trip engineering
Round-trip engineering is the ability to generate code from UML model (forward engineering) and to generate the UML model from the code (reverse engineering). There are multiple levels of support for round-trip engineering, ranging from generating method stubs from class diagrams or updating the method description in the model when the method signature is changed in code, to full automatic synchronization between model and code.
Most of the UML tools offer an intermediate level of support for round-trip engineering, some tools offering one way engineering only. Full automatic synchronization between model and code is provided by highly specialized tools only; the model and the code have to adhere to restrictive rules to allow this type of synchronization.
4. generation of documentation from model
Many engineers working with an UML model require only read-only access. The UML tool should provide the capabilities for generating easily accessible static views of the model (usually HTML and PDF formats are used for generating the static view). These static views should be as close as possible to the tool view of the model from the point of view of navigation, display and informational content.
An UML model contains a significant amount of information that usually has to be presented in other documents like requirements documents, design documents, etc. Some of the modeling tools have the capability to generate documents with customisable format and content. This feature is valuable when the model contains enough information so an almost complete document can be generated.
5. UML standard support
UML standard is vast and complex and although most of the tools claim full support for an UML release, probably no tool really does it. Real life shows that full support for UML standard is not required. Therefore, when conducting an evaluation for an UML tool, the evaluation team should decide on a subset of UML standard that is required to be supported and the evaluation should be conducted for this subset.
6. diagramming features
Ultimately, an UML tool is used for drawing diagrams and the ease of creating diagrams is of top importance when evaluating the tool. Features like auto-completion, quick-pick lists, tool-tips, copy-paste for model
elements, etc should be considered for assessing the diagramming capabilities.The criteria described above should be considered in the context of the forecasted use of the UML tool. One criterion of the above ones may not apply, other may apply partially, others may be weighted differently. This list describe only the most common criteria, but other relevant criteria for selecting the UML tool (e.g. data modelling, multi-platform support, model analysis features, etc) should be considered too.
