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?"
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.
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!
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'm on a project that is using Executable and Translatable UML (xtUML) for developing embedded firmware. The target is an 8-bit microcontroller.
Our software process involves doing an extensive requirements analysis phase. Next, we break the problem down into domains, which are further anaylyzed. Finally, we begin work on the class models and state models.
The xtUML methodology includes precise semantics, which allow it to be directly translated into C using off-the-shelf compilers. Or, you can be brave and write your own model compiler to directly translate your models into the target assembly.
There is some high-level action specification language code which is written for the state actions and instance based operations, but besides that, no coding is required.
Check out this site for some xtUML information: http://www.projtech.com/
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?