3 ms·
Also the level of detail that UML demands always turns out to be imprecise once coders end up implementing specs. So it's a place where enough formality is requ
by Daishiman 6y ago
Also the level of detail that UML demands always turns out to be imprecise once coders end up implementing specs. So it's a place where enough formality is required to be a PITA to model but where it falls just short enough of the specifics a programmer will need once they get to actually building out the product.
- lordnacho 6y agoI was gonna say just this. If you are able to specify how the objects are related, why not just code up the skeleton? Similar issue in UI design. Why draw up the mock when you could just make a static webpage?
- throwawayboise 6y agoThe idea was if you found that the model was lacking in some way, you would update the model and regenerate your code. In practice that just didn't work, or at least it didn't result in saving any time or in producing better software.
- deleted 6y ago[deleted]
- forinti 6y agoI always treated UML as a window into the domain, not as a precursor to the code. With just a few Use Case diagrams, some class diagrams, and maybe some sequence diagrams, you could communicate what the final system should do and how people will interact with it. The details of how to implement would be derived from the architecture used. I always found even a few basic diagrams with little detail (classes without fields) very useful and miss them now that people don't want to "waste time".
- 8note 6y agoThis sounds like UMLs job is to be drawn after project is complete for documentation/refactoring, rather than as a design tool. I think the proper comparison is then a suite of test code
- deleted 6y ago[deleted]