| UML is a tool like any other: one should understand the tradeoffs and make an objective decision as to whether it is useful and appropriate for a specific organization and scenario. Specification has a fundamental tension between clarity and completeness. I don't believe it is possible to maximize both. As a specification becomes more specific, rigorous, and 'correct', it diminishes in understandability, due to the limits of our working memory. As a specification diminishes in clarity, it loses appeal with most audiences. See also the rise of JSON in reaction to XML. This is the key tradeoff with UML. If the ultimate goal is to model a system, with platform-independence, at a level of detail sufficient to enable code generation, the specification and model representation will become complex, and the friction and overhead become too great for a typical corporate internal or external product, thus limiting the specification tool's adoption. The tool is no less valid, and can be useful for high-criticality areas, such as aerospace, or for academic exercises. One should objectively analyze the tangible and intangible costs of UML against benefits and use something else if it provides a better outcome. Perhaps a 'UML-lite' approach, such as C4 [1] or PlantUML [2], is a better tradeoff on the completeness-clarity continuum for a given scenario. Another interesting modeling framework is 'Object Process Methodology' (OPM) by Dov Dori [3]. The two aspects of OPM that stand out to me: 1. A focus on the model alone, maintaining understandability, and an effort to keep things simple. Information hiding techniques such as zooming are provided as a means to manage system complexity during the modeling process. 2. Instead of an ultimate promise to allow bidirectional translation from model to code, and code to model, the visual OPM representation has a textual counterpart, 'Object-Process Language' (OPL). With this facility one can translate from model to descriptive text, and vice-versa. Thus, one may read or define a model visually in diagram form, or as a series of sentences using a minimized set of English words that is also machine parseable. Still we must recognize the tradeoffs: OPM may provide more clarity, but has less completeness. It won't round-trip with a code base, and it lacks modeling capabilities that can descend into an operation/process, e.g. one cannot model control flow concepts such as sequences, branches, loops, etc. Within the UML garden, concrete operation implementation can be specified in OCL, and the newer fUML can, in theory, reach down even further into operation specification. [1] https://plantuml.com/
[2] https://en.wikipedia.org/wiki/C4_model
[3] https://en.wikipedia.org/wiki/Object_Process_Methodology |