Ya, that's pretty terrific. Having the diagrams paired with the code is a boon. My GoF study group (of mostly Java and C++ devs) spent way too much time divining how to "realize" (something short of implementation) the design patterns. I wish we had the SmallTalk version of these graphs.
Last year, I used the UML static object modeling notation for understanding and documenting an existing RDBMS schema. Also last year, I used some of the UML state modeling (or Harel Statecharts) for getting the UI right for a SwiftUI app. Earlier this year, I used DeMarco-Yourdon DFDs (but we can call it UML) for business process modeling. (And our director of marketing picked it up instantly, and even had an insight into some structure of the data flows between some processes, because of this formalism.) And I'll probably use UML imminently for a new schema, if it turns out to be nontrivial.
I used to use UML (well, OMT, but fortunately Rumbaugh's notation won over Booch's for UML) constantly, when I was doing lots of Java. I worked on high-end CASE and methodology, and on the side I made a convenient little tool to help go from OMT to Java, and keep it up-to-data (in conjunction with Rumbaugh's own OMTool): https://www.neilvandyke.org/jomtool/
One thing to know about these system analysis&design methodologies (before UML, there were maybe a dozen prominent ones) and their various diagrams is that the user bases seemed to change over time. If you were a technical developer of a large system, or maybe a certain kind of big embedded systems developer, you might use it. If you were a database architect, there was a different camp for that, and they had different needs and tools. At some point, maybe around the time that Java was adopted for corporate internal IS development, the UML I occasionally saw was usually simply as a way of visualizing class inheritance hierarchies (and summarizing their Java attribute and method signatures). Which is fine, but it's only a fraction of the benefit they could get from higher-level modeling and documenting, with even that one kind of UML diagram.
> One thing to know about these system analysis&design methodologies...
It's crazy think about now, but the methodology strongly influences the design.
Late 90s, I favored the Fusion Methodology for design. There was a researcher in the UK (Tony something?) that showed using the UML process led to overuse of Observable (Listener), which quickly becomes intractable. Tony (?) then reimplemented the same problems with Fusion, then diffing the resulting implementations.
The notion is almost lost in the sands of time. I'm pretty sure this is the same Fusion. I couldn't quickly refind Tony's (?) original work.
The diagrams and other artifacts were largely the same.
> ... only a fraction of the benefit
Emphatic agreement.
Alas, I've never worked at orgs that would or could keep the modeling and the implementation in sync. Perhaps it's more feasible now. (I haven't looked for a long time.)
Not really, everybody is up to their own Heuristical Modelling Language, that is simply based on custom circles/rectangles. Shockingly, works pretty well (and faster to draw) if there's some context understanding between people who read the graph.
Apparently JPL uses Model Driven Development to build telescopes. There is an interesting presentation[0] which describes their setup to design and build the JPL Thirty Meter Telescope. They use SysML[1] and Jupyter to provide true model driven development, i.e., changes to models are propagated to the code.
Will watch, thanks. That was the Holy Grail, back when I cared about these things. So much time wasted with tools like Rational Rose et al. It'd be very satisfying if it's finally feasible, or better.
Just discovered plantuml and liked it - i can use some visual aid if only i do not have to draw it.
Sequence and use case diagrams are useful. Class diagrams i would rather see in code.
I also misuse use case diagrams for arbitrary graphs. It is good to see if a graph i came up with looks too much like spaghetti. Helps to untangle it. But it is not proper UML and i could use the graphviz dot itself for it without plantuml frontend.
I use it. Diagrams are easy to grasp especially when the alternative is lots of text. UML2 is a good specification IMHO. There are tools that let's you model your solution, which makes it easy to maintain it.
https://www.omg.org/spec/UML/About-UML/
I generate them automatically from intellij otherwise it wouldn't be worth it.
The UML notation is easily cryptic to the neophyte but it can sometimes help to give an overview.
The only pattern I regularly use is the Visitor pattern, which is very common in compilers these days. It's productive, but I'm still slightly worried when I use it because it seems to encourage relatively stateful code that doesn't compose properly. Writing a new visitor takes a while, so people also put too much in one visitor.
Tangent: Over time I migrated to favoring Iterator over Visitor. Similarly, using event model with Command objects instead of Observable. YMMV, of course. Both require seeing problems thru a different prism.
Also, most unit tests are a waste, outside of library code (and I’d venture in most library code the majority of unit testing is duplicative, or otherwise unnecessary). Prefer integration tests.
Nowadays, I hardly ever hear of it. Does anybody use it any more?
I used to use UML (well, OMT, but fortunately Rumbaugh's notation won over Booch's for UML) constantly, when I was doing lots of Java. I worked on high-end CASE and methodology, and on the side I made a convenient little tool to help go from OMT to Java, and keep it up-to-data (in conjunction with Rumbaugh's own OMTool): https://www.neilvandyke.org/jomtool/
One thing to know about these system analysis&design methodologies (before UML, there were maybe a dozen prominent ones) and their various diagrams is that the user bases seemed to change over time. If you were a technical developer of a large system, or maybe a certain kind of big embedded systems developer, you might use it. If you were a database architect, there was a different camp for that, and they had different needs and tools. At some point, maybe around the time that Java was adopted for corporate internal IS development, the UML I occasionally saw was usually simply as a way of visualizing class inheritance hierarchies (and summarizing their Java attribute and method signatures). Which is fine, but it's only a fraction of the benefit they could get from higher-level modeling and documenting, with even that one kind of UML diagram.
It's crazy think about now, but the methodology strongly influences the design.
Late 90s, I favored the Fusion Methodology for design. There was a researcher in the UK (Tony something?) that showed using the UML process led to overuse of Observable (Listener), which quickly becomes intractable. Tony (?) then reimplemented the same problems with Fusion, then diffing the resulting implementations.
The notion is almost lost in the sands of time. I'm pretty sure this is the same Fusion. I couldn't quickly refind Tony's (?) original work.
http://wiki.c2.com/?FusionMethodology
The diagrams and other artifacts were largely the same.
> ... only a fraction of the benefit
Emphatic agreement.
Alas, I've never worked at orgs that would or could keep the modeling and the implementation in sync. Perhaps it's more feasible now. (I haven't looked for a long time.)
[0]=https://www.youtube.com/watch?v=CshfBGrjdBU [1]=https://en.wikipedia.org/wiki/Systems_Modeling_Language
Sequence and use case diagrams are useful. Class diagrams i would rather see in code.
I also misuse use case diagrams for arbitrary graphs. It is good to see if a graph i came up with looks too much like spaghetti. Helps to untangle it. But it is not proper UML and i could use the graphviz dot itself for it without plantuml frontend.
I rather do whiteboard UML than throw away code that costs money and no one is going to use.
ER for database modelling.
Same applies to UIs, Balsamiq with paper simulations, and click dummies, until everyone agrees what the GUI workflow should actually be like.
Also, most unit tests are a waste, outside of library code (and I’d venture in most library code the majority of unit testing is duplicative, or otherwise unnecessary). Prefer integration tests.