But there's some goodness in there. The principal of using diagramming as a descriptive documentation and communication solution is highly worthwhile, but again it should be limited to pieces of the system that need such things. And in addition, the level of detail should be just as much as is sufficient to communicate what's necessary -- don't "prematurely optimize" by trying to document every bit of the system in excruciating detail.
There's also often better, simpler ways to document many aspects of a system, a few boxes and arrows work well for many things. Lightweight versions of the Archimate style work well for describing complete systems. Protocols are well described by a lightweight treatment of sequence diagrams, etc.
They'll often go out of date as quickly as you make them, so keeping them up to date and well versioned turns into a challenge.
Because it's free and provides cross platform compatibility (and the diagrams are supposed to be communication devices), we tend to use yEd for most things.
Keeping them up to date with the code is an issue, as with all documentation. I actually wrote my own Java class diagrammer  for that purpose so I can just re-run a project file to create updated diagrams of the current code base, with little or no editing required.
- Entity relationship
- State chart
All 3 are useful for communicating protocols, schemas and state charts.
Sequence diagrams are probably the most ubiquitous, and very useful in explaining protocols. Even RFC-s have them.
Relationship diagrams are often (ab)used to visualize relationships between tables in SQL databases. While it's not very useful for designing, I have actually used them for understanding and simplifying a complicated database schema.
I actually believe every API documentation should start with an abstract entity relationship diagram. Abstract in the sense that it should not necessarily represent physical tables, but give an overview of the underlying structure to the first time user. Doesn't even have to complete or correct.
State charts are occasionally useful for obvious reasons. Try explaining TCP without one.
I think it's worth noting that the above 3 existed before UML and UML merely tried to formalize them, so while I don't think anyone uses "UML" anymore,
being able to comprehend the above 3 charts is as basic of a skill as being able to read pseudo-code, and saying they are not is use would also be false.
Sequence diagrams nicely represent separate entities involved in a system, the order of communication between them, and the conceptual content of messages between them. Even briefly reading a sequence diagram helps you understand how different components relate to each other.
Often, and usually with API endpoints with some complexity behind the scenes, I'll go out of my way to draw an ASCII sequence diagram with Monodraw and leave it in the comments or a readme.
It is useful to draw ideas as graphics for people who's brains are wired visually. And it can makes nice figures for books and articles explaining structures and concepts. But in neither case does the value predominantly depend on the depictions begin adherent to a standard, as much as other qualities, like focusing on the right part of a larger system, or leaving out unimportant detail, etc.
So nonstandard diagrams offer the author or user more creative flexibility, which is often very important.
I do see value in loosely following UML notation, for the obvious reason that one can immediately see if someone tries to show classes, states, requests, systems parts, and so on. That was probably the original goal behind UML all along, even if people lost sight of it during the fad phase.
Seems like everybody use the same "subset" that is graphs of things related to each others ... what a mystery.
I think it pretty much stands for the whole arrow, but comes from the word for “flying” back in old Germanic languages – but via the arrow being a flying projectile, not from the feathers per se.
My explanation is this: computer programs are documents. The best way to capture the essence of a document is to summarise it's most important bits in language I can easily understand.
And for me, that requires English not UML.
"And there is an explicitly political idea that drove OOP to its peak in the 1990s: the idea of outsourcing. The idea of outsourcing software development rested on some assumptions about how software development should work, in particular the idea of the “genius” architect, backed by an army of morons who act as secretaries, taking dictation. OOP was the software equivalent of a trend that became common in manufacturing during the 1980s: design should stay in the USA while actual production should be sent to a 3rd World country. Working with UML diagrams, writing code could be reduced to mere grunt work, whereas the design of software could be handled by visionaries, possessed with epic imaginations, who could specify an OO hierarchy which could then be sent to India for a vast team to actually type out. And the teams in India (or Vietnam, or Romania, etc) were never trusted, they were assumed to be idiots, and so, for a moment, there was a strong market demand for a language that treated programmers like idiots, and so the stage was set for the emergence of Java. "
Ok, it's wordy, ok it doesn't have a REPL but if you were living the life 20 years ago it was a godsend.
The downside was that it took about £300 a day out of the market for contractors in 3 years.
Besides, during the 90s the idea seemed to be that that the next step after the outsourcing was actually no programmers at all. UML and 4gl systems would handle all the complexities and laymen domain experts could just define all bread and butter administrative systems they like - no expensive and socially awkward nerds in the basement necessary...
Lest someone think this is an exaggeration, no, this was literally the conversation at the highest levels of some companies. A relative told me to reconsider going after a comp sci degree in 1995 because within ten years the computers would be programming themselves. There were presentations at their workplace about it.
I think that BPEL thankfully died just a couple of years ago, but not thanks to some globally aquired insight but rather because a new batch of developers isn't quite there yet so they are busy learning and reinventing basic stuff, but now at 'internet scale'
A bonus comment for the youngin's ... When you hear that some new system will allow "the common man" to write his own software without developers, smile and agree with them because they'll come back when it doesn't go as planned and you can charge a higher rate for the resulting expedited project.
I should also admit that I liked (like?) the idea of writing code using diagrams. In the '80s I wrote a program I called "Flo-Pro" in Turbo C that never quite became self-compiling. It wasn't at all OOPsish or FP. In the '90s I wrote several tools in Prograph  (now known as Marten) but was stymied by the fact that I was the only one in the company using the tool. In the early aughts, I tried URL tools that promised to write my code from the diagrams - it worked for very simple code but I never saw round-tripping work.
I love drawings in general - my coworkers joke that it's not a meeting unless I have a dry-erase marker in my hand. But those diagrams are invariably system-level, architectural drawings. As others have noted, I also appreciate ERD as a way to visualize relationships in RDBMS. So as much as I like the idea, development stays in the world of text - I'm not holding my breath for some magic bullet.
Yours is so far the most insightful comment I've read on the page. Have an up vote.
"The common man" often seems to think that mastering the syntax of a programming language is the hard bit, and that replacing textual syntax with some pretty graphics will magically make software easy to build.
Of course, the real challenge is accurately specifying what you're trying to accomplish, and exactly how you want it to happen. Everything else is just window-dressing.
There's a lot to say about uml and the "model" approach history. One bit of trivia, I did my internship at an old IBM acquisition, that shop had made its own process/modeling philosophy with a dedicated environment in the 80s (the reason it got successul with some big clients thus IBM interest). Coming there I thought it would be yet another rational-like thing. But that old console program had live modeling relationship between layers, the model thang was implicit, a beautiful thing. Now replaced by whatever Eclipse based rational children IBM forced onto the teams now.
Imagine an app where you can fix your own car without any mechanical knowledge. The user simply explains the problem to the app and the app figures it out. In every scenario the app ends up directing you to an actual mechanic.
That's my best analogy to "programming without programming".
I just changed the alternator on my truck - you have to wait for the exhaust to cool before you do it, disconnect the battery and then punch the security code into the radio when you're done.
A business person trying to write their own software (assuming they're not also a developer and that they believe some magic tool will let them complete it) will end up with painfully burned hands in the process and at the end they won't be blissfully listening to music again.
But why wait for a powerful AI, if you can hire / enslave developers today?
That's where we spend the majority of our time and always where things go horribly wrong in SciFi movies.
Halfway through 2016, "a programmer with 1 year of experience" using nothing by Python, numpy and a couple of spare weeks could roll their own convolutional neural net to identify images with high-90-percent accuracy.
I dunno about you but that sounds like a significant advance to me.
That's actually the point.
I won't comment on the pros and cons of UML. Instead I'll invite you to ask yourself a couple of questions.
1. What other clients do you support who have similar characteristics as this client (and may therefore also benefit from UML support)? If the number is significant in terms of impact to your bottom line versus the time you'd have to spend implementing it, then you should consider it worth your time, and view it as an opportunity to up-sell (if you can) or keep existing customers.
2. Do you intend to attempt to move into supporting large enterprise, and especially government contractors? If so, you might consider UML support just because it is ubiquitous there.
I'm a low-level guy and learning some web coding these days, so I can tell the difference views on software between HN and other places.
It isn't really divided by front end versus back end or the like.
I presume you mean the Haskell crowd? The Lisp crowd is more about expression rather than "correctness" and rigidity. FP doesn't really have a formal definition.
> trying to evangelize the world of programming to do things one way; their way.
I think the world of computing is shifting towards a lot of async work, and if you've ever written large threaded apps, having too much state becomes the greatest of burdens. Clojure, for example, minimizes state and uses Software Transactional Memory to manage mutability.
Originally it was mostly because it was the default setting in my Enterprise Architect tool, but it's proven more useful than Archimate (and other notations) because people without architect knowledge understands it much better.
On the business side it's mainly the system integrations, dependencies and information flows that are of value and you could honestly do them in Word if you wanted. Because it's very easy to build upon it, it's also easy to turn the business specs into something I can hand to an actual developer or use as a common language when talking features and requirements.
I wouldn't use UML if I was doing the systems engineering from requirement specs handed to me, and it is very rare that we use more than 10-25% of its full functionality, but it has enourmous value when you are trying to get future system owners to understand their own business processes and what they actually need from their IT.
Given the choice I'd probably not use UML BPs a lot either. They are very good if you want to do graphical use cases for architects, but I don't think they have a lot of communicative value unless you know UML.
Being able to stand in front of a big screen and point to and talk about connections and cardinalities magically draws questions and comments out from the business stakeholders. That feedback helps me get the model to a place where it generally matches what the business wants.
Keeping that diagram alive and updated as we implement the system has served as a super valuable tool for communication with other teams that need to touch the model. Everyone continuously hashes out and agrees on common terms, ownership, etc.
The worst defects come from requirements or design defects. I'm not advocating for giant up-front designs with hundred+ page software design spec docs. But, paraphrasing Uncle Bob, "'no up-front design' doesn't mean no design." There has to be some design of some sort and some documentation of the system being developed.
I think the time to stop diagramming/designing is when adding more detail won't communicate anything more about the model or business process in casual conversations about the system. That's a very subjective line to draw, but it helps me to think that way.
Of course, other people's experience may differ - but I largely thought it was a big con.
When designing, you are implicitly asking yourself: "what problem am I trying to solve, what data structures should I use to represent the elements of this problem, how should they relate to one another, what should this system interface look like, etc".
And when implementing, you are focusing on mapping those concepts from design into code. Often during implementation you can discover new elements of the problem or requirements that need solving. So implementation itself is valuable.
But design can be considered and reasoned about without requiring an implementation. Even without a peer to discuss the design with, considering "what if I decompose the data structures this way?" is a valuable exercise. Now, you don't need UML to do that. But you can leverage it to do that. I will posit that the screen-to-brain throughput of a UML diagram is greater than that of code or prose. Also, the brain-to-screen throughput of UML is probably better than those.
You might be surprised at the discussion inspired by a simple class diagram:
"Ok, sure, but which class holds the file descriptor?"
"None -- fred's working on a library that does that"
"No, Fred's library only considers the command line args but doesn't open the files."
I'm not against diagrams or discussion of design, far from it, I just think that UML is a terrible notation - it makes people think they are working with blueprints rather than sketches.
I wonder whether they are the same people selling bullets in different shades of silver though the ages, or it could be that the SW business is big enough that we can witness different species develop the same survival strategy of going from host to host and sucking their money out in different niches?
When starting out a project, I tend to lean more towards well labeled conceptual diagrams. I will also use activity diagram, sequence and state diagrams.
While I have often read about people designing class diagram before hand, then writing or generating code. I never use class diagram before code is written. I use class diagram to document an existing system.
It's a tool, if you are willing to be flexible and realize it for what it is, then it's useful.
I tried StarUML 2 and it's ok but I found it slightly clunky (it also does not have a realtime collaboration feature as far as I know, that would be nice to have when your team is remote IMHO)
In Linux there is modelio, and there is also Visual Paradigm which is available on most platforms and has a free community edition.
Super easy to learn, efficient to use, runs anywhere, can reverse engineer Java code, free and open source.
It also comes with a palette so you can draw UML diagrams without knowing much UML.
by the way, do you guys do scrum?
The idea that a picture is worth a thousand words is not applicable to most of the words one would use to discuss systems designs. It is very difficult to discuss purpose and intent, or to present arguments that the design satisfies requirements or observes constraints, to justify choices, and say how things work, through any sort of diagram, let alone only those of UML (use cases are something of an exception, as they are not actually diagrams.)
On the other hand, diagrams are a very useful adjunct to these activities, and are widely used in informal discussions. This is broadly in line with how diagrams and pictures are used in other technical and scholarly fields: for example, maps, statistical charts and pictures of places and artifacts are very useful in history articles, but are never the full story.
Furthermore, I can usually write a thousand words faster than I can draw the corresponding UML diagram. The UML I am most likely to use will be machine-generated from code and will be used as a supplement to the text I am writing.
It's intersting to see what classes aren't used at all and where all the associations accumulate.
Also, if the "previous devs" are still around it's easier to talk with them about these pictures, than to talk about 100 text files.
I use my own subset/version of UML, which uses a simplified "grammar", and allows you to express basically only the following:
- Class with attributes
- Parent/child relationship
- One-to-one relationship
- One-to-many relationship
- Many-to-many relationship
If I have some other need (rare), then I improvise. Usually I'm the only one who looks at these, but if a client or someone else needs to, the language is simple enough to understand that I can explain it in a few examples/sentences.
I used Rational Rhapsody for a few years. We used it for use case diagrams, sequence diagrams, class diagrams, object model diagrams, statecharts+code generation.
Many folks scoff at and draw the line at code generation. By default, tools like Rhapsody seek to box you in to a certain way of doing things. It's not difficult at all to customize but it requires effort to opt out of some defaults. I felt like I experienced significant pros and cons. One one hand it was awkward to use their IDE to edit the code. OTOH it helped encourage a level of organization to the code. Statecharts are very expressive and very clear, I really liked them. There's no limit to the expressiveness of the code you can write. But the vocabulary used to describe the widgets I was working with was new to me, so it took a good deal of time to look up and understand the customizations required.
In the absence of code generation features of UML, the diagramming features are really great. Developers are too quick to treat it like a religion and (on both sides) become inspired to pray at the altar or preach about the evil that lies within. But really, it's just a glossary of visual representations mapped to software design concepts. That's all it needs to be -- conventions like the ones used in other engineering discipline's diagrams. Diagrams with "boxes and arrows" are just fine but there's always the implicit questions: "does that rectangle represent the process executing the 'flabtisticator executable' or the 'flabtisticator class'?
For Java, perhaps high level class diagrams are still useful also, but I have been switching over to using Haskell (as much as I can) and I have not worked on a large Java project in a long while.
State and sequence diagrams are really cool to discuss dynamic flows and identify potential logic holes.
UML-like diagrams are way better then to come up with your own representation of this everytime
I almost have a prejudice against people who use UML because a lot of them seem to be the "architect" types who talk about integration patterns and stuff but don't get much done.
Although this is a small team project, making the diagram takes at least 5 times the time needed to write the code. In our team of 4, 3 of us will not need to write code.
I understand it is good for management but I hope I will never be required to do this ever again.
A picture is sometimes worth hundred words and this applies to UML as well.
C1 ---> C2
mean that C1 inherits from C2 or that C2 inherits from C1? Does:
C1 ---* C2
[Note: the * is supposed to be a filled-in black diamond, but HN apparently doesn't allow unicode characters in comments.]
mean that C1 contains instances of C2 or that C2 contains instances of C1? What would it mean if the diamond were hollow instead of filled? What is the difference between a solid and a dashed line in a class diagram? A sequence diagram?
The only way you can possibly know the answers to these questions is if you have mastered an enormous amount of trivia. And then what have you actually gained? How is a class diagram better than simply writing out as text, "Class C1 inherits from C2, C3 and C4, and contains single instances of C6, C6 a set of C7s, and an ordered list of C8s?"
In >90% of cases, the information conveyed by UML can be much more easily and effectively communicated by plain text.
I agree with much of your criticism of UML, but there is significant value in having a visual representation of class interactions. Your text takes longer to parse and understand than a simple diagram would be. For scenarios with numerous classes, the diagram becomes far easier than a text description.
If the text is hyperlinked it can be every bit as easy to follow as a diagram. In fact, it can be easier if things are really complicated because it allows you to focus your attention more easily just on the parts that matter to you at any given time.
If class diagrams are useless then so are bar graphs and scatter plots. You can just list out the data points and everyone can read them.
Just about the only diagram that has a natural mapping from spatial relationships of the diagram elements to the actual underlying semantics is the sequence diagram.
We can probably just agree to disagree here. I think class diagrams are often quite useful. They existed before UML and they are used even by people who don't use UML.
That works for me :-)
For architectural diagrams, I just use basic boxes, arrows, cans, etc. UML also tends to feel complicated to the point of being hard to read.
In both of the above cases, I think my not using UML is because its goals differ from mine. UML seeks to capture how a system comes together as completely an accurately as possible. I tend to think that the code should suffice for that (and if it doesn't, it's time to have a long hard talk about technical debt). I prefer diagrams to just be a gloss that helps to explain how things come together at a high level.
For understanding protocols and suchlike, though, UML sequence diagrams are my go-to. That's a rare spot where I really do want the diagram to capture a whole lot of fine detail, and the UML standard provides a pretty clear, intuitive and uncluttered visual language for the job.
UML is actually the first language a software developer should learn. The most ridiculous words I have heard is that a senior engineer "mentor" other juniors say the IBM Rose is UML! And argue about how Rose huge and hard to use.
I really worry if there still have some deciplines exist in software industry, if so many people still obsessed to call themself software engineer?
We don't go full UML, but it is the best tool to have a solid architecture overview, before committing to solutions that won't fit with what customers actually want.
It is also a very good tool to onboard new developers into the team without forcing them spending endless hours reading code.
"Modern" as in "Introduced to programming languages 35 years before the invention of UML, finally turning up in Java 20 years after the invention of UML"?
Most developers don't have a complete knowledge of it and don't enjoy writing it; essentially I believe it's because they know it's not an efficient way of communicating ideas with other developers.
Modelling can be useful, but as far as I can work out something like gliffy with lines, boxes and little else is almost always sufficient. I'd imagine safety critical space or aviation systems and other niches are a different kettle of fish.
Maybe it's because I work in front-end, which "traditionally" is a bit less strict (JS is dynamically typed etc.), but also, I think that typically the codebase changes too rapidly and the fancy graphs can't catch up with that, they get outdated in a few months, and no one bothers to update them or even look at them anymore (they might be useful in the beginning of the project though).
Other than for explaining particular design patterns I don't find class diagrams all that useful, certainly not for giving you a complete picture of a system that consists of more than a handful of classes.
Sequence diagrams, state diagrams, use case diagrams, basically anything that involves or describes activities: I think those are tremendously useful.
I used to write a lot of UML diagrams in Mechatronics Engineering for a big company, where specs were not supposed to change often.
For projects with a long lifetime and a slow change velocity, UML is totally justified.
UML diagrams are not worth it for Software Engineering: code evolve too fast to keep your diagrams up to date.
In that case, I replace UML diagrams by simple sketchs / mockups and simple tables.
IMHO, adding full UML support is crazy for your application and would potentially add years of development.
Even adding simple, non-model based UML creation would be a significant burden if you are a small company. Plus, there might be open source generators or generators you could call programatically to generate the images desired.
But first, you probably need to better understand your client's actual needs. I have doubts that they would need all the UML diagrams...
Unfortunately, I think UML suffers from all the dysfunctions of a language designed by many stakeholders. It's just not intuitive, so you have to remember the details. I start practically every handwaivy whiteboarding session with the disclosure "this is not UML but ...".
As with many "standards", we've sucked the oxygen out of the room by saying this is the one true way. I very much prefer having multiple competing specifications and letting the winner shake out. I imagine if we hadn't prematurely standardized on UML years ago, visual programming and diagramming would have evolved in exactly the same way regular programming languages have evolved. Why do I have 30+ choices for what to write my web server in, but only 1 seriously spec'ed out language for drawing it?
UML diagrams can be very useful to represent a system to someone which is not technical enough to understand code, but can understand the basics of the diagrams.
Personally, to myself it's usually more a waste of my time.
And then there's the domain specific UMLs, such as Operations Management and BPMN, where the diagram can be programmatically "powered up" to analyze operational efficiency. If you work in a hierarchical organization where you need deliverables that filter to other departments, and there is a perceived value, then someone is going to be tasked to make it. But in a flat organization in startup mode, it's a waste of money.
If you're working across organizations, in public/private partnerships; if your government organization needs to be accountable at diverse levels, then UML is visual language that communicates a lot of information at once--in one artifact. Tax dollars going for new transportation infrastructure in New York City, maybe there's a need to get diverse groups on board. But you're going to pave potholes in Levittown, NY--who cares? Get it done; stop wasting money.
And finally, there is a the language-cultural dimension. Europe is multi-lingual, so it's no surprise the Open-Education Resources offering UML-like education materials are from European universities , and not American Universities. That's not our language problem (yet).
If you have a customer asking for UML, you need to understand their problems. Once you do that, then you can decide if the problem vector they present is profitable sector for your company.
To put all this in other words, UML is a tool and a visual language. Use it or not, it's not going away--ever.
The class diagrams that everyone is really thinking about when they say "UML" are imho kind of useless. It reflects a kind of obsessive OO purism, and taxonomical obsession, that was quite trendy in the late 90s, early 2000s.
But it turns out in most cases looking at a class diagram doesn't really tell you much about what software does or how it works. And in any case I personally find it easier to look at header files or source files to get a picture of how things fit together. Class diagrams don't really help.
There was a recent talk about the model-code gap . How diagrams often don't map to the code. The C4 model. "Structurizr." Lack of common abstractions to describe software, in contrast with other fields like electrical engineering. Good to still start out with paper/whiteboard.
@7:13 "1 out of 10 people use UML," in his experience. People adopt ad hoc notations instead.
His use of UML is not for describing the system at a high level.
 GOTO 2016 • Visualise, Document and Explore Your Software Architechture • Simon Brown
At a job not too long ago, we used a modified form of DOT to describe a protocol state machine. This generated dot, .h's, and some template .c files. This made it such that each state machine for the protocol had a diagram that would map out all the states. Logging and other subsystems output were generated as well so you could go from a log of a test run back to a diagram of what had run.
Code generation (or compilers for compilers) are entirely underrated outside of Lisp, and they're not too difficult to create.
EDIT: And note that your linked presentation is AWESOME, but I think he misses the description / guidebook being up to date is best accomplished by having it be what needs to be updated to create the software.
I can definitely see an argument for certain types of projects (libraries and frameworks). If you have diagramming capability, and you are in the enterprise Windows market, I think this is a no-brainer. I'd be curious what diagramming support you had if it were not UML....
Having said that, I wouldn't try to implement a full object modelling solution. It's not the kind of thing that help files need. Actor diagrams and sequence diagrams would make more sense to me.
When I take notes, some concepts are better/faster materialized as relationships between objects or actors or activities
Also reasoning about schematics topology is useful and enlightening when a problem is large
I wouldn't generally use it to design code that hadn't been written yet. There's a lot you only discover once you get something working, and that needs to inform the design.
I like how UML class diagrams defines the different potential relations between objects involved in software.
It would be nice if more people (myself included) learned better ways to consistently communicate software design. Lots of ad-hoc meetings result in confusion because often a design is scribbled in ones own notation then communication takes longer. But yet such communication is crucial to large projects.
Some call it architecture, others call it design patterns. Either way its important to have thought-out, standard ways to communicate ideas.
I challenge any of you to come up with something better.
Once in a while I'll fire up Visio and sketch out a state machine or sequence diagram, but all I'm really doing is throwing down some bubbles or rectangles, drawing some arrows between them, and tacking on some labels. It's nowhere near as formalized as UML, but it works well enough.
All teachers knew that, but let it go
Class diagrams are pretty nice when building a rich domain model since it's pretty easy to move from rough conceptual level closer to designing and documenting the actual implementation while working on the same diagram over time.
Now, sequence diagrams remain one of the best ways of explaining distributed workflows (e.g: OAuth) that I know of. If you work with an OOP language, a class diagram might be useful to express some ideas. Other UML diagrams are less used.
I do miss Booch's fluffy clouds a bit, though.
I tried to keep it up to date for the public docs, but that can be an uphill battle.
Easy to use, allows you to "code" the UML structure in a simple template language, and the output looks rather nice.
But just for higher concept sketching and most definitely not for generating code. I tried that, 12 years ago with Rational Rose. Boy did it suck.
It's just a tool for modelling. You can pick and choose the diagrams you need, and at the abstraction level you desire.
Biased a little?
Question to HN: What tools do you guys use to draw UML diagrams?