Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!news.uu.net!bellcore!porthos!taichi!haim From: haim@taichi.uucp (24122-Haim Kilov(L028)m000) Newsgroups: comp.object Subject: Re: Objects and Interactions: Separate Definitions Message-ID: <1991May22.141555.18076@porthos.cc.bellcore.com> Date: 22 May 91 14:15:55 GMT References: <3999@motcsd.csd.mot.com> <1991May22.021151.18641@visix.com> Sender: netnews@porthos.cc.bellcore.com (USENET System Software) Reply-To: haim@taichi.UUCP (24122-Haim Kilov) Distribution: comp Organization: Bellcore, Livingston, NJ Lines: 57 On objects and ER: " Which is not necessarily a bad cross. ER is used for determining Entities and Relationships which is very useful for understanding object definitions as well. Relationships can be treated, though, as objects just as easily as Entities. Once again, agreed. I find ER and "objects" to both be useful ways of looking at the same things in different ways..." I am not sure these ways are different at all. Both entities and relation- ships (in fact, different kinds of entities -- like "composite", "dependent", etc.) can be treated as objects. They have different properties defined by their behavior. Now comes the interesting part. This behavior is defined not just by a par- ticular entity (class), but rather by operations jointly owned by this entity and its associated entities. For instance, in a simple case of a "relationship", an object becomes a relationship with respect to two or more entities because it has, e.g., an operation "create relationship with entities" with corresponding parameters, and also because the precondition of a successful execution of this operation states that instances of these entities should exist before an instance of the relationship is created. Naturally, for each of these entities there will be an operation like "get relationship instance", also with a parameter -- the name of the relationship type. "Delete" for an entity will have a precondition stating, say, that no instances of associated relationships should exist, i.e., that they should have been deleted earlier. (Cascade delete is another possible approach, of course.) The postcondition will state that after a successful deletion both the entity instance and associated relationship instances do not exist anymore. In this manner, the idea of "interaction" Z between two "objects" X and Y may be considered as the idea of using ER methodology in a precise way. In particular, the association between X and Z is the same as between Y and Z, and there also exist two other associations -- between Z and X and between Z and Y. Implementation-wise these may be considered pointers, but these "pointers" in fact have properties of their own. The designer states that there exists such a (typed) interaction and also states who participates in this interaction. The properties of the interaction and its elements are pre- defined and therefore reused. This example may be treated as a relationship Z between two "symmetric" entities X and Y. As entities need not be symmetric (e.g., parent and dependent), associations between them will look (slightly) differently. Note, however, that the association between a usual entity (say, X) and "its" relationship (say, Z) is also asymmetric and may be considered in the same manner as the association between a parent and a dependent (see my recent note in the April issue of ACM Software Engineering Notes). This seems to be very promising, and we are moving in the direction of integrating "ER" and "OO" approaches. Hope this helps. -Haim Kilov haim@bcr.cc.bellcore.com