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.

Re:Insightful

[M1FCJ]

You might not like it but XP methodology recommends you design first, design the unit test first, then code. This doesn't mean you are not going to change your design but at least you should start with something in your mind. UML is just a tool, if you don't need it, don't use it. Most programmers are not that good at writing code as it goes.

Documenting code? Hah! :-)

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/