Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!uw-beaver!zephyr.ens.tek.com!tektronix!sequent!mntgfx!plogan
From: plogan@mentor.com (Patrick Logan)
Newsgroups: comp.object
Subject: Re: testing object oriented programs
Message-ID: <1990Jun1.232430.1010@mentor.com>
Date: 1 Jun 90 23:24:30 GMT
References: <1990May20.154035.15064@axion.bt.co.uk| <54783@microsoft.UUCP> <5121@stpstn.UUCP> <54917@microsoft.UUCP> <480@tetrauk.UUCP> <1990May30.204110.22011@ux1.cso.uiuc.edu> <31960@sparkyfs.istc.sri.com>
Organization: engr
Lines: 61
In-reply-to: mckenney@sparkyfs.istc.sri.com's message of 31 May 90 18:35:12 GMT

In article <31960@sparkyfs.istc.sri.com> mckenney@sparkyfs.istc.sri.com (Paul Mckenney) writes:
  > One major reason that testing inherited classes becomes complex is that
  > classes often have member functions and variables that cooperate; these
  > members must therefore be overridden in groups (or, if only a single
  > member of the group is overridden, the programmer must very carefully
  > ensure that the overriding function fits properly with the other members
  > of the group).
  > 
  > So, one approach would be to allow the programmer to specify groups of
  > member functions/variable.  The compiler could then give errors is
  > some, but not all, members of a group were overridden.
  > 
  > This approach of course requires additions to the languages in order to
  > specify the member groups.  However, it is a good fit to the major problem
  > and adds absolutely no runtime overhead (at least for languages that allow
  > inlining).
  > 			   Thanx, Paul

At last Fall's Pacific Northwest Software Quality Conference, Fredrick
Hart of the Georgia Institute of Technology presented an interesting
paper titled "Constructing Reusable Software Using Feature Contexts".
(Co-authored by John Shilling.)

The abstract:

  "Explicit documentation of software features, using feature
   contexts, provides an effective way to create easily customized
   software components thus promoting reuse and enhancing
   maintainability."

The paper describes "features" as "logical units of program
functionality". And a "feature context" is "simply the realization of
a feature in the environment".

In this case the feature is "mutually dependent member functions and
data".  A feature context could be used to capture (realize, in their
words) this feature for use in the process of specializing super class
functionality in a subclass.

Features and feature contexts are loosely related to database views
and hypertext. I hope this description is somewhat clear. My point is
that the functionality described by Paul does not have to be a
programming language extension. It could be a part of the development
environment and applied to more than one language and to languages
that are not explicitly object oriented.

Proceedings of the conference I mentioned can be ordered for $30 from:
    PNSQC
    P.O. Box 970
    Portland, OR 97075

(It's the 1989 Pacific Northwest Software Quality Conference)

It is full of useful and interesting papers. I can't make individual
copies of this paper, sorry.

Patrick
-- 
Patrick Logan  uunet!mntgfx!plogan         |
Mentor Graphics Corp. 8500 SW Creekside Pl |
Beaverton, Oregon 97005-7191               |