Submittor Line Number Comment Kenji Itoh Examples CC User Guide uses different sample, e.g. not catalogue order example. Kenji Itoh 224 Incorrect notation of association 717 Incorrect Notation of Association Kenji Itoh 891 (fig 5-2) This Diagram is not in UMM.(Use Kenji Itoh Case Realisation) 891(Fig 5-2) Stereo-type is incorrect. (This is Kenji Itoh not in UMM) 913 (Fig 5-3) Incorrect notation of Activity Kenji Itoh Diagram 1244 (Fig 5-13) Incorrect notation of Activity Kenji Itoh Diagram 1305 (Fig 5-20) Incorrect notation of Sequence Kenji Itoh Diagram 300 Property name is not the same as shown in Payment Card class Allyson Winter 224 Property name in Person class is not the same following examples – for example class diagram at line 358 Allyson Winter Allyson Winter 340, 513 BCC is Basic Core Component 623 In the Address Class has Allyson Winter unidentified Term Examples The Business Process Use Case Worksheet is not part of the set of UMM worksheets and therefore these examples are not UMM compliant Allyson Winter Overall It is not clear as to how the UMM Business Objects are aligned with and used to create Core Components Allyson Winter 411 This REA preliminary class diagram has only one economic event called shipment. REA requires the exchange of one economic event for another Allyson Winter otherwise known as duality. 411 and Examples As stated in the UMM User Guide, “Business requirements identified in completing the REA worksheets is used as input to the BRV.” REA itself is not part of the UMM. It’s a very powerful technique used for business process and business object discovery. Therefore the class diagrams are not UMM compliant. Allyson Winter Examples The BSV should not be included as part of the examples since it is implementation specific. The BSV is “the view of a business process model that specifies the component services and agents and their message (information) exchange as interactions necessary to execute and validate a business collaboration. The BSV is expressed in the language and technical concepts of the software developer.” Allyson Winter Overall Most of the detail regarding Business Objects/Entities is contained in the BTV artefacts yet there is no mention of this in the CC User Guide. This is vital information that should be used in the development of Core Allyson Winter Components. Overall Given the above comments it is generally not clear as to how one would derive Core Components from the UMM Business Model Allyson Winter artefacts. Possible Resolution Resolution/Response Use same examples in both guides CCSD decided after careful discussion to invite Boeing and EAN to provide their real examples. The CCSD team sees no objection in the inclusion of different examples in the different user guides, however the UMM team is invited to include the Boeing and EAN examples in the UMM user guide. It is felt there is nothing to be gained at this time from changing the examples, but will consider including the UMM example in the next version of the CC User Guide as a supplementary example. No change will be made. Change type of arrow point Change made Change direction of arrow and type of Change made arrow point Correct one should be Business Change made Collaboration Protocol (BTV) Correct one should be Change made «BusinessTransactionActivity» Correct diagram Change made Correct diagram Change made Correct diagram Change made Change Payment Card. Expiration. The truncation rule applies and the Date to Payment Card. Expiration following statement "(see section 4.7 for Date. Date naming and truncation rules)" will be added after "Payment Card. Expiration. Date": for clarity. Change Person ID: Identifier to Person ID is the not (yet) normalised Identification: Identifier name of the property. The text illustrates how dictionary entry names are derived from names given in the Class diagram. They need not to be the same. No change. Change Basis to Basic Change made Change Object Calls Term to Object Change made Class Term Use the UMM User Guide for the The names and lay-out of the worksheets examples have been aligned with the UMM-UG as far as possible. The following has been added to section 5 'Note: Due to concurrent development of this document and the UMM User’s Guide, there may be differences in the diagrams, worksheets, etc.' Align the CC UG with the UMM meta- Business Objects are not defined in the model and the UMM UG which are UMM Metamodel, so it can not be business process centric determined how Business Objects are used to create Core Components. Yet the text of the examples has been changed to align it with wordings found in the UMM Userguide. Change the REA class diagram so This is a snapshot of a portion of the REA that it reflects Economic Event duality model, not intended to show the entire model. No change. Remove the REA diagrams and This is a CC user guide, not the UMM replace them with appropriate UMM userguide. REA is showed as guidance, class diagrams not as being part of UMM. No change. Remove any reference to the BSV This is a CC user guide. We show implementation specific examples as illustrations of how the CCTS may be implemented. No change. Include BTV artifacts and their BTV artefacts have been identified in the relationship to Core Components to examples. the User Guide Clarify how one would derive Core If the present text is not sufficiently clear, Components from the UMM Business please propose the wording to clarify how Model artefacts. one would derive Core Components from the UMM Business Model artefacts. Submittor Line Number Comment Paul Levine 197 add "attributes" Paul Levine 205, 206 Person has three attributes, and has two associations with Address, named Work Address and Home Address Paul Levine 207 prefer "attributes" Paul Levine 209 prefer "attributes" Paul Levine 213-215 Incorrect notation of association Paul Levine 227 prefer associated with Paul Levine 375-376 A class diagram of business entities involved in a business collaboration may be contributed from many different sources, based on many approaches. Paul Levine 391 Avoid the impression that this is the only discovery methodology Paul Levine 641-642 Discovery methodology is free to use any modeling approach, and should not be constrained to the UMM. In fact, the only time CC discovery should result from a UMM-based business collaboration model is when appropriate CCs/BIEs can't be found for a BCM. In that situation business information structures are created as needed for the BCM. At the same time those business information structures without CCs/BIEs would serve in the discovery of CCs/BIEs. That would be the "only" link from a UMM-based BCM to the discovery of CCs/BIEs and therefore should be mentioned in the CC UG, as well as fully explained and illustrated by example in the UMM-UG. Paul Levine 843-844 Since the examples are only illustrative of the CC discovery process, which may follow any methodology, there is no need to imply that the UMM should be followed. The purpose for the UMM is not to discover CCs. Rather it is to develop Business Collaboration Models. As stated in the comment on 641-642, the only time CC discovery should result from a UMM- based business collaboration model is when appropriate CCs/BIEs can't be found for a BCM. In that situation business information structures are created as needed for the BCM. At the same time those business information structures without CCs/BIEs would serve in the discovery of CCs/BIEs. That would be the only link from a UMM-based BCM to the discovery of CCs/BIEs and therefore should be mentioned in the CC UG, as well as fully explained and illustrated by example in the UMM-UG. With the illustratative example that will be added to the UMM- UG, I would strongly recommend that the business collaboration model examples of Clause 4 not be included in the CC UG. Including BCMs with worksheets in the CC UG is likely to confuse users as to the relationship between CCs and BCMs. Paul Levine 851 Allyson Winter 398-411 Remove Allyson Winter 441 Allyson Winter 442-447 Remove Allyson Winter 878,879-881 Allyson Winter 1240, 1241-1262 Allyson Winter Remove any reference to the BSV Allyson Winter Remove Boeing CC example - no need for a nearly 30 page example - too much extraneous information. There are two other examples that are more than adequate. Kenji Itoh Some diagram notations should be revised as per Page 9 & 14 diagrams: attached. Although my earlier comments already reflected in the captioned version, but I propose to remove arrow marks. Reason: It may be no problem to place arrows as it is, but it’s much better to remove arrow marks at the analysis of this level. Kenji Itoh Since UMM uses different model element names depending on its version, e.g. BusinessDocument -> BusinessInformation, CollaborationTask -> BusinessProcessActivity, the version number of UMM and CC UG should be aligned. Kenji Itoh 5-2 Page 40 Figure Now reads: Business Collaboration Protoco Should read: Business Collaboration Protocol (BTV) Kenji Itoh The visibility shown as the tool dependency mark (a Page 46 etc Figure 5-6 key mark) applied to an attribute of class diagram described by RationalRose should be removed, because this visibility is not reflected into CC and BIE when a CC and BIE is automatically generated from UML. Kenji Itoh By the same reason of the item 4, the visibility (+ mark) applied to a relations of a role of class diagram should be removed, because of not reflecting into CC and BIE. Kenji Itoh Page 77 Figure Actors “ShipTo” and “ShipFrom” are roles associated 5-15 Use Case by Buyer and Seller, and then they are not targets to be defined as actors. Possible Resolution Complete the sentence with: "...their properties (i.e., attributes)" Replace sentence with: "Person has three attributes, and has two associations with Address, named Work Address and Home Address." Start the sentence with "Address has three attributes:…" End the sentence with "…contains the attributes." Replace the sentence with "The association name describes the relationship of one class to another class, which is shown by an arrow head at the side of the class which is the object in the relationship." Replace end of the phrase with "where one Object Class is associated with another Object Class;" Replace the sentence with "The REA model is an excellent starting point for structuring the High Level Class Diagram that depicts the relevant business entities in a collaboration." Start the sentence with, "Following the REA approach, steps for modeling …" Replace first sentence with the following: "Business information and inter-relationships should be modeled within the context of a business process, resulting in a class diagram. The UN/CEFACT Modeling Methodology (UMM) would normally not be used, since Information structures within UMM-based Business Collaboration Models are developed with reference to previously discovered Core Components/Business Information Entities. The only time CC discovery should result from a UMM- based business collaboration model is when appropriate CCs/BIEs can't be found for a BCM. In that situation business information structures are created as needed for the BCM. At the same time those business structures without CCs/BIEs would serve in the discovery of CCs/BIEs." If Clause 4 is to be retained, add the following text to the Note: "However, there is no need to align examples in this document with the UMM or the UMM example in the UMM User Guide. CCTS 4.7 states "Within UN/CEFACT standards efforts, the Core Component framework of Core Components and Business Information Entities prescribes the mechanism for discovery, normalization, Context specialization and structure of UMM InformationEntities." Since there is a loosely coupled relationship between CCs and the Information structures within Business Collaboration Models, it is for the UMM User Guide to describe how CCs/BIEs are used as a reference in creating reusable, specific business information structures. It is also for the UMM UG to describe how business information structures in BCMs would serve in the discovery of CCs/BIEs when appropriate CCs/BIEs can't be found for a BCM." If Clause 4 is to be retained, change the sentence to: "In order to capture the business and data requirements of this process for the purpose of discovering the core components, a preliminary version of the UN/CEFACT Modeling Methodology (UMM) was used." Summarising the steps to follow when discovering Core Components, starting with the overall detailed class diagram Resolution/Response Change made The following text is in Martin Fowler''s UML Distilled, which is the normative reference to UML from the UMM User Guide: "Properties are a single concept, but they appear in two quite distinct notations: attributes and associations". This means that both attributes and associations are properties. No change. The text is meant to introduce the "property" concept, so we prefer "properties". No change. Changed into: "..contains the properties that are attributes" Martin Fowler: "An association is a solid line between classes, directed from the source class to the target class. The name of the property goes at the target end of the association". Present text seems more in line with Fowler and is less ambiguous (what is "the object in the relationship"?). No change. In CCTS this association is interpreted as property. Present text seems clearer. No change. Change made Change made Discovery of the BIE's that are to be used in a specific (or standardised) collaboration can only be performed by analysing/designing the process. UMM should be used for this. To state that a BCM needs only to be created when BIE's can't be found seems to turn the world upside down: for what BIE's should one look if one does not have a BCM, or at least a use case description? The statement that "BCM's are developed with reference to previously discovered BIE's" creates a chicken-or-the-egg problem. How were these BIE's "previously" discovered? The relation between BCM and information structures clearly needs more discussion within TMG. For now we feel the CC- UG gives useful guidance. No change. We feel that the relationship between BIE's and the Information structures within Business Collaboration Models are not as loosely coupled as suggested. They need more discussion. The examples have followed a UMM approach. The disclaimer warns the reader that the teams used an older version of UMM documents, so (small) misalignments may exist. The examples however have later been brought in line with current terminology. The proposed statement that the examples need not to be aligned with UMM will confuse the reader. No change. The terminology of the examples have been aligned with the latest version of the UMM-UG. No change. This is the core of the discovery process. No motivation has been given why this needs to be removed. If the text needs to be replaced the submittor should have provided an alternative text. No change. Line 441 is in the section on naming rules. A summary of the discovery steps does not belong here. No change. Clarification of naming rules is cricial. No change. Section has been aligned with the UMM-UG Section has been aligned with the UMM-UG In this CC user guide we show implementation specific examples as illustrations of how the CCTS may be implemented. This was explicitly mentioned in the CCSD Terms of reference. No change. Boeing example is cricial to illustrate Core Components concepts and the discovery process. No change. Arrows show navigatibility. In Core Component models navigation is essential: it shows which ASCC's are listed as properties of which ACC's. Removal of the arrows introduces ambiguity on how to represent the associations in the CC library. No change. Versions are aligned as much as possible. Version numbers need not to be equal. Figure Removed Change made Change made Changed in"Consignor" and "Consignee"