Comment by agumonkey
5 years ago
The thing is I found quite paradoxical (to stay polite) that you'd spend time drafting something that is not precise, not data to help you but just a document in a tool.
The model driven thing was nice but it was never good enough to actually help with code. It was also deeply rooted in the crippled Java days so full of verbose diagram representing overly verbose classes.
To hyperbole a bit, I'd rather spend time writing property based tests and a few types in haskell in a way.
There can be a stage between "I have kind of an idea of what this is supposed to be" and "I'm ready to code this", where you think carefully about what this thing is actually supposed to be, and how it's supposed to behave and interact. It's not amiss to think for a bit before creating the code.
I'd rather spend some time making sure I'm building the right thing, rather than testing that what I built correctly does the wrong thing.
On the other hand, if you want to argue that UML is not the optimal way to do that, you could make a case. It makes you think through some questions, but those may not be the only questions, and there may be other ways of thinking through those areas than drawing diagrams.
And if you want to iterate your designs, UML is a painful way to do so. You'd want to design in some other medium that is easier to change. (Maybe something text based?) But if you're thinking through all the design issues in another medium, and iterating the design in that other medium, then why produce the UML at the end? To communicate the design to other people - that's the point of UML. But if you can communicate the design better using something else (like maybe the medium you actually design in), then why produce the UML?
That assumes that before you have a thing in your hand (a working program with expected input, and output), you can exactly describe how that thing should act, what it should look like, what the input and output should be (and not be) and have that be successful - and structured correctly internally the first time.
In my 25ish years of experience writing code? That has happened for a non trivial task exactly zero times.
If the idea is you could refactor the UML (and hence generated code) to adjust, since none of the tools are able to generate functional code (stubs and simple templates yes, but not much more than that), that means it would need to refactor a bunch of human manipulated and generated code without breaking it. Which I think is well beyond even our current capabilities.
It's weird to read this because building's architects and designers do exactly that: they have to make tremendous efforts to design complex systems (think an airport or a hospital) before they lay down a single brick. Somehow this idealization and planning step is impossible for software developers.
20 replies →
Enterprise UML modelling tools certainly allow for complete development not only stubs.
> You'd want to design in some other medium
That's why I really like PlantUML [1].
It generates UML diagrams from a simple text markup language.
Much quicker to iterate on, easy to put into a repo and share or collaborate.
Still not something you would use to design your whole code structure, but great for brainstorming or drafting once you internalized the language a bit.
[1] https://plantuml.com/
Completely agree with this sentiment: Don't include every detail in your UML, but use it instead to straighten out your high-level ideas. PlanUML is also my go-to for this.
1 reply →
> > To hyperbole a bit, I'd rather spend time writing property based tests and a few types in haskell in a way.
> I'd rather spend some time making sure I'm building the right thing, rather than testing that what I built correctly does the wrong thing.
I don't believe the GP was saying to use tests instead of planning. They were saying to use the tests as planning.
They called out property-based testing in which you describe behavior of the system as a set of rules, such as `f(x) % 2 == 0`, and the test harness tests many inputs trying to find the simplest example that fails that criteria.
They also called out defining types (in their chosen language, not a step removed in a UML diagram), which allows you to think about how the data is shaped before you write an implementation that forces a shape.
I agree completely with your first two paragraphs, but UML, in my opinion, failed to support that approach. Its primary failure is that it neither captured nor communicated the rationale behind the requirements, the answers to "why this?", "why this, instead of that?" and "is this right? is it sufficient?" Answering these sorts of question is central to the production of requirements and also to understanding them, but with UML these questions and their answers are treated like scaffolding, taken away from the result before its delivery.
One might argue that UML could support the capture of such information, but what matters is that this rarely, if ever, was done. It is not the sort of information suited to being presented diagrammatically, or at least not by the sort of diagrams that made it into UML.
One might also argue that no other requirements specification method centered on these features has made it into mainstream software development. Some people here, for example, have argued that the code is a statement of requirements, and code also lacks these features. It does not follow, however, that therefore UML should have succeeded.
Ultimately, UML was an added layer offering insufficient benefits to justify its costs. Its benefits were insufficient because it was predicated on the false assumption that requirements can be adequately captured by a sufficient number of simple declarative statements about how things must be, and that the process of specifying requirements is primarily a matter of making such statements.
It certainly isn't the optimal way. Imagine the UML for a metaclass that creates classes, or for composition/trait based object definitions.
The good UML diagrams are sequence and maybe use case.
Why would you ever not want to iterate your design? Doing is the fastest way of learning. The details can drive a design, so that if you don't remove all ambiguity, you will create an architecture that won't actually work. The problem people who just jump in face, is that they do not abandon their bad prototype and begin again, instead clinging to faulty architecture which leaves them in the same boat as someone who made an architecture unaware of the details.
Agreed ... the thing that bothers me about UML is that it has displaced better, smaller-bore tooling in a significant way. The idea of thinking-before-coding work is of course completely necessary.
Model driven isn't dead though, it has transformed. It's all about text models now. The only thing you really see is people using clicky-clicky tools to make databases.