Ask HN: Is UML still relevant today?
Are UML diagrams worth to be designed? Are top technology companies still using it?
68 comments
If you learn only one diagram from UML, take the time to understand and use Sequence Diagrams [1].
Being able to break down an interaction into a sequence diagram (especially between 2 or 3 servers) is a powerful thought tool for specifying interactions and its easy for people to understand.
[1] http://en.wikipedia.org/wiki/Sequence_diagram
Being able to break down an interaction into a sequence diagram (especially between 2 or 3 servers) is a powerful thought tool for specifying interactions and its easy for people to understand.
[1] http://en.wikipedia.org/wiki/Sequence_diagram
+1 exactly right
I co-wrote a book on UML years ago, used to be an enthusiast. Now I write some sequence diagrams, and once in a while might write a high level class diagram.
It is all about communication, and a sequence diagram is good for that.
I co-wrote a book on UML years ago, used to be an enthusiast. Now I write some sequence diagrams, and once in a while might write a high level class diagram.
It is all about communication, and a sequence diagram is good for that.
I've always written off UML, but that is a sublimely useful notation. Thanks for sharing.
Sequence diagrams are extremely useful.
The only problem with UML is that it was used as a method of intellectual masturbation by people who love massive class hierarchies. There's a lot of good stuff in UML, the problem is that the people who were attracted to it in the mid 90s were the same people who were poor programmers and were looking for any excuse to avoid writing code. There are the same guys who spent years building up formalisms in tools like Rational Rose and other pseudo-engineering tools.
When used by good programmers to illustrate specific hard-to-reason about components of the system, it is a useful tool. Activity diagrams, sequence diagrams, use case diagrams and communication diagrams are all useful.
The only problem with UML is that it was used as a method of intellectual masturbation by people who love massive class hierarchies. There's a lot of good stuff in UML, the problem is that the people who were attracted to it in the mid 90s were the same people who were poor programmers and were looking for any excuse to avoid writing code. There are the same guys who spent years building up formalisms in tools like Rational Rose and other pseudo-engineering tools.
When used by good programmers to illustrate specific hard-to-reason about components of the system, it is a useful tool. Activity diagrams, sequence diagrams, use case diagrams and communication diagrams are all useful.
> the people who were attracted to it in the mid 90s were the same people who were poor programmers and were looking for any excuse to avoid writing code
Sounds like the same people who became Agile consultants in the early 2000's. Perhaps they realized activity and sequence diagrams can get fairly complicated soon enough, so they looked for a bandwagon requiring no technical chops whatever.
Sounds like the same people who became Agile consultants in the early 2000's. Perhaps they realized activity and sequence diagrams can get fairly complicated soon enough, so they looked for a bandwagon requiring no technical chops whatever.
Some of them became TDD consultants later on - it is more trendy now, although the hype is dying down a bit lately.
A great open source tool for these is http://www.mcternan.me.uk/mscgen/
Also https://www.websequencediagrams.com/
and http://www.umlet.com/ (if you need to do more then just sequence diagrams)
and http://www.umlet.com/ (if you need to do more then just sequence diagrams)
And I'd like to add js-sequence-diagrams: http://bramp.github.io/js-sequence-diagrams/
WebSequenceDiagrams also has a Google Docs add-on [1]
[1] https://chrome.google.com/webstore/detail/websequencediagram...
[1] https://chrome.google.com/webstore/detail/websequencediagram...
Thanks for that link! That's a great looking tool.
zenbowman's reply is [dead]. Why?
The most common cause of individual [dead] comments on an otherwise not-banned account is double posting. If you accidentally submit the same comment twice, the second one is killed. Since both show as live on your screen, when you delete one of the duplicates, you may delete the one that's live to everyone else, while leaving the one that's dead to everyone else.
I'm impressed that you got this exactly right. We've made a few fixes to try to plug this hole, but it unfortunately still happens.
I'm not sure, but I'm guessing it's because of the dismissive tone regarding early proponents. I lived through this period and remember being attracted to Booch notation and similar early efforts (as well as GoF patterns, etc.). Ours is still a relatively young profession and before UML codified some of the ways to view problems clearly (from a particular perspective), one was often reduced to writing out algorithms and data structures and diagramming in off-the-cuff ways.
Because business users can understand them and the process flow is important to them (entity-relationship diagrams work well too for modeling the data and establishing a basic glossary for future communication)
After that it usually turns out to be simpler to create a prototype or wireframe than UML diagrams these days (IMO).
After that it usually turns out to be simpler to create a prototype or wireframe than UML diagrams these days (IMO).
It set off a spam filter.
Presumably hellbanned, but on a quick perusal of the account's comment history, I don't see anything warranting that.
I am seeing it as not dead--is it possible the post was deleted then resubmitted?
You should read about it just so that you can read the acronym OMG over and over again. It makes all the UML related documentation hilarious. It's OMG this and OMG that.
For example, check out this 100% legit Wikipedia reference:
OMG (2011). OMG Unified Modeling Language (OMG UML), Superstructure, V2.4.1, p. 507.
OMG is short for Object Management Group, but the acronym has obviously not aged well, so what we are left with is a really funny, but totally unintentional joke. Like, check out these certificiations:
OCEB - OMG Certified Expert in Business Process Management (BPM)
OCUP - OMG Certified UML Professional
OCSMP - OMG Certified Systems Modeling Professional
OCRES - OMG Certified Real-time and Embedded Systems Specialist
Who wouldn't want to be OMG Certified?
For example, check out this 100% legit Wikipedia reference:
OMG (2011). OMG Unified Modeling Language (OMG UML), Superstructure, V2.4.1, p. 507.
OMG is short for Object Management Group, but the acronym has obviously not aged well, so what we are left with is a really funny, but totally unintentional joke. Like, check out these certificiations:
OCEB - OMG Certified Expert in Business Process Management (BPM)
OCUP - OMG Certified UML Professional
OCSMP - OMG Certified Systems Modeling Professional
OCRES - OMG Certified Real-time and Embedded Systems Specialist
Who wouldn't want to be OMG Certified?
UML is used in many companies, but learning it is probably not the highest leverage use of your time. Be forewarned that it comes out of the same general regions within the enterprise as WindowAdapterFactoryServiceLocatorFactory.
Personally, in about a decade of programming, I've only had call to say "You know what we need right now? A UML diagram, that's what." about two or three times, and it is always about a sequence diagram for fairly complicated protocols.
Personally, in about a decade of programming, I've only had call to say "You know what we need right now? A UML diagram, that's what." about two or three times, and it is always about a sequence diagram for fairly complicated protocols.
It depends where you work and who you work with. I'd say only about a quarter of the places I've worked since UML became popular have used them at all (yes - I'm an old fk who can remember before UML ;-).
Despite what some have said here I don't think using UML is an sign of technical chops, or otherwise. It's just a tool. Some people use it sensibly. Some people use it stupidly. Thus has it ever been.
People drew and draw representations of data, structure and flow long before UML was around, and will continue to do so in years to come.
People wasted a bunch of time writing diagrams which would have been more effectively spent writing code before UML was around, and will continue to do so in years to come.
People wasted a bunch of time writing code when they should have spent five minutes drawing a diagram to make sure they were building the right thing before UML was around, and will continue to do so in years to come.
I'd say the more important skill is being able to talk about data and structure and flow visually - and to know when the right time to do that is. UML is a nice common language to throw on top of that skill.
But UML is certainly not used everywhere. Never has been.
Despite what some have said here I don't think using UML is an sign of technical chops, or otherwise. It's just a tool. Some people use it sensibly. Some people use it stupidly. Thus has it ever been.
People drew and draw representations of data, structure and flow long before UML was around, and will continue to do so in years to come.
People wasted a bunch of time writing diagrams which would have been more effectively spent writing code before UML was around, and will continue to do so in years to come.
People wasted a bunch of time writing code when they should have spent five minutes drawing a diagram to make sure they were building the right thing before UML was around, and will continue to do so in years to come.
I'd say the more important skill is being able to talk about data and structure and flow visually - and to know when the right time to do that is. UML is a nice common language to throw on top of that skill.
But UML is certainly not used everywhere. Never has been.
TL;DR Yes but only the basics and only certain key diagram types
Of course it is! Now the verbose, overblown specs are only really useful for propping up your monitor (see http://www.omg.org/spec/) but fundamentally UML is all about a common way of discussing code, patterns, architectures and algorithms visually.
It's kinda handy to be able to sketch out something on a whiteboard and have everyone in the room be able to read what you have drawn.
[Showing my age] I was around before UML and there were any number of conflicting notations used to describe things... total chaos.
There are like 14 different types of UML diagrams which is complete overkill. You only really need to understand a few (at a high level) and you are sweet...
Roughly in order of usefulness:
* Sequence diagrams
* Deployment diagrams
* Use case model
* State diagram
* Activity diagram
* Class diagram
See more http://creately.com/blog/diagrams/uml-diagram-types-examples...
Of course it is! Now the verbose, overblown specs are only really useful for propping up your monitor (see http://www.omg.org/spec/) but fundamentally UML is all about a common way of discussing code, patterns, architectures and algorithms visually.
It's kinda handy to be able to sketch out something on a whiteboard and have everyone in the room be able to read what you have drawn.
[Showing my age] I was around before UML and there were any number of conflicting notations used to describe things... total chaos.
There are like 14 different types of UML diagrams which is complete overkill. You only really need to understand a few (at a high level) and you are sweet...
Roughly in order of usefulness:
* Sequence diagrams
* Deployment diagrams
* Use case model
* State diagram
* Activity diagram
* Class diagram
See more http://creately.com/blog/diagrams/uml-diagram-types-examples...
I mostly agree, but I would qualify this with saying you don't need to know exact UML. I wouldn't worry about filled in triangles vs. diamonds, just the big ideas.
Like everything enterprise, before it UML was wrapped in a three ring binder and sold by consultants it was created to solve a problem. That problem is; at the beginning of a project(or at cross-team-collaboration-bs-meetings) you'll have an idea in you head, a fist full of markers, and an empty whiteboard. How do you go about explaining that idea to everyone in the room? UML was an attempt at standardizing some of the boxes-with-lines schemes everyone invented.
Like everything enterprise, before it UML was wrapped in a three ring binder and sold by consultants it was created to solve a problem. That problem is; at the beginning of a project(or at cross-team-collaboration-bs-meetings) you'll have an idea in you head, a fist full of markers, and an empty whiteboard. How do you go about explaining that idea to everyone in the room? UML was an attempt at standardizing some of the boxes-with-lines schemes everyone invented.
It really depends what you mean by designing UML diagrams. From my personal perspective, UML is mostly a communication language, so that certain abstract concepts (class structures and hierarchies, message passing sequences, etc.) can be communicated using a common language. For example, if two people are to work on the same piece of code or two pieces of code that are to interact together, being able to sketch a quick class diagram or a sequence diagram so that both parties can understand what is happening is much easier than writing it in an unambiguous textual representation.
If you're asking about designing UML diagrams for tools that will automagically generate your application from diagrams, then I think that's definitely a different question. I haven't looked at what the current state of the code generation tools are, but when I looked at it several years ago, it didn't look very promising.
If you're asking about designing UML diagrams for tools that will automagically generate your application from diagrams, then I think that's definitely a different question. I haven't looked at what the current state of the code generation tools are, but when I looked at it several years ago, it didn't look very promising.
I'll admit it ... I drank the UML cool-aid and thought that someday we'd have code-generation directly from the diagrams (we do in part) and round-trip engineering (changes to the code automatically reflected in the diagrams).
Since then, I've become a lot more realistic and use the diagrams when they're the best method of communicating a conceptual or concrete thought. I rarely use class diagrams, but I find myself using sequence diagrams and deployment diagrams a few times a month. Occasionally I also use Use-Case diagrams when there's more complexity than can be easily included in a single user story.
Since then, I've become a lot more realistic and use the diagrams when they're the best method of communicating a conceptual or concrete thought. I rarely use class diagrams, but I find myself using sequence diagrams and deployment diagrams a few times a month. Occasionally I also use Use-Case diagrams when there's more complexity than can be easily included in a single user story.
No.
Proof:
http://www.google.co.uk/trends/explore#q=%2Fm%2F07x3g&cmpt=q
Interesting though, Grady Booch - the man who wrote the Ada text book I had to learn for university - is behind UML. Glad it failed.
Proof:
http://www.google.co.uk/trends/explore#q=%2Fm%2F07x3g&cmpt=q
Interesting though, Grady Booch - the man who wrote the Ada text book I had to learn for university - is behind UML. Glad it failed.
that's called "evidence", not "proof".
That is not exactly an accurate portrayal.
For instance add object oriented or test driven development: http://www.google.com/trends/explore#q=%2Fm%2F07x3g%2C%20%2F...
I would say that it's much more likely that UML is just one of the many tools that developers use, it just isn't generating any "buzz"
For instance add object oriented or test driven development: http://www.google.com/trends/explore#q=%2Fm%2F07x3g%2C%20%2F...
I would say that it's much more likely that UML is just one of the many tools that developers use, it just isn't generating any "buzz"
google trends is definetly not relevant! you cant draw any conclusion from anything especially when it's not clear what are the search volumes. They should throw that stuff anyway.It doesnt make sense.
Depends on how you define top technology companies, but many large software companies (5000+ employees) uses UML as a part of their systems architecture deliverables.
Whether they are worth being designed will very much depend on who you ask. The architect who spends a lot of time on designing them will of course be very much in favor. He might feel they properly communicate his architecture.
Certain business types might favor them, on a more simple account - they look deliciously technical and can be used to persuade a customer "we really know what we are doing".
My personal opinion is that certain diagrams can be useful. In general though, way too much time is wasted on doing these diagrams, which aren't going to be at all representative of the end system.
It's not a good communication tool, and it'll in most cases be hopelessly out of date just a few weeks or months into the project.
UML also smells of a top-down approach where the star architect is sitting in an ivory tower handing down blueprints to lowly developers. That kind of approach goes against what I believe about successful software development.
There's useful elements in UML and you definitely won't be worse off if you understand it. But I do not think it's in any way required unless your aspirations are to be developer /architect #2032 in BigCorp.
But again, it'll depend on who you ask.
Whether they are worth being designed will very much depend on who you ask. The architect who spends a lot of time on designing them will of course be very much in favor. He might feel they properly communicate his architecture.
Certain business types might favor them, on a more simple account - they look deliciously technical and can be used to persuade a customer "we really know what we are doing".
My personal opinion is that certain diagrams can be useful. In general though, way too much time is wasted on doing these diagrams, which aren't going to be at all representative of the end system.
It's not a good communication tool, and it'll in most cases be hopelessly out of date just a few weeks or months into the project.
UML also smells of a top-down approach where the star architect is sitting in an ivory tower handing down blueprints to lowly developers. That kind of approach goes against what I believe about successful software development.
There's useful elements in UML and you definitely won't be worse off if you understand it. But I do not think it's in any way required unless your aspirations are to be developer /architect #2032 in BigCorp.
But again, it'll depend on who you ask.
Lot of companies are moving away from UML but not away from modeling tools by using domain specific languages (DSL) instead of a language like UML which tries to please everybody. The Eclipse Foundation hosts lot of domain specific tools like Xtext (1) for textual DSL or Sirius (2) for graphical DSL. Both tools are even compatible since they are using the same underlying framework, the Eclipse Modeling Framework (EMF). With those tools, and others (have a look at all the modeling tools in the Eclipse Foundation), you can build a "development environment" for your own domain with your dedicated editors (syntax highlighting, completion, error detection, etc) and designers.
1: https://www.eclipse.org/Xtext/ 2: http://www.eclipse.org/sirius/
Disclaimer: I work for the company behind Eclipse Sirius.
1: https://www.eclipse.org/Xtext/ 2: http://www.eclipse.org/sirius/
Disclaimer: I work for the company behind Eclipse Sirius.
There was a presentation that tackled this question at the most recent ICSE conference. Here's the paper: "UML in practice", http://oro.open.ac.uk/35805/8/UML%20in%20practice%208.pdf
The author interviewed people from 50 different major companies, and found people's use fit within the following:
Category of UML Use, Instances of Declared Current Use
no UML, 35
retrofit, 1
automated code generation, 3
selective, 11
wholehearted, 0
From the conclusion: "The majority of those interviewed simply do not use UML, and those who do use it tend to do so selectively and often informally."
In my own experience and research, people draw extensively, but have their own shorthand for writing things specific to their domain.
The author interviewed people from 50 different major companies, and found people's use fit within the following:
Category of UML Use, Instances of Declared Current Use
no UML, 35
retrofit, 1
automated code generation, 3
selective, 11
wholehearted, 0
From the conclusion: "The majority of those interviewed simply do not use UML, and those who do use it tend to do so selectively and often informally."
In my own experience and research, people draw extensively, but have their own shorthand for writing things specific to their domain.
No. I have never known anyone that uses UML, outside UML coaches.
Our new SDLC includes UMLs and ERDs for all new projects. Sigh. For a Drupal site, really? (ok, to be fair we do a lot of mobile development too, but a blanket requirement seems silly)
FWIW, contractor working on government projects (DOD).
FWIW, contractor working on government projects (DOD).
UML is pretty lousy as a formal design language, but it's about the best we have. It's a pretty good communication tool though and a pretty good tool for documenting an existing system for later reference. Not all of the diagram types are equally useful, some are better than others. Sequence diagrams are really useful for example, but use-case diagrams are usually small enough that they aren't necessary.
Simple answer: it depends.
Different companies doing development (pure tech to Fortune level corporations) all have different requirements and environments. A small, fast-pivoting, ever changing start-up isn't going to need, want or have the time for all the detailed documentation a large, regulated Fortune X company will require.
That said, I think a knowledge of UML is beneficial to all levels, if just having a common modeling "language".
Start-ups can use selected diagrams (eg, sequence, deployment, component) to develop, work out and "document" the high-level vision, and maybe major bugs. Keep them light on details and flexible. Like a paper road-map, they show only the major things, and don't require much time to update.
Large and maybe regulated corporations (and even start-ups in regulated industries) will not only need, but require deeper levels of detail. Class, state and other diagrams. They get into the city-street level maps. But again, they can afford the levels of bureaucracy staffing (like "enterprise architects") required to maintain all the documentation.
Different companies doing development (pure tech to Fortune level corporations) all have different requirements and environments. A small, fast-pivoting, ever changing start-up isn't going to need, want or have the time for all the detailed documentation a large, regulated Fortune X company will require.
That said, I think a knowledge of UML is beneficial to all levels, if just having a common modeling "language".
Start-ups can use selected diagrams (eg, sequence, deployment, component) to develop, work out and "document" the high-level vision, and maybe major bugs. Keep them light on details and flexible. Like a paper road-map, they show only the major things, and don't require much time to update.
Large and maybe regulated corporations (and even start-ups in regulated industries) will not only need, but require deeper levels of detail. Class, state and other diagrams. They get into the city-street level maps. But again, they can afford the levels of bureaucracy staffing (like "enterprise architects") required to maintain all the documentation.
Yes,it helps communicate ideas between engineers and is not bound to any paradigm. UML can even be a great tool to communicate between devs and non devs.I ask my clients to draw actor diagrams all the time. It's often better than a long paragraph of text.
I'm not sure how any big team can work without using some UML diagram of some sort. SCRUM boards dont help writing code.
I'm not sure how any big team can work without using some UML diagram of some sort. SCRUM boards dont help writing code.
Outside of sequence diagrams:
Over many years as a indie developer, corporate developer, architect, engineering manager, product manager, technical founder, and CTO, I've never found the specifics of UML (which arrows and box types mean what, or its distinctions between different types of containment and relationships) to be useful. I've never been in a room with someone who admitted knowing UML, or where UML made a discussion shorter or easier. I've never seen architecture diagrams or sequence diagrams, in whitepapers, technical documentation, or engineering discussion, use UML. I'd hoped that at the least UML would introduce a shared vocabulary, but within my experience it hasn't.
Reading Fowler's “UML Distilled”, on the other hand, did teach me a lot about software architecture and design, and it also taught me to read the rest of Fowler's work, which has been equally rewarding.
Over many years as a indie developer, corporate developer, architect, engineering manager, product manager, technical founder, and CTO, I've never found the specifics of UML (which arrows and box types mean what, or its distinctions between different types of containment and relationships) to be useful. I've never been in a room with someone who admitted knowing UML, or where UML made a discussion shorter or easier. I've never seen architecture diagrams or sequence diagrams, in whitepapers, technical documentation, or engineering discussion, use UML. I'd hoped that at the least UML would introduce a shared vocabulary, but within my experience it hasn't.
Reading Fowler's “UML Distilled”, on the other hand, did teach me a lot about software architecture and design, and it also taught me to read the rest of Fowler's work, which has been equally rewarding.
just want to second uml distilled. if you need to use uml you should read it - it's very slim and very practical. http://martinfowler.com/books/uml.html
also, uml with a tool like enterprise architect (which is basically a set of gui interfaces onto a database, where you construct a design in the database using the views, and are forced to be consistent) is very different from sketching a few diagrams.
it's not for me, but with a good tool you can see the attraction in certain scenarios.
also, uml with a tool like enterprise architect (which is basically a set of gui interfaces onto a database, where you construct a design in the database using the views, and are forced to be consistent) is very different from sketching a few diagrams.
it's not for me, but with a good tool you can see the attraction in certain scenarios.
Nope, learned about it during college and had to present every project I made using it (ugh...) and I haven't used it -once- in the real world. Nobody cares.
Learn how to diagram sequences and that's about it. The rest is just a fancy way to charge $150/hr consulting fees for 'architecture.' Utterly useless these days.
Learn how to diagram sequences and that's about it. The rest is just a fancy way to charge $150/hr consulting fees for 'architecture.' Utterly useless these days.
No.
In embedded software development some companies use Rational Rose (state digrams) to specify behavior and perform model checkings. So YES top companies use it but not the kind of top Rails or mobile software company that you usually see in HN. And No it's not used a lot.
I think UML is a nice communication tool for the general purpose development (just the basic syntax of UML). But not more than that, please don't specify an app in UML, is just bullshit.
However, in embedded software development it makes sense to specify the system using UML (like some very important controller software). Why? Because the system is very small (so you can model it) and you need a high certainty that it will perform as it it supposed to (you can perform model checkings and validation).
Otherwise UML is just a nice way to have a common language in the whiteboard.
I think UML is a nice communication tool for the general purpose development (just the basic syntax of UML). But not more than that, please don't specify an app in UML, is just bullshit.
However, in embedded software development it makes sense to specify the system using UML (like some very important controller software). Why? Because the system is very small (so you can model it) and you need a high certainty that it will perform as it it supposed to (you can perform model checkings and validation).
Otherwise UML is just a nice way to have a common language in the whiteboard.
I think I spent three years in college getting examined on UML diagrams of all sorts. There is so much detail you can put into a UML diagram that means so much, like arrow heads mean class A implements interfface B. I have never seen anyone in work life ever use that much detail. I have done 100s of sketches of class diagrams and sequence diagrams but never have I made one that would fit the rigid rules of UML diagrams.How can there be so many rules for drawing lines between boxes?
I once did create fully compliant UML diagrams for a requirements document. The next day half the team emailed me back asking what all the box types, arrow heads and broken lines meant. Honestly, simple sketches with annotations have served me so much better than following the rigid rules of UML.
I once did create fully compliant UML diagrams for a requirements document. The next day half the team emailed me back asking what all the box types, arrow heads and broken lines meant. Honestly, simple sketches with annotations have served me so much better than following the rigid rules of UML.
No. TL;DR: Drawing is useful, UML is not.
For database designs, textual schemas, E/R diagrams or plain SQL are sufficient. I've drawn plenty of state diagrams without crediting UML handbooks. E/R diagrams can double as "class diagrams" in the sense that you don't need all the complexity of properties and methods in a diagram to convey which classes exist and how they're related.
People who think that drawing bubbles with arrows between them is a language, in more than a philosophical-linguistic sense, should probably take some more certificates.
To be fair, and to repeat some answers I've read so far: Of course, some diagrams are very useful. But to credit UML because individuals find it useful and necessary to draw things is stretching it.
For database designs, textual schemas, E/R diagrams or plain SQL are sufficient. I've drawn plenty of state diagrams without crediting UML handbooks. E/R diagrams can double as "class diagrams" in the sense that you don't need all the complexity of properties and methods in a diagram to convey which classes exist and how they're related.
People who think that drawing bubbles with arrows between them is a language, in more than a philosophical-linguistic sense, should probably take some more certificates.
To be fair, and to repeat some answers I've read so far: Of course, some diagrams are very useful. But to credit UML because individuals find it useful and necessary to draw things is stretching it.
Yes, but it is also useful having a standard way to express some of the things in your diagram.
I work for a very object-oriented customer, and I find class or object diagrams useful (for example, to take notes about an unfamiliar system being explained to me, like expressing precisely and concisely that Permissions are granted either to Employees or Groups of Employees, and not associated to the Employee's or Group's parent OU directly) much more often than sequence diagrams (typically used to document boring and straightforward odysseys of method calls through layers and layers of indirection, not interesting protocols).
All non-bullshit UML diagram types are going to be valuable sooner or later in one's career; basic familiarity with all of them is a useful language skill.
All non-bullshit UML diagram types are going to be valuable sooner or later in one's career; basic familiarity with all of them is a useful language skill.
State charts can be a powerful method for rapid prototyping of embedded systems if you use a minimalist code generation tool like Quantum Leaps QM.
It is a little difficult to get a hang of, but with familiarity it greatly increases the speed at which I can iterate on designs.
See: http://state-machine.com/qm/index.php and http://www.amazon.com/exec/obidos/ASIN/0750687061/quantumlea...
Note: I am not affiliated with Quantum Leaps, but I have found the tools to be very useful.
It is a little difficult to get a hang of, but with familiarity it greatly increases the speed at which I can iterate on designs.
See: http://state-machine.com/qm/index.php and http://www.amazon.com/exec/obidos/ASIN/0750687061/quantumlea...
Note: I am not affiliated with Quantum Leaps, but I have found the tools to be very useful.
As an illustrative anecdote, I spoke at Code Generation 2010 in Cambridge, UK on real world DIY code generation from found models in a normal software practice. The event was attended by people from the Object Group, who are responsible for UML. I used the phrase UML Hell as something to avoid in my talk, and it garnered much amusement and understanding. I was even audience rated near highest for a first time speaker in the history of the event and invited back to speak again... but it's a long way to fly from Asia! I don't use UML today, but encourage documentation and automated diagrams where appropriate.
You don't "design" diagrams, they are design tools. The point is communicating and formalizing models to iterate ideas more quickly and cheaper than coding or prototyping (of course, they work up to a point). They are ways of visualizing interactions, states, operations and so on, the "heart", the main "idea" or "the point" of a system in a way that implementation details don't get in the way of the main innovation and/or core value added.
It's a really useful skill.
...but "UML" as a brand to add to your resumé is pretty much useless.
It's a really useful skill.
...but "UML" as a brand to add to your resumé is pretty much useless.
Here's another way of putting it:
Are squiggly boxes with lines and words in them still usefull? And maybe we should have some convention around them squigglies?
Well, considering you're reading this on a screen filled with squiggly boxes and lines and words, yes, I'd say that much is still useful.
The advantage of UML, as with any standard, is that it is a universal way of drawing those squiggly lines and boxes. If you've ever tried to draw a software representation, you'll realize its actually quite difficult to do.
Until language and conventions stop being useful, UML will remain.
Are squiggly boxes with lines and words in them still usefull? And maybe we should have some convention around them squigglies?
Well, considering you're reading this on a screen filled with squiggly boxes and lines and words, yes, I'd say that much is still useful.
The advantage of UML, as with any standard, is that it is a universal way of drawing those squiggly lines and boxes. If you've ever tried to draw a software representation, you'll realize its actually quite difficult to do.
Until language and conventions stop being useful, UML will remain.
I don't think so; but there may be disciplines that find benefit from it.
However, there is one element that I still use and find very useful--time sequence diagrams. Like tracking web requests and responses and communications with back ends, for example.
And often used, but not really exclusive to UML are state diagrams. Certain problems are elucidated nicely that way.
There may be some enterprise, governmental, or aerospace environments that benefit from it or are required to use them.
However, there is one element that I still use and find very useful--time sequence diagrams. Like tracking web requests and responses and communications with back ends, for example.
And often used, but not really exclusive to UML are state diagrams. Certain problems are elucidated nicely that way.
There may be some enterprise, governmental, or aerospace environments that benefit from it or are required to use them.
Like a few have pointed out, it depends, but even then not the whole beast. Certain few diagrams are useful in the early stage, where having diagrams is fastter to communicate ideas and concepts across. Other than that UML is a wastage of time as the software base evolves - it cannot pace itself well to that dyanamism and agility; it has no inbuilt dialectical characteristics. However, document core stable parts could be done. I personally do not know any body who does though.
Learn to sketch UML (not use it as a formal development language) -- it's incredibly useful if you don't get too caught up in formalities. "UML Distilled" by Martin Fowler is a tiny book that teaches you enough to sketch it.
I made a UML cheatsheet a while ago for a talk:
http://loufranco.com/blog/uml-cheatsheet
I made a UML cheatsheet a while ago for a talk:
http://loufranco.com/blog/uml-cheatsheet
Only for consultants for milking money from clients.
Yes ... hierarchical UML state charts are best in class for their niche, sequence diagrams are useful too. I use both for a Firebase abstraction layer: https://github.com/tomlarkworthy/firesafe/wiki/Send-Item (state chart is at bottom)
UML is something that shouldn't be avoided nor encouraged. Is a mere tool to represent code in a graphical and compact manner.
"Worth to be designed?", depends on your situation, you tell me. If you don't know if you need you probably don't need at all.
"Worth to be designed?", depends on your situation, you tell me. If you don't know if you need you probably don't need at all.
[deleted]
Was it ever "relevant"?
Diagramming out a system can be very useful. Strict UML is no as important today. I learned a lot of UML in university and have never used it once. I did a rough diagram of a process once, but that was just for communication.
If not UML, what do you recommend for most effective communication?
ERDs? Documentation tools? Or do you simply tell the engineer to read the code?
ERDs? Documentation tools? Or do you simply tell the engineer to read the code?
Yes, just read the code (and whatever textual documentation comes along with it). The best I can hope for is a set of OO interfaces that is really well-described in their comments. And some oral presentation/walkthrough. And some small tasks to get me acquainted with a new codebase. If there's a large library, some HTML-based documentation, perhaps even with examples, is very fine.
No. Except maybe sequence diagrams.
No.
Yes!
Here are a couple recent research papers that basically say no, UML isn't used much in practice.
http://www.gorschek.com/doc/publications_files/GorschekTempe...
http://oro.open.ac.uk/35805/
(via Erik Meijer on Twitter)
http://www.gorschek.com/doc/publications_files/GorschekTempe...
http://oro.open.ac.uk/35805/
(via Erik Meijer on Twitter)