I think that entity-relation diagrams are underused, especially when analysing requirements with stake holders.<p>Unfortunately a lot of otherwise capable people that could benefit from some simple structuring of things and their relations have never thought about the world in that way and may take a little while to catch up.<p>In some cases I have found it to be easier to represent one-to-many relations as a bunch of stacked boxes on the "many" side. But that only works once...<p>Sequence diagrams and state-charts helps from time to time, but does not really help much when talking to non-professionals.<p>But I don't really like the very formal UML. Some bubbles, arrows and crow's feet will do fine in most cases. The precision promised by UML is really a lie, as most diagrams are simplifications and can probably not represent the actual complexity in anything that warrants the use of UML...<p>Anyway, I think it might actually be a good idea to do some simple entity-relationship analysis in schools at some point, if not to just get another tool for sorting out the mess.<p>The underlying reason that led to OO-languages still exists, namely that a lot of things can be described rather nicely with entity-relation maps. It's just unfortunate that the "relation" part was forgotten, and all energy was spent on wrestling various languages into bizarre "OO" hacks such as C++.
UML diagrams. I sometimes use sequence diagrams, but almost certainly with all the wrong symbols and so on. They're just parallel timelines showing communication between conceptual objects.<p>Otherwise, all I've ever seen anyone do is take their actual design diagrams and laboriously turn them into UML diagrams of some kind for a document. The recipient then took the UML diagrams from that and made their own new sketches from that, turning them into something they could easily read and understand and that generally looked very similar to the original diagram that was laboriously translated into UML.<p>My conclusion is that a UML diagram is better than nothing, but not as good as a well-written and well-explained design. I suspect UML diagrams are meant to be part of a well written, well-explained design, but for any given design there seems to be a better way to draw it than UML diagrams.
In the sysadmin world yes but not nearly enough. UML along with similar ones like blockdiag and nwdiag interface nicely with my documentation systems in orgmode and asciidoc.<p>One of my side projects is an automated nwdiag mapping system with diff's to be able to help sysadmins coming in blind to orgs (happens way more than you'd think, usually a 5 yr old visio file somewhere).<p>Anyway, in the future I see uml style things as useful for similar automation projects, due to the simple text nature.<p>Also, I live in a terminal most of the time so personally prefer stuff like nwdiag over say visio or some of the alternatives.<p>I also used to make repair flowcharts with seqdiag for my t1 and 2s.
I'm doing a degree part-time, online, and that's the only time I've ever used UML.<p>I work at a kind of graduated tech start up, so we're doing most things the modern way. I've never even heard anyone mention UML.
I've not seen anyone use any UML for years to be honest except for class diagrams or something similar to give a high level architecture overview or to explain how major components interact.
They are, but perhaps agile methods who diminish the importance of documenting have played against it. We will see what price we have to pay for this.<p>In my experience, people don't like to document, developers even more, and managers probably don't like to read documents, either. However, if people leave your company (something highly probable), how are you expected to train the new people?<p>If you are working in a startup, that's not major problem: the startup may just die and you can have fun programming in the meantime. However, if there is company that intends to last more than a few years, ways of documenting your system are needed.<p>IMHO, not using UML, or any other language, to think about our systems or even tell others how they work is a complete mistake. It is not only for telling others (colleagues and future workers) what the system does and why it does it that way, it is also to save effort and realize sooner that it will not work.<p>So, whatever the case, training in how to explain your system to others is required. Call it UML or whatever. And, since UML is there, it may be worth to use it. It is not just the invention of a couple of mad engineers. You are free to use UML as you like. And do not need to use a huge tool. Text UML is a nice and refreshing way of looking at UML which I strongly recommend. Have a look at <a href="http://planttext.com" rel="nofollow">http://planttext.com</a>, for instance.
A few months ago I wrote this <a href="https://news.ycombinator.com/item?id=12879493" rel="nofollow">https://news.ycombinator.com/item?id=12879493</a> and I think that's still valid.<p>Simplified UML class diagrams (i.e. boxes and arrows) are expedient for explaining specific aspects of a design. Complex class diagrams trying to give an all-encompassing picture of an application: Not so much.<p>Sequence and activity diagrams can be quite useful for clarifying application state, too.
Yes (ex: with plantUML for a just quick DSL draws)
and you can use Archimate too. (<a href="http://www.archimatetool.com" rel="nofollow">http://www.archimatetool.com</a>)<p>Are you using RUP? <a href="https://en.wikipedia.org/wiki/Rational_Unified_Process" rel="nofollow">https://en.wikipedia.org/wiki/Rational_Unified_Process</a>
For software projects with new clients, I use cacoo.com and create simple domain and sequence diagrams to capture more complex workflows. I usually don't tell them it is UML and say these diagrams help better express workflows.
Yes.<p>If they're used as an analysis/design tool and not as a documentation-after-the-code-is-written tool, with tools that generate code from the diagrams, they are really powerful.<p>I work in Embedded Software and mainly use:
Use Case Diagrams, Statecharts, Sequence Diagrams, Component Diagrams, Class Diagrams. The 80/20 rule is true, and I think about 80% of the value comes from 20% of the entirety of UML.
In the past 2 jobs even though it was just small startups with less than 5 devs, we used them in relatively critical or complex cases, but it wasn't anything formal (e.g. for every major component introduced do this).<p>I personally like them, maybe because I like thinking of the big picture no matter the task, plus we had extensive practice on uni.
More than we tend to think. Less than I'd like.<p>But the key to benefiting from UML is to first decide what subset of the whole language you need and focus only on that. Very few companies will find a use for the 13 types of UML diagrams.