UML tool

A UML tool or UML modeling tool is a software application that supports some or all of the notation and semantics associated with the Unified Modeling Language (UML), which is the industry standard general purpose modeling language for software engineering.

"UML tool" is used broadly here to include application programs which are not exclusively focused on UML, but which support some functions of the Unified Modeling Language, either as an "add-on", as a "component" or as a "part" of their overall functionality.

Kinds of Functionality

UML tools support the following kinds of functionality:

Diagramming

"Diagramming" in this context means "creating" and "editing" UML diagrams; that is diagrams that follow the graphical notation of the Unified Modeling Language.

The use of UML diagrams as a means to draw diagrams of – mostly – object-oriented software is generally agreed upon by software developers. When developers draw diagrams of object-oriented software, they usually follow the UML notation. On the other hand, it is often debated whether those diagrams are needed at all, during what stages of the software development process they should be used, and how (if at all) they should be kept up-to date. The primacy of software code often leads to the diagrams being deprecated.

Round-trip engineering

"Round-trip engineering" refers to the ability of a UML tool to perform code generation from models, and model generation from code (a.k.a., reverse engineering), while keeping both the model and the code semantically consistent with each other. Code generation and reverse engineering are explained in more detail below.

Code generation

"Code generation" in this context means, that the user creates UML diagrams, which have some connoted model data, and the UML tool derives from the diagrams parts or all of the source code for the software system. In some tools, the user can provide a skeleton of the program source code, in the form of a source code template where predefined tokens are then replaced with program source code parts during the code generation process.

There is some debate among software developers about how useful code generation as such is. It certainly depends on the specific problem domain and how far code generation should be applied. There are well known areas where code generation is an established practice, not limited to the field of UML.

The idea of completely leaving the "code level" and start "programming" on the UML diagram level (i.e., design level) is quite debated among developers. That is the vision for Model-driven architecture (MDA). This idea is not in such widespread use compared to other software development tools like compilers or software configuration management systems.

An often cited criticism is that the UML diagrams just lack the detail which is needed to contain the same information as is covered with the program source. Some developers even claim that "the Code "is" the design" [http://www.developerdotstar.com/mag/articles/reeves_design_main.html by Jack W. Reeves] .

Reverse engineering

"Reverse engineering" in this context means, that the UML tool reads program source code as input and "derives" model data and corresponding graphical UML diagrams from it (as opposed to the somewhat broader meaning described in the article "Reverse engineering").

Some of the challenges of reverse engineering are:
* The source code often has much more detailed information than one would want to see in design diagrams. This problem is addressed by [http://www.sei.cmu.edu/architecture/ata_extraction.html software architecture reconstruction] .
* Diagram data is normally not contained with the program source, such that the UML tool, at least in the initial step, has to create some "random layout" of the graphical symbols of the UML notation or use some automatic "layout algorithm" to place the symbols in a way that the user can understand the diagram. For example, the symbols should be placed at such locations on the drawing pane that they don't overlap. Usually, the user of such a functionality of a UML tool has to manually edit those automatically generated diagrams to attain some meaningfulness. It also often doesn't make sense to draw diagrams of the whole program source, as that represents just too much detail to be of interest at the level of the UML diagrams.
* There are language features of some programming languages, like "class-" or "function templates" of the C++ programming language, which are notoriously hard to convert automatically to UML diagrams in their full complexity.

Model and Diagram Interchange

XML Metadata Interchange (XMI) is the format for UML model interchange. Unfortunately, XMI does not yet support diagram interchange, which is a significant shortcoming for a visual modeling language. Consequently, even when you can import a UML model from one tool to another with XMI, you will likely need to redraw your diagrams.

Model Transformation

A key concept associated with the Model-driven architecture initiative is the capacity to transform a model into another model. For example, one might want to transform a platform-independent domain model into a Java platform-specific model for implementation. It is also possible to refactor UML models to produce more concise and well-formed UML models. Finally, it is possible to generate UML models from other modeling notations, such as BPMN. The standard that supports this is called QVT for Queries/Views/Transformations. One example of an open-source QVT-solution is the ATL language built by INRIA.

References

ee also

*List of UML tools
*Model Driven Engineering
*QVT
*ATL
*Metamodeling

External links

*dmoz|Computers/Programming/Methodologies/Modeling_Languages/Unified_Modeling_Language/Tools/|UML Tools.
* [http://www.UML-Forum.com/tools.htm UML Tools listed on UML Forum web]