Docstoc

Core Components Comments - Universität Wien

Document Sample
Core Components Comments - Universität Wien Powered By Docstoc
					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"

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:3
posted:3/12/2010
language:English
pages:13