TMG-L Archives

Archiver > TMG > 2004-07 > 1088971968


From: Dennis Lee Bieber <>
Subject: Re: [TMG] Spouses even though no marriage shown?
Date: Sun, 04 Jul 2004 13:12:48 -0700
References: <485ea3c84c.tim@south-frm.demon.co.uk><8806b8c84c.tim@south-frm.demon.co.uk><5a5dc4c84c.tim@south-frm.demon.co.uk><013201c4611e$2e17a070$6401a8c0@charliexv><07c333c94c.tim@south-frm.demon.co.uk>
In-Reply-To: <07c333c94c.tim@south-frm.demon.co.uk>


On or about 07/04/04 05:01 a carrier pigeon from Tim Powys-Lybbe delivered:


>This is where TMG is not reading the data in Generations correctly.
>Generations would say that a couple's status is Marriage unless the user
>has entered something different. That is how Generations works.

Ah, but this requires one to know the "business rules" IMPLEMENTED
by Generations. This is a much more complex arena than just reverse
engineering from only the data tables. Anyone honest, given just the task
of importing the data contained in a set of files, would follow what is in
those files explicitly.

Can you state, in a format usable for software engineering, the
logic Generations uses when reading data from a file to come to some
conclusion? These statements, if done to formal specifications look similar to:

The import module shall generate a marriage event when the marriage-flag is
set to 1 (marriage).

The import module shall generate a marriage event when the marriage-flag is
set to 0 (marriage unset).

The import module shall generate a custom common-law marriage event when
the marriage-flag is set to 3 (common-law marriage).

The import module shall not generate a marriage event when the
marriage-flag is set to 2 (unmarried).

Carry this process out for all criteria that Generations uses for
determining marriage conditions. (Oh, that "shall not" in the last
requirement, in the most strict specifications, is a "no-no" --
requirements state what a program must perform, not what a program must not
perform).


Complaining about TMG's lack of knowledge of Generations computed
marriage state would be similar to complaining about a "tax program"
computing a large taxable income because it is working from data from
another program that has a table of "person:gross income:# dependents" and
one of "income:tax due" with no information that the value of "income" is
based on "gross income - (# dependents * some-constant)".

Since disassembling Generations to find out the actual code logic
is commonly frowned upon (if not illegal), one is left with black-boxing.
Enter data into the program, and see what comes out the other side -- then
use that knowledge to design the module that accesses the data files. I
doubt that WG has the staff to try every possible means of data entry, with
every possible program, to analyze and derive requirements for the import
module(s). Not to mention, the staff -- being familiar with how TMG works
-- everything must be explicitly entered, quite likely would add marriage
data, thereby masking Generation's implicit "marriage if not stated
otherwise". So, I suspect WG is strictly reverse engineering the data files
only, in the absence of the Generations program.

--
> ============================================================ <
> | Wulfraed Dennis Lee Bieber KD6MOG <
> | Bestiaria Support Staff <
> ============================================================ <
> Home Page: <http://bieberd.home.netcom.com/>; <


This thread: