Re:Do real developers use UML and other CASE tools?
by bane on Saturday March 05, 2011 @11:49AM
(#2291740)
These tools serve two, very useful, purposes that aren't often readily apparent unless you have to use them.
1) Organize complexity. UML, for example, is extremely useful as a language capable of describing complex information systems -- just like the periodic table organizes chemical elements or the biological classification taxonomy organizes life -- or perhaps a better analogy are skeletal formulas in chemistry and life sciences.
You can probably get away with not using this language on small projects, maybe less than 10 people and under a quarter million lines of code. But on larger projects, 300 developers on one project spread over a continent and tens of millions of lines of code, some kind of formal organizational method becomes a necessity. Ad hoc diagrams just don't really cut it. You'll be glad to know that UML is not just stick figures anymore, some of the other diagrams do a much better job at modeling and organizing deeper into the design than others.
But like I said, the utility doesn't really become apparent until you deal with this kind of scale.
2) Communication. Similar to the above, but distinct. UML also provides a lingua franca for communications between business people and tech people. It forces business users to apply a rigid logic to their requirements (which can often become contradictory if not controlled by some kind of formal framework) which aids in communicating with engineering staff and forces engineers to stop talking about code and to talk about higher level abstracts that are more easily relatable to business people. The ability to actually communicate between these two parties has been extremely powerful.
In smaller organizations, the business people are quite often the tech folks as well so this isn't as necessary to have. But in most traditional companies, business folks have almost no way of communicating with the engineers in any constructive way without something like this.
1) Organize complexity. UML, for example, is extremely useful as a language capable of describing complex information systems -- just like the periodic table organizes chemical elements or the biological classification taxonomy organizes life -- or perhaps a better analogy are skeletal formulas in chemistry and life sciences.
You can probably get away with not using this language on small projects, maybe less than 10 people and under a quarter million lines of code. But on larger projects, 300 developers on one project spread over a continent and tens of millions of lines of code, some kind of formal organizational method becomes a necessity. Ad hoc diagrams just don't really cut it. You'll be glad to know that UML is not just stick figures anymore, some of the other diagrams do a much better job at modeling and organizing deeper into the design than others.
But like I said, the utility doesn't really become apparent until you deal with this kind of scale.
2) Communication. Similar to the above, but distinct. UML also provides a lingua franca for communications between business people and tech people. It forces business users to apply a rigid logic to their requirements (which can often become contradictory if not controlled by some kind of formal framework) which aids in communicating with engineering staff and forces engineers to stop talking about code and to talk about higher level abstracts that are more easily relatable to business people. The ability to actually communicate between these two parties has been extremely powerful.
In smaller organizations, the business people are quite often the tech folks as well so this isn't as necessary to have. But in most traditional companies, business folks have almost no way of communicating with the engineers in any constructive way without something like this.