Uml Fallacy

The fallacy of taking UnifiedModelingLanguage (UML) in the direction of ModelDrivenArchitecture (MDA) and executable diagrams is the idea that programming languages are hard because they look like code; and that if you make a language that looks like diagrams, it'll be easy. Cf. CobolFallacy. -- MatthewAstley

I'd say the CobolFallacy at least points in a better direction than the UmlFallacy. OO languages represent a move toward the semantic structure of natural language that goes beyond the surface similarity of COBOL.

I don't find OO particularly a close fit to natural language. Could you please clarify?

Problems with UML:

there must always be an associated specification in natural language without which diagrams can't be interpreted.
the semantics of the diagram are not easily extensible by composition of existing diagrams but require new natural language specification - unless you're an artist; extension of semantics in a text language is intrinsic: the lexicon of the natural language is directly available.

Use Case diagrams are an example of the above. The stick figure representing "Agent" may seem like a "natural" way to extend diagrams but it leads to ambiguity. And the arrows are really ambiguous. -- TomRossen

I have concluded that it is often bad form to say how software "should" be represented. Some prefer code, some diagrams, others tables (TableOrientedProgramming), and others like a mix. I think the BenefitsAreSubjective WRT which is better. If somebody claims they work faster/better using a diagram-based approach, who am I or you to tell them that is not true.