From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 1108a1,c52c30d32b866eae
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 103376,2ea02452876a15e1
X-Google-Attributes: gid103376,public
X-Google-Thread: fac41,c52c30d32b866eae
X-Google-Attributes: gidfac41,public
From: schlegel@informatik.uni-rostock.de (Juergen Schlegelmilch)
Subject: Re: Real OO
Date: 1996/05/15
Message-ID: <slrn4pj2gb.291.schlegel@pella.informatik.uni-rostock.de>#1/1
X-Deja-AN: 154897980
references: <slrn4p1bep.2dl.schlegel@pella.informatik.uni-rostock.de>
 <Dr4538.D27@assip.csasyd.oz>
 <Pine.GSO.3.92.960509171645.1191B-100000@nunic.nu.edu>
 <1996May14.190322.18222@merlin.hgc.edu>
organization: Comp Sci Dept, Uni Rostock, Germany
reply-to: schlegel@Informatik.Uni-Rostock.de
newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object
Date: 1996-05-15T00:00:00+00:00
List-Id: <comp.lang.ada>


On Tue, 14 May 1996 19:03:22 GMT, James McKim <jcm@hgc.edu> wrote:
> 
> It's been a while since I've looked at these, but again I don't believe
> either paper addresses how the semantics of a subtype may vary from that
> of its supertype. The earliest paper that I know deals with this
> issue in the now accepted way (weaker preconditions, stronger postconditions,
> stronger invariants) is
> 
> [Meyer, 1987] B. Meyer, Eiffel: "Programming for Reusability and Extendibility", ACM SIGPLAN Notices, 85-94, February, 1987.

I agree that this is a very important part of the picture but I also
want to point out that this is not the full picture. With invariants,
pre- and postconditions you fix the semantics of objects and single
operations. Methods are often not designed one-by-one, but are intended
to be called in certain sequences. Preconditions can be used to enforce
these sequences (e.g. for files: first open(), then either any sequence
of read operations, or any sequence of write operations, finally a close()),
i.e. they have two different tasks:
   1. protect the method against being called with wrong arguments
   2. protect the object against invalid life cycles
The second part could be expressed by class invariants in temporal logic to
make it more explicit.

There are few publications about inheritance of these life cyle conditions;
I only know of one:
  @INPROCEEDINGS{SHJWF94,
   key={SHJWF94},
   author={Saake, G. and Hartel, P. and Jungclaus, R. and Wieringa, R.
                  and Feenstra, R.},
   title="{Inheritance Conditions for Object Life Cycle Diagrams}",
   booktitle={Workshop Formale Grundlagen {f\"ur} den Entwurf von
                    Informationssystemen, Tutzing},
   editor={Lipeck, U. and Vossen, G.},
   publisher={Technical Report Univ.\ Hannover, No.\ 03/94},
   year=1994,
   pages = "79--89"
  }
If there are more papers on this topic, please let me know.

  Juergen 

-- 
+-----------------------------------------------------------------------------+
 Dipl.-Inf. Juergen Schlegelmilch                 University of Rostock
 email: schlegel@Informatik.Uni-Rostock.de        Computer Science Department
 http://www.informatik.uni-rostock.de/~schlegel   Database Research Group 
 Tel: ++49 381 498 3402                           18051 Rostock 
 Fax: ++49 381 498 3404                           Germany
+-----------------------------------------------------------------------------+