Hacker News new | past | comments | ask | show | jobs | submit login

First, I must say that the inventors of UML saw it as the last layer. The grand vision was a complete code generation from UML diagrams. And this was the overall grand vision that drove OO in general. I think that this is was happening now with the "low code" startups.

The whole idea is to separate the global decisions (which are hard to change) - e.g. architecture, what classes, what each class do, from the local one (e.g. which data structure to use). So you would use UML for the global decisions, and than make programming the classes almost mechanical.

Of course the customer do not see that. The customer see the user interface, and if the overall use cases are implemented correctly. Hence using those tool might help or not.

Lets take architecture for example, why do people use an architect ?. Why does architect needs diagrams? Will the owner care of the architect use diagrams?




Again, I am not asking how to use UML, or why the inventors of UML designed it in a certain way, or why it sounds like it could be a good idea, or whether there are other systems like UML that are good ideas (I can just use those systems directly then!).

I am asking what evidence there is that UML helps me deliver better products more efficiently. Are there successful software projects that do this complete code generation thing (and how do they compare to directly writing real code in more efficient programming languages with rich typesystems)? Are there development efforts where giving up and deciding that certain architectural elements are hard to change has been the right approach (in my experience it generally never is)? What are their names? Do they have experience reports? Are there numbers?

I am looking for, at the least, a specific name like "The Chrysler Comprehensive Compensation System took these approaches to development." (But hopefully not a massive and expensive failure like C3.)


So you would not find any. You would need to judge those tools based on your specific use cases.

Even if you find such and such project did X and got Y, the sample size is too small.

The issue with software is that each project is different, and hence we cannot generalise from any given project.


> The whole idea is to separate the global decisions (which are hard to change) - e.g. architecture, what classes, what each class do, from the local one (e.g. which data structure to use)

And this would be one of the reasons why UML is objectively a terrible idea for developing great software efficiently. (I assume it is ok for developing poor software at great cost)




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: