UML: Panacea or Malady?
Guillermo Camilo Torres Díaz
National University of San Agustín of Arequipa—Perú
Unified Modeling Language
Summary: We already know that the Unified Modeling Language (UML) is not perfect; but, how far does its imperfection go? This article tries to answer that question; by extracting the work of different investigators (who disclose and study defects in UML), it finds serious imperfections in the whole. In the end, it explains why either an improvement in the extensibility mechanisms of the language or—even better—the creation of a suite of modeling languages is necessary and urgent. (19 printed pages)
In the 1990s, UML  arises and becomes a landmark in the history of software development; its creation marks the beginning of an era in which methodologists, developers, investigators, and managers share (at least) the same design and work elements—the same vocabulary.
Despite that, in the beginning, it satisfies many necessities by providing constructions that are formal enough to be used in the development of different processes (especially those of software); and, although it is the de facto standard for the design of object-oriented (OO) systems  and the official standard of the Object Management Group (OMG), today, UML is insufficient.
In the next section, “Revision of Facts,” we review the history of the language. Then, in the “Classification” section, we explain the classification that will be used in a taxonomy of its flaws; in the “Divide for Defeat” section, they are all listed. We finish with the conclusions in the “Results and Conclusions” section, together with the respective considerations.
In its moment, UML arose like an answer—a natural reaction that the industry had in the face of the proliferation of many different methodological currents of software development in the 1980s and 1990s. In fact, in his revision of the OO methods, Ian Graham lists more than 50 of them —each one with its own language, iconography, colors, and even almost with its own hymn—without any one profiled as the best of them. Even Grady Booch mentions that UML was created specifically for acting like an integrative force that was unanimously adopted as the standard by OMG in November of 1997. “This language introduced a standard notation and fundamental semantics, so that its users could describe and communicate the software design like never before.” 
OMG defines UML as:
[A] visual language for the specification, construction, and documentation of the devices of systems. It is a language of general purpose that can be used with most of methods of objects and/or components, and in all the domains of applications (e.g., health, finances, telecommunications, aerospace) and implementation platforms (e.g., J2EE, .NET). 
Not all of its components are equally important, but all of them have deserved the same attention of OMG, which has approved new subversions with changes, or addition of them or their semantics, until arriving at version 2 (in its current subversion 2.2). This marks the fundamental beginning of a new face of the language, so much so that it is necessary to distinguish version 1.x from version 2, when mentioning it.
Table 1 shows the list of the diagrams of version 2.x and a semblance of its differences from version 1.x.
Table 1. Diagrams list, with their respective equivalences between UML versions
UML means different things for each of us. That’s why it could place many different classifications and taxonomies of its flaws—flaws by mistake or by omission—that each one will find in it. For this reason, I look for an intermediate point of view in which the graphic part and the semantics of the language are heeded, with simple approaches that help us describe and understand a flaw.
These approaches are expressed as a list of simple questions, in which the graveness of the flaw increases as the answer is positive, and as you advance in the questionnaire.
The questions are the following:
1. Is the flaw in a field or domain of general application?
2. Is the flaw manifested mostly in applications of academic domain?
3. Is the flaw manifested mostly in applications of commercial domain?
4. Does the flaw imply a lack in some aspect(s) that goes beyond just the graphic representation?
5. Do the proposals include the modification of one or more artifacts, or the creation of new diagrammatic elements?
6. Does the flaw imply an ambiguity or a lack in the semantic specification?
7. Do the proposals include the creation of one device or newer devices?
With the proposed approaches, an outline will be traced that allows for understanding how far the lacks or weaknesses of this language go. With this in mind, the next list proposes the lacks or weaknesses that stand out among the found research.
4.2.1. UML does not offer appropriate constructions for frameworks.
A framework is a collection of several complete or partially implemented components, with predefined patterns of cooperation among them. Consequently, some of the components are designed to be replaceable. These components are called variation points or hot spots of the framework.
An application that is based on certain framework does not reuse only its source code, but, more importantly, also its architecture design. The constructions that are provided by UML are not enough to assist in the framework development. There is no way (natural or explicit) in the design diagrams of UML to indicate the variation points or their instantiation constraints. 
OO frameworks acquired popularity in the software industry in the 1990s. Many were developed in commercial and academic domains, with very varied purposes and application fields. The frameworks, combined with the components, offer capacity of reuse at great scale more promissory then and now. 
If the frameworks have this potential, it becomes important to be able to describe them in an efficient, formal, and structured way, without their modularity and characteristic semantics drowned in constructions labeled “stereotype” all around.
Well, to answer the questionnaire:
1. Yes, the frameworks are already applied in a general way; there is no specialized and unique niche that uses them.
2. Yes, it is applied and taught in the academics sectors.
3. Yes, it is applied in the industry in general.
4. No, the frameworks are already considered in the language, but not in an appropriate way for their representation and explanation of a system architecture.
5. Yes, the solutions propose changes of the artifacts, especially the diagram of classes.
7. No, it just is contemplated to enrich the existing ones.
4.2.2. UML is not enough as a standard mechanism for interoperability of CASE tools to integrate applications of roundtrip engineering.
With UML, the CASE technology reached the following level of maturity: the consent in a common notation help to both vendors and developers, to concentrate on more outstanding matters that address in what way the arrows should be drawn or if we should represent classes like rectangles or clouds.
One of these more outstanding matters is the notion of roundtrip engineering. With this, a programmer generates code from the design diagrams, changes that code—when necessary—in a separate development environment, and has the capacity to re-create the design diagrams into a new adaptation from the source code. Likewise, the inverse road is also possible.
That OO development emphasizes in an iterative process, without doubt, makes roundtrip engineering an outstanding matter. Actually, because UML is guided specifically to the OO analysis and design, it lacks some concepts that are necessary to model the source code in an appropriate way—in particular, the concept of “invocation of method” or of “access to attribute.”
Of course, it is possible to extend UML to incorporate these concepts; but, then, the protection of the standard is abandoned and, with it, the needed reliability to reach this interoperability. 
Since the 1970s, being able to obtain the whole source code of a system from just its analysis and design diagrams has been a dream pursued by all developers, as well as a chimera offered by all vendors—though never completely carried out. Inclusively, with the same soul, Stephen Mellor et al.  proclaim to have solved the lack of semantics of UML in order to be able to develop tools that do not generate just an outline or frame of the source code, but the complete source code of any application that is modeled by using his language: xtUML, a derivative/subset of UML, complemented with the Object Constraint Language (OCL).
On a personal note, I don’t think it could be enough; OCL is a language to express restrictions—a declarative language, and not one that expresses action. One of the alternatives was also to complement it with the Object Action Language (OAL), but this is still in study.
Before we continue, let us understand that this interoperability issue is double edged. On one hand, UML itself does not cover the source code with much granularity; thus, any change in our models interoperates in it (the source code). Then again, any changes that we make in our source code will not be detected necessarily by our automation (CASE or pencil and paper) tool, to echo these changes in our models. On the other hand, though secondary, there is also a lack of interoperability among the different CASE tools:
(a) None of them covers the entirety of the language elements (less now than it has extended) and, (b) even covering the same area, they do not make it with the same level of detail. Also, although there are efforts in this sense, as the CASE Data Interchange Format (CDIF), MetaData Interchange Specification (MDIS), or the most recent (1999) proposed by OMG proper, Metadata Interchange Format (XMI), we cannot yet open a model that is made in one tool without losing some of the information by opening it in another—that if it could be, at least, loaded up.
Responding to the fact that the CASE tools can reach just a limited level in systems development, besides the high cost that the most sophisticated (and useful) ones have, the quantity of developers that use them is not very wide; therefore, there are not many of those who feel the lack that is described in this point.
To answer the questionnaire:
1. The CASE tools are not used so thoroughly that one can say that it is about a field of general use.
2. No; the CASE tools, though they are used, are not broadly used in the academic environment.
3. Yes; it is much the promotion that they receive in the industry, and several also are the companies that depend on them.
4. Yes; it is not a question that we lack an icon, but instead a complete other semantic level and some type of syntactic control of the constructions that we do.
5. Yes, the solutions propose changes to the current artifacts.
6. Yes; a great lack in such concepts as “access to attribute” or “method invocation,” among others.
7. Yes; not just new artifacts, but also new languages have been proposed with the desire of covering this topic.
4.2.3. UML does not allow keeping the outstanding information related to patterns. 
A design pattern describes a general solution to a design problem that happens repeatedly in many projects. Software designers adapt the solution from the pattern to their specific projects. Design patterns are usually modeling in UML. However, UML does not allow making pursuit of the information related to a pattern, when a design pattern is applied or is made up of other patterns. Thence, it is difficult for developers to identify design patterns in the models of software systems. The benefits of design patterns are jeopardized, because developers cannot communicate with each other, in terms of the patterns that they use or the design exchanges that they carry out (...), as the constructions that are offered by the standard are not enough to identify them in their applications and compositions.
The elements of the pattern—the classes, operations, and attributes in each pattern—generally play a role that is manifested in their names. However, the application of a pattern includes changing the names of the classes, operations, and attributes to terms that correspond to the domain of the application. Therefore, the information of the pattern’s role gets lost, and it quits being obvious what elements of the model participate in the pattern. UML does not allow making pursuit of the information related to the pattern, when a pattern is applied to a software system. 
We use the different design diagrams and charts of UML (or any other notation) to be able to see a system from different perspectives. The force of the visualization consists of providing us with an internal perspective of the complex relationships among the data that are more complex as the systems are bigger.
We must slice up the quantity of information with which we have to deal whenever we develop a system, to be able to choose the more outstanding slices. As Sigfried said, “It is not the number of details in itself that contributes to complexity, but the number of details we have to be attentive to at the same time.” 
We must be able to visualize the constructions that we use in the implementation of a certain system—even more, if it includes specialized constructions as the design patterns—so that, once they are identified, they can be discussed, reused, or replaced as it suits. We must be able to keep and indicate what pattern type we have used in a certain part of the buying subsystem, or if we have implemented a singleton instead of an abstract factory, for some justified reason, and how it has been applied.
These are examples of the types of valuation that we usually make, and of the design decisions and exchanges that we take as architects/developers and that we should be able to communicate with simplicity and integrity. If a diagram at first sight cannot indicate what patron we are using, or how just one class intervenes in more than one pattern, we probably will be forced to work in an extra way on our designs and, at least, supplement them with documents that explain our work to new colleagues or any investors—making the diagrams dependent on these extra documents and vice versa.
Because having more documentation is a luxury that is difficult to keep, maybe we should take the solution that the authors who point out this flaw implement  or some other similar one [12, 13]; although they are expensive in terms of space and development, they will help us at least appease our necessity to be explicit and simple at the same time.
To answer the questionnaire:
1. Yes, it is a field of general application more and more.
2. Yes, it is thoroughly an academic topic.
3. Yes, it is a field very promoted in the industry.
4. No; mainly, it is about capturing the relative information graphically to the patterns, to be able to take advantage of their solutions.
5. Yes, the artifacts would have to be enriched.
6. No; the patterns are included in the specification of the language, and each pattern owns documentation that is thoroughly made up in UML.
4.2.4. UML is not enough for the modeling of embedded and real-time systems. [15, 16]
Most of the technical complex systems—those that go from simple controllers of slow processes being executed in cheap processors, up to distributed systems that are built on dozens of powerful computers that control critical devices such as cars, airships, and nuclear-power plants—underlay in real-time computers to control and track their operations.
Throughout the years, several methods have been proposed for their analysis and development. Currently, there is a lot of interest in those OO ones, for their “natural” dimension in focusing the problems. Along with them, the election of UML is consolidated, as expression language for the modeling of this type of system.
However, the OO methods together with their expression languages originally are supposed to be focused on the description of the software inside the system and the interaction with external users (human), leaving aside the fact that the real-time systems interact primarily with a physical environment that controls or tracks, so much so that they are inseparable, and you cannot model the one without including the design of the other—besides the inclusion of physical laws, continuous values, differential equations, and variables of time, among others.
Given its category of standard, UML enjoys the benefit of being the expression language of the OO methods that the developers use in this type of system—even when, at first sight, it is not appropriate enough for modeling physical processes.
The two most important deficiencies of UML, from the perspective of an engineer of these systems, are the weak support to the flow of data and the difficulty for describing systems architectures. Even when these two areas are considered in the specification of the superstructure of UML 2.x, and they are also in the interest of hardware engineers, it is rational to think that the effective achievement of UML in these fields is feeble.
The engineers of systems [like these] often use the data flows to describe a general behavior and define key algorithms in the control systems. Currently, the only tool that they count on is the Activity Diagram, which implements a very small portion of the true data flow and is guided to the classes design, instead of to the global system one. They [the engineers of systems] are also often worried by the precise representation of the complex architecture of the total system, something for which the current Deployment Diagram is sadly appropriate. Thus:
[...] The areas that are not very specified in UML include:
-The exact semantics of passive and active objects.
-The relationship between passive objects and state machines.
-The selective nature of the type of the active object to call and to send actions (something that potentially violates the encapsulación principle).
[...] They would also have to consider the following characteristics to be included:
-Time and their derived -modes (ranges of the values of the variables).
The real system models embrace a study field that is complex enough to justify that they have their own space of concepts and definitions. Likewise, it needs an expressiveness that I don’t think can be reached with just the constructions of UML2.x. As opposed to UML 1.x, where only profiles can be created as a specialization way, with UML 2 has matured the capacity to develop domain-specific languages (DSL) that are extensions to the UML meta model.
This can represent an advantage for this model type; but it should be treated very carefully and by the light of UML, so as not to lose the protection of the standard.
To answer the questionnaire:
4.2.5. Currently, UML is insufficient to model agents and/or systems that are based on (multiple) agents. [17, 18]
The OO paradigm visualizes an application like a composition of objects that interact with each other, sending and receiving messages. The objects are contained in classes. Then, the relationships among classes can be captured in separate hierarchies. The objects are reactive entities, because they receive messages and react to external specific events.
The agent-oriented paradigm goes a step farther, seeing to the application made of one or more autonomous agents. All agents continually receive inputs. They respond to the environment in which they reside, taking actions that affect that environment. Then, the agents are proactive, evaluating situations, and behaving in the way that corresponds to those situations. The agents do not require messages of specific instructions in order to act.
The applications that currently are developed in agent-oriented technology include aerospace flaws diagnosis, administration of business processes, air-traffic administration, simulation of missions, and telecommunications administration [...].
Contrary to objects, the agents have goals and work proactively to reach them. On one hand, the procedures of objects are simply procedures, coded by a programmer, to deal with different messages [...]. On the other hand, an agent can synthesize plans to face contingencies not foreseen by the programmer, and it can learn from the experience [...].
After a complete investigation of the analysis techniques and OO design, it has been found that they are not directly applicable to the development of multi-agent systems.
Even more, some authors describe the multi-agent system as a special type of distributed system (objects with their own execution threads), with special characteristics where there exists a higher grade of complexity than OO systems; and this complexity is caused by the collective behavior of many simple agents that interact.  One aspect that stands out is the topic of the associations (semantics); that is, UML contemplates mainly binary relationships—leaving aside the n-ary relationships of behavior that the agents keep among each other and with the environment.
Although UML 2.x introduces important improvements that can be used for modeling this type of system—such as the parameterized collaborations, or the new modularity of the sequence diagrams, of state or of activity; and the solution proposals include new profiles [18, 20, 21] that sometimes warn (surprisingly) that they cannot be enough for their purpose —there are also bigger proposals, complete methodologies [24, 25] that have their own languages (inclusive, sometimes, based on UML) and specific languages for the exchange of information and modeling of the relationships among agents (that is, protocols [48, 49]) that try to cover all of the holes that this language leaves after itself in this field.
Well, to answer the questionnaire:
4.2.6. UML is not enough to develop aspect-oriented (AO) systems. [26, 27]
[...] The goal of a system is to satisfy requirements or, more generically, concerns (a concern is anything that is of interest to a stakeholder, whether an end user, project sponsor, or developer.
[...] Then, decomposing a problem into smaller separate modules1, it is part of what is called in computer science “separation of concerns.”
Ideally, we want to be able to separate the different concerns cleanly into modules of some kind, and explore and develop each in isolation, one at a time. Thereafter, we compose these software modules to yield the complete system. Thus, the concept of separation of concerns and the concept of modularity are two sides of a coin. However, there are certain concerns that existing techniques (for example, the orientation to the object, in general2) are not capable of modularizing.
The reason that these properties are difficult to keep in separate modules is that they affect (that is, cut across) a large number of other properties that compose the system. For that reason, they are known as crosscutting concerns, and they are manifested by producing (a) scattered code, when the implementation of a given property is not located in a single module and (b) tangled code, in which each module contains information about several distinct properties. So, the result is applications that are very difficult to understand, maintain, and evolve. Common examples of crosscutting concerns are some nonfunctional requirements, such as distribution and security.
The code that implements each of these properties cannot be encapsulated in a single class and, typically, is spread among several classes.
Aspect-oriented software development (AOSD) aims to address crosscutting concerns by providing means for their systematic identification, separation, representation, and composition.
Crosscutting concerns are encapsulated in separate modules, known as aspects, so that localization can be promoted. This results in better support for modularization, which in turn reduces development, maintenance, and evolution costs.
While AOSD has become a topic of important investigation in the last years, insufficient attention has been paid to the methods of evaluation of AO designs and their respective implementations. In general, the literature includes only some isolated cases of study that evaluate the implementations of AspectJ, which are focused in relative matters on the separation of concerns. This happens mainly because it is very difficult to evaluate multiple factors without a focus of systematic analysis and support tools. As a result, software engineers have assumed that the property that more affects the AO systems is the separation of concerns.
However, some recent studies [28, 29]5 have shown that other fundamental principles of software engineering must be appraised, together with this separation.
Even when these authors do not sentence explicitly—as do Yan Han et al. —that UML 2.x does not support the aspect-oriented modeling, they rather allow to see the reason for this: The general theory of the development OO, in the time of the birth of UML (and, barely, at the present time) was not arranged to solve these so-called crosscutting requirements (or concerns); ergo, UML thought only in terms of objects and components, still cannot offer expression elements to this new shade in the evolution of the general theory of the OO development.
This is reinforced by the fact that the solutions that the different authors offer to this situation go from (I have to mention it) extensions and profiles of UML to (and mainly) new languages [30, 31, 32, 33] that are based on the UML meta model. Of course, the fact that they are based on the same meta model of UML does not make them necessarily compatible with it.
And, to answer the questionnaire:
4.2.7. UML does not provide any support of the modeling of the graphical user interface (GUI). 
The user interface [UI] is a significant part of most applications; it should also be modeled by using UML. In fact, UML is a natural candidate notation for its modeling. However, there is no clear way of how to model UIs by using UML. 
...Although UML can be thought of as a quite complete modeling language, with several diagrams that can keep relationship, to describe the structure and behavior of an application in different levels of abstraction, very little attention has been paid to the necessities of interface developers. As a result, the intents of developing UIs in UML tend to challenge barriers against the natural expression of the characteristics of the interfaces. 
...The classic diagrams provided by UML, as the diagrams of classes or the state diagrams, are not enough to model all of the aspects of the hypermedia systems—for example, to model the navigational space and represent this model graphically. 
Even more generically:
The UML suite fails in modeling the human-computer interaction properly. 
UML is recognized as being the dominant modeling language in the software industry. However, its support for interactive systems is still recognized as insufficient. There is an erroneous common interpretation that the same models that are developed for the design of the internal elements of the application are adapted also for the design of the interaction, which makes the aspects of application usability more critical. 
The list of authors who accuse this lack in UML (inclusive the last version) in giving support to the modeling of the presentation (or of interaction) layer could be lengthening even more, but we will not find one who tries to explain the why of this onerous and unheard-of omission.
Because every program, however small it might be, depends direct or indirectly on the interaction with the user for it to work (even the simplest batch process starts as a consequence, at some point, of the interaction with the user), and because a system is an aggregate of programs, the interaction that it can have with users is made directly more outstanding.
The scene is darkened even more if we consider the playful applications (games) that represent an important sector in the software industry, and where the interaction with the user is not only important, but the most important thing.
In UML, there is not just a lack of appropriate constructions for the representation of visible structures of access to the information (that also can be sound and/or with movement) or of others that allow the use of the application services, but neither is there a way of abstracting the behavior that these very structures could convey and that goes beyond just the first visual reaction, nor of their link with processes that go from the validation of data to the invocation of instances and methods that belong to the underlying domain that is modeled.
Then, to model appropriately in UML, the interaction of the simpler and more well-known program “Hello, world” is just not possible, and it is left for us only to look for new artifacts, be they already created by third parties or by ourselves. Of course, it would not help to skip the standard.
To answer the questionnaire:
1. Yes, it is a topic or domain that is thoroughly treated.
2. Yes, of academic domain.
3. Yes, of commercial domain.
4. Yes, it goes beyond just the graphic aspect.
5. Yes, the proposed solutions modify artifacts.
6. Yes, there is a deep lack of appropriate constructions with their semantics.
7. Yes, the solutions propose several new and multicolored diagrams (or artifacts).
4.2.8. The class diagrams are less than ideal for the modeling of data. 
In a recent encounter of the New York Enterprise Modeling User Group (NYEMUG), an exhibition was carried out on the class diagrams of UML. The discussion was centered on an introduction to its structures. It was exposed how they are similar to or different from the structures of a model of ERwin.
Someone proposed the natural question: “Can the class diagrams be used to make the data modeling?” Without blinking, the presenter, a senior software engineer with Computer Associates (CA), exploded in laughter. The engineer, an expert in UML and one of the top designers of the Paradigm Plus UML tool of CA, did not have to say anything else on his feelings about using the class diagrams for the design of data.
[But it is necessary to recognize that] there have been efforts to make it. UML for Database Design (Addison-Wesley, 2001), by Eric J. Naiburg and Robert A. Maksimchuk3, offers a focus on this matter, but beyond the current confines of the class diagram. The extensions of UML that are suggested in this book are not official elements of UML and, therefore, not still part of any UML diagrammatic tool. 
More generally, next, Scot Becker shows us how the OO process, with UML-like fundamental work tool, makes perhaps a missed displacement of our attention of the work that should be carried out.
The class diagrams are used to express graphically the classes, their data structures (as members and/or dependent classes), and the encapsulated process that it acts on the data (the methods). Communication among the classes (roughly similar to the relationships of the data modeling) is expressed through the associations, while the subtypes are expressed through the inheritance.
From a pure data-oriented perspective, persistent class diagrams are roughly equivalent to Entity Relationship (ER) augmented with methods and multi-value attributes. In mapping persistent class diagrams to ER structures, we must account for other relationship types, such as the composition, aggregation, and dependencies.
The most obvious difference between a class diagram and an ER model is the use of all sorts of non-persistent classes, interfaces, dependencies, and methods. These elements are crucial to proper application design and implementation of the chosen architecture, but utterly irrelevant to proper data design. Because of their inherent detail, class diagrams seldom are fully detailed in the analysis phase. Thus, most of the specification of class diagrams is performed during the design phase.
Weaknesses of an OO Approach
The OO process typically lacks one important detail: persistence of the data. The data structures are, by definition, object oriented.
[...] However, if the target database-management system (DBMS) is a relational database-management system (RDBMS), as is presently the typical case, the mapping is not so straightforward. For this reason, the traditional data-modeling techniques of creating a Logical Data Model and Physical Data Model often are employed.
[...] As previously discussed, class diagrams, when abstracted down to the persistent data-storage layer, are little more than ER diagrams with behavior and multi-valued attributes. For this reason, they are subject to the same criticisms that previously were reserved for ER diagrams: lack of attribute-level rule specification, non-natural ways of expressing dependencies amongst data, tendency towards un-normalized schemas, inflexibility when it is time to change the system, and ease of introducing errors that are correct as far as the syntax is concerned. 
There are several solutions that have been outlined to deal with the modeling of the data layer—almost each one with different shades of the object orientation. They include profiles or DSLs outside of UML. But all of them forget some worthy details by the moment to consider a real solution to the problem of the data modeling:
1. We keep using use cases as primary instruments for the capture of processes and data, and these do not have yet a validation and/or verification way. Then, the use cases made vaguely are incomplete and not very useful; and the use cases over specified end up making implementation commitments that are precocious regarding the technology and premature, as they are documents that correspond to the analysis phase.
2. We usually finish with a class diagram that is translated to the DBMS with which we are working, and which almost every time is a relational one. (And, if not relational, we prefer to switch it into one, because the class diagram is very bundled to the relational model.) And, instead of putting the information to the user’s order in the user’s own terms, we finish forcing a vocabulary that is not always intelligible to the domain expert, and in which we demand that the expert have an exact knowledge—involving, once again, the underlying technology even before we finish the analysis phase of the first iteration (if we use an agile method).
3. We have to consider, as Terry Halpin  exposes, that the relational model that we advocate (whether consciously or not) uses attributes that inherently are unstable; it requires additional ways to specify restrictions (one for attributes and another for relationships); it tends to consider/switch all of the relationships into binary ones, introducing non-natural ways of domain description and artificial elements/entities to fill up its own holes; and the ER models are little auto-explicit for most people.
Fortunately, this situation is not terminal. There are proposals such as the object role modeling (ORM)4 that, though nothing new (it has been present since the 1970s), seem to bring new blood when looking for new leaders in our battle with the problem that supposes that we lack data-modeling structures that are efficient, verifiable, methodical, and with automation-tool support.
To answer the questionnaire:
4.2.9. The UML specification, in general, is semiformal. This lack of precise semantics can lead to severe problems, as different or ambiguous interpretations. 
Isn’t it serious that a language that is supposed to help developers and/or designers to express the bowels of a software application does not have a syntactic vocabulary that might be integral? Dave Thomas tries to explain to us what happened:
UML found an ideal home at OMG. The language seemed so simple that there was no need to worry if there were already working implementations. [Because] it was clearly defined in pictures and familiar concepts, no semantic account was required.
It all seemed so innocent, simple, obvious: Standardize OO modeling notations, so that methodologists and developers would not have to fight with each other over which symbol should stand for a class, a method, etc. Most of us gave a sigh of relief that such a stupid and ill-considered debate about notation was over, and few of us worried about whether we had in fact found the right answer. 
But OMG has realized this lack, and it has looked for covering it; the clearest resolving intent is the Object Constraint Language (OCL) , which complements UML since version 1.4 and consists of a formal language to describe restrictions and (mainly since version 2.0) queries, too.
Though, in my personal view, taking account that it is a predicates and declarative language, I don’t find its use to describe operations very clear.
And, actually, there are people such as Luis Reynoso et al.  who have made experiments; they have made statistics to prove that it is not a clear language, not even to describe restrictions (its initial objective), and that also presents problems regarding learning ease and compressibility—yet another pimple in the flatness of the general semantics of UML.
What teamwork can we expect, if the team does not know or does not understand well the tools on which it counts? Does this not imply a new set of minimum abilities that are required for a developer or designer? Does it not take us away from the concept of having a language that, although complete, is also simple?
In the specification document [4, 5], the constructions of UML include a section that is titled “Semantics” that just does not complete its task of explaining the meaning and use of each construction, or it is very vague in making it. For example, for a note or comment (the small square that has one of its top corners folded), their “Semantics” section says, literally:
Semantics: A comment does not add any semantics to the elements, but it can represent useful information for the reader of the model. 
If we meditate on this and look for the effective use that it has, we will see that:
· Whenever there has been something that an interaction (or any other) diagram cannot express, a note is used.
· Before the diagram of activities had had a way of expressing loops or optional sections, these were indicated with a note.
· If we need to include a type of special value for some class, we did use—and we do use—a note.
· And many, many other cases.
The note or comment is the most flexible construction of all, and it is so important the semantics that bears that it quits having that almost optional character—which is received from the specification—as their presence or absence can determine the way that two developers understand the same model.
For this reason, I don’t think that a more powerful semantic construction exists—in total, as opposed to what the official document says.
And, to answer the questionnaire:
In the Classification section, approaches are proposed to help us understand the flaws in UML according to the symptomatology that they provoke and the graveness of this. These approaches are expressed through simple questions, in which the graveness of the lack increases as you advance in the questionnaire, and in which an affirmative answer is more serious than a negative.
Table 2 summarizes and assigns the positive answers to each imperfection, according to what was exposed:
Table 2. Summary of the UML flaws
Each “Yes” has been changed to an “X” and a new column has been added, with the sum of Xs by line (the more Xs, the graver the lack). Then, the resulting table has been reordered, based on this new column, to obtain Table 3:
Table 3. Summary of the UML flaws, ordered by graveness
Before we advance and reach any conclusion, note that it is NOT considering ALL the critics that the unified language has received—only those that have been better argued (by more than one author) or that are very obvious.
1. Most flaws affect aspects that are of general application; that is to say, they appear in daily or common tasks in the system life cycle of any system. This implies that the language, although not for all, is insufficient for the common modeling tasks.
Issues such as the database modeling or UI are issues in all applications; the patterns usage is more and more generic, and we can say even that their management is already a requirement for the current developer.
A flaw in a general field carries in itself a bigger urgency to be attended, as its solution is necessary under all sides and conditions.
2. All flaws begin to make havoc in an academic domain and then move to the commercial one. What is today a prototype error is tomorrow a problem in the industry.
3. Most flaws go beyond a simple diagrammatic issue, and usually imply the modification of some of the artifacts of the language and/or the creation of new elements and their respective definitions. This fact reflects an incomplete group of diagrammatic elements, in which the group includes the visual elements and their corresponding semantic ones.
4. The flaws that are not of general fields or domains always modify the existing artifacts; but, even more, they cause the creation of new artifacts and generally new sublanguages, profiles, or DSLs.
There are flaws by omission or lacks in the language that never could be resolved, in the soul of maintaining it like a tool of generic application. However, also, there are non-general domains that must be assisted with a standard specification, though not generic. They are fields like the intelligent agents or the real systems (among others) that provoke generating new specifications, and they bring us to the problem that originally gave place to UML: an explosion of competitive languages, where none is profiled as better than another one, but whose abundance generates a delay and an unnecessary heterogeneity in the industry.
5. In conclusion, although the last version of the unified language has had the intention of covering all the flaws of the previous ones (1.x)—and thus has increased for many the complexity of the language—this one continues to be incomplete, and more and more far away from being an effective but simple tool.
In fact, this is the biggest dilemma that UML faces: being able to be simple and complete at the same time, able to assist the developer who uses it only as an outline tool, the same the one who wants to execute it directly from the model.
Then, its only chance would be to reinforce or increase its mechanisms of extensibility and/or flexibility; and, at the same time, to restructure its semantics and create a complete syntactic rule set for the use of each one of its constructions.
Another complementary and viable proposal would be to form a group of unified languages, a frame of frames, in which UML could be just an integrant and not the panacea that currently it is sought to be—a suite of languages in which all of them share most constructions and, later, can be separated by the specialization or the software-engineering area that each one has as an objective to assist.
The engineering and software industries are entering the state of uncertainty of the ‘80s–‘90s, the same as before the official emergence of UML, which blinds us a little to the development or stagnation that the future affords us. However, I believe that the time has not passed pointlessly, and that we will repair our previous errors and witness the result of a community effort—either a new language (maybe UML 3, maybe OML 2 ) or instead a range of languages that, although they be siblings, have their own specialty. In the end, this way, we can say that, indeed, we have evolved speaking in a technological and humanly way.
Be this way.
1. In the sense of the text, modularization is the encapsulación of the realization of any of the concerns/requirements, indistinctly through a class, component, or subsystem.
2. This is just an example of the techniques that are mentioned, which only by reading the whole text can one deduce, and which, for reasons of space, I don’t include.
3. The ironic note is that the book to which Ben Ettlinger refers it is not considered a good one, according to the record in http://www.accu.org/bookreviews/public/reviews/u/u003393.htm, where they qualify it as NOT RECOMMENDED. Though, undoubtedly, it is not the only one and, yes, there are other works that are indeed excellent in the topic of using UML as data notation. For example:
· “Object Relational Wrappers” (Lee Fesperman)
· “The UML and Data Modeling” (Rational Software)
· “Mapping Objects to Relational Databases” (Scott W. Ambler)
· “Expressiveness in Conceptual Data Modeling” (A. H. M. Ter Hofstede and Th. P. Van Der Weide)
4. The best place for resources on this topic can be found at http://www.orm.net.
5. References made by the author.
 The Object Management Group (OMG). “Unified Modeling Language (UML).” www.omg.org
 Baumeister, Hubert, Nora Kock, and Luis Mandel. “Towards a UML Extension for Hypermedia Design.” Proceedings of UML ’99, 1999.
 Booch, Grady, IBM Fellow. “The Fever Is Real.” ACM Queue, Volume 2, No 1, March 2004. (www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=131)
 OMG. “Unified Modeling Language (UML) Specification: Infrastructure Version 2.0.” www.omg.org
 OMG. “Unified Modeling Language (UML) Specification: Superstructure Version 2.0.” www.omg.org
 Fontoura, Marcus (Department of Computer Science, Princeton University), Wolfgang Pree (C. Doppler Lab for Software Research, University of Constance, Germany), and Bernhard Rumpe (Software Systems Engineering, Munich University of Technology, Germany). “UML-F: A Modeling Language for Object-Oriented Frameworks.” 2000. (Extract)
 Hamu, D., and M. Fayad. “Achieving Bottom-Line Improvements with Enterprise Frameworks.” Communications of the ACM, Volume 41, Issue 8, August 1998.
 Demeyer, Serye, Stéphane Ducasse, and Sander Tichelaar (Software Composition Group, University of Berne). “Why FAMIX and Not UML?” 1999. (Extract)
 Graham, Ian, Alan O’Callaghan, and Alan Cameron Wills. Object-Oriented Methods: Principles and Practice. Third edition. Harlow, England; New York: Addison-Wesley, 2001.
 Dong, Jing, and Sheng Yang (School of Engineering and Computer Science, University of Texas). “Extending UML to Visualize Design Patterns in Class Diagrams.” 2003.
 Mellor, Stephen J., and Marc J. Balcer. Executable UML: A Foundation for Model-Driven Architecture. Boston; San Francisco; New York: Addison-Wesley, 2002.
 Schauer, Reinhard, and Rudolf K. Keller (Département IRO, Université de Montréal). “Pattern Visualization for Software Comprehension.” Proceedings of Sixth International Workshop on Program Comprehension (IWPC ’98), June 24-26, 1998.
 Fontoura, Marcus, and Carlos Lucena (Software Engineering Laboratory, Computer Science Department, Pontifical Catholic University of Rio de Janeiro). “Extending UML to Improve the Representation of Design Patterns.” 2001.
 Sigfried, Stefan. Understanding Object-Oriented Software Engineering: A Practical Approach. Piscataway, NJ: IEEE Press, 1996.
 Axelsson, Jakob (Volvo Technological Development Corporation). “Real-World Modeling in UML.” Proceedings of Thirteenth International Conference on Software and Systems Engineering and their Applications, 2000.
 Moore, Alan, Vice President of Product Strategy (ARTiSAN Software Tools, Inc.). “The (Continuing) Evolution of UML for Real-Time Systems Development.” 2001. (White paper)
 Odell, James (James Odell Associates), H.Van Dyke Parunak (ERIM Center for Elec. Commerce), and Bernhard Bauer (Siemens ZT IK 6). “Extending UML for Agents.” 2000. (White paper)
 Zeid, Amir (Department of Computer Science, American University in Cairo). “A UML Extension for Agent-Oriented Analysis and Design.” 2002. (White paper)
 Odell, James. “Agents and Complex Systems.” Journal of Object Technology, July–August 2002.
 Kang, Miao (School of Computing, Leeds Metropolitan University), and Lan Wang and Kenji Taguchi (Department of Computing, School of Informatics, University of Bradford). “Modeling Mobile Agent Applications in UML 2.0 Activity Diagrams.” 2004.
 Lind, Jürgen. “Specifying Agent Interaction Protocols with Standard UML.” Unterhaching, Germany. Proceedings of Second International Workshop on Agent-Oriented Software Engineering (AOSE), Montréal (Canada), 2001.
 OPEN Consortium. “OPEN Modeling Language (OML).” http://www.csse.swin.edu.au/cotar/OPEN/omlrm.html
 FIPA Agent UML Web site. “Agent UML.” http://www.auml.org/ (Last updated June 2007)
 Miles, Simon, Mike Joy, and Michael Luck (Department of Computer Science, University of Warwick). “Designing Agent-Oriented Systems by Analyzing Agent Interactions.” Proceedings of First International Workshop on Agent-Oriented Software Engineering (AOSE-2000), 22nd International Conference on Software Engineering, 2000.
 Castro, Jaelson (Universidade Federal de Pernambuco, Recife PE, Brasil), and Manuel Kolp and John Mylopoulos (University of Toronto, Department of Computer Science, Toronto, Canada). “Developing Agent-Oriented Information Systems for the Enterprise.” Proceedings of Second International Conference on Enterprise Information Systems, Stafford, UK, July 4–7, 2000.
 Jacobson, Ivar, and Pan-Wei Ng. “How to Address Crosscutting Concerns in Aspect-Oriented Software Development.” Aspect-Oriented Software Development with Use Cases. Upper Saddle River, NJ: Addison-Wesley Professional, 2005.
 Brito, Isabel (Escola Superior de Tecnologia e Gestão, Instituto Politécnico de Beja Beja, Portugal). “Aspect-Oriented Requirements Engineering.” 2004.
 Garcia, Alessandro, et al. “Modularizing Design Patterns with Aspects: A Quantitative Study.” Proceedings of AOSD’05 Chicago, IL (USA), 2005.
 Garcia, Alessandro, et al. “Separation of Concerns in Multi-Agent Systems: An Empirical Study.” Software Engineering for Multi-Agent Systems II. LNCS 2940/2004. Berlin; Heidelberg: Springer, 2004.
 Yan, Han (Nanjing University of Science and Technology), and Günter Kniesel and Armin B. Cremers (University of Bonn). “Towards Visual AspectJ by a Meta Model and Modeling Notation.” Proceedings of Sixth International Workshop on Aspect-Oriented Modeling, 2005.
 Havinga, Wilke, Tom Staijen, Arend Rensink, Lodewijk Bergmans, and Klaas van den Berg (University of Twente, Holland). “An Abstract Metamodel for Aspect Languages.” Workshop on Open and Dynamic Aspect Languages, Bonn, Germany, March 2006.
 Chavez, Christina, and Carlos Lucena. “A Metamodel for Aspect-Oriented Modeling.” Workshop on Aspect-Oriented Modeling with UML at AOSD2002, Enschede, Holland, April 2002.
 Reina, A. M., and J. Torres (Languages and Computer Systems Department, University of Seville). “Weaving AspectJ Aspects by Means of Transformations.” 2005.
 Blankenhorn, Kai. “A UML Profile for GUI Layout.” Master’s Thesis, Department of Digital Media, University of Applied Sciences, Furtwangen, May 2004.
 Pinheiro da Silva, Paulo, and Norman W. Paton (Department of Computer Science, University of Manchester). “User Interface Modelling with UML.” 2000. (White paper)
 Greco de Paula, Maíra, Simone D.J. Barbosa, and Carlos José P. de Lucena (Departamento de Informática, PUC-Rio, Rio de Janeiro, Brasil). “Relating Human-Computer Interaction and Software Engineering Concerns: Towards Extending UML Through an Interaction Modeling Language.” 2003.
 Jardim Nunes, Nuno (Universidade da Madeira, Unidade de Ciências da Computação, Dep. de Matemática, Portugal), and João Falcão e Cunha (Universidade do Porto, GEIN Faculdade de Engenharia, Portugal). “Towards a UML Profile for Interaction Design: The Wisdom Approach.” Proceedings of Unified Modeling Language Conference, UML, 2000.
 Pinheiro da Silva Paulo, and Norman W. Paton (Department of Computer Science, University of Manchester). “A UML-Based Design Environment for Interactive Applications.” Second International Workshop on User Interfaces to Data Intensive Systems (UIDIS'01), 2001.
 Baumeister, Hubert (Institut für Informatik, Ludwig-Maximilans-Universität, München), Nora Koch (Institut für Informatik, Ludwig-Maximilans-Universität, Forschungsinstitut für Angewandte Software Technologie, München), and Luis Mandel (Forschungsinstitut für Angewandte Software Technologie, München). “Towards a UML Extension for Hypermedia Design.” «UML» ’99—The Unified Modeling Language. LNCS 1723/1999. Berlin; Heidelberg: Springer, 1999.
 Dr. Halpin, Terry, Director of Database Strategy (Visio Corporation). “Entity Relationship Modeling from an ORM Perspective: Part 1.” 1999. (White paper)
 Ettlinger, Ben. “The Future of Data Modeling.” DM Review, March 2002.
 Becker, Scot A. “Conceptual Data Modeling in an Object-Oriented Process (Part One).” InConcept, Copyright, 1998–2004.
 Ross, R.G. (Database Research Group Inc.). “Modeling for Data and Business Rules: An Interview with Terry Halpin.” Database Newsletter, vol. 25, no. 5, September/October 1997.
 Cibrán, María Agustina, Vanesa Mola, Claudia Pons, and Wanda Marina Russo (Universidad Nacional de La Plata, La Plata, Buenos Aires, Argentina). “Building a Bridge Between the Syntax and Semantics of UML Collaborations.” In ECOOP 2000 Workshop on Defining Precise Semantics for UML, 2000.
 Thomas, Dave (Bedarra Corp., Carleton University, and University of Queensland). “UML: Unified or Universal Modeling Language?” Journal of Object Technology, vol. 2, no. 1, January-February 2003, 7–12.
 OMG. “Object Constraint Language (OCL).” www.omg.org
 Reynoso, L. (Universidad Nacional del Sur, Argentina), M. Genero (Universidad Nacional del Sur, Argentina), M. Piattini (Universidad Politécnica de Madrid), E. Manso (Universidad de Valladolid, España). “Un análisis experimental sobre el efecto del acoplamiento en la comprensibilidad y facilidad de modificación de expresiones OCL” (“The Effect of Coupling on Understanding and Modifying OCL Expressions: An Experimental Analysis”). Latin America Transactions, IEEE (Revista IEEE América Latina), Volume 4, Issue 2, April 2006, 62–67.
 Artikis, Alexander, Jemery Pitt, and Christos Stergiou (Intelligent & Interactive Systems Group, Department of Electrical & Electronic Engineering, Imperial College of Science, Technology and Medicine, London). “Agent Communication Transfer Protocol.” Proceedings of Fourth International Conference on Autonomous Agents, Barcelona, 2000.
 X-SS Project Web Site. “X-SS Protocol: eXtensible Social System Communication Protocol.” 2002. http://www.x-ss.org/