UML Support for Python [was IDLE development - Call for participation]

[Martin Rand]

On 20 Aug 2000 15:41:20 GMT, aahz at netcom.com (Aahz Maruch) wrote:

>In article <cokppsc6mutq7qeq8j0vh9sj1csk94h1sv at 4ax.com>,
>Martin Rand  <mwr at hsl.tcp.co.uk> wrote:
>>
>> [Big snip about circumstances where I think diagramming can be useful]
>>
>>Protoyping and simulation strategies can help with all of these. So
>>can diagramming, and often it's cheaper, cleaner and of more lasting
>>value.
>
>While I agree with you in the abstract sense, IMO we don't yet have
>enough powerful, cheap, and ubiquitous compute/display technology to
>make this a universal statement in the practical sense.  From my POV,
>paper just doesn't work for this, and when it comes to real
>collaboration, paper often ends up as the lowest common denominator.


And on 20 Aug 2000 23:39:10 GMT, aahz at netcom.com (Aahz Maruch) wrote:

>In article <slrn8q0rja.8s5.neelk at brick.cswv.com>,
>Neel Krishnaswami <neelk at alum.mit.edu> wrote:
>>Aahz Maruch <aahz at netcom.com> wrote:
>>> In article <8noves$a76$1 at gaia.cdg.acriter.nl>,
>>> Cees de Groot <cg at cdegroot.com> wrote:
>>>>
>>>> I have started taking the whiteboard off the wall and dropping it
>>>> on the meeting table. Way better than an UML diagrammer ;-)
>>>
>>> That's good for brainstorming, but you lose record-keeping, not to
>>> mention the ability to look up existing documentation.
>>
>>At my office there is a whiteboard with a xerox-thingy built in: you
>>can push a button and the contents of the whiteboard are printed out
>>onto a sheet of paper. I think this is the coolest thing I've ever
>>seen -- there's just something *cool* about something that is so
>>obviously the Wrong Thing actually working. :) 
>
>Yes.  They even have a version that connects directly to a computer and
>can do OCR (see www.mimio.com).  I still think it's Not Good Enough Yet.

And on 20 Aug 2000 23:11:16 +0200, cg at gaia.cdg.acriter.nl (Cees de
Groot) wrote:

>I've found UML to be infinitely more useful as a brainstorming language
>than to serve as a documentation language. Class diagrams can be readily
>reproduced from the code, and my experience is that sequence diagrams
>you draw during a brainstorming/designing session are invariably 
>implemented in a slightly different way later on - better have no
>diagrams and bet your life on clear source code than have wrong diagrams
>and a safe sense of security...
>
>Of course, in some companies record-keeping is an end, not a means, but
>for these any diagrams go, as long as the pile of paper is large enough
>to prevent everyone from actually checking them for correctness ;-)

-----------------------------------------------------------------------------------------------------------------------

I find it interesting that this discussion has headed off towards
generalities about diagramming / formal speccing vs. coding, and then
argued back from _other_ specific circumstances as if to make general
points. On the other hand it seems to be much concerned about specific
implementation technologies, which I think are slightly peripheral. 

In my posting I listed a set of circumstances where diagramming
(however it's done)  _could often_ be "cheaper, cleaner, and of more
lasting value" than other approaches. Not "a universal statement"; nor
an "abstract" one - for every one of the circumstances listed I can
think of practical examples in my own work experience.

Of course many of the diagrams we draw are ephemeral. This doesn't
detract from their value. But equally, the fact that they have a value
doesn't dictate that they must be maintained permanently, or in
documentation independent of the code they serve.

On the other hand, if you need to lay down that a certain thing _is
so_, or _will be done so_ (a common enough occurrence in industrial
automation where I mostly work), you use whatever is the most
transparent, timely and reliable way of saying these things - and
often that's not by coding! When diagramming is a part of it, the cost
of maintaining those diagrams and other design documentation in line
with reality is _as nothing_ compared with the cost of losing the
fundamental design thread during implementation or in subsequent
maintenance across the system's lifetime. To say "but it doesn't get
done" perhaps reflects one of two things - it doesn't need to be done
in the first place, and so your organization's process is wrong; or it
_does_ need to be done, and so your organization's process is wrong.

I don't really understand the point about paper being the "lowest
common denominator". If I was going to make an analogy, I think I'd go
for "highest common factor" - that is, for communication amongst a
group with differing interests in a project, pictures and text may be
as high (as deep?) as you can go without losing clarity and therefore
value for some part of the group. Yes, sometimes those pictures are
the ones thrown up by code more or less like the solution as it will
be implemented. Often (for one or more reasons I mentioned) they
won't.

I don't think the fact that bad practice exists in applying a
particular approach condemns the aproach out of hand. Unless, of
course, you can show that the approach encourages that practice, which
can be judged "bad" on some wider criterion. (I think there _are_
valid arguments of this kind to be made concerning UML in particular
areas of application.)  I wouldn't advocate indiscriminate use of UML
or any other form of diagramming simply to bulk documentation. As a
mentor to specification writers, I often find myself telling people to
remove or simplify diagrams (and other material) in order to get rid
of detail that serves no useful purpose for the readers of a document.

I could go on with examples, and with my detailed opinions on
appropriate uses of diagramming in specifications, but this is
supposed to be a Python forum...


--
Martin Rand
Highfield Software Ltd
mwr at highfield-software.co.uk
Phone: +44 (0)23 8025 2445
Fax:   +44 (0)23 8025 2445