UML (Unified Modeling Language) provides a powerful capability for modeling software systems. The various modeling elements and views, along with an extensibility mechanism, can be applied for modeling other systems. So why not use UML to model any system? Users would only need to buy one modeling tool, and the market for UML tools would be expanded.
Standard extensions of UML for specialized applications are called "UML profiles." OMG (Object Management Group) has defined a number of UML profiles. For example, there is a UML profile for modeling physical systems called SysML, a UML profile for modeling software development processes called SPEM (Software Process Engineering Metamodel), a UML profile that extends UML for specification and integration of services called SoaML, and a UML profile for DODAF (Department of Defense Architecture Framework) and MODAF (Ministry of Defense Architecture Framework) called UPDM.
A UML profile can be imported into a standard UML tool to create a specialized modeling environment. UML tools support views (graphical displays) that are appropriate to a variety of modeling applications. The extensibility mechanisms of UML enable existing UML elements to be adapted as new types of model elements and attributes. While a UML tool may be able to support useful diagrams, in the long-term users will suffer from a limited modeling capability.
There are three basic limitations: (1) the UML modeling elements were designed to represent the concepts of a software system design, (2) the graphical representations are not designed for most effective human understanding of the models, and (3) a UML tool does not provide the computational support for structural consistency and functional analysis.
One of the problems encountered in the design of a UML profile is the design baggage that restricts the use of UML elements. Design of a UML profile (a specialized language) requires deep knowledge of the design of UML in order to work around these restrictions. The result is a compromise that provides a less than ideal representation of the problem domain. The semantics of the profile are in the profile documentation and minds of the users. The tool only reflects the semantics of software design.
UML does not provide good quality graphical representations for modeling software, and this does not get any better for UML profiles. An excellent paper by Daniel L. Moody, "The Physics of Notation: Towards a Scientific Basis for Constructing Visual Notations in Software Engineering," refers to UML for examples of the ineffective use of graphical notation. Users should be able to quickly associate the graphical representation of a concept with its semantics. In many cases UML makes very limited use of visual variables, thus obscuring semantic distinctions, and in many cases combinations of these variables create complexity. For example, combinations of three visual variables (shape, brightness and texture) are used to distinguish 20 different types of relationships in a UML class diagram. In a UML profile, a text label is often used to identify a concept. Text requires less efficient, serial human interpretation (reading) while distinctions using graphical shapes are interpreted through parallel, image recognition. As a result, good graphics make it easier and faster for users to grasp the meaning of a diagram.
Perhaps the most important limitation of a UML profile is that the modeling tool does not provide computational support for structural consistency and functional analysis of the model. Enforcement of structural consistency of the model using a UML profile is based on consistency of UML software design models.
A good modeling tool will help the user develop a consistent and complete model. Furthermore, a robust tool will assist in the analysis and improvement of the model. For example, BPMN 2.0 (not a UML profile) defines a modeling language for specification of business processes. This includes modeling of executable processes and choreographies-interactions between participants supported by their executable internal processes. A good BPMN tool will support analysis of compliance of an internal process with the requirements of interactions specified by a choreography. A robust tool might also provide simulation capabilities to analyze the flow of business transactions.
These functional capabilities are not defined by the standard, but will be developed as differentiators by the modeling tool vendors. Addition of such functional capabilities for a UML profile would require implementation of functionality that may not be consistent with the use of the tool for generic UML. The resulting profile language would still not be the best representation and visualization of the problem domain.
The development of UML profiles may provide a quick and cheap solution to modeling new problem domains, but, in the long term, it provides less effective domain representation and visualizations, and it undermines the market incentives for development of functionality that improves modeling efficiency and the quality of results.