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!
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.
>If it uses UML, I'm out.
Its a communication tool. Thats all.
Its like saying "If the business analyst wears a white shirt and tie, I'm out." or "If the specifications are in New Times font, I'm out."
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
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.