21–30 of 69 posts
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
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...
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.
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
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?
No. I have never known anyone that uses UML, outside UML coaches.
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
A great open source tool for these is http://www.mcternan.me.uk/mscgen/