[ubl-lcsc] 8/25/2002: Newest version of the OO-design position paper

[Monica Martin <mmartin@certivo.net>]

Good, Gunther.  I would like to see this as well, as I have also seen
similar concepts applied using Java (object-relational synergy - Castor
JDO http://www-106.ibm.com/developerworks/library/j-castor/?n-j-8222).
 
I'll look forward to more detail.
Monica

	-----Original Message----- 
	From: Stuhec, Gunther 
	Sent: Fri 8/23/2002 1:21 AM 
	To: 'Chan, Sally M'; 'ubl-lcsc@lists.oasis-open.org';
'ubl-ndrsc@lists.oasis-open.org' 
	Cc: 
	Subject: RE: [ubl-lcsc] Newest version of the OO-design position
paper.
	
	

	Hello Sally,
	
	I will do that. I'm in vacation next week and I hope I will find
any time for the elaboration, next week.
	
	Kind regards,
	
	        Gunther
	
	-----Original Message-----
	From: Chan, Sally M [ mailto:sally.m.chan@boeing.com]
	Sent: Donnerstag, 22. August 2002 19:08
	To: Stuhec, Gunther; 'ubl-lcsc@lists.oasis-open.org';
	'ubl-ndrsc@lists.oasis-open.org'
	Subject: RE: [ubl-lcsc] Newest version of the OO-design position
paper.
	
	
	Gunther,
	> use the data class model for defining tables in a OO-based or
XML-based
	database.
	yes, this should work
	>use this classes of data for building classes with behavior.
	yes, this may work
	
	>I started with that definition of seamless integration between
object model
	and data model. After my first tests is my feeling that it
works.
	Please elaborate this part in your paper, show your test, this I
think is
	the real benefit of the OO data design.  Also, from a non-OO
apps point of
	view, how the OO data design help them.
	
	
	Thanks,
	Sally Chan
	
	
	-----Original Message-----
	From: Stuhec, Gunther [ mailto:gunther.stuhec@sap.com]
	Sent: Thursday, August 22, 2002 9:41 AM
	To: Chan, Sally M; 'ubl-lcsc@lists.oasis-open.org';
	'ubl-ndrsc@lists.oasis-open.org'
	Subject: RE: [ubl-lcsc] Newest version of the OO-design position
paper.
	
	
	Hello Sally,
	
	that is correct, that classes without any behaviour is not good
designed.
	But my intention is, that you can use this classes of data for
building
	classes with behavior. Additionally, you can use the data class
model for
	defining tables in a OO-based or XML-based database. For that
definition is
	a
	behavior of classes not necessary.
	
	I started with that definition of seamless integration between
object model
	and data model. After my first tests is my feeling that it
works.
	
	Kind regards
	
	        Gunther
	
	-----Original Message-----
	From: Chan, Sally M [ mailto:sally.m.chan@boeing.com]
	Sent: Mittwoch, 21. August 2002 23:38
	To: Stuhec, Gunther; 'ubl-lcsc@lists.oasis-open.org';
	'ubl-ndrsc@lists.oasis-open.org'
	Subject: RE: [ubl-lcsc] Newest version of the OO-design position
paper.
	
	
	Gunther,
	
	In OO design, the focus is on object behavior and emphasis on
data
	encapsulation (hiding data behind its public interface).  In XML
or data
	model, the focus is on exposing the data, not behavior.  Using
OO design to
	design data, is it the right thing to do?  this could lead to
classes that
	don't have behavior, not good OO design!
	
	In OO application development, you need both class model and
data model.
	The challenge is how one can align the two to achieve seamless
integration
	between the object model and data model, show me how an
OO-design data model
	helps me write less code when I need to access the XML data from
an OO (or
	non-OO) application will be a value to me.
	
	Regards,
	
	Sally Chan
	Associate Technical Fellow
	The Boeing Company
	Boeing Commercial Airplanes
	IS - Architecture & eBusiness
	425-965-0141
	
	
	
	-----Original Message-----
	From: Stuhec, Gunther [ mailto:gunther.stuhec@sap.com]
	Sent: Tuesday, August 20, 2002 1:57 PM
	To: 'ubl-lcsc@lists.oasis-open.org';
'ubl-ndrsc@lists.oasis-open.org'
	Subject: [ubl-lcsc] Newest version of the OO-design position
paper.
	
	
	
	Hello all,
	
	this is our newest version of the OO-design position paper. It
describes
	generally the definition of aggregate core components as well as
the
	aggregated business information entities.
	
	In this paper all aggregates representing an object. The
subelements which
	are basic business information entities representing the
attributes of an
	objects. An the aggregates insided of an objects are further
objects or
	parts of an objects. The object itself refers to these furhter
objects.
	
	In addition all containers are avoided, consciously.  Because it
is not
	possible to represents containers as objects with attributes and
influence
	the representation of a conclusive class diagram unfavorably. 
	
	Please review this document and send me your comments and
remarks.
	
	Kind regards,
	
	      Gunther
	
	
	
	----------------------------------------------------------------
	To subscribe or unsubscribe from this elist use the subscription
	manager: < http://lists.oasis-open.org/ob/adm.pl>
	
	----------------------------------------------------------------
	To subscribe or unsubscribe from this elist use the subscription
	manager: < http://lists.oasis-open.org/ob/adm.pl>
	
	----------------------------------------------------------------
	To subscribe or unsubscribe from this elist use the subscription
	manager: < http://lists.oasis-open.org/ob/adm.pl>