3 ms·

I think this is the real problem with UML. It first kinda seems to work when project is managed with waterfall-style, but when actual development is done iterat

by feider 11y ago

I think this is the real problem with UML. It first kinda seems to work when project is managed with waterfall-style, but when actual development is done iteratively (when is it not?) it just adds confusion or work either by providing out-of-date spec or introducing more stuff to keep in sync.

jschwartzi 11y ago
If you have a problem with out of date documentation, I think you might have a problem with the development team rather than the documentation. If you don't think the documentation is useful, please get rid of it. But blaming UML for your documentation problems is like blaming English for forcing you to rewrite comments that no longer make sense. My sense is that people associate bad processes and bad teams with the tools that they were using. Crappy tools exist, and people have had some pretty dumb ideas about how to use UML, but is useful as a way to express aspects of your design that may lend themselves to a more object-oriented approach. This is something for which no other widespread diagramming language exists. Whether you're using an iterative or waterfall approach, at some point it is necessary to provide some context for your software units, like explaining how they are associated or what their areas of responsibility are. That's all the documentation does.
mpdehaan2 11y ago
UML is a way to talk about things. Just having a standard-ish way to draw on whiteboards is pretty helpful, even if the diagrams are super temporary. In practice in most industries, most folks can probably get away with just knowing the ISA/HASA type stuff and 1..N, * arrity, etc. Swimlanes are also somewhat useful as a concept (but so are regular flowcharts). There's a whole other ton of UML (see 5/7th of Rational Rose around the early 2000s, which is probably gone all deep and crazy now, etc) that is, IMHO, pretty skippable. I've not even seen some of the "stuff you have to know" (ball and socket, etc) used. I do think that designs get better when you can draw them, as when they get hard to draw, it becomes conceptually obvious there may be problems. UML generation code tools running against 1300+ Java classes and making some huge diagram covered up in arrows definitely doesn't work too well though :)

by feider 11y ago

jschwartzi 11y ago

If you have a problem with out of date documentation, I think you might have a problem with the development team rather than the documentation. If you don't think the documentation is useful, please get rid of it. But blaming UML for your documentation problems is like blaming English for forcing you to rewrite comments that no longer make sense. My sense is that people associate bad processes and bad teams with the tools that they were using. Crappy tools exist, and people have had some pretty dumb ideas about how to use UML, but is useful as a way to express aspects of your design that may lend themselves to a more object-oriented approach. This is something for which no other widespread diagramming language exists. Whether you're using an iterative or waterfall approach, at some point it is necessary to provide some context for your software units, like explaining how they are associated or what their areas of responsibility are. That's all the documentation does.

mpdehaan2 11y ago

UML is a way to talk about things. Just having a standard-ish way to draw on whiteboards is pretty helpful, even if the diagrams are super temporary. In practice in most industries, most folks can probably get away with just knowing the ISA/HASA type stuff and 1..N, * arrity, etc. Swimlanes are also somewhat useful as a concept (but so are regular flowcharts). There's a whole other ton of UML (see 5/7th of Rational Rose around the early 2000s, which is probably gone all deep and crazy now, etc) that is, IMHO, pretty skippable. I've not even seen some of the "stuff you have to know" (ball and socket, etc) used. I do think that designs get better when you can draw them, as when they get hard to draw, it becomes conceptually obvious there may be problems. UML generation code tools running against 1300+ Java classes and making some huge diagram covered up in arrows definitely doesn't work too well though :)