Re: [EVALUATION] - E01: The Java Failure - May Ruby Helps?

On Thu, 17 Feb 2005 23:14:51 +0900, Markus Pilzecker
<[e-mail]> wrote:
[snip]
>| Yes, but a generator isn't necessarily the same as what was being
>| talked about. All of the generators that I've ever used have been
>| domain and application specific.
> At least those modern ones like AndroMDA or ArcStyler are quite
> independent of the practical domain. They are of course to some
> extent specific to the target technology -- but only in one
> aspect: you get delivered object technology for the [transformer/
> generator] framework plus some ``library'' transformers, you can
> start with. These latter are partially quite generic like an EJB
> generator, you can derive your own specific, lets say Jonas-,
> generator from. Partially, you get e.g. a concrete
> product-specific WLS8 generator. And for this, of course, it's
> quite right to speak of specificity wrt. the target technology.

I'm still highly skeptical. I don't doubt the value and efficiency
benefit from code generation: I was one of the many technical
reviewers on Jack Herrington's _Code Generation in Action_ and it's
an amazingly useful book. But I've seen entirely too many situations
where UML has been abused and misused.

That said, I also think that most modern frameworks are far larger
than they need to be, and I think that Rails, Nitro, Wee, and IOWA
are excellent examples of what can be done if you have a highly
expressive language and don't have to write ten thousand helper
classes. I also don't think that UML simplifies matters in the
least.

ArcStyler looks impressive -- and it will be a tool that I
investigate should I ever need to work in one of these crazy
environments again. But I'll probably lean more toward the CGiA
approach rather than another expensive tool that makes it difficult
to migrate from.

[big snip]

> | (And I'm unsurprised that UML is being pushed this way. UML is
> | good for very few things, and the most important part of making
> | an n-tier database applications is one of the things that UML is
> | worst at: data modeling.
> 
> I'm not sure, if it is that bad: define the datatypes of your
> database and store that in a profile. Every table is a class with
> attributes /*the columns*/ of one the available types. May be, I
> oversimplified a bit -- but did I too much?

Yes, actually. The language behind UML lends itself well to class
definition, but not so well to relation definition. In my logical
model, I might have:

  +-+0..*  0..*+-+
  |L|----------|R|
  +-+          +-+

Where L and R represent tables that have many-to-many relations with
each other. In practice, this is almost always implemented
relationally as:

  +-+0..*  0..*+-+0..*  0..*+-+
  |L|----------|M|----------|R|
  +-+          +-+          +-+

Where M is that many-to-many relation table. There's no way that
would ever be represented that way in UML. In all likelihood, the
class L would contain a set of Rs. This sets up a one-way-browse
situation. To bring it a bit more concrete, if L is a customer and R
is a rate package, then many customers may have a single rate
package and some customers may have multiple rate packages. The
proper relationship in an OO hierarchy in this case is that an L
owns zero or more Rs. Without setting up a cyclical hierarchy or
scanning the set of Ls for all their Rs, you have no way of knowing
which Rs are used by what Ls. In a relational database, this is
easy -- and the modeling as such is very different.

> The other question is, if it _should_ be good at that. At least
> the a-priori assumption was[ according to some human judgement of
> a certain community], that OO is superior to ER. And if you have
> legacy RDBMSs, you have specify some OR-mapping -- most probably
> somewhere in your transformer model. If you don't have that
> legacy, you could have that mapping undercover -- or you use an
> object database anyway. In these latter cases, you won't have to
> model any ER part.

Well, the problem is that object databases are simply a repeat of
hierarchical databases. The object graphs are typically one way, not
two way. Relational databases describe relationships and are and
always will be superior to object databases, despite the impedance
mismatch that most people have when converting from the open-ended
relationship description in relational databases and the closed-
ended relationship description in most OO languages.

So yes, the a priori assumption was that OO is superior to ER, but
that assumption is unequivocally wrong. OO makes the mistake of
putting the data on equal footing as the application. Considering
that a lot of people developed applications without concern for the
data, this was an important step forward in theoretical circles. In
practice, businesses *always* consider their data more valuable than
their programs. OO turns this on its head by tying the data so
tightly to the program that the data becomes difficult to use in any
other way.

Yes, I'm biased. I saw a company that I worked for spend many
millions of dollars on implementing a system that was designed by
hotshot college graduates who had been filled with the worst sort of
OO design garbage and had absolutely no data modeling skills to
understand their data separately from their object model. The system
took thirty seconds to simply authenticate users -- and they
couldn't get it under seven seconds. The version of the system that
I worked on was much more realistically developed and had a good,
strong data model that drove the object design. Ultimately, the
expensive project that was heavy on UML and related technologies was
killed and many of the developers were integrated into the team that
I worked on.

The OMG isn't a disinterested observer here. Neither, ultimately,
are you, as you work for the makers of ArcStyler. But UML holds very
hollow promises for anything smaller than an enterprise billing
system -- and its promises there aren't much better, because it adds
a lot of overhead. Data modeling is the single most important skill
that any developer can learn; if you can learn to model your data,
you can learn to make good objects than have better reuse
characteristics.

>| It's too based on OO technologies to even remotely come close to
>| properly modeling data relationships other than hierarchical.)
> Where is the restriction to hierarchies? I think, I'm able to draw
> general graphs...

You can, sort of. But for a variety of reasons, you're not going to,
and UML actively discourages it. See my discussion above on the one-
way-browsing problem.

-austin
-- 
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]