RE: [ubl-ndrsc] OO Design Paper

["Stuhec, Gunther" <gunther.stuhec@sap.com>]

Hello Bill,

thank you very much, that you did the review so quick.

I putted my comments under your feedback,

Kind regards,

	Gunther


-----Original Message-----
From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com]
Sent: Montag, 19. August 2002 15:23
To: UBL-NDRSC (E-mail)
Subject: RE: [ubl-ndrsc] OO Design Paper


Here's my feedback on the paper:

In general I found the use of the XML Spy diagrams, especially when
presented side-by-side with other spy diagrams, class diagrams or XML code
really helpful.  We all need to do this more.  It eliminates a lot of
ambiguity.


Line 68-69: "The additional elements in the specific intermediate levels
(eg. Header, Item, Summary, Parties or References) are neither re-usable nor
inheritable as business objects"

In the UBL modeling methodology, elements are almost never reusable.  The
exception is top-level elements (message types).  Types are reusable,
elements are not, in general.

The types you mention certainly _are_ both reusable and inheritable.  While
it may be the case that in the library as it stands, they are neither reused
nor derived from, there is nothing prohibiting it.

Is your concern that the content model (type) of e.g.
DeliveryNotificationHeader is not reused in the library?  There is no
problem prima facie with a single-use type (such as
DeliveryNotificationHeader).  It happens all the time in OO design and
programming.  

<GS>I understand, the business document type "order" have some sub elements, like "Header, Item, Summary". But what is with that sub elements. They have to based on another types like "HeaderType", "ItemType" and "SummaryType". Or will you define inside of this sub elements further sub elements? But this make problems with the modelling itself. What is this sub element "Header", "Summary" or "Item" than? An object class or an part of object class?</GS>

Line 90:

The section is titled "Starting point of message design", yet it goes on to
make a very specific recommendation that...

<GS>I will compare your recommendation with my section and than I will give you a response</GS>

Line 94:
"Usually one main business object per message with relationship to other
business objects and usually with "Items" as part of the main object class.
"

I question the need for that recommendation, but if you really want to make
it, it needs some justification on its own (a separate section).

<GS>I will define that in much more detail</GS>

Line 108:

"artificial class" is undefined.  As I indicated above, there's nothing
inherrently "bad" about a "Header" class.  

<GS>I will describe "artificial class" a little bit more</GS>

Line 112: "Each property name as well as object class name of a super object
class should be ineheritable to the sub object classes directly."

I don't understand that statement.  Please clarify.

<GS>In my next version</GS>

Lines 118-119:

In the "No" example, the dictionary entry name of the indicated element is
(assuming it's actually a set of Party): 

DeliveryDetails3.Parties.PartySet

In the "Yes" example, the dictionary entry name of the indicated element is:

DeliveryDetails.ShipperParty.Party

There is no change required to the naming and design rules here.  These
names are perfectly unambiguous as they stand, since DeliveryDetails and
DeliveryDetails3 are ostensibly uniquely defined within some (UBL)
namespace.

<GS>But PartySet is not "ShipperParty". My understandig is, that i have to concetenate alle element tags, if I would like to get a dictionary entry name. What is the correct and complete dictionary entry name for the "No" example? DeliveryDetails3.Parties.PartySet.ShipperPart or DeliveryNotification.Header.Delivery.Parties.ShipperParty? This rules are not really clear.</GS>

Line 130: "... but don't represent a whole class..."

What is the criteria for something representing a whole class, or not?  I
don't think we have a criteria.

<GS>The criteria is, that every object class must have an identifier and period for example don't have any identifier</GS>

Line 132: "... there is no "container" element ..."

Is the only value of model groups that we eliminate the need for a
containing element? That can be nice I guess.  I think the best way to make
the case for this is to show what the processing code looks like for both
alternatives.  

<GS>What do mean with processing code? A Java code for example?</GS>

Line 141-142 (diagram): 

The model group for the "yes" case is not reusable as far as I can tell.
You've traded what you view as a superfluous enclosing element "IssuePeriod"
for situation-specific element names within the model group "IssueDateTime",
"ArrivalDateTime".  What's the point of the model group now?  It isn't
nearly as reusable as the "no" case "PeriodDetails" type.

<GS>"IssueDateTime" and "ArrivalDateTime" are the StartDateTime and EndDateTime of a period. That are a copy of these elements.</GS>

Line 155-156 "... unique identifier..."

This position is unsupported.  Support it.

<GS>Every business object can identified by an identifier. For example an "Product" by the EAN.UCC Productidentifier or the Party by an DUNS Number etc. This identifier must existing on the first place of a business object.</GS>

Line 157-158:  "... hidden identifier ..."

Why should it be hidden?  What does "hidden" mean?

<GS>"hidden" means that is an identifier for modelling or internal using purposes and do not exits as an exchangeble identifier like the EAN.UCC number. This "hidden" identifier are for example necessary as unique keys in database tables</GS>

Line 161-162: "... sequential number ..."

Again, this needs support.  On its face, I disagree.  In many situations,
order is unimportant and the addition of a sequence number is inappropriate.

<GS>I'am not really agree with you statement. I will define this in the position paper in much more detail</GS>

Line 180-185:

I don't see how the proposal "reduces the structural differences of the
message and the corresponding business object within the application".  Are
you talking about some particular application at SAP? 

<GS>I talk about applications in general</GS>

Line 203 (diagram):

Missing a lot of cardinalities in the diagram.

Many of the classes use the '+' modifier in front of their "Identifier"
attribute.  This denotes a "class attribute" (whereas '-' denotes an
"instance attribute").  I think this is a mistake.  They should all be
instance attributes.

<GS>I used Vision Professional. It is not possible to define the cardinalities of every attribute in addition the diagram was not really readable if I let all cardinalities in this diagram. This diagram is a quick and dirty solutions for representatin issues.</GS>


Also, feel free to remove the word "Details" from all the class names.  


That's all.

Best Regards,

Bill Burcham
Sr. Software Architect, Standards and Applied Technology
Sterling Commerce, Inc.
469.524.2164
bill_burcham@stercomm.com <mailto:bill_burcham@stercomm.com> 


-----Original Message-----
From: Stuhec, Gunther [mailto:gunther.stuhec@sap.com]
Sent: Tuesday, August 13, 2002 11:28 AM
To: UBL-NDRSC (E-mail)
Subject: [ubl-ndrsc] OO Design Paper


Hello all,

this is the our position paper about OO-design. This describes the building
of messages according the oo-design rules. I gave the schemas and
UML-diagram to Dave Carlson last week. And he sent me some suggestions. I
recognized this suggestions in this version of the position paper now. If
you have
some suggestions, comments or improvements too, please let me know.



Kind regards,

	Gunther

 <<OODesign-0p1.doc>> 

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>