[ruby-talk:6532] Re: Ruby vs. UML ?

[e-mail] (Ross Mohn) writes:

> Dave & Andy:
> In your interview (http://www.amazon.com/exec/obidos/tg/feature/-
> /99126/106-8617608-4759630), you make the following prediction:
> 
>     Ruby will be used increasingly for "live modeling,"
>     in place of UML or other static techniques.
> 
> Could you please elaborate on this? Do you really mean replace UML? How 
> would this work in practice? The visuals of something like UML are often 
> quite helpful. Would you propose to have Ruby dump it's model to diagrams, 
> etc?

This is something we're currently in the middle of, so what follows
may well have large holes. Bear with us.

This starts off with the question: how and why do we capture
requirements?  One reason is to have a permanent record: some
formalism of what was agreed. Another reason, and one that we're all
struggling with, is to try to reach an understanding of what is
actually needed. The client says they want "x", and we write down what
we understand "x" to mean.

As an industry, we've tried many ways of doing this, from prose
specifications, to formal notations, to use cases. They all work to
some extent, but they all also have problems: prose isn't precise
enough, formal notations are not much different that programming, and
use cases are widely misunderstood and rarely done properly. In all
cases, there is also a communications gap: the client says "x", the
programmers echoes back "x", but there's no guarantee that they're
talking about the same thing.

Along come practices such as eXtreme Programming. They say that the
best communication is working code, and minimize up-front work in
favor of getting something in front of the end user. We think that's
wonderful: we've been advocating tracer-bullet and prototyping
approaches to describing systems for a long time.

Now what if you could reduce the gap even further. Rather than use
(say) Java, and get 10% of the overall work done in a 2 week
iteration, what if you could use Ruby, and get 50%, or 100%. Wouldn't
that be better?  So, we're investigating how Ruby could be used as a
way of expressing a requirement in running code.

Do we mean that the final system gets programmed in Ruby? Not
necessarily. The Ruby version could be viewed as a prototype: as a
specification. However, rather than throwing it away, perhaps we could
look at _why_ the Ruby code isn't the final system.

Is it too slow? Then let's find where the bottleneck is and recode it
in something faster. Ruby is easy to extend in C or C++.

Is it missing the libraries or interfaces we want? Then perhaps
extending it to have them might be quicker than rewriting the whole
application.

We're wondering to what extent a rapid Ruby development could then be
incrementally migrated to a final solution. You have a rapidly working 
system to express you requirement, and a solid and flexible skeleton
over which you could flesh out your application.

Of course, the devil's in the details.... ;-)


Regards


Dave