The Old Joel on Software Forum: Part 4 (of 5) - UML tools

UML tools - software savior or utter waste?

Anyone here using UML or similar tools to create their software? From the reading I've done, people fall into 2 camps on this one:

1. UML and such tools are saviors, and are really necessary for large scale projects.

2. UML and such tools are an utter waste of time. They're for programmers and their crew who don't know what the hell they're trying to accomplish.

Your thoughts?

MoreStorage4Me
Saturday, March 13, 2004

I looked at UML and some reverse-UML tools to support the ongoing development of the bad code I just posted about.

What I quickly concluded was that UML offered nothing in terms of "helping" development. It's a only a documentation tool. It's not really a reverse engineering tool, and can't cope well with large undocumented code going in.

At very best, you can generate function headers and data structures from UML diagrams with some tools.

And it only works when the entire design team is on board from the beginning.

I think UML has applications where everyone working on the project believes in UML and is able and willing to apply it everywhere consistently. It's a cost center with an unclear payoff. Mainly, it would support management requirements for documentation, as it's the gold standard of software docs.

Bored Bystander
Saturday, March 13, 2004

I use Enterprise Architect, but consider it neither savior nor a waste of time. Like anything else, experiment and use whichever features that actually help you, not because of someone else's opinion.

Joe Hendricks
Saturday, March 13, 2004

I did work on one project that used UML. It was helpful, but had its limitations.

Perhaps you read the recent article "Death by UML Fever" by Alex Bell in ACM Queue magazine for March 2004. In it he describes many unreasonable expectations UML and irrational behaviour by some of its users.

The problems with use of UML are not new, just the latest manifestation of a problem described by DeMarco and Lister in Peopleware. They characterize the problem as the difference between a "big M" and a "little m" methodology where the little m methodolgy is a set of procedures and tools that aid the developers in their work and the big M Methodology as a procedure that centralizes thinking and the developers just follow the rules to crank out code.

UML is really just the specifications for the diagrams, not the methodology, so you really have to blame the procedures being used, not UML itself. For some people just using the diagrams is a methodology that eliminates the need to think.

In my experience, the way to produce quality software at reasonable cost is to hire intelligent skilled experienced people and provide them with a quality work environment, a reasonable development process and appropriate tools. Doing the opposite, that is putting tools and process in place, then hiring people to fill slots dictated by the process is likely to result in a software disaster.

On the project I was on, the class diagrams and, especially, the sequence diagrams were helpful in understanding what someone else was doing. The diagrams didn't always keep up with the code, so they had their limitations. We used Rational Rose which wasn't too bad, but was rather slow at times and could get its data files corrupted so it would crash when reading them in.

mackinac
Saturday, March 13, 2004

Remember that the 'L' in UML stands for 'Language'. Anything that can be described in UML can be described at least as easily in English or whatever language your development team is most comfortable speaking.

Devil's Advocate
Saturday, March 13, 2004

UML can provide a method to work through complex interactions - identify areas you've overlooked.

Just don't let them become the talismans in your cargo cult - use them if you need them, but don't feel like you always need them.

Philo

Philo
Saturday, March 13, 2004

As someone said, UML is a great *Documentation tool*. It provides a nice way of showing-new-users/reminding-old-users what goes where, why this does this, etc.

Also, the most user I've gotten out of reverse-engineering UML tools is their ability to draw class diagrams of code I havent seen before. That was mildy useful and probably saved me an hour or two of work (so not great, but OK).

Crimson
Saturday, March 13, 2004

Devils' Advocate:

A picture is worth a thousand words. When used sparingly UML diagrams can communicate much better than a mere system description. The "problem" with UML happens when anal-retentive designers/architects start trying to document the ENTIRE system in one big class diagram.

I think reverse engineering UML diagrams from code isn't that great. My best experiences with UML have been when it is used to document subsystems or behavior within a system.

NathanJ
Saturday, March 13, 2004

I'm very much a UML As Sketch guy, http://www.martinfowler.com/bliki/UmlAsSketch.html

It's a useful language and common vocabulary. But some places spend so much time fleshing out the models that no code gets written and the project gets canned.

All things in moderation

Koz
Saturday, March 13, 2004

I can make pictures faster, easier and better with a pen and paper than with a UML tool though.

Hence, for me at least, utter waste.

Sum Dum Gai
Saturday, March 13, 2004

The "Picture worth a 1000 words" is not applicable to many things, and design is often one of those. Why are movie scripts written as text, and only _then_ storyboarded and _finally_ filmed? If a picture was always better, there would be no script, but rather everything would start with the storyboard.

Most detail cannto be put into a picture. You _can_ do without the picture, but you _can't_ do without a formal description.

A visual representation may help sometimes, but it cannot replace a detailed ,well defined representation - neither in movie scripts, nor in software.

Ori Berger
Saturday, March 13, 2004

"Why are movie scripts written as text, and only _then_ storyboarded and _finally_ filmed? If a picture was always better, there would be no script, but rather everything would start with the storyboard."

Two reasons:
1) Drama is supposed to be about character and plot. Location is incidental.
2) In the past, technology dictated typed pages as the medium for communication.

With blockbuster action films out of control and the growth of animation tools thanks to Moore's Law, I'd be honestly surprised if we hadn't already had a major motion picture that was originally pitched via mpg.

[Note that Mission Impossible 2 was a bunch of stunts John Woo wanted to film, so he had a script written around them]

Philo

Philo
Saturday, March 13, 2004

Ori,

I agree with you completely about the movie script. Most software projects start with a list of written requirements. Developers convert these requirements to a design. A good design includes some diagrams.

I have NEVER been on a team that didn't use diagrams (even if they were just whiteboard scribbles). And most movies are also done with storyboards. There is no better way to accurately shoot a complex visual.

UML does not replace all other forms of documentation. But UML is a superior form of documentation for several parts of software.

NathanJ
Sunday, March 14, 2004

I agree with what Mackinac said.

I worked on a team about 4 years ago using a lot of Rational tools, the big problem was that developers seemed to have a different understanding of the meaning of the object sequence diagrams.

Some of the design sessions were quite heated with basic philosophical arguments about the use of the tools cutting deeply into the project budget. The reverse engineering of Rational Rose was at best flaky with inappropriate variable naming conventions etc.

I put it firmly in the "waste of time (and money)" basket.

As far as I'm concerned it hides the woods with the UML trees.

Realist
Sunday, March 14, 2004

I read an article once. I think it was on the Rational website. Or possibly the OMG one. Its Sunday and I am too lazy to look for it.

At it's its most basic UML is a language for describing code or processes or whatever.

The example the author used was diagrams and formula in mathematics. You could tell someone that you have a triangle with one sides of length a, b, and c. The angles of the triangle are x, y, and z degrees. The alternative is to show them a picture of the triange with everything labelled.

It get's messy when one's models get more complicated, and the need for an alternative language becomes more apparent.

Similarly, you could look at the CreateTable SQL, or you could look at a UML schema of the database. I always find the latter easier to understand.

Give the tools a bit of time. As more people understand the UML, I think it will really take off.

I remember when the WYSYWIG tools first came out for HTML. They made it easier for novices to build websites, but they were horrible. 1x1 GIFs everywhere to fudge the layout. Now, tools like Dreamweaver generate code that is pretty clean. The UML tools will get there soon.

Tapiwa
Sunday, March 14, 2004

I spent a fair amount of time (~7 years) working in an environment where Rational tools were provided and used as the primary modelling tool. If I had a choice, I would not develop without similar environment support.

In my case, all code to be written was first modelled in Rose and then generated. The model, and inherently the documentation, was always up to date because changes were directed through the model. In general, this didn't add much overhead and left us with a living representation of our code base.

This doesn't mean that some parts of the model weren't a mess. Your model remains only as good as the developers that work on it. If some yahoo thinks that they should put all 100 classes they are using on one page, it is going to be a mess. There is no substitute for someone who knows what they are doing.

However, if you do have some people who know what they are doing, it becomes a fairly powerful medium for creating new or evolving existing designs. Need to know what changing this class will impact? Check the model.

All of that said, I have never been that fond of UML. A great deal of time was spent trying to make it all things to all people which adds to the general confusion about how it should be used. I still have a preference for old-fashioned Booch, which may not be as extensible as UML, but got the job done for me.

!
Monday, March 15, 2004

I am a SAP consultant (SD & MM) and use UML seq. diagrams in Visio as my main tool to map out a business process. I find it better than some of the SAP recommended tools.

Liam
Saturday, March 20, 2004