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

[Martin Rand]

On Thu, 17 Aug 2000 15:52:41 -0400, "Warren Postma"
<embed at NOSPAM.geocities.com> wrote:

>
>I have yet to see the wisdom in Draw Blobbygram First, Code Later.  Can
>anyone point me at a book which might change my mind?   I use Delphi a lot,
>and I feel a certain affinity to Smalltalk, but none at all to C++ or Java,
>because Delphi and Smalltalk programmers have the "learn by experimenting,
>then build your own tool set" mentality pretty much down, so if they can
>adopt UML, then perhaps it can work for a Pythonista.
>
>A book on UML with Smalltalk (since there are probably none for Python)
>would be interesting to read. Anybody got a recommendation? Perhaps it could
>lend some insight into UML on dynamically typed languages.
>
>IMHO, it is better for me to prototype than draw blobbograms and type in
>use-cases.     Customer feedback can be tracked, and specs can be written
>and agreed on, and the right design becomes obvious, by doing it via 'RAD'
>principles.
>
>Okay, Okay, I'll admit I'm a sucker for nice visuals.  Some times I use
>Visio or Corel Draw to illustrate my ideas, but that's only where I think a
>visual model helps.  If it was easier, or automatic, then sure I'd use a
>Python UML tool, but I think a visual form builder would actually save me a
>lot more time, and get my prototypes done faster. Then after that, I would
>*maybe* worry about what lines go from what cloud to what other cloud.
>
>Anybody agree with me? Anybody think I'm nuts?
>

Such a lot depends on the environment you're working in. Do you work
in a team where not everyone who analyses requirements or does
functional design also codes? Do you work on distributed systems where
an architecture must first be worked out, and several implementation
languages are then used? Do your systems include complex control
philosophies and fault handling that need to be talked through, where
a  "Rapid" App Dev demonstration would involve complex simulation code
or the loan of a large factory? Do you need to model *any* process in
an implementation-dependent manner, so that it can be walked through
easily? Do you need to think about structuring of information for a
client in general, and independent of a single application? Do you
concern yourself with designing software for re-use? Do you have to
worry about designing large systems that are robust under changing
requirements?

Protoyping and simulation strategies can help with all of these. So
can diagramming, and often it's cheaper, cleaner and of more lasting
value.


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