Re: Specifying all biz rules in relational data

From: Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net>
Date: Tue, 21 Sep 2004 22:10:11 -0400
Message-ID: <4umqic.81v.ln@mercury.downsfam.net>

mAsterdam wrote:

> GL? Generation Language ?? General Level of abstraction ??
>

>> level capabilities. there are known issues both with the RM and real
>> world implementations: projection-join anomaly and updateable views,
>> to name just two. so, the RM can't model everything, and even if it
>> could, a tool which aggregates its semantics loses some part of that
>> semantics.

> 
> Yep. Some of the loss will be deliberate
> in any such aggregating effort, though.

Exactly! Leading to the question, do we need more tools, models and layers of abstraction, or do we just need better discipline?

>> in a later part of this thread is the notion that the "language of
>> the month" could be swapped out (COBOL for Lisp, let's say) at the
>> whim of, well, the owner of this Magic Bullet. who would know whether
>> the generated system was still correct? how would anyone know, save
>> by exhaustive enumeration of every path through the code? not to
>> mention that the folks who have to use the Magic Bullet generated code
>> become instantly redundant; replaced by experts in the "language
>> of the month". i suppose that coders are as expendable as cogs in a
>> machine, but the Magic Bullet Co. might find their ability to staff
>> inhibited by this.

> 
> Yet, change does happen. Early COBOL by
> assembly programmers who had to make the
> switch wasn't nice, but they learned,
> eventually.

Short answer: If all you change is the language of the UI, then it is technically outside the scope of this thread, because we are worried about the stuff that handles biz rules. But I get the point, so:

Long Answer: But what if I write a new generator that hits part of the biz rules processing in a new language, such as targeting a new DB server/vendor? How can I be sure the generated database works?

This is easy. Go back to the fundamental premise that we limit ourselves to a finite number of solution patterns. This means our testing is by definition finite, if not small. Even the n! combination of all these features is finite, and also generatable itself. This means you write only one tester, and you do it in the language of your choice, and it does this:

Generate a test data dictionary containing all combinations of features.
Invoke the builder to build on a platform
Generate transactions that implement all features you are testing.
Compare database values to specs in the data dictionary.
For good measure, add a feature that allows the column-by-column row-by-row comparison of any two databases. This allows your gadfly person to create a db by hand and try to fool the tester.

Even you have projected all biz rules into x patterns, this test can still run in less than an hour on any modern equipment.

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me

Received on Tue Sep 21 2004 - 21:10:11 CDT