<Michel>We believe that UN/CEFACT and ebXML use as a baseline UML (perhaps adapted to the specific purpose of EDI with the UN/CEFACT version UMM). We have difficulty in understanding how to apply the UML principles to the CCTS especially when we look at the core components. All our analysts use extensively UML and one of the prinicpal interests in ebXML and UN/CEFACT is the strong attachment to UML as it enables us to remain business orientated rather than syntax orientated. The standardisation of core components that can be used within UML seem to be extremely rich to us and we therefore want to align our basic constructs on their UN/CEFACT equivalents. The basic principle of UML is that a class is the description of a set of objects that share the same attributes, operations, methods, relationships and semantics. When one looks at the principles of the CCTS core components where a core component contains only the information pieces necessary to describe a specific concept, one expects a UML class and a core component to be very similar. However, one does not understand the requirement within the CCTS that obliges a basic core component only to be used in a aggregate core component. Why can't an atomic part such as an attribut (BCC) be used within any construct, as is possible in UML?</Michel> A UML Class is equivalent to an ACC or an ABIE. A UML Class Attribute is equivalent to a BCC or a BBIE. As far as I know UML Class Attributes are always part of a Class and are not defined separately. Data Types are. <Michel>Can one assume that an ASCC is merely an association between two UML classes?</Michel> Yes. <Michel>There appears to be an inconsistancy between the use of a BCC that can only be referenced through an ACC, however, in a message construct one can mix and mingle both ABIEs and BBIEs as appears in figure 4.2. Thus, since a BBIE is based on a BCC one can construct a structure that contains both ABIEs and BBIEs at the same hierarchical level. Is this correct? This does appear however to be illogical from a UML point of view since an attribute can't be a class.</Michel> Message Assembly is out of the scope of CCTS. Disregard the Message Assembly box and the Assembly Component in Figure 4-2. A change request has been forwarded to remove these artefacts in the next version. But even the figure doesn't tell you how BBIE's and ABIE's are mingled. In an Assembly spec it could (and should) be prescribed that BBIE's can only be used as part of their ABIE. <Michel>I would appreciate a definition and example of datatype as it appears to be used all over the place with different meanings. My understanding is that it is a set of values and thus only has significance if these values are restricted. Is that correct?</Michel> Not quite. If a Data Type without value restriction is needed it should be defined. Then it probably will be unqualified and have the same name as the Core Component Type it is based on. Whenever value restrictions apply the name should be qualified. <Michel>My understanding of the CCT is that it corresponds to a UML attribute type and that a BCC corresponds to an UML attribute and finally that an ACC corresponds to a UML class? Is this correct?</Michel> Yes. <Michel>If this is so, then I assume that the ABIE simply inherits the ACC through a generalisation and that the generalisation itself provides the business context. Is this exact?</Michel> Rather through Specialisation (but you may mean that). The context in which the Specialisation applies should be defined as meta-attribute to the ABIE. <Michel>However, if this is so I therefore have a problem with the BBIE, where does this fit into the UML picture?</Michel> BBIE's are specialised from the BCC's. This is not a native UML mechanism, but it is allowed and can be defined in UML. <michel>I assume that the datatype notion can be derived from a constraint on the type using a UML constraint built in OCL. Is this exact?</Michel> Yes, I think so. OCL is not mentioned or mandated in CCTS, but I am advocating its use for this purpose. <Michel>I know I'm asking an awful lot of questions, but since you people have been working so long with the CCTs and UML you have certainly worked all this out already and thus will save me the time in trying to figure out the relationships.</Michel> Sure, I am glad all work that went into CCTS has not been in vain and that the CCTS is used in practise! Regards Fred
<<attachment: winmail.dat>>