1. To make theory more closely match practice that already works. This gives teachers something to teach.
2. To make someone who doesn't know what he's doing appear as if he did. This gives consulting firms profitability.
3. To help organize the System Development Life Cycle (waterfall process) of very large projects. This gives someone who knows what they're doing a few more tools in their toolbox.
My take? If you've really found good use for tools like these, then your project is probably too big. Break it down into smaller pieces, build a prototype for each piece, get feedback, and refine. It's not how quickly you appear to get started; it's how soon you deliver something of value.
Many software projects /are/ big. Many of them are complicated and monolithic, written by "someone else", unrefined, and quite possibly the first thing that they managed to get working. I find UML diagrams (sequence, class etc) invaluable for understanding code like this, as a reverse engineering tool.
"An occasionally invaluable tool" is how I could describe UML diagramming.
Engineering blueprints are the "code". They are intended to be read in a systematic manner by someone who can put the parts together. In software, we call that someone a compiler.
Design documents, such as sketches, artists renderings, specifications of performance, etc., may or may not be useful to the engineer producing the blueprint. The discussion of UML is at the level of these artifacts. If UML is useful, I want to look at it and have an idea of what the software is going to do. Some parts, like event-state diagrams, activity diagrams, and use cases, are pretty good at capturing that design in a way that I can talk about it with someone who doesn't understand code. I would not pay someone for completing a document like that, though, not until it was reflected in code.
Another way of capturing design is through functional tests. Look at projects like Fit for examples of how that might work.
This is a completely philosophical discussion, but I do not think blueprints can be the code, since blueprints in every other industry still leave a degree of freedom for the final implementation and in the software industry code IS the final implementation.
Good things are not designed in this fashion. I'm sure everyone else in the aviation industry used the uml equivalent, I'm pretty sure the skunkworks teams do not.
It was hard for the skunk works teams to use UML for a long time since it was only published in the late 90's, but what makes you so sure they are not using it now? or do you have a survey of which "good things" are not designed in this fashion?
And besides what is the relative share of skunk works type teams from the overall software development market?
UML does NOT equal CASE. Yes, you can use MDA and other techniques to somehow convert UML and OCL into a quasi-CASE tool, and there are lots of folks excited about UML as part of a code-generation tier, but UML is a specification for drawing technical diagrams. That's it.
UML is also not a methodology. Yes, there are methodologies that rely on bits of UML but that's a one-way association. You can use UML all the time and never do a bit of any kind of methodology.
UML is also not for large projects. Yes, it helps to diagram things instead of writing them out, especially if you have 100 developers or more. But drawing things can help teams as small as two people. Heck, drawing things can help a sole developer.
You need to be clear about the question if you would like to get a meaningful answer. UML is for drawing pictures in a consistent way. So is the question "Do real developers draw pictures consistently?" Because in my teams, we use UML when we need to sketch out things so that everybody has some baseline to understand what's being drawn. It has nothing to do with generating code, completing a process, or being part of some huge team.
I liked this comment: If a diagram takes more than 5 minutes to sketch on the back of an envelope it is generally too complex
I might extend it to 15-20 minutes, but the gist here is correct, at least for small teams. Different story entirely with large teams, though. With a large team, having a visual roadmap of where things are and where things go is hell of a lot better than trying to type it up in a Word document or teach people by random story-telling. (It should still be pretty simple, though. The purpose is communication, not documentation or showing people how detailed you can make something)
I prefer to use UML as an output language, never input. It's good to come to foreign codebase and generate visual presentations of its hierarchy and flow graphs.
As an input language, created by hand? No, not really. It's mostly something for java/.net architecture astronauts: often used only once, to generate the cruft that will be the project directory hierarchy, but it's brittle and grows quickly out of touch with code & documentation.
As a fake developer (i.e. PhD student in Computer Science who did very little programming) I used UML, MOFF, and other such tools extensively. I've worked on the GME from ISIS at Vanderbilt and Ptolemy from CHESS at Berkeley. The one point that my thesis advisor - Janos Stipanovitz - made brutally clear whenever we were discussing Model Integrated Computing was that the value is not in building a better IDE that makes programmers more efficient. The value is in building analyzable frameworks that you can use in safety critical systems to show that your system adheres to the safety specification that you have to meet. So, I don't think there are any programmers who would benefit from these tools, but they absolutely do benefit system engineers building fly-by-wire airplanes, nuclear reactors, Mars rovers, etc...
Now, I am starting to work on a web-ap with a designer and I find that State-Charts are a great way for us to spec out the application. We're not trying to generate code from these but my partner is such a visual thinker and learner that State-Charts are a much more appropriate way for us to communicate than a spec written in English.
These tools serve two, very useful, purposes that aren't often readily apparent unless you have to use them.
1) Organize complexity. UML, for example, is extremely useful as a language capable of describing complex information systems -- just like the periodic table organizes chemical elements or the biological classification taxonomy organizes life -- or perhaps a better analogy are skeletal formulas in chemistry and life sciences.
You can probably get away with not using this language on small projects, maybe less than 10 people and under a quarter million lines of code. But on larger projects, 300 developers on one project spread over a continent and tens of millions of lines of code, some kind of formal organizational method becomes a necessity. Ad hoc diagrams just don't really cut it. You'll be glad to know that UML is not just stick figures anymore, some of the other diagrams do a much better job at modeling and organizing deeper into the design than others.
But like I said, the utility doesn't really become apparent until you deal with this kind of scale.
2) Communication. Similar to the above, but distinct. UML also provides a lingua franca for communications between business people and tech people. It forces business users to apply a rigid logic to their requirements (which can often become contradictory if not controlled by some kind of formal framework) which aids in communicating with engineering staff and forces engineers to stop talking about code and to talk about higher level abstracts that are more easily relatable to business people. The ability to actually communicate between these two parties has been extremely powerful.
In smaller organizations, the business people are quite often the tech folks as well so this isn't as necessary to have. But in most traditional companies, business folks have almost no way of communicating with the engineers in any constructive way without something like this.
On first look UML looks like the "proper" way of building software, but it really isn't because software changes way too much while it's built. It's like planning out a road-trip to the minute - it won't hold up. Some compare UML to how architects use blueprints to build brick-and-mortar stuff, but concrete walls and ceilings don't move midway like software does (figuratively speaking).
IMO software process is all about controlling complexity. When the problem is small, our human mind can come up with ingenious solutions no computer can match. So it's better to break down the project into small, modular, and testable components rather than try to overcome the complexity with fancy plans that will start breaking down the moment you start implementing.
UML could be useful for documentation purposes though, giving a bit more info than say Javadoc. But that will come after you write the software, not before. There are some tools that claim round-tripping (i.e., you write your UML, the tool magically generates code, you edit the code, and the tool magically updates the UML to stay in sync). I tried a few and found them too painful to use.
I'm distrustful of people who make lots of diagrams; it indicates to me that they may not actually know how to create the thing they're drawing, and thus lack the capacity to make truly sound decisions about it.
I've found UML-y diagrams to be useful it a few cases:
1. When sketching out an object model in a statically typed language, it helps to see the whole thing at once. The class diagram tool in later versions of visual studio is a nice compromise between functionality and usability for this case; it's easy enough to generates the code, but it's easy to ignore the diagram and do real work when you're ready.
2. When talking about system interactions with people via email, sequence diagrams can be useful. http://www.websequencediagrams.com/ is by far the fastest and easiest way I know to make them; trying to use a GUI tool is an exercise in frustration.
3. If my system has some internal structure I want to draw for people, I output graphViz data and let it draw the picture for me. Pictures generated in this way are always up to date.
I don't know that I've EVER kept a diagram around as a piece of documentation; they're invariably wrong after a short amount of time. In fact one of my favorite things about the visual studio diagrams is that they break if you change the code out from under them.
UML and case tools were all the rage 5-10 years ago, but have fallen out of favour with the rise of Agile methodologies. I have a feeling* that the teaching of software engineering at university lags about that same distance behind current industrial practice. So in another 5 years time I'd expect universities to have largely abandoned teaching UML except for in certain niche classes.
* I don't have any facts to back this up, it's really just a guess.
Keep in mind that many parts of industry itself lag 5-10 years from the leading edge of industry. And the parts of industry many universities track--i.e. the large firms that employ graduates by the dozens--are not the companies on the leading edge. This is probably more the case for your middle tier state universities than for Stanford or something, though.
I used a lot of diagramming tools (just out of my head):
Flow Charts (later criticized for encouraging GOTO)
Syntax Diagrams (similar to BNF/EBNF grammars)
ERD - mainly database stuff
UML - complex C++ systems and recently for Erlang gen_servers
MSD - message sequence diagrams
StateCharts(and FSM diagrams in general)
They are all useful for documentation or for meetings as a communication tool.
When working on huge waterfall projects in C++ I just wrote the code stub first and then run reverse engineering tool for UML class diagram generation - it's easier than drawing the diagrams yourself.
The problem with UML class diagrams may arise in large organizations, when Architects can be tempted to put many small rectangles on UML class diagram, frequently forgetting, that each such rectangle can be days or weeks of work for a programmer to fully implement, debug and test.
FSM and MSD are especially useful, even for non-OOP languages like Erlang/OTP.
If you learning new grammar or writing parsers - Syntax Diagrams can be useful too.
In recent years I just switched to using web-based and offline tools to generate diagrams from text (GraphViz/dot/msd/ditaa/etc.)
These are listed in decreasing order of ceremony. You can find "real" developers, somewhere, using all four of these.
A better question might be, at least in this community "will UML be useful for my startup". My answer to that question is "check out state diagrams and sequence diagrams and leave the rest behind" and use some form of Data Flow Diagrams.
In a very young project, it is likely that you will need to throw out the code you have written and start over. The less ceremony (translating to time) you put into the stuff that you throw out, the better off you are. If you are working in a category 5 CMM outfit, then that is a whole other story entirely.
By the way, methodology #4 (JSC) is Just Start Coding.
I used to use these tools much more extensively when working in more formal, water-fall-ish, slow, more arcane development environments; nowadays I use UML only for documentation after the fact. Specifically, the only place I use UML is after feature X has been implemented and tested, and if it is reasonably complex where just reading the code and tests can get you there, but a couple of high level visuals with some text that describe design rationale would get you there much quicker...well then, I try to be a good netizen and jot that info down. Can't tell you how many times people have thanked me for that. That said, UML is a lot easier to do this with vs. any other visual tool. It is standardized, and most people can read it fairly easily. On a side note, I've found Sparx Enterprise Architect to be the best tool out there for UML.
I wonder where the asker's degree is from. With the exception of entity-relation diagrams in my Database course, my CS degree didn't touch any of the things he mentioned (I haven't even heard of some of them). Even my DB course didn't focus much on ER diagrams; a significant chunk was over relational algebra.
There was one professor I had to deal with that required a UML for every assignment, sometimes the UML was to be turned in before you got assigned the code. In either case points would be docked if your UML didn't match your code.
Solution? I coded all my projects before the UML deadline and turned in a screenshot from XCode's UML generator.
That's how I got through all my uni assignments that required UML. I just hacked it together in the agile style and then generated UML diagrams in svg after the fact.
I think it is difficult to get fair answers to this kind of question, because mostly people who use UML will answer. All those developers who never use UML probably do not know enough about it to feel confident criticizing. Or they just find other discussions more interesting.
I'm currently doing a computer science (& maths) degree and within the CS department there's two main degree schemes: information systems, and computer science.
The latter is programming, i.e. the more technical side of things. The former is more about the IT/business consultancy side of things.
The former group hate programming, but there's a large emphasis on UML and other such 'design' 'tools' within their course.
We (the computer scientists) never tend to use UML or CASE tools though.
So yeah, I have no real World development experience yet (other than helping out in a couple of relatively big online projects), but it does seem to me that programmers ('real developers', as the title puts it) don't use UML and other such 'tools', whereas the IT consultancy side of things tend to use them.
Personally I don't. I started off with data flow diagrams and similar top down design methodologies which I'd been formally taught, but it's very difficult to keep your software and your diagrams in line and over time the diagrams become more and more spaghetti-like, to the point where they're no longer useful.
The best methodology seems to be the unix-like approach of dividing the problem into small self-contained programs for dedicated tasks which are then strung together as needed. This allows development to proceed in a flexible way, without having to waste a lot of time re-drawing impossibly complicated diagrams. Instead of a hierarchy of programs you can think of this as being an ecosystem of programs.
Not really. Generally speaking, some projects use a few of them for some communication, but generally speaking, they're not used anywhere to the degree they're portrayed they are in classes.
That said, I've seen them on white boards (and drawn them myself) or tossed some in documentation occasionally, but they're relatively rare.
Except for all the times when Real Developers have to use tools which may not be the best due to various constraints but they go ahead and do it anyway because they're Real Developers and not Magpies looking for shiny objects.
I would say yes; alot in places where security is key. These types of model are also generated when doing different types of analysis as well. Day to day use not alot but when you getting familiar with something its priceless.
This is a great point. We always focused on safety critical applications when I was in school but security is another area where having a clear and consistent architecture is a hard requirement. This is a great example of an area that would benefit from having an analyzable framework in place.
Getting my masters in computer science was the only time I ever used those tools (thankfully). It was somewhat helpful to learn a few of the UML diagrams as they are referenced in design pattern books, etc. - but I've never had a desire to create my own diagrams, let alone use a tool to create them for me.
To me, being familiar enough with UML to sketch efficient and consistent diagrams on a whiteboard or whatever has justified the time spent learning it. I don't care about absolute correctness, but just having the reserve of ideas to draw from when you are trying to communicate a complex idea to a group of people has proven valuable to me throughout my professional career.
This is a funny topic. The best developers generally solve a problem by using high level abstractions. They would usually (in my humble experience) make some drawings on a piece of paper or a white board, before writing any code. UML&Co tried to teach average developers this method, but lost focus, bloated and are hated by real developers nowadays.
1. To make theory more closely match practice that already works. This gives teachers something to teach.
2. To make someone who doesn't know what he's doing appear as if he did. This gives consulting firms profitability.
3. To help organize the System Development Life Cycle (waterfall process) of very large projects. This gives someone who knows what they're doing a few more tools in their toolbox.
My take? If you've really found good use for tools like these, then your project is probably too big. Break it down into smaller pieces, build a prototype for each piece, get feedback, and refine. It's not how quickly you appear to get started; it's how soon you deliver something of value.