From: Austin Ziegler Date: 2005-02-18T01:52:54+09:00 Subject: Re: [EVALUATION] - E01: The Java Failure - May Ruby Helps? On Thu, 17 Feb 2005 23:14:51 +0900, Markus Pilzecker 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 * halostatue@gmail.com * Alternate: austin@halostatue.ca