Slashdot Mirror
How Do You Use UML?
christophe.vg asks: "We are currently investigating the feasibility of a new (open source) project and part of this study involves a scope definition of how people/developers currently actually use UML. So there it is: How do you use UML? Do you use it to have nice class diagrams to pin up to the wall so you/it just looks great or do you first model out every little detail into class and sequence diagrams before generating or writing even one line of code?
Now for a moment, let's dream the UML dream. Do you think that in the future one could maybe even envisage software development where UML could simply replace all existing coding languages? One could argue that coding languages are merely formatting tools to implement the actual logic, which can be portrayed 'in a Unified way' using UML schemas. What are your ideas regarding the real merits of UML, currently and in the not so distant future?"
...documentation afterwards. That's logic!
Wouldn't Parrot, or similar approaches that let you code in whatever idiom you feel most expressive in, while compiling down to efficient, cross platform bytecode be the pentultimate achievement? You could add a module for UML and let those crazy Visio programmers write what they wanted while leaving the C Programmers alone?
...But I digress. TREMBLE PUNY HUMANS!ONE DAY MY SPECIES WILL DESTROY YOU ALL!
The way I use UML is as way to select projects I want to participate in. If it uses UML, I'm out. The correlation of using UML with rigid authoritarian organization and fighting with "productivity enhancers" rather than developing software is too high.
It's a pity, because visualizing the structure of a program can be a Good Thing. Still, the idea behind UML isn't exactly new, and does not seem to be very successful historically.
Please correct me if I got my facts wrong.
In late 1998, I was working for a small company that decided to explore this new-fangled UML. A group of about 10 of us took a week-long course on it, and learned the basics of it. We decided, as a practice project, to re-implement one of our small subprojects with UML. We spent a few hours a week working on this.
When I left the company in April of 1999, we had made no signfigicant progress on the project.
UML is useless because it can largely not be meaningfully verified, kept up to date, or executed. As a communication language in the middle of a design session a simplified version of it has a place, but there's little point in trying to drive development with it.
I can't point to a project that does everything UML tries, only it works, because state of the art has not advanced there yet, and anyone telling you otherwise is selling you something, be it software or an agenda.
But I do know one thing that you must internalize: If it doesn't execute, automatically, it won't be kept up to date.
The best thing I've found so far is a strong coding style that emphasizes readability above most everything else (none of this "np_doSCRTtrd" crap, give me "mainWindow" or something... even in C++ where this is strongly counterculture), comments for why the code is doing what it is doing, and unit tests to provide and verify specification compliance.
Nope, that's not complete; it is difficult to borderline impossible to unit test everything. But this will take you far past anything UML can do reasonably, so it's a start. (I'm inclined to think the way forward is to make more things more testable; while unit tests have problems with multithreading even in theory, a lot of the practical problems one encounters comes from a lack of testability built into libraries. The canonical example of this is GUI libraries; there is no fundamental reason GUIs should be hard to test... if you could post events to simulate anything the user might do, that alone would nearly be enough, and you'd think this wouldn't be hard...) It's just the best I know, and, like I said, as far as I can see it handily defeats UML in every way that matters to me, so the fact that it doesn't fulfill the promises of UML doesn't bother me, especially as I'm not convinced anything can.
At least somebody should mod parent Insightful. You can't fully design your program in advance, because you're always going to run into issues, and because the requirements will be different when the implementation is done.
This is exactly the trap most UML users fall into, which is why I avoid UML like the plague. Design and document as you code. Hardly any project is ever finished, and the design and documentation shouldn't pretend otherwise.
Please correct me if I got my facts wrong.
I rarely use UML. Sometimes in class they force us to use it for things, even grade us on it. But its just a waste of time really. The problem is that some people use UML to layout the design for their application in full, or part, and then build the software following that design. But inevitably the design goes through a thousand changes. Most often a simple flow chart is quicker to make and more useful for this purpose.
What UML IS good for is communication. If you have a software design and you want to communicate that design to someone else, then UML is a handy tool. It's also useful for division of labor. You can make UML for the project and divide up the pieces of the diagram each programmer has to do. But in this situation you're really just commicating the design to each other, which is all UML is really good for.
The idea that one day we can just make UML and not have to code in C or something is ludicrous. If we move away from "real" coding it will definitely be to a much more abstract tool than UML which will write code for us. You can see it happening already like all the drek that Visual Studio comes with.
The GeekNights podcast is going strong. Listen!
It stands for "Three Letter Acronym."
-30-
That's a very interesting take on some specific issues one often comes across when trying to use UML.
Personal experience has shown that some of the features of UML are useful. We often use class diagrams to help new developers on the project get quickly up to speed. The class relationship information, which is what they need, is more densely represented in UML than as code. That said, we rarely use most of the other artefacts. Pseudocode and flowcharts often seem to work much better.
When it comes down to it, UML is sometimes a useful communication tool, but that's about the extent of it. When you have a bunch of developers who communicate better in some other way, you use that instead.
The other parts of UML I do not find so useful. I mean, I could just use regular flowcharts, state tables, or class declarations instead of the UMLized equivalent.
UML is just a way to describe your software requirements and design. Heck, you can even use regular English prose if you like, just like the good old days.
The art is to know how much modeling is enough. This depends on the development tools you're using (languages, IDE's), the problem you're trying to solve, and the skill level of the developers and "buyers" of the project. I find it most useful at a higher level of abstraction: activity diagrams are really good afor understanding business processes; a high-level object model is usually a good thing to have early in the project definition phase; and I always want a convincing story on object life cycles before we start: this probably involves realization and sequence diagrams.
I seldom use more than 20% of the semantic richness of UML-- I use it more to "rough out" a description of objects and their behavior. Part of the reason for that is that there is no value in using UML to replicate capabilities that are already built into the development tool suite. And detailed modeling of stuff that doesn't matter is just bullshit. Anyone who documents every page on a website with a sequence diagram that basically tells you nothing should be taken out back and shot. Since I'm usually the tech lead on projects, I'm the one who tells the clients what we use and why. And if they expect some UML feature that we're not using, I tell them why we're saving them money by tailoring it out. If your management aren't capable fo doing that, they aren't fit for their jobs.
My main point is that UML is a common language to make analysis and design more effective. It's only useful when it does that. Knowing when it's helping and when it gets in the way is a judgement call for which somebody had better be prepared to take responsibility. Unthinkingly doing everything everytime to insane levels of detail is nothing but a shameful waste of resources. It should be the yeast, not the flour, in your loaf of bread. It cannot take the place of intelligence.
Get your teeth into a small slice: the cake of liberty
I use UML to design and document apps I write, when it's helpful. Usually for apps it takes longer than an eight hour day to write, and will see change in the future. It provides a birds-eye view of what the app is doing, and how it represents data.
How many open source projects do you see that come bundled with documentation cleary explaining how its internal structures look and relate, and how the program was intended to behave? If you answered "Few to None", you'd be today's winner! Monty, tell 'em what they've won!
UML is a visual modeling *language* used to communicate program behavior and data structure concepts with others (mostly humans), typically in an object-oriented context. As a bonus, there are quite a few visual modeling tools that work with UML. Some emit corresponding code in Java, Python, C++ and a handful of other languages. Some are OSS/FS, while others are proprietary and pricey.
UML is also handy when weaving Design Patterns into your application framework. If you're into designing your applications before you code them, you probably know about Design Patterns and the GoF book. Design Patterns are another kind of *language* for communicating about structure and behavior.
I'm not saying the only way to design an app is with DP and UML, but together they are very effective at communicating data structures, how objects/structures are to be constructed, and program behavior. Which, not coincidentally, are the three main categories of code patterns described in the GoF book.
The main point of UML is clear communication; for DP it's creating solid designs. To create an application that works well (does what's intended, doesn't need refactoring/rewriting when new data formats or behaviors are expected in the future), and is easy for other programmers to pick up (program logic easily understood, relationships between classes and other structures easily identified and grokked), it is good to choose a common language to communicate those things, besides the one the app is written in.
For the folks who pedantically attack UML as being part or product of an authoritarian regime - well, it's just a tool that helps you get your job done, and communicate effectively with others. Sometimes it will get used by hardliners I suppose. The flip side to that is, are you communicating clearly and consistently?
Maybe that doesn't matter to you, but maybe also you would be better off for expanding your personal toolset, and making yourself better understood.
Big Daddy, Johnny, Burp, Aunt Zelda, Scott, Slurp, Big Momma
A few years later, I did some work for a major aerospace concern that had brought in an army of UML consultants to completely re-org the way they built their flying machines. They had literally wallpapered an entire floor of an office building with UML diagrams. Needless to say, nothing ever came of their delightful illustrations (other than relieving the corporate coffers of much coin).
UML has unfortunately become an industry with lots of fancy GUI tools to draw pretty pictures, purporting to magically generate code from committee meetings. Just the sort of thing that keeps PHB's in corner offices, at least until the customer asks to see the working final product.
UML is good as a starting point; it provides a lingua franca to flesh out requirements, and to communicate those requirements to implementors (I'm esp. fond of use case scenarios). However, it doesn't translate well to the often chaotic world of actual implementation, where performance issues, platform specifics, breakneck delivery schedules, and changing/creeping requirements usually crush the elaborate UML blueprints.
UML is a discipline, rather than a technology. Properly used, it will likely improve your ability ro deliver what the customer wanted. Just don't fall into the trap of assuming its a magic wand that will make the hard parts of implementation disappear.
007: "Who are you?"
Pussy: "My name is Pussy Galore."
007: "I must be dreaming..."
There is the model driven architecture (MDA) issue (that isn't being talked about here much).
There is the waterfall vs. agile vs. sloppy issue.
There is the authoritarian martinet boss vs. childish coder run amok issue.
The "the tools suck so UML sucks" issue.
And finally, there is the "It sucks so I'll never use it" vs. "Use the right tool for the job" issue.
MDA first. UML is only the first part of OMG.org's attempt to revolutionize software engineering. I find MDA silly beyond words, and so I will not do it justice. Go visit OMG if you are interested in their side. The MDA folks want to be able to build universal models that get reused, transformed to fit domains, manipulated by tools to do all manner of wonderous things. I personally think they are having wet dreams, but it would be great if they could pull it off. That said, if you fully drink the OMG kool aid, you wind up thinking that all we need is a few high priests of models and really smart tools. right.
As for the lifecycle issues, all of us who have been on more that one project know that the waterfall doesn't work; the "let's just write stream-of-consciousness code and screw everything else" doesn't work; and XP requires especially disciplined troops to make it work at all and then only or relatively small projects.
What is also clear to anybody who has ever done maintenace, is that unless your code will never be used by anybody but you or it is small enough and well enough written to be understood by a complete noob before lunch the first day he looks at it, it is unprofessional not to document your design. It is also stupid to tackle anything but the tiniest projects without a design (and I count XP's emergent design as a design). So what are you going to use to express your design? How about the notation that all the books about software now use -- UML?
I have worked for more authoritarian bosses than I care to remember. But I have also worked with too many nightmare developers who either simply didn't know what they were doing, had emotional problems, or were just jerks. This has nothing to do with UML, these same types were poinioning the same wells in the days of FORTRAN.
Tools. The three amigos are the worst possible thing that could have happened to UML. They all work for Rational, so bosses think that Rational must have the best tools. **gag** Go look at Magic Draw, or Together, or Embarcadero Describe. I've had reasonable luck with all three. BTW, the three amigos are also behind MDA. I haven't been paying close attention to UML 2, but it seems to me they are making UML less useful for real work to make it more friendly to MDA.
Sometime UML does suck for a particular job, or a particular implementation of UML sucks. That doesn't mean that is should be forever foresworn. It is a good tool for some tasks. Use it for those tasks. If the boss is so stupid as to think that the teams' best guess at a design at the start of the project should be cast in stone, then it is immaterial how you express your design, cuz you are screwed no matter what. (but don't be so silly as to neglect doing any design just to spite a stupid boss)
Here is my $.,02 for what's it worth.
If the following sorts of things apply to your project the you are good candidate for UML:
1) I would gladly triple the costs in exchange for halving the number of bugs
2) There is almost no value in having the project complete early. On the other hand we need virtual certainty of meeting the conservative deadline we generating in the planning stage of the project.
3) The costs of the software are overwhelmed by the costs of XYZ (where XYZ = marketing the software, getting it certified, the cost of how it gets used...)
4) The cost of a serious bug is a large percentage of the cost of the project
5) At the higher levels of the project we need to budget in terms of dozens/hundreds of man years for completion. Traits of individual developers are irrelevant
6) No piece of code gets into a build without passing through at least 6 different stages involving independent or mostly independent groups
7) We already have a highly controlled environment but the size of our projects is simply overwhelming the abilities of the dedicated (build, analysis, code control..) staff to understand what is going on.
Conversely if the following apply it won't work out:
1) We are under a tight deadline
2) Individual programers have a feeling of ownership about their sections of the code
3) Management is highly cost conscious
4) While no one likes bugs its hard to imagine any single bug which is likely to get through would be serious enough to warrant increasing the total cost of the project by 10%.
5) We have kind of a loose environment and we are hoping that UML help us to tighten up a bit.
UML should be used to DESIGN your programs. After all it's "Unified *MODELLING* Language", not "Unified nifty diagrams documenting language".
Lack of previous (even on-paper) design is what makes programs buggy. When you code first, doing the UML diagrams is useless. Why? Because when you find out the structure of your code and see possible improvements, you realize that it's too late to make any changes, due to compatibility problems, etc etc etc.
Look at what happened to the Lazarus project. it's been on "pre-beta" for more than 6 years, and they 're still telling me it's too early to make an UML diagram because "the structures change too much". (WTF?!?!? If I want to cooperate in a project, the least i can ask for is the UML diagrams so i can focus on where to help, not navigate among the millions of lines of code!)
Follow my advise. Design first, code afterwards.
The tragedy here is that the big marketing machines have brainwashed the gullible, desperate, and ignorant into believing that UML is a silver bullet. As a result, diagram making robots are often directed to generate their beautiful models for unknown stakeholders and with unknown value to create the illusion of progress (Gravitational Fever: Afflictees measure progress by the weight of their UML diagrams).This is just one scenario of many that gives the UML a black eye.
Let's face it, any tool can be misused and abused. People need to learn to use the UML where it is valuable to do so, at the proper level of detail, and with appropriate completeness. When used under the proper adult supervision, the UML truly can be a valuable communication and visualization tool with which to improve productivity as opposed to killing it.
Is Death by MDA Fever around the bend?