
All You Need to Know About UML Diagrams - noelceta
https://tallyfy.com/uml-diagram/
======
kaushalmodi
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.

[1]: [http://plantuml.com/](http://plantuml.com/) [2]:
[https://scripter.co/org-contribution-flowchart/#flow-
chart](https://scripter.co/org-contribution-flowchart/#flow-chart)

------
giseir
UML Diagrams are actually quite useful, sometimes you just need a structured
way to reason about software.

~~~
bluGill
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, 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).

~~~
vram22
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.

~~~
blattimwind
In IntelliJ you can refactor from UML views.

~~~
vram22
Interesting, will check that out.

------
npendleton
My favorite flavor, plantuml, available with a cheesy (but very convenient)
cli wrapper via npm- [https://www.npmjs.com/package/node-
plantuml](https://www.npmjs.com/package/node-plantuml) The --unicode mode is
particularly delightful

~~~
wainstead
+1 for plantuml. You can make very useful sequence diagrams with it, in ascii
no less.

~~~
_puk
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 :)

0:
[https://www.websequencediagrams.com/](https://www.websequencediagrams.com/)

------
GorgeRonde
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).

------
seattle_spring
> All You Need to Know About UML Diagrams

Honestly thought it was just going to be a blank page.

------
htor
aha, you almost got me there. keep your distance, uml. we shall not
intermingle ever again...

~~~
Eyght
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.

------
bastijn
“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.

------
kyberias
I don't think this article covers "all you need to know" particularly well.

------
bane
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.

[https://en.wikipedia.org/wiki/ArchiMate](https://en.wikipedia.org/wiki/ArchiMate)

~~~
diminoten
> 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?

~~~
bane
Because you're creating a waterfall that you can only slide down and the
development process becomes an exercise in alignment to "the plan".

~~~
grzm
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.

~~~
bane
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.

~~~
diminoten
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.

------
dry_flamingo
[http://www.nomnoml.com/](http://www.nomnoml.com/) is another good one.

[https://github.com/skanaar/nomnoml](https://github.com/skanaar/nomnoml)

------
clstl
neat, the pictures could be better doh

~~~
noelceta
You are right, pictures should be better focused and more unified in style.
Can you recommend any software?

~~~
clstl
I personally use [https://draw.io](https://draw.io)

~~~
Born_Again
Draw.io is also great for working in groups.

------
tilt_error
You lost me at ”Visio”!

