UML: Aside - Completeness vs Clarity and other CvCs

- 3 minutes read - 619 words

One of the recurring issues I have experienced with UML, or more generally Model Driven Design is the continual struggle between definition and interpretation. One of the tenants of UML is to abstract upwards towards a level that avoids implementation specifics. However, this introduces the potential for a need of a “Leap of Faith”, something that was discussed my post UML: Modelling User Interfaces Part 1.

In tools that allow a complete forward driven Modelling approach (by this I mean where the model generates code for implementation) the gap between abstraction and implementation must be bridged, generally by propriety extensions, properties or mechanisms. Ignoring some of the practical issues, this seems to work counter to the benefit of the abstraction in the first place, putting a larger burden on the Modeller. However, a counter argument is that these additional decorators offer and capture the bridging formally and explicitly; this could be view as beneficial in comparison to implicit knowledge held withing a group. Whether the Model is the best place to document such information is a topic for another day.

Between Completeness and Clarity

The main issue I have with the described situation is the struggle between completeness and clarity. The forward driven Model must be complete in order to generate semantically correct code, however the clarity suffers as a result. Propriety bridging decorators by their nature fall outside the common UML specification and introduce a barrier to entry. If the model is to form the basis of communication between Stakeholder, Modeller and Implementer (even if there is and overlap in roles) then we begin a battle of priorities. I recently came across Martin Fowler’s article Is Design Dead and 10 years on I feel it is just as relevant to my experiences. The resounding theme for me is the issue of Comprehensiveness vs. Comprehensibly. Why invest large amounts of effort in the Model when one of the core aims, communication, suffers during the standard use case? The modelling activity can start to become a balancing act, which itself is an impediment to the main activity. In a loose Modelling scenario, as Martin suggests in his article we could approach balancing like this.

Don’t draw every class - only the important ones. For each class, don’t show every attribute and operation - only the important ones. Don’t draw sequence diagrams for all use cases and scenarios - only… you get the picture.

However, in the complete forward driven Model we cannot do that, everything must be specified, to the letter, in order to ensure syntactically and semantically correct code generation; comprehensiveness is king, there is no tradeoff.

Taking some cues from MVC, we could create alternate/additional views that articulate the model more clearly for the target audience but can that additional effort be justified? In my experience the additional effort does not offer value but that does not rule it out for others.

Summary

To summarise, UML Modelling provides a method to capture and communicate a solution to a problem or requirement, generally by introducing abstraction. The communication involves Stakeholder, Modeller and Implementor. The needs of these parties are different and can be at competition to each other. I encourage anyone involved in modelling to consider the “CvCs”

  1. Completeness vs. Clarity - Have you captured everything required in a clear manner? What are the definitions of “everything” and “clear”
  2. Correct vs. Contrived - Have you captured everything required, or just the parts that fit the approach, process or timescale constraint put upon you?
  3. Cathedral vs. Cloisters - Does the information stand out or is it squirreled away?
  4. Comprehensiveness vs. Comprehensibility - Can it answer the same questions as 1, when asked in an alternative way?

image courtesy of Wikipedia