From: mat@mole-end.matawan.nj.us
Subject: Re: Object-Oriented Methodologies - Class Specifications
Summary: To Characterize Relationships Ask
Organization: :
Date: Fri, 11 Sep 1992 09:33:38 GMT

In article <1992Sep8.192520.2575@projtech.com>, sally@projtech.com (Sally Shlaer) writes:
 
> Graham writes:
> >There are many many
> >more relationships that I cannot model with inheritance, so I am
> >suggesting that people need to look very carefully at inheritance. 
>                                                        ~~~~~~~~~~~
 
> I would suggest instead that we need to look carefully at *additional
> techniques* for modeling relationships.  ...

(I'm sure I mentioned this before ... but ...)

In teaching OO to programmers skilled in procedural programming, I found
it useful to treat Inheritance as something other than a `relationship.'
When I tried to treat them together, students spent a lot of time coming
up with `unnatural' Object-Relationship diagrams.  When I had them
identify behavioral inheritance early in analysis (when the objects
themselves were identified) a plausible, workable inheritance diagram
resulted almost w/out effort.  It needed augmentation as types were added
to complete the solution (principally MI to bring in capabilities from
libraries), but it was never dismantled.  And most of the students came
up with workable O-R diagrams in a very short time.

>  ... entities in the world are related in very interesting and complex
> ways -- and to capture these relationships accurately requires a much
> richer topology than can be attained with hierarchies alone.  ...

While I've disagreed with Sally Shlaer and Steve Mellor on elements of
methodology, their treatment of relationships is probably the strongest--
and some of the work from Structured methods (esp. Ward-Mellor, if I
recall; the book is not here) maps quite well into OO design and
detailing.

> 1.  Inheritance
> 2.  Use a pointer to point to the related object
> 3.  Use an instance variable to contain an identifier of the related object
> 4.  Define a class to implement the relationship, and use either a pointer
>     or an instance variable with an identifier to link the related objects.
>     (per the suggestion from eric@tfs.com (Eric Smith):
> 		. . .
 
> Is it possible to state guidelines to help a designer decide what
> is the best way to implement each of the relationships in
> the Dog example above?  I would like to see a discussion
> on this matter.

The first place to look is at the cardinalities of the relationships
themselves.  It helps, IMO, to look at `pure' E-R diagrams (those that
do not prejudice the question by deciding what is an attribute) as well
as O-R diagrams.  The cardinality must be considered both by Object
existence and by Object value (entity).  A relationship that is 1-1 on
object identity (and {n or N}-1 on entities) can be represented by making
the second object a member or subobject of the first.  A relationship
that is 1-{0,1} on object identities requires a pointer in one object
to identify the second object.  Etc.

I haven't written a truly exhaustive description of these, but I believe
that one can be written.  (And the rules for posting entities to data
stores in the structured world are probably a good guideline to have
at hand while writing it.)

I found these `steps' helpful in describing how to program relationships
reliably:

	1) Determine how the relationship must be represented.

	2) Identify the `rules' of the representation
		(e.g.: When an A is created, a B must be created; when a
		C is created, there must exist a (not-necessarily-unique) D.)

	3) Write the `policies' that enforce the rules
		(e.g.: When an A is created, a B shall be created; when a C
		is created, the creation requires the identity of a D as a
		parameter)

	4) Assign responsibilities for the policies to various methods
		in the various objects, creating methods as necessary.

I believe that, should it be necessary, these could be enumerated
exhaustively, just as the rules for the `minimum' data structure to
support the relationship can be.

And yes, they could probably be implemented by a CASE system.  Such a
system, in the OO world, would also have to be cognizant of which side(s)
of the relationship needed to know of the relationship, and of
acquaintanceships established during various process steps.  These, in
turn, require that the Object-Communication diagram(s) be worked out (as
overlays to the O-R diagram, and with acquaintanceships shown).

IMO, such CASE support would be far more valuable than trying to raise
the level of process steps by grouping all the domain interfaces at one
`level,' a process which discards dependency information among domains.
(Ok, a cheap shot at an old issue ...)
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
Newsgroups: comp.object