Rational-Rose and Python ...

[Warren Postma]

"Ralph Heinkel" <heinkel at LABER.embl-heidelberg.de> wrote in message
news:8bt5fh$p2t$1 at news.urz.uni-heidelberg.de...
> Hi,
>
> I am considering to purchase Rational Rose to plan a medium complex
> software system in our lab. However (as most CASE tools) they do not
> yet support Python. Did anybody take the burden and developed his/her
> own (and is willing to spread it to the world)?
>



Philosophical Question:

What need is there for a modelling language, in component based or
interpreted [Smalltalk/Python/TCL/Perl/Java/Delphi] languages that promote
"RAD" or "incremental" development, and which given rapid feedback to their
developers, and encourage experimentation and prototyping?

Is UML a creature best suited to non-RAD/non-Component-based languages, such
as traditional "C++ with class library" development?


 ---

Experiential Question:

Is anyone else out there jaded about OOP+UML?  See my "rant" for reasons
why...

Has anyone thought of a more Pythonic replacement for the visual
Object/Class/Instance/UseCases/Interfaces Modelling?  I rather think the
Smalltalk Browser concept could be interestingly applied to python, perhaps
with a few visual "objects with arrows between them" kinds of touches thrown
in.  Perhaps wxPython's Object Graphics could be used to draw these. Any
thoughts?



 ---



A Rant on Modelling, Buzzwords, Etc, Since the Topic Came Up:

In 1995, about 2 years after graduating from CompSci, I got hired for a
C++/ROSE project, with a team of about 10 developers, which ended up getting
mired down and eventually collapsing under it's own weight.  Since that
time, I have been quite scared of "modelling and design" activity, and of so
called "System Architects" in general.

We designed things in small teams, according to the best practices we could
find in whatever we had read in books.  What started as a clean and
intuitive object model got bizarre when we factored in the buzzwords:

- we promised the customer a "three tier client-server architecture" using a
  GUI client (OS/2 presentation manager), middleware tier (OS/2 Pipe
Server),
  and SQL backend (IBM DB/2) with server-size stored procedures in a
compiled
  DLL format.

- we decided to use the smalltalk-ish "model-view-controller" architecture
to
  separate the presentation layer (GUI) which was coded using IBM
VisualAge/C++
  PARTS class library, from our client-logic and client-data-access layers.

- Our SQL Database Administrator was crazy about "normalizing" the
relational
  database, so that mapping the object model to the relational model became
an
  exercise in mental gymnastics.  We're talking about 20+ tables just to
store basic
  personal contact information.

All these elements were designed by people religiously following the "best
practices" of their industries. The relational SQL people knew about
normalization, the OOP designers knew about Model/View/Controller
architectures and the overall client-server-application designers believed
deeply in three-tiered architectures and each could itemize clear benefits
and reasons for going with all of their much-loved technological buzzwords
of choice.

Multiply all those permutations and layers and you got a C++ program with
bazillions of ill-advised intermediary objects with little functionality,
which existed merely to pass data from one layer to the next.  We were
supposed to keep this byzantine object model in ROSE in sync with our C++
code. This was supposed to be a no-brainer, since even then (1995) ROSE had
"two way tools".

I began to feel it was rediculous that it took 1000+ classes and 500,000
lines of code to replicate what we could do in about 1000 lines of the
scripting language we had at the time (REXX for OS/2 with Presentation
Manager GUI) which we used to build a prototype of the system in a few days.

Since that time I have started to think that if designs get so complex that
they can't be expressed on a proverbial napkin, perhaps step 1 is to rethink
the basic assumptions that got us to this point. For example, how much sense
does it make to hardcode business rules in a static language (C++) and since
all that object orientation goes away as soon as you compile C++, why does
it matter how many intermediate objects you have nestled snugly together in
your SQL database client GUIs anyways?

So, all this leads me back to Python, which I believe is a powerful weapon
against buzzword-toting specialists who like to chronically over-design
their applications.

Python is a good enough language [better than REXX, Realizer, and others I
have used] that I now believe it makes sense to build both the prototype and
the eventual system in Python. Given that, I don't know if I'd need a visual
modelling tool for what I do.  I would think instead, that using Python's
introspection capabilities that it should be possible to generate design
documentation for a Python program, that would serve the same end.  So, I
guess I think of ROSE as a tool that helps the "C++-is-a-way-of-life" people
generate rube-goldberg-machines that, statistically speaking, have ZERO
chance of actually working as designed. Geez, am I cynical enough yet?! ;-)

Warren