RE: [ubl-ndrsc] OO Design Paper

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

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.  

Line 90:

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

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).

Line 108:

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

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.

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.

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.

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.  

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.

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

This position is unsupported.  Support it.

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

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

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.

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? 

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.

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>>