UML suffers from all of the same flaws that most graphical / non-textual programming environments do: 1) Not expressive enough - Most graphical programming en

UML suffers from all of the same flaws that most graphical / non-textual programming environments do: 1) Not expressive enough - Most graphical programming environments, UML included, are not as expressive as the programming languages that they are being used for. Most graphical systems will need to be converted into a text-based programming language or some kind of code generation performed to create code that can be compiled. Frequently, the resulting code will be missing details or nuance that could not be represented in the graphical system and will need to be added. Should the slightly altered code become the new "source of truth"? Does the system have some kind of "side car" system so that future generated code with include some additional changes? (Sometimes called "round tripping".) 2) Inherent difficulty with version control and diffing changes - In most graphical programming environments, it is difficult to work with version control systems and show diffs. It is difficult to visually see differences in large, complex graphs compared to side-by-side diffs in text. 3) Poor organization / composability - Most graphical programming environments do not have a good way to organize the graphs in composable ways. Many will try to do automatic layouts of the graphs, but usually you still end up with large spaghetti networks of connectors between different program elements. 4) Typically proprietary and expensive with high vendor lock-in potential - most graphical programming environments are proprietary and rely on expensive tooling. UML or another graphical environment might be used to design the system, but the environment is specific to the vendor and does not follow open standards because few standards exist and those that do are underspecified.