Re: [regrep-cc-review] Association Core Components - Represent withAssociations

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Sent on behalf of Diego.

Diego Ballvé wrote:
> 
> Joe and Farrukh,
> 
> Comments inline, plus analysis/suggestion on ASBIE/BBIE.
> Comment that, please.
> 
> Regards,
> Diego
> 
> Chiusano Joseph wrote:
> > <Quote1>
> > An instance of type ASCC can be seen as a CC since extends CC (it has
> > all CC fields).
> > </Quote1>
> > AND
> > <Quote2>
> > Sorry, but I still cant see the replication.
> > </Quote2>
> >
> > Since ASCC extends CC (it has all the CC fields plus more): If an ASCC
> > were represented as a RegistryObject (rather than an Association with
> > Slots), wouldn't values for the fields that it has in common
> > with CC be
> > duplicated as well?
> 
> Detail: CC is abstact. ASCC, ACC and BCC are concrete.
> ASCC extends CC, so it must have all the fields defined for CC.
> The same way, ACC extends CC, so it must have all the fields
> defined for CC. Now, ASCC references ACC. ASCC does not reference
> ACC in the sense of inheriting fields.
> 
> Illustration:
> ACC "Address. Details" might have business term "Address",
> 
> while ASCC "Person. Residence_ Address" might have business terms
> "Residence, Residence Address, Home Address",
> 
> and ASCC "Person. Official_ Address" might have business terms
> "Official Address, Work Address, OfficeAddress".
> 
> > If not, what values would the ASCC fields hold?
> 
> According to Figure 7.1, the fields below (which have different values
> than the fields in the referenced ACC)
>     * from RegistryClass *
>   - Unique Identifier
>   - Version
>   - Dictionary Entry Name
>   - Definition
>   - Usage Rule
>     * from CoreComponent *
>   - Business Term
>     * from our merge with BIEProperty *
>   - Property Term
>   - Cardinality
>   - Reference to ACC
> 
> Similarly BBC fields should be the same except for "Reference to ACC",
> which is replaced by "Reference to DataType".
> 
> Finally, ACC fields are
>     * from RegistryClass *
>   - Unique Identifier
>   - Version
>   - Dictionary Entry Name
>   - Definition
>   - Usage Rule
>     * from CoreComponent *
>   - Business Term
>     * from AggregateCoreComponent *
>   - ObjectClassTerm
>   - References to aggregated ASCCs/BCCs.
> 
> Most of the fields have the same name in ACC/ASCC/BCC and also
> the same type of information, but there's nothing saying the
> values are the same. In fact, some of them must be different
> (DictionaryEntryName and Definition).
> 
> > [Keeping in mind that the fundamental question is still:
> > Should an ASCC
> > be represented as an Association that "connects" two ACCs in the
> > registry, with additional Slots to represent things such as
> > Cardinality
> > and Object Class Qualifier]
> 
> Before answering this fundamental question, some comparison
> using data from example - page 12 CCTS. Slots not mentioned
> should correspond to the field lists above, with exceptions.
> 
> A) ASCC as RIM Association that "connects" two ACCs:
> 
> 1. Extrinsic Object - ACC "Person. Details"
> 2. Extrinsic Object - ACC "Address. Details"
> 3. Association - ASCC "Person. Residence_ Address"
>    .sourceObject = Extrinsic Object - ACC "Person. Details"
>    .targetObject = Extrinsic Object - ACC "Address. Details"
> 
> B) ASCC as RIM ExtrinsicObject "connected" to two ACCs:
> 
> 1. Extrinsic Object - ACC "Person. Details"
> 2. Extrinsic Object - ASCC "Person. Residence_ Address"
> 3. Extrinsic Object - ACC "Address. Details"
> 4. Association - "ACC contains ASCC"
>    .sourceObject = Extrinsic Object - ACC "Person. Details"
>    .targetObject = Extrinsic Object - ASCC "Person. Residence_ Address"
> 5. Association - "ASCC references ACC"
>    .sourceObject = Extrinsic Object - ASCC "Person. Residence_ Address"
>    .targetObject = Extrinsic Object - ACC Address. Details"
> 
> Approach B has 2 extra objects (3 vs 5).
> Approach B (might) requires 2 steps to get from Aggregate to Aggregated.
> 
> My opinion: make it more complex but optimized. Well documented,
> of course. Approach A.
> 
> The interesting fact that comes from this analysis is that
> BCC has a similar behaviour, as I wrote in the other mail..
> that day I was just brain-storming, but today I'm serious
> about it. BCC as Association has advantages!! See this:
> 
> A) BCC as RIM Association that "connects" ACC to DataType:
> 
> 1. Extrinsic Object - ACC "Person. Details"
> 2. Extrinsic Object - DataType "Text DataType"
> 3. Association - BCC "Person. Name. Text"
>    .sourceObject = Extrinsic Object - ACC "Person. Details"
>    .targetObject = Extrinsic Object - DataType "Text DataType"
> 
> B) ASCC as RIM ExtrinsicObject "connected" to ACC and to DataType:
> 
> 1. Extrinsic Object - ACC "Person. Details"
> 2. Extrinsic Object - BCC "Person. Name. Text"
> 3. Extrinsic Object - DataType "Text DataType"
> 4. Association - "ACC contains BCC"
>    .sourceObject = Extrinsic Object - ACC "Person. Details"
>    .targetObject = Extrinsic Object - BCC "Person. Name. Text"
> 5. Association - "BCC is of type DataType"
>    .sourceObject = Extrinsic Object - BCC "Person. Name. Text"
>    .targetObject = Extrinsic Object - DataType "Text DataType"
> 
> C) ASCC as RIM ExtrinsicObject "connected" to ACC referencing DataType with slot:
> 1. Extrinsic Object - ACC "Person. Details"
> 2. Extrinsic Object - BCC "Person. Name. Text"
> 3. Extrinsic Object - DataType "Text DataType"
> 
> Again, Approach B has 2 extra objects (3 vs 5).
> Approach B (might) requires 2 steps to get from Aggregate to Aggregated.
> C does not make use of Association..
> 
> My opinion: Same as before, make it more complex but optimized.
> Approach A.
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard