Re: Feedback Due 9/5: Updated Requirements Mapping

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

Forwarded on behalf of Diego. Please see comments marked with <JMC3>.

Diego Ballvé wrote:
> 
> Chiusano Josheph wrote:
> > <JMC2>
> > We won't need such fields, since we will not be representing ASCCs as
> > entities but rather as Associations (so no dictionaryEntryName, no
> > propertyTerm, etc.). The CCTS spec is *much* too heavyweight on their
> > representations here - on top of ASCCs being entities, it
> > also specifies
> > Association Core Component Properties (more entities!). Yikes!!!!
> >
> > So we're getting rid of layers that do not need to exist.
> > </JMC2>
> 
> .. and creating new layers to substitute them - that
> "Address. Details" dicussion, where ACC extends ACC????

<JMC3> 
The case you cite does not involve layers - it is horizontal in nature
(extension), rather than vertical in nature (layers).
</JMC3>

> I DO see the point for propertyTerm, propertyTermQualifier and
> cardinality for an ACC/ABIE's contained properties (from UML POW),
> regardless if the property is simple (Basic) or complex (Aggregate).

<JMC3> 
I concur.
</JMC3>

> I can go through the page12 example again but the Address Object
> being used twice inside the Person Object is the perfect example:
> once it is the Residence Address, once it is the Official Address.

<JMC3> 
That is a perfectly acceptable (and common) occurrence. A Person may
have multiple addresses associated with them. Additionally,
creating/storing/maintaining an entity called "ResidenceAddress.
Details" allows it to be reused in multiple scenarios. I'm not sure what
the issue is here.
</JMC3>
 
> I'll shut up if outnumbered and use that approach only inside
> Republica, but IMHO we can't drop those fields.

<JMC3> 
Not sure what fields you mean - I was referring to the properties on
ASCCs/ASBIEs. Since we are not representing these as entities (in the CC
sense) but rather as Associations, these properties are not required for
ASCCs/ASBIEs.
</JMC3>

Joe

> Diego
> 
> > -----Original Message-----
> > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > Sent: Tuesday, September 02, 2003 7:46 PM
> > To: Diego Ballvé; CCRev
> > Subject: Re: Feedback Due 9/5: Updated Requirements Mapping
> >
> >
> > Forwarded on behalf of Diego. Please see comments marked with <JMC2>.
> >
> > Diego Ballvé wrote:
> > >
> > > Chiusano Joseph wrote:
> > > > <JMC>
> > > > Not at all - reference [S2]: "Association Core Components will be
> > > > represented as Associations between ACCs, and will not be
> > > > considered as
> > > > "first rate" Core Components".
> > > > </JMC>
> > > >
> > > > If I have ASCC and I want to store them in the registry
> > > > can I still choose our mapping approach?? I hope so. I though
> > > > the point was to use RIM Association to represent it.
> > > >
> > > > <JMC>
> > > > Yes - see above.
> > > > </JMC>
> > > >
> > > > I propose again (if that is not what we're doing already!)
> > > > that we store
> > > > ASCC as RIM Association, use Association.name/Association.
> > > > description/Association's Slots to store CC/CCProperty details,
> > > > just like we do for BCC.
> > > >
> > > > <JMC>
> > > > Not sure what you mean by "to store CC/CCProperty
> > details". An ASCC
> > > > Association will serve to associate 2 ACCs, and nothing more. CC
> > > > Properties will not be represented as entities in our
> > architecture.
> > > > </JMC>
> > >
> > > Great. No problems here then, I hope.
> > > I meant the fields that CCTS attributes to ASCC/ASCCProperty
> > > (i.e, ASCC.dictionaryEntryName, ASCCProperty.propertyTerm,..).
> >
> > <JMC2>
> > We won't need such fields, since we will not be representing ASCCs as
> > entities but rather as Associations (so no dictionaryEntryName, no
> > propertyTerm, etc.). The CCTS spec is *much* too heavyweight on their
> > representations here - on top of ASCCs being entities, it
> > also specifies
> > Association Core Component Properties (more entities!). Yikes!!!!
> >
> > So we're getting rid of layers that do not need to exist.
> > </JMC2>
> >
> > > Diego
> >
> > Joe
> >
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