UML always seemed like a waste of time to me. I have an allergic reaction to the kinds of large, big-budget, mega-staffed, long-term projects where UML fits. And I'll just sidestep the question of which UML are you using. ;-)
That said, I'm in the midst of an interesting project at work. I'm using XOTcl in AOLServer, which pulls the design in a direction that's quite different from what you would find in apache/mod_perl. Basically, a whole mess of code is loaded into an interpreter at startup, and that interpreter is cloned (via memcpy) to provide the necessary state for worker threads to respond to a request. Furthermore, closures are missing, lexical scopes are kinda there/kinda not, and object finalization/destruction doesn't occur automagically at end-of-scope (it all piles up until end-of-thread).
But there are some interesting features that XOTcl offers: mixin classes, and per-object methods (like binding an unbound method to an object in Ruby). And the whole define-the-world-and-clone model feels more like Smalltalk's "live objects" mindset than the "dead code" model used by C/C++/Java/etc. In fact, XOTcl+AOLServer naturally lends itself to thinking about "live objects", where the system constructs a mess of singletons at startup, which send messages back-and-forth to each other to get stuff done. (This is due to the fact that creating temporary objects has a rather nasty side effect, since discarded objects are not automatically freed.)
In an informal design review today, I had to describe this system, which uses many concepts that XOTcl borrows from hither and yon, none of which are found in C++/Java. And my review partner is a C++ programmer from wayback, so this presents a mild handicap.
In a project such as this, there are two classic organizing principles used to structure the codebase: a big pile of functions (like any standard C, Fortran, Tcl, etc. project), or a forest of classes (as projects in C++, Java, C#, etc. tend evolve into). But with XOTcl, there's another model: the smalltalk-style "live object soup".
All of which brings us to a problem. How do you model a mixture of classes, mixins (at the class- and object-level), inheritance relationships, interface specifications, per-object methods and composition-through-delegation using UML? If some form of UML is your primary means of conceptualizing software design, then concepts like these are outside your field of vision.
Re:Tools
ziggy on 2004-10-18T01:49:37
Right. And UML is a codification of a common set of graphic idioms to communicate how to build and use C++/Java systems. It falls down when you use coding techniques outside the capabilities of those languages (like real macros, live objects, mixins, and per-object methods).The main idea is you believe drawing a diagram or two will help you communicate your ideas.It's not that these concepts are impossible to diagram, or difficult to communicate. It's that there is no way to accurately or adequately describe these concepts in UML, just like there is no word in English to describe what taste umami really describes.
