21–30 of 36 posts
aha, you almost got me there. keep your distance, uml. we shall not intermingle ever again...
Earlier quoted context omitted.
There are two types of useful UML: The first is what I call whiteboard UML - it looks like any UML course except you draw it on a whiteboard, snap a picture on your phone and start implementing it. A couple weeks latter you realize that the design has diverged from the whiteboard so you delete the pictures. The whiteboard was useful for those two weeks to get the discussion started. The second is maintained, preferab…
When UML was more popular at the height of the OO(AD) frenzy, there was a tool from Peter Coad's company called TogetherJ. IIRC it could do round-tripping between UML and Java code. I think I tried the tool out but not that feature. TogetherSoft was later acquired by Borland, as I remember.
My favorite flavor, plantuml, available with a cheesy (but very convenient) cli wrapper via npm- https://www.npmjs.com/package/node-plantuml The --unicode mode is particularly delightful
neat, the pictures could be better doh
You are right, pictures should be better focused and more unified in style. Can you recommend any software?
[1]: http://plantuml.com/ [2]: https://scripter.co/org-contribution-flowchart/#flow-chart
a) creating a "thing" to facilitate communication and understanding
b) capturing a design after it's done as part of a deployment/hand-over package
c) a useful toolkit for reverse engineering a system that you had dumped on you
etc.
basically, any sort of ad-hoc communication need or information capture process.
Software Engineering coursework will warp your brain into thinking that you need to spend a few years in a spaceship in orbit around Saturn dreaming up millions of UML diagrams that when done, will magically barf out all of the code that makes up some enormous over-engineered enterprise fizzbuzz system.
It takes a long time to overcome that nonsense without throwing away the goodness that exists here -- there's some excellent diagramming techniques that really help with coming up with a common understanding of how a system should work for a team and product owners and used well can bridge huge communication gaps. Many of the diagrams more or less show the same information, but with a slightly different angle that can help communication.
The diagram grammars themselves can get really fussy and particular, but I think when they're used best only certain components of the grammars are used to fill very specific communication needs, the rest is more or less sketched in, and the remaining grammar can be pretty comfortably be left out.
Many times, you can just invent a diagramming grammar that you can the other parties agree to and just "be inspired" by ideas from UML and get most of what you need done. There's also grammars that are not part of UML that would make sense for people to get familiar with. ArchiMate comes to mind as a particularly great example. I don't use it explicitly (the software tooling support for it is garbage, but you can fake it with yED pretty well), but I've used systems inspired by it numerous times to succinctly capture incredibly complex enterprise systems and data flow and tie those things to business processes and needs.
Creating a bunch of UML diagrams up front is usually the sign of a broken software development process. However, there's a lot of great work that went into the various diagramming grammars that turn out to be really useful in different cases. I've found that spinning up UML-like diagrams for certain subsystems on a whiteboard, or quickly in yEd or similar tool helps immensely with: a) creating a "thing" to facilitate…
Wait, what? Why?
Assuming I'm doing them because they help me flesh out an idea, it should be fine, right? You're talking more about being forced to express a concept in UML when it's already adequately described in a non-UML format, right?
Creating a bunch of UML diagrams up front is usually the sign of a broken software development process. However, there's a lot of great work that went into the various diagramming grammars that turn out to be really useful in different cases. I've found that spinning up UML-like diagrams for certain subsystems on a whiteboard, or quickly in yEd or similar tool helps immensely with: a) creating a "thing" to facilitate…
> Creating a bunch of UML diagrams up front is usually the sign of a broken software development process. Wait, what? Why? Assuming I'm doing them because they help me flesh out an idea, it should be fine, right? You're talking more about being forced to express a concept in UML when it's already adequately described in a non-UML format, right?
Earlier quoted context omitted.
> Creating a bunch of UML diagrams up front is usually the sign of a broken software development process. Wait, what? Why? Assuming I'm doing them because they help me flesh out an idea, it should be fine, right? You're talking more about being forced to express a concept in UML when it's already adequately described in a non-UML format, right?
Because you're creating a waterfall that you can only slide down and the development process becomes an exercise in alignment to "the plan".