gnue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: UML cooperation


From: Micheal J
Subject: RE: UML cooperation
Date: Mon, 30 Oct 2000 16:51:00 -0000

I'm sure all list members would understand when I say I won't continue the
philosophical debate in this or other messages. What I would do is address
the issues of where UML and other design tools/processes/languages may be of
help to the project:

| -----Original Message-----
| From: address@hidden [mailto:address@hidden Behalf Of Andrew
| Hill
| Sent: 30 October 2000 10:35
| To: vio
| Cc: Derek Neighbors; address@hidden
| Subject: Re: UML cooperation
|

<SNIP>

| Graphical development tools are not essential in anyway to the project.
| They just help development
| processes for large scale development.

No tools are essential Andrew. We don't even have to write GNUe. All that
GNUe does can be done on pen and paper. We are producing GNUe to help
financial processes for end users. We perceive some value in doing that and
so do the end users (some of us are potential end users as well).

UML isn't just a graphical development tool and, Rational Rose (or other UML
tools) aren't just graphical development tools. What you see on the screen
when you draw class diagrams for instance is a graphical representation of a
design model that defines the structural and semantic architecture &
interfaces of a system. You can capture more of course and Rational Rose for
instance supports extended attributes beyond the vanilla UML ones.

A standard language for communicating design like UML is very useful because
it allows detailed nuances of a design to be captured in a format that is
platform neutral and universal (assuming of course that everyone learns
UML). The data behind the UML model of the design can be transformed using
custom tools if need be to generate code, documentation, frameworks etc.
Many of these transformations are offered with many UML tools out of the box
but you are free to provide your own.

<SNIP>

| I still have to grasp how RR or ArgoUML will benfit GNUe in any
| reasonable way.
| They don't generate any code that we need. They are only automate the
| process of 'pen&paper to
| headers' to 'RR to headers'. How many hours would it save us initially,
| 10, 20hours? of coding.
| Theres no point.

Ignore code generation for a minute Andrew. Would you like to have the
design of the system as we know it now fully documented ?. Yes?...thought
you might like that.
well, UML tools do not automagically document your systems but they sure
make your life a lot easier once you've decided that you *are* going to keep
the designs documented so that your peers can review and improve the system
and, so that were you to leave others can carry on and not restart because
the system is documented, ...

<SNIP>

| > Finally, if you want me to shut up, well it's your project, so
| I'll (try to) respect that.  But as my grandma would say "You
| won't go far with That attitude, young man". I believe you want
| to attract people willing to put their free time and effort on
| your project, not scare them away. Else, you will see your people
| shutting down or ... branching out. Trick or treat!
|
| I for one don't want you to shutup. We have done a lot of work (many
| MB's of just pure source
| code) and i don't want to go backwards and dump all because we didn't
| use the best tools for
| the job but made do with what we had.  So don't ask me to do that
| without real good reasoning.  I definitly want the best software. But i
| am willing to make some comprimises to get there.

The minimum end result is just the code Andrew. If we got working code that
did it's job without a single design document, we will be deemed to have
succeeded. The system may be impossible or prohibitively expensive to
maintain/upgrade but it will exist.

If on the other hand we had perfect design documents but no code, we would
really be able to claim to have succeeded beacuse we have no working system.

The irony is that, the system with the most likely chance of *long term*
success is the design document. Anyone should be able to come along later
and build the system from the design. They can then go on to improve,
maintain, upgrade (even replace) the system easily because it is so well
documented. Of course this assumes that the design was a "good" design to
start with...

Cheers!,

Micheal




reply via email to

[Prev in Thread] Current Thread [Next in Thread]