[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: [CEFACT-ATG:682] RE: [atg2] modularity discussion]
--- Begin Message ---
- From: JOSTEIN FRØMYR <jostein.fromyr@edisys.no>
- To: ECE - Communication with Applied Technology Group<cefact-atg@list.unicc.org>
- Date: Mon, 12 Jan 2004 10:49:00 +0100
Tony, You will notice that Fig 6.1 shows the CC Property as a composition (using a filled diamond) of an ACC. In UML 1.4 the definition of a composition is as follows: "Composite aggregation is a strong form of aggregation, which requires that a part instance be included in at most one composite at a time and that the composite object has sole responsibility for the disposition of its parts." As you indicate the normal interpretation of cardinality when nothing is explicitly given is 1. Thus in my interpretation a CC Property, whether BCC or ASCC, can only exist as part of one ACC. Jostein > -----Original Message----- > From: paula.heilig@worldspan.com [mailto:paula.heilig@worldspan.com] > Sent: 9. januar 2004 20:35 > To: ECE - Communication with Applied Technology Group > Subject: [CEFACT-ATG:680] RE: [atg2] modularity discussion > > > > > > > Tony, > James or Jostein can probably respond more eloquently, but i > will make an > attempt to respond to your questions. > > No, you can't have a BCC/BBIE in more than one ACC/ABIE. > Since both a BCC > and BBIE are a property of an object class and the name includes this > object class, they can not be in two different ACC's/ABIE's. > Your example > of an ACC of address and an ACC of short address is also not > allowed in the > CCTS. It is my understanding that what you would have is an > address ACC > that would include everything possible for an address and > from it you could > create an ABIE of short address that would restrict the use > of some of the > properties so that they would not be used. You would not > want to define > two different BCC's for house number because then you would > have two BCC's > with the same semantic meaning and different names. > > i hope this helps clarify. > > paula > -------------------------------------------------------------- > ----------------------------------------------- > > Worldspan e-Pricing... The next generation in fare search > technology âÇô > http://www.epricing.net > > > > > > "Tony Fletcher" > > <tony_fletcher@bt > > openworld.com> > To > Sent by: "ECE - Communication > with Applied > owner-cefact-atg@ Technology Group" > > list.unicc.org > <cefact-atg@list.unicc.org> > > cc > > > 01/08/2004 04:26 > Subject > PM [CEFACT-ATG:677] RE: > [atg2] > modularity discussion > > > > Please respond to > > cefact-atg@list.u > > nicc.org > > > > > > > > > > Dear Paula, Jostein and James, > > The three of you are much more well versed in the core components > specification than I am so I suspect you are correct. > However, I have to > say that it is not obvious that this should be the case. > > I am sure I am missing something trivial as I have not been in the > discussions, but does it not mean that you can not re-use > BBIE in several > ABIEs (and likewise a BCC in several ACCs) and I thought that > was the whole > idea. So please reply to me with the solution / reasoning of > line if you > think they are already well known to other members of the > group - thanks. > > It also does not seem completely evident to me from figures > 6.1 and 6.2. > Your comment on Figure 4.2 may still be correct, but is a > different issue - > namely can a BBIE be used directly in a message assembly or > only as part of > an aggregate. > > I am addressing the issue of can an BBIE only be use in one > ABIE or several > (and similarly whether a basic core component can be used in only one > aggregate core component nor several). Figure 4.2 is silent > on this point > as it does not show cardinality on any of its relationships. > > However, Figure 6.1 does. It seems to say that a BCC is one > to one with a > Basic CC Property which is a sub-type of CC Property of which > there are one > to many composing an ACC, but frustratingly the cardinality > from ACC to CC > Property is not shown explicitly (so I guess it defaults to 1?) and > similarly in Figure 6.2 (this time for both ACC and ABIE). > > Use case: this may not be the best example, but suppose I > want to have an > ACC of short address = house number, post code and an ACC of address = > house > number, street, town / city, region, country > Then I would have to define different BCCs for house number > as I can not > re-use in different aggregates?? > > Best Regards Tony > A M Fletcher > Home: 35, Wimborne Avenue, IPSWICH IP3 8QW > Tel: +44 (0) 1473 729537 Mobile: +44 (0) 7801 948219 > amfletcher@iee.org (also tony.fletcher@talk21.com & > tony_fletcher@btopenworld.com) > > > > -----Original Message----- > From: owner-cefact-atg@list.unicc.org > [mailto:owner-cefact-atg@list.unicc.org] On Behalf Of James Whittle > Sent: 07 January 2004 11:20 > To: ECE - Communication with Applied Technology Group > Subject: [CEFACT-ATG:676] RE: [atg2] modularity discussion > > > Paula > > Having looked at the CCTS again I agree with you. I also > agree with Jostein > I think that figure 4.2 does have an additional arrow which > is misleading > between a BBIE and the Message Assembly component. > > Regards > > James Whittle > > Consultant > Standards & Security Unit > APACS - Association for Payment Clearing Services > Mercury House, Triton Court > 14 Finsbury Square > London EC2A 1LQ > Tel: +44 (0) 20 7711 6209 > Fax: +44 (0) 20 7711 6299 > e-mail: james.whittle@apacs.org.uk > web: http://www.apacs.org.uk > > >>> jostein.fromyr@edisys.no 01/07/04 09:26am >>> > Paula, > > I support your conclusion. The definition of BCC says it clearly: > "[Definition] Basic Core Component (BCC) A Core Component > which constitutes > a singular business characteristic OF A SPECIFIC AGGREGATE > CORE COMPONENT > that represents an Object Class." > > This does however imply that figure 4.2 is incorrect, as a > BBIE cannot be > aggregated in a Message Assembly other then through an ABIE. I.e. the > direct > line between the BBEI and Massage Assembly should be removed. > > Jostein > > > -----Original Message----- > > From: paula.heilig@worldspan.com [mailto:paula.heilig@worldspan.com] > > Sent: 6. januar 2004 17:08 > > To: ECE - Communication with Applied Technology Group > > Subject: [CEFACT-ATG:672] [atg2] modularity discussion > > > > > > > > > > > > > > in the discussion on monday on modularity the question was > > asked as to why > > you would need a schema module for Common Basic Components > > since they can > > only exist as part of the Common Aggregate Components. This > > raised another > > question as to whether the CCTS allows for BBIE's that are > > not part of an > > ABIE. Some felt that the CCTS did not say that a BBIE can > > not exist by > > itself. Right or wrong, i feel that the CCTS is fairly > clear in that > > BBIE's (or BCC's) can only exist as part of an ABIE. I cite > > the following > > in the CCTS: > > > > 4.6.1 in definition of BCC âÃçô âÃçÿBBCs function as the > > properties of ACC. > > Figure 6-1 BCC's only seem to exist as part of an ACC. > > Figure 6-2 BBIE's only seem to exist as part of the ABIE > > Rule B24 - The Dictionary Entry Name of a Basic Business > > Information Entity > > shall consist of the following > > components in the specified order: > > - the Object Class Term of the ..... > > how can you have an object class term > > without an ABIE? > > S53 Stored Business Information Entity Properties shall be > > stored as part > > of the stored Aggregate Business Information Entity to which > > they belong, > > i.e., they shall never exist independently of their owning Aggregate > > Business Information Entity. > > S62 Stored Basic Business Information Entities shall > > represent a Basic > > Business Information Entity Property of a particular > > Aggregate Business > > Information Entity. > > > > paula > > -------------------------------------------------------------- > > ----------------------------------------------- > > > > Worldspan e-Pricing... The next generation in fare search > > technology âÃçô > > http://www.epricing.net > > > > > > > -------------------------------------------------------------- > --------- > > ************************************************************** > ************** > > *********** > The opinions expressed are those of the individual and not > the company. > Internet communications are not secure and therefore APACS does not > accept legal responsibility for the contents of this message. > If the rea > der > of this message is not the intended recipient, or the > employee responsible > for delivering this communication to the intended recipient, > you are hereby > notified that any disclosure, distribution or copying of this > communication > is > strictly prohibited. If you have received this communication in error, > please > notify us immediately by telephone to arrange for its return. > Thank You. > ************************************************************** > ************** > > *********** >--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]