Communication. You get a shared language between people in hopes that when you draw a box it could mean the same thing to people in different orgs and cultures. Can't really design anything large without communication.
I'm teaching it. It feels increasingly out of date. Tool support has stagnated for years on Linux. Modern features like lambdas are not really supported.
"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"?
I notice that young coders hate to deal with diagrams. Customers are more and more educated in IT, so in most cases there's no need for intermediate language to communicate.
Some 10 years ago I took part in two very large projects in two different organizations, and in both cases all our shiny diagrams were scrapped at the end. So sad :)
I do. UML class diagrams can help you turn real world business objects into model and think about dependencies and relationships of entities. I would say that it is the best tool to model software. Sequence and activity diagrams can help you design and document a process.
A picture is sometimes worth hundred words and this applies to UML as well.
Sure, pictures are great for communication. But is UML required? A lot of teams that I observe go with arrows and boxes on a whiteboard, and everything is clear nonetheless.
Yes, but not in the formal sense. And i don't get why agile and proper documentation should not go Hand in Hand.
There are components and class Diagramms that are invaluable for me when i'm joining an existing code base. Even if they are not up-to-date everytime.
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
Time limits, I guess. It's the only reason not to create good documentation. If you fail to deliver on time there's no need in good project docs. More like a chronic desease.
I still think in use cases but without the goofy graphics. I just make a Markdown bulleted list then give the use cases each a name and a short description.
Yes I do. When you have a team of developers with different model of how the system should work or works, it's usually a recipe for disaster. By modeling, we get to unify our thoughts and idea of the system.
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.
Helpinator already has basic diagram shapes (ellipses, boxes, arrows), and I just think it's enough for a help authoring tool. But the "client" is a bunch of cool old school guys from Australia, they bought an expensive license and plan to use Helpinator both for internal and end users docs, and I just can't say no without arguments. And arguments are that UML is still good for cool old school guys :)
Any tool in particular that you suggest to make diagrams? Or maybe just pen and paper?
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)
Try https://www.lucidchart.com . It is slick, has real-time collaboration, has UML (including via markup) and lots of other diagrams. Freemium that allows you to do most things.
Unfortunately lucidchart is only a drawing tool (no model validation, no documentation nor code generation).
If you need both real-time collaboration and real UML tool, you should try https://www.genmymodel.com
I use doxygen mixed with dot for rendering the UML. Mostly for looking over the layout of the code after it's written to make sure there aren't any lines/dependencies that there shouldn't be. The nice thing is that this leaves you with both an HTML doc and UMLs as PNGs. I haven't found any great tools for creating UMLs ahead of code... like for many here, that seems like a recipe for outdated/mismatched code to UML in the long run.
White board it, modeling should be a group activity. Everyone should contribute their ideas so we can converge towards one mental model. If I'm working with 1 or 2 developer, we can cluster around a table and use pen and paper. I only use professional tools if I'm going to be giving presentation or wish to store it for long term.
In Linux there is modelio, and there is also Visual Paradigm which is available on most platforms and has a free community edition.
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.
I don't deal with a lot of end users, I mainly advice stakeholders and try to make them as equipped as possible for making the right overall decisions. That being said I wouldn't because our project maneuvers use bizagi and are comfortable with that notation.
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.
In recent times, about on the same level as ERDs for databases. So mostly as a quick top-level sketch when designing something (mostly on paper), not really kept up to date when the code/model changes. Goes along with getting away from rigid class models in general, and for UI classes, the relationships are a bit more self-evident.
Not exactly UML but I find rails-erd can be helpful to understand a data model, particularly if I'm trying to come up to speed on an existing codebase. It has the very large benefit of automatically staying in sync with the code.
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.
Probably it is not. I think I'm late enough that I missed the UML wave, and I also did well enough on the AP CS test that I tested out of the CS 101 Java course in college, and got thrown into the Haskell one instead, so I was never forced to do UML.
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.
I absolutely hate UML and regard the associated tools as time swallowing abominations and the main advocates that I encountered as the worst kind of snake oil salespeople.
Of course, other people's experience may differ - but I largely thought it was a big con.
Now that was an expensive con. All UML bullshit is a joke: more energy is spent on being Correct than addressing the original issue UML was meant to solve.
To be fair, every modeling tool had terrible UX at that time - save for some domain-specific ones (e.g., NI had a great tool, but it only worked with their hardware components).
I think there's lots of potential for abuse/time wasting with UML. But consider the fact that when you're writing code, you're often focusing on two distinct concepts: implementation and design.
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 take your point, but for a UML diagram that describes things in levels of detail where those kinds of points can be addressed you could probably throw together a work proof of concept in real running code.
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.
Well, imo the statement holds true with any of the UML -> Agile/Scrum(especially True Scrum, when it is your fault when it not works) and Lean/Kanban substitutions.
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?
If those advocates were sellers, then they were all proposing this as a panacea - and no tool is a panacea. Anybody who promises to solve all your problems is selling snake oil.
It is, but mainly for sequence diagrams, flow charts and state diagrams. I think OP is asking more about object/class diagrams which I've never seen much value in.
There's no evidence to think that at all. He's talking about diagramming for helpinator, which could very well include sequence diagrams, flow charts and state diagrams.
Good UML diagrams are hard to write, easy to understand.
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.
Even bad UML diagrams are hard to write for a human that is more into typing than drawing. I was even forced to create text-to-UML tool when I was a young dev. Saved a lot of time.
Yes. Keep in mind though that the - perhaps historically, perhaps still - most widely used kind of UML diagram - the class diagram - is just one component of UML.
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 use boxes-and-arrows sketches a lot. The UML which was so popular around 2000 was this detailed quasi-standard graphical language. It was very centred around being correct, and diagrams being of a specific type of a number of permissible types, and so on. And that whole part I never found to be too helpful.
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.
I use to argue with a friend about this, I was so fed up with all the UML mystique, I wanted to release CarréFleches 1.0 (french for boxes and arrows, with the appropriate lack of grammar to mock the fluff behind UML).
Seems like everybody use the same "subset" that is graphs of things related to each others ... what a mystery.
OT: just realised where the word fletcher (an arrow-maker) comes from. In French does fleches refer always to the whole arrow? Just it sounds a bit like "flight" which is the layman's English term for the feathers.
Good one. I'd never question this one, because somehow it felt anglosaxon enough, but it seems so obvious. The anglo-french linguistic feedback loop is quite fun.
etymonline: fletcher (n.) "arrow-maker," early 14c. (as a surname attested from 1203), from Old French flechier "maker of arrows," from fleche "arrow," which is probably from Frankish, from Proto-Germanic •fleug-ika- (compare Old Low German fliuca, Middle Dutch vliecke), from PIE •pleuk- "to fly," extended form of root •pleu- "to flow" (see pluvial).
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.
Yeah, I use boxes and arrows a lot, but even more than that I use indented lists, just fire up a text editor and break everything down. They're harder to show structure with for big complicated parts of the application but when you're breaking down a single feature into just a few classes I find it a lot quicker to work with.
I concur that box-and-arrow diagrams are useful, and if I am doing them, I might as well use UML as my base language. But even then those diagrams are not nearly as valuable as the diagrams used in any other field of engineering.
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.
187 comments
[ 2.6 ms ] story [ 213 ms ] thread"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"?
All teachers knew that, but let it go
A picture is sometimes worth hundred words and this applies to UML as well.
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
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.
by the way, do you guys do scrum?
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)
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.
In Linux there is modelio, and there is also Visual Paradigm which is available on most platforms and has a free community edition.
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.
I do miss Booch's fluffy clouds a bit, though.
https://github.com/voormedia/rails-erd
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.
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.
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?
Biased a little?
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.
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
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.
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.