[quote] "Argh! Blind leading the blind! " just because you are of the different opinion gives you right to mock others … time to go back to your charts and rethink it one more time. - if that brings you back to the initial state you might be hiting never- ending loop …no good …BTW I didnt say UML is bad or useless - I spent 3 hours per day on Together/J to sync team’s changes …I’ve said it is overkill for ‘presumably’ small gaming project. Even on big release game you usaully see couple of names those who actually do dirty coding work … in such a enviroment and in REAL life people talk to each other becouse they CAN…in big team folk needs some other means of “keeping in touch” and that is where UML plays its role. And if you still think this is not the case and have diferrent opinion - so be it - i accept that - but without making any additional remarks poited toward you…
[/quote]
Don’t take this personally but you appear not to fully understand what you are talking about. Every time you make statements such as “nd in REAL life people talk to each other becouse they CAN…in big team folk needs some other means of ‘keeping in touch’ and that is where UML plays its role” you show not inconsiderable ignorance of what UML is, what it is intended to be, and how it came about.
I’m not saying you are wrong in highlighting a particular use of UML, nor that you don’t know anything about using it. But your perspective is artificially narrow, and really doesn’t do the tool any justice. Your absolute statements are just plain wrong. Here is a quote about UML and size of projects, from the OMG’s Intro to UML (which is worth reading, it’s fairly light and contains some useful pointers http://www.omg.org/gettingstarted/what_is_uml.htm ):
“Of course a well-designed architecture benefits any program, and not just the largest ones as we’ve singled out here. We mentioned large applications first because structure is a way of dealing with complexity, so the benefits of structure (and of modeling and design, as we’ll demonstrate) compound as application size grows large. Another benefit of structure is that it enables code reuse: Design time is the easiest time to structure an application as a collection of self-contained modules or components.”
The 3 amigos (Booch, Jacboson and Rumbaugh - the inventors of UML) handed over it’s safekeeping to the OMG, so the OMG’s documents are what passes for the official word on the language (and, incidentally, manage the standardization process for new specifications). They clearly do not see it as primarily a communication tool (as you appear to do).
I made the eye-grabbing statement about the blind leading the blind because you were way off base, not just slightly. No offence was intended - just to shock you into re-evaluating quite deeply this tool.
Here are some more salient thoughts from the Intro to UML. Unfortunately, their docs are mainly not for a mass-market, and quickly move into extremely high-level abstract discussions, but I’ve always found it works quite well if you just quickly skim over the parts where they start to use too many vague words (anything that sounds like marketing tripe ;))
“Modeling is the designing of software applications before coding. Modeling is an Essential Part of large software projects, and helpful to medium and even small projects as well. A model plays the analogous role in software development that blueprints and other plans (site maps, elevations, physical models) play in the building of a skyscraper.”
" You can do other useful things with UML too: For example, some tools analyze existing source code (or, some claim, object code!) and reverse-engineer it into a set of UML diagrams. Another example: In spite of UML’s focus on design rather than execution, some tools on the market execute UML models, typically in one of two ways: Some tools execute your model interpretively in a way that lets you confirm that it really does what you want, but without the scalability and speed that you’ll need in your deployed application. Other tools (typically designed to work only within a restricted application domain such as telecommunications or finance) generate program language code from UML, producing most of a bug-free, deployable application that runs quickly if the code generator incorporates best-practice scalable patterns for, e.g., transactional database operations or other common program tasks. Our final entry in this category: A number of tools on the market generate Test and Verification Suites from UML models."
“One characteristic of UML - in fact, the one that enables the widespread industry support that the language enjoys - is that it is methodology-independent. Regardless of the methodology that you use to perform your analysis and design, you can use UML to express the results.”