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
There is a conflict over territory in what UML and ER (entity-relationship) diagrams dipict. Where they don't overlap is behavior, but UML tends to assume that the relationship between entities and behaviors is one-to-one when actually it is not. My development philosophy is more or less to decouple, or at least not hard-wire at a high level, what entities are used to carry out a specific task. The relationships between entities and tasks is often fluid and not one-to-one, so I see little use in hard-wiring such relationships into a design by using diagrams that encourage it.
Table-ized A.I.
It would have been better if the modder had written a motivation why that product (and method) was bad.
Anyone with answers?
Karma: Excellent (My Karma? I wish...:-( )
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.
You admit that this was your first experience with UML, and by the sounds of iy, you didn't get it right. Can you blame UML, or can you say that it was because it was a first project and so on. Without knowing further details, I think your attitude is bad: you had one bad experience and have let it cloud your judgement for the future. Plenty of other people have good experience with UML, whether on first or subsequent attempts, which is testimony to the fact that it does work: but of course, UML is just one part of a whole complexity of issues in a project, and perhaps it was one of those other issues that caught you out. UML isn't a silver bullet, and like most software technologies, you can't expeect it to save the day on first use: time, patience, experience and hard work bring the results.
Start with Use Case diagrams, Activity diagrams and Component Diagrams.
l
The order is arbitrary (depending on your knowledge about the future system and your UML skills).
The goal is to have -- before you code:
a) Use Case diagrams which roughly capture what kind of actions the users can do with your software.
b) Components (either planned libraries/dlls or database tables or executeables or configuration files or just imagined "partitions" of one big executeable) where every use case is assigned to a component. That means the business logic for that usecase will later be in that "partition" of code. It makes sense to divide the components up into business components, data access and communication components and gui components (usually a use case is then realized as logic in the business component and also in a gui component for interaction)
c) Activity diagrams for the complex use cases describing their controll flow.
If you do not do a), b) c) above you can not write big systems anyway (except you have 20% factor 10 coders (The Mythical Man Month))
After that is done you pick one use case or two, depending on team size, make the class diagrams for it, generate the code for them and fill out the empty methods with your code.
If you have "scenarios" (that are user acceptance test cases) or XP user stories, make sure they conform with the activity diagrams and make a sequence diagrams as needed for them. That helps in finding the needed methods for you classes.
Use a tool that supports round trip engineering so you can import that code back into your model. So the "private" methods you "invented" during coding get pulled into the model.
Write your unit tests (better user acceptance tests based on the activity diagrams) and import those also into the model.
When needed generate the SQL statements to create the DB tables and/or the DB access components.
Is your application a protocoll driven, e.g. communication, robotics or persistance heavy, you probably might need state diagrams. A state diagram usually refers to a single class or a few connected classes.
Here is a easy tool for UML sketching, it is not usefull for codegeneration etc. but toi get the first ideas how to use UML its probably the most simple one: http://qse.ifs.tuwien.ac.at/~auer/umlet/index.htm
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
For me, UML is for expressing requirements - you are not designing your program in advance - you are expressing in a formal way what you want the program to achieve in advance - if your requirements are non-complex and you can accept escalation (scope-creep) then go ahead and use rule of thumb, works fine for lots of people, but for managing huge projects, the problems rarely lie but rather in the expression of requirements. Even for a simple project, interconnected use cases with pre and post conditions is a far better than english prose. It also gives you a nice mental model to hang the code off to make sure that you are solving the right problem. For more complex behaviour UML Activity Diagrams help greatly, the combination of use case and activity diagram creates an excellent way to decompose behaviour. Adding class models with constraints goes even further defining data and rules that give a head start into the development. The rule is to capture the essence. That requirements will change is a given fact of life, but with an MDA approach, the impact of those changes have a better chance of being managed and costed properly. Best thing is that once you have completed the requirements model, you have a re-usable system description. Since technology changes are v. expensive re-inplementations of existing functionality on a new platform, the base requirements in a non machine/language specific form are worth real and serious money to your company. Leave development for the developers (or in XP, RAD or @home, for when you don your developer's hat). Use UML to express requirements and let the programmers work out the best implementation with current tools and tech. - that's what they're paid for. This is the fundamental approach of MDA (model driven Architecture) - though I reckon the OMG's MDA approach might go a little too far down the RTE (round trip engineering) path to give truly useful expression of requirements. So the UML models tied with a good requirements system (we're using Telelogic DOORS - there are many others, but DOORS came out top for our needs) now, back to modelling the requirements for a requirements system - talk about fead huck...