I have started using PlantUML[1] quite a bit recently in my blogging (one example[2]). I have PlantUML code in Org mode source blocks, and Org Babel then generates the svg/png of the diagram each time I update the code block.
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, preferably automated. If you use viseo that means an entire team who's only job is to police the code to ensure everybody updates as change happens. Lesson: don't use viseo, use a tool that either generates your code (in C like languages this would be the header files), or a tool that imports the actually code to create diagrams. In either case the reason you do this is because every week you print the diagram out on poster paper and hang it on the wall of your cube/office. (if you are in an open floor plan UML is useless because you don't have a wall to hang it on).
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.
I suppose in an open office you could use your UML diagram printouts to make a cubicle. After a half a year or so, if you keep pasting them up on top of each other, you might start getting some sound-proofing effects.
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
It would be remiss at this point not to recommend websequencediagrams[0].. been using it for years (and convinced multiple workplaces to shell out for the self hosted version..). It's great :)
Some thoughts I've had on "graphical based programming" (if UML can be deemed as such):
- Don't draw the product. Draw the organization that produces it. As per Conway's law, you'll be drawing the same thing in the end, but contrary to UML you won't face the problem of the representation of the product evolving faster than the ability of the organization to update it. The representation (the diagram) will just evolve as fast as the organization can represent itself. This require that:
- The diagram is the organization and the fundamental aspect of code is UI. There is no distinction between the primitives of the UI/UX system (clicking on that, moving this item from here to there, etc ...) and its computational primitives. This is the tipping-point that:
- a) makes this system homoiconic
- b) makes this system homoschematic.
Homoschematicity (same-representation/same-gesture in ancient Greek) is reached when the datastructure that is set in immediate relation to itself (typically lists in Lisp) is also what is directly presented to the end user and can be displayed as such, ie. immediately (lisp code is too ugly and limited for that).
I once took a couple of informatics courses at uni. They talked about uml as if the software would just magically fly out of the diagrams onto peoples computers.
“The relation between different classes (represented by a connecting line), makes up a class diagram.”
Taken from class diagrams. Not everything you need to know it seems. It misses multiplicity at least. (Didn’t read/scan more)
Also, did you really intend to have one-to-many for both client and account? Since you labeled owns. One client multiple accounts is ok for the sample. One account can have multiple owners (clients) in theory but for the introduction (audience is I guess the inexperienced) I would go with 1.
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 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.
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?
One doesn’t need to be wedded to diagrams one works out up front. Doing a bit of design upfront can be useful in fleshing out ideas. Whether that’s in UML, sequence diagrams, stories, or just some sketches on a whiteboard, or some notes on paper, what one does with them is up to the team. It need not determine everything that follows. You point out all of this yourself upthread.
Yes exactly. Pointing a development effort towards a goal or in some direction is a very different thing from an Enterprise Architect dropping a bible of UML on a team.
It sounds like the problem is the rigid adherence to the original design, not UML itself.
Good, okay. I was worried that, because I liked drawing UML diagrams, I was somehow a bad engineer! Just keep being flexible, and I'll be in good shape.
Just last week I deleted a whole bunch of boxes on a UML diagram I had drawn because someone suggested a simpler approach.
You can do an impressive amount of diagramming with the free yED. It also has some automatic layout tools and so on. It's also cross-platform so everybody can use it. The gallery has some impressive examples in it.
[1]: http://plantuml.com/ [2]: https://scripter.co/org-contribution-flowchart/#flow-chart