A quick search on Google Trends shows how the hype on UML has been decreased steadily since 2004. This trend appears to be stabilized nowadays on a pace of less than 20% the searches per month of what it was at its peak of maximum popularity. Several reasons can explain this situation, and not all are necessarily bad (e.g. the broad acceptance of the language, more well-known resources available, more training, reduced needs to look for basic information on Google).
In this post, however, I don’t want to comment every possible reasons behind the data. I prefer to delve into what I consider a common pitfall applying software modeling: treating at the same level the notation and the design (the language vs. the subject matter expressed by the language). To which extent any consideration about the language can be applied to the modeled subject? For example, is the apparent UML crisis a symptom of a more diffused crisis (i.e. the OO design crisis)? Are there any relationships between the trends concerning the UML adoption and the adoption of the OO software development practices? These questions, in my opinion, cannot be answered without addressing in the first place the context in which the modeling notation is used, and the goal adopters state in using the notation. In my experience as a consultant, the mere adoption of UML do not intrinsically introduce a better level of quality in a project, nor it increases the speed of development. Only when the use of UML adds value to the design process, then we have a substantial (not merely formal) adoption of the modeling language. What is, then, the difference between a mere adoption and a substantial one?
A typical case of mere adoption is when the UML is used “post-mortem”, e.g reverse engineering a product in order to produce a documentation for the sole act of documenting. If you are thinking about the need to comply a process certification, you know what I mean. A first evidence that UML is not really integrated in the team-thinking is the lacking of explicit goals satisfied by the models. Why a specific model exists? Which is its audience? Which is its scope and its expected obsolescence? What elements affects the model obsolescence? In which ways the designers handle the durability qualities? How the model is exploited in the development process? In which activities? And finally (but not less important), which are the strategic goals inherent to the explicit modeling activity? Answering such questions can address the above mentioned “substantial” value provided by the UML. This value is not intrinsically tied to the UML syntax. It is more subjected to the modeling goals and the way the notation is used to satisfy them.
There is not a single, unique, standard way to exploit UML in a software project. Even the parts of UML that are more useful in one context change in another one. Indeed they are often subjected to experience, specific needs, internal culture, and so on. But in all cases a software model without a clear concrete goal to achieve is only a mere drawing without too much value. Then, one more time again, the first thing to do when adopting UML in a project is to identify the general goals and their strategic value that justify the creation of graphical model in the first place. The second thing is to refine such goals at the level of every single diagram. The intentions of the modelers need to be clearly conveyed in order to facilitate the audience in the overall understanding. This advice can be exploited, for example, adding a mission statement in each diagram.
Another aspect to consider when we delve with graphical models is the different layers of interpretation that can be addressed by a visual notation such as UML. A good understanding of such layers is essential because many modeling goals are specific of a particular layer. Consider the common misunderstanding rooted on the belief that a “good” CASE tool capable of generating UML diagrams is all that suffice to create software models and, eventually, adopt UML in an organization. Usually, this is not the case. To understand why, we need to consider what a model – and in particular a visual model – conveys.
At a first level, a model expresses concepts in a (semi)formal setting. This level is foundational because provides both the (graphical) notation and its (in)formal semantics. Because semantics is somewhat tied to the notation, I refer to this level simply as the Notation layer. (I assume here the perspective of the UML model user; if I would like to assume the perspective of tools builders, I should separate notation and semantics in two distinct layers). Every UML model compliant to the well-formed rules of the UML meta-model (OCL constraints included!) is interpreted in this layer.
One level above, there is the Aesthetics Layer. Here visual models adopt aesthetic conventions such as clustering hierarchies, avoiding crossed lines, depicting inheritance relationships upward, in order to facilitate the grasping of important parts of the model. Aesthetics, if adequately used, helps the comprehension of a diagram.
Aesthetics combined with Notation forms the foundation for using models as a communication tool. I refer to this latter level as the Communication Layer. These modeling layers are additive. Aesthetics is applied to notation; communication involve both notation rules and aesthetics conventions.
These layers affect also the intended audience of a model. There are two different broad recipients for a model: human beings and machines. Visual languages are a natural medium for communicating information, ideas, concepts in a succinct way; from this point of view, visual models are better suited for humans than code, especially at large scales. Moreover, communication is of paramount importance for software modeling (why we need to depict graphical models at all, if this practice doesn’t add something not immediately obvious from the other artifacts such as the code?). Unfortunately, many modeling efforts seems to lack this important layer. Models seem to survive only at a notational level. This is the level of the CASE tools, where a model is checked against well-formed (syntactic) rules. If we consider the model as the repository of some sort of strategic (business) knowledge, the model itself must be designed purposely, beyond the fulfillment of syntactic rules.
Every architect should work carefully at the communication layer. The diagram mission must be stated in order to represent the goal, the intent, the purpose of the diagram. The mission is the “information payload” the model should convey to its readers. If the diagram is not intention-revealing, the diagram fails at the communication level. Where is the value of the modeling effort, if the communication is poorly conveyed? Creating intention-revealing diagrams is what I call designing intentionally. This means more than simply add a textual annotation (mission statement) to a diagram: it involves conveying the right information in the right place, as discussed before,exploiting all the three modeling interpretation layers. The designer should know, for example, how to adapt aesthetics in the same way he knows which part of the notation can effectively express a particular concept. In future posts, I will show how modeling intentionally can affect the way to address each modeling layer.