Broken, Not Bent
It’s one thing to “bend” the UML to express a design concept that you don’t know how to express with the language, but it’s another thing to “break” it outright. By “break“, I mean drawing old-school, ad-hoc, single-symbol diagrams that all look alike and passing them off as UML class, deployment, activity, etc, diagrams.
By propagating broken UML diagrams out into the world in a sincere, but fruitless, attempt to establish a shared understanding among team members, the exact opposite can occur – mass confusion and an error prone, friction-filled development effort. Even worse, presenting the ad-hoc quagmire to customers and financiers who have a rudimentary education in object orientation and UML can cause them to question the competence of the presenters and the wisdom of their investment choice.
But hey, there’s nothing to worry about. Nobody understands or cares about the UML anyway. Thus, the ambiguity, inconsistency, and conflicts inherent in the design won’t be exposed (or ever traced-back-to) if schedule and cost disaster strikes.
All models are wrong. Some, however, are useful. – George E. Box