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.
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.
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.
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).
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 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.
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.
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.
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).
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.
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.
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.
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.
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.
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)
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...
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.
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.
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.
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.
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
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.
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.
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.
68 comments
[ 6.7 ms ] story [ 281 ms ] threadSince 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.
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
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.
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.
and http://www.umlet.com/ (if you need to do more then just sequence diagrams)
[1] https://chrome.google.com/webstore/detail/websequencediagram...
After that it usually turns out to be simpler to create a prototype or wireframe than UML diagrams these days (IMO).
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.
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.
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"
FWIW, contractor working on government projects (DOD).
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'm not sure how any big team can work without using some UML diagram of some sort. SCRUM boards dont help writing code.
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.
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.
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.
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...
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.
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.
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.
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?
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.
It's a really useful skill.
...but "UML" as a brand to add to your resumé is pretty much useless.
"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.