<ajb at spamcop.net> wrote in message
news:20060119185325.iw9di8gwcc0kkkgw at webmail.spamcop.net...
> G'day all.
>> Quoting Benjamin Franksen <benjamin.franksen at bessy.de>:
>>> However, not everyone in the OO camp thinks that UML is really useful:
>>>>http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html>> Having actually used it (once), the consensus seems to be:
>> 1. It only applies to a "pure" OO style. Just about all useful
> programming
> languages for programming-in-the-large (Haskell included) are
> multi-paradigm.
>> 2. It's difficult to refactor. This makes it useless for design purposes,
> especially if your development development methodology is sufficiently
> agile.
>> The upshot is that UML's only use is for docmentation after the fact, or
> for Big Design Up Front projects. But only if you use a strict subset
> of what most programming languages give you.
I am no rabid UML fan, but I am reasonably familiar with it, and I have to
say this is garbage. UML class diagrams are invaluable both for the
conceptual analysis and design work as well as for after the fact overview
of the class structure. State models are essential for designing the
behavior of interesting objects. Slightly less important (IMHO) but still
useful are acitivity charts (for use case flow), and interaction diagrams
(although I have found them personally less useful for the initial
conceptualization. I have found them more useful for explaining method
interactions to someone). The fact that highly popular tools like TogetherJ
put a lot of effort into recovering the class diagram and the interaction
diagram from code should be some indication of their importance and
usefulness. In addition, the latest MDA model compilers can generate entire
applications from UML models. Some documentation that is!
I have personally noticed less of a need for modeling tools with Haskell b/c
the language itself is fairly abstract, but also because i tend not to write
stateful, structurally rich applications in Haskell. If the next version of
Haskell does support a more convenient and extensible datatype mechanism,
then i can see people using Haskell for such applications and therefore a
need for some kind of diagrammatic modeling tool there too.
cheers
-s