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?"

Comments

I use it to select projects

[RAMMS EIN]

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.

Rarely

[Apreche]

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.

UML Fever

[danpat]

Death by UML Fever

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.

And I Use It to Weed Out Staff

[tom's a-cold]

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.

I've done development for a very long time and there are few non-trivial projects where modeling, used correctly, doesn't reduce risk and end up delivering a higher-quality product. In fact, I won't hire any developer who refuses to use UML since I'll assume that s/he is lacking in essential software engineering skills and is a "code first, understand the problem later" sort of person. I've burned too many hours fixing that kind of code to ever want to do it again. And I'm about as far from an authoritarian manager as you can get.

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.

Re:UML is useless

[digitalyak]

But I do know one thing that you must internalize: If it doesn't execute, automatically, it won't be kept up to date.

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/