> From: Wojtek Narczynski <[log in to unmask]> > Yes. My impression is that UML is less about "design" than about rough > "scrathing" of ideas. > > At some level you have to drop those scratchings, because there is no way > back from code back to diagrams. > > But I'd love to be proven wrong. I would love to see an UML design of, for > example, smtp or http server, or rdbms, or UML modeling tool - caputred in > UML diagrams. Unfortunately I only see trivial examples everywhere > (included with tool distros, uni lessons, etc.). My project is using my open-source code generator ColdFrame (at the moment you need Rational Rose at the front end, in principle I could interface to eg UML Studio but there are project deadlines!) at http://www.pushface.org/coldframe/ The idea is that the UML model is a set of formal domain (subject matter) analysis models. There's little need to model framework concepts (such as where all the current instances of a particular class are kept) because the generated code will do that. Your Ada code appears in separate subprograms and task bodies. You are not allowed to modify generated specs or package bodies! (and people don't). If you are a really good Ada person you get to work on the framework (aka software architecture); but most of us are modelling, writing code to complete the models, testing it (and engaged in lots and lots of reviews). If you need to change the structure of the code (because you need an additional operation on a class, say) you change the model, regenerate the framework, and carry on. A major reason for this is that it's very hard to relate random changes in code to what they might have meant in the model -- that's easier if your generated code is 1..1 with the model, of course. We find that in application domains we have about 20% hand-written code (ie, separate bodies), whereas in i/o domains it's the other way round.