From lechner@cs.uml.edu  Fri Sep 15 22:34:23 2006
From: Bob Lechner <lechner@cs.uml.edu>
Subject: Re: week 1 homework Question (A.G.)
To: agabriel@cs.uml.edu (Anthony J Gabrielson)
Cc: alison_lea@yahoo.com, kbagley@us.ibm.com, cguffey@gmail.com,
        agabriel@cs.uml.edu, nitin.sonawane@verizon.net,
        lechner@cs.uml.edu (Bob Lechner)
RJLref: $PH/06f522/asgnt1/06f522asgnt1FAQ1_ag.txt

> From agabriel@cs.uml.edu  Fri Sep 15 09:02:34 2006
> From: Anthony J Gabrielson <agabriel@cs.uml.edu>
> To: lechner@cs.uml.edu
> Subject: week 1 homework (fwd)
> Hello,
> 
> I'm confused by the ledger in the drawing you passed out, 
> why doesn't it point to sale?  
> Do you want to discuss the before class on Tuesday?
> 
> Thanks for your help,
> Anthony
> 

Thanks to Anthony for raising this question.
I welcome all your attempts to solicit such clarifications of
requirements - for assignmens, projects or otherwise.

Larman's Fig. 9.27 (Fig. 9.17 + attributes) indeed connects Sales to both
Ledger and Store.  Thus it contained an fkey to both parent types.
My handout drawing 9.27C (9.21Ci is a typo) permits one 'consolidated' 
Ledger to handle multiple Stores. I did not expect you to change 
the requirements from those implied by the ERDiagram. I just 
jumped ahead for this reason:

My Sale has only an indirect path via Register and Store to Ledger. 
It's reasonable that no Sale can happen except thru a Regiser.
A direct path to Ledger and to Store from each Sale would be  
redundant because it requires an fkey to Store in each Sale
(this dkey is already acxcessible via the Register). 
The Ledger fkey would appear in many instances of Sale; 
it is only needed in a few Register instances. 

If each Store had its own private Ledger as a component,
then I would demote Ledger to a peer of Store as in Fig. 9.17/9.27,
or put it below Store and give Register an fkey to Ledger (not Store).
Sale would then have a two-link path via Register to Ledger.
I would NOT include a Store fkey in Sales, only a Register fkey. 

Of course, the mistake is to think of fkeys as an implementation
decision made much too early. Here it is only a convenient term 
for the conceptual association of each components 
to their (unique) aggregate container.

The important factor at the conceptual or logical level 
is not time and/or space efficiency but clarity of expression
(especially aggregate and multiplicity properties).  
I think clarity is helped by a common notation
used over multiple abstraction levels (but to each his own :-)

Questions like this may resolve multiplicity and optionality ambiguities 
(couched in the customer's language, of course). 
This may clarify the analyst's own domain knowledge
and make the model more precisely fit the application.

[But then again, it may not - you have to judge the customer.
On the largest projects (>10M lines of code) the real problem is
to find out who the real customer is, for each cost/feature tradeoff.] 

Thanks again to Anthony for raising this question.

R Lechner