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.
See Also: ModernDinosaur