ftp.pasteur.org/FAQ//ftp-pasteur-org-FAQ.zip/FAQ/object-faq/part2

Text File | 1996-04-03 | 50.8 KB | 1,078 lines

Newsgroups: comp.object,comp.answers,news.answers
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!hookup!news.join.ad.jp!news.imnet.ad.jp!usenet.seri.re.kr!news.cais.net!news.jsums.edu!gatech!newsfeed.internetmci.com!ncar!uchinews!news
From: Bob Hathaway <[e-mail]>
Subject: Comp.Object FAQ Version 1.0.9 (04-02) Part 2/13
X-Nntp-Posting-Host: ford.uchicago.edu
Message-ID: <[e-mail]>
Followup-To: comp.object
Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
Sender: [e-mail] (News Administrator)
Organization: Geodesic Systems
References: <[e-mail]>
Date: Wed, 3 Apr 1996 04:07:04 GMT
Approved: [e-mail]
Lines: 1061
Xref: senator-bedfellow.mit.edu comp.object:46836 comp.answers:17911 news.answers:68443

Archive-name: object-faq/part2
Last-Modified: 04/02/96
Version: 1.0.9

OOA and OOD stand for Object-Oriented Analysis and Object-Oriented Design,
respectively.  OOA strives to understand and model, in terms of object-oriented
concepts (objects and classes), a particular problem within a problem domain
(from its requirements, domain and environment) from a user-oriented or domain
expert's perspective and with an emphasis on modeling the real-world (the
system and its context/(user-)environment).  The product, or resultant model,
of OOA specifies a complete system and a complete set of requirements and
external interface of the system to be built, often obtained from a domain
model (e.g. FUSION, Jacobson), scenarios (Rumbaugh), or use-cases (Jacobson).

[Shlaer 88] is often credited as the first book on OOA, although their method
adds OO techniques to the traditional structured analysis principles of Yourdon
and Constantine. Their complete approach ([Shlaer 88, 92]) consists of
information modeling and recursive design, or OOA/RD and represents a recent
addition to the structured analysis family (as does Martin and Odell).
[Yourdon 92] provides a critique, although may only refer to their earlier
work.  Many other methodologies including Rumbaugh's OMT, Martin and Odell's
OOA/D, and many others, also share common ground with SA and other existing
analysis methodologies with such constructs as associations (E-R), functional
models, and even DFD's.  Booch, Jacobson, and Wirfs-Brock are examples of OO
methodologies representing a greater departure from the conventional
"structured" techniques, with greater emphasis on objects.  OOram [Reenskaug
91] provides support and emphasis on types and roles as guiding principles,
which is quite powerful.  [Booch 94] presents a methodology which is an
evolutionary step beyond the first edition by incorporating a collection of the
best features from several of the major OO methodologies, as does HP's new
FUSION methodology.

A new Unified Modeling Language (previously Unified Method) is now being worked
on by Grady Booch, James Rumbaugh, and Ivar Jacobson at Rational Software which
should be made into a public standard, perhaps to be adopted by the OMG.  The
.8 docs can be found online from the Rational home page, http:/www.rational.com.

The usual progression is from OOA to OOD to OOP (implementation) and this
Universal Process Model roughly corresponds to the Waterfall Model [Royce 70].
See [Humphrey 89] and [Yourdon 92] for a few of many discussions on software
life-cycle models and their use.  Humphrey also details Worldy and Atomic
Process Models for finer grained analysis and design in the Defined Process
(see below) and discusses other alternatives to the task oriented models.  He
also provides the following critisisms on the Waterfall Model which had led to
Boehm's seminal work on the Spiral Model:

  * It does not adequately address changes
  * It assumes a relatively uniform and orderly sequence of development steps
  * It does not provide for such methods as rapid prototyping or advanced
    languages

Modern OO methodologies directly address these points and emphasize the
incremental, iterative, evolutionary, concurrent and situational nature of
software development.  [Boehm 86] presents a seminal spiral life-cycle model
with a risk-driven incremental prototyping approach.  [Booch 91, 6.1]
proposes a "round-trip gestalt" design with analyze-design iterations and
an overall system perspective and [Berard 93] proposes an (incremental)
"parallel-recursive design" with analyze-design-implement-test iterations.
[Coad 91b] presents the following development cycle breakdown:

  Waterfall-
    Analysis
    Design
    Programming

  Spiral-
    Analysis, prototyping, risk management
    Design, prototyping, risk management
    Programming, prototyping, risk management
    [Boehm, 1988]

  Incremental-
    A little analysis
    A little design
    A little programming
    Repeat
    [Gilb, 1988]

[Author's note: The spiral model is often incremental and may waterfall if
 called for.]

Since classes and objects are used in all phases of the OO software life-cycle,
the process is often referred to as seamless, meaning there is no conceptual
gap between the phases as is often the case in other software development
methodologies, such as the analysis (DFD's) to design (structure charts) to
programming gaps found in traditional structured analysis and design.
Seamlessness together with naturalness is a big advantage for consistency.

A problem domain has many realizations, or differing OOAs.  An OOA has many
realizations, or differing OODs, but a similar notation is often used for
the two.  An OOD also has many realizations, or differing OOPs, but allows a
selection from among various languages for implementation (choosing the best
language to implement the design).  But some, such as Bjarne Stroustrup, don't
like OOA and OOD getting too far from OOP (implementation independent), for
fear that great discrepancies could occur between OOD and OOP by losing sight
of the implementation language, which in some cases is predetermined.  See also
[Stroustrup 91].

From a greater perspective, the SEI has developed the Capability Maturity Model
(CMM), a process-based TQM model for assessing the level of an organization's
software development and which is often required of government contractors
in the US [Humphrey 89].  The CMM also serves as a 5 level improvement process
by specifying steps for organizations to progress to the next level, ultimately
leading to statistical (process) control and sustained improvement.  Watts S.
Humphrey is now working on the Personal Software Process (PSP), a scaled down
version of the CMM for individuals [Humphrey 95].  Next should follow a team-
based software process (TSP?).  Other CMM's in the works at the SEI include a
personnel management CMM (PM-CMM).

 Level 1: Initial:    Every project is handled differently; ad hoc and chaotic.
 Level 2: Repeatable: Every project is handled similarly.
 Level 3: Defined:    Standard processes are defined and used for all projects.
 Level 4: Managed:    A measurable basis for all improvements to the process.
 Level 5: Optimizing: Emphasis on defect prevention and optimizing/continually
                      improving the process.

CMM documentation is available online from: http://ricis.cl.uh.edu/CMM and
ftp.sei.cmu.edu/pub/cmm/

See also:
Kitson, D.H. and Masters, S. "An Analysis of SEI Software Process Assessment
Results 1987-1991", CMU/SEI-92-TR-24

Humphrey, W., Snyder, T. and Willis, R. "Software Process Improvement at
Hughes Aircraft", IEEE Software, July 1991

Dion, R., "Elements of a Process Improvement Program," IEEE Software, July
1992.

"Concepts on Measuring the Benefits of Software Process Improvement,"
CMU/SEI-93-TR-9.

See also [Yourdon 92], [Wilkie 93], and [Booch 94] for discussions on this
often cited model.  There is also an ISO 9000 standard [ISO] applicable to
software quality and ami working group in Europe helping to creat the ISO
SPICE [Rout 95] standard (among other work), which is similar in scope to
the CMM.  To join the ami mailing list email to:
  [e-mail]
with the following message:
  subscribe firstname, lastname, e-mail address.

Object-oriented analysis now includes "Enterprise Modeling" [Martin 92], also
found in [Jacobson 92], and along with recent business process "reengineering"
efforts places information systems within an organizational perspective by
modeling entire organizations or a large part of them, with the information
processing system and software products development as integrated components.
[Yourdon 92] even calls for "global modeling"!


1.22)  Where Did Object-Orientation Come From?
----------------------------------------------

Simula was the first object-oriented language providing objects, classes,
inheritance, and dynamic typing in 1967 (in addition to its Algol-60 subset).
It was intended as a conveyance of object-oriented design.  Simula 1 was a
simulation language, and the later general-purpose language Simula 67 is now
referred to as simply Simula.  Smalltalk was the next major contributor
including classes, inheritance, a high-powered graphical environment and a
powerful dynamic typing mechanism (although these existed to some extent in
Simula).  Self is somewhat of a Smalltalk-based next generation language, as is
BETA a followup to Simula (by its original designers).

[Meyer 88] contains a brief summary and history of Simula and Smalltalk, among
other OO languages.


1.23)  What Are The Benefits Of Object-Orientation?
---------------------------------------------------

Reuse, quality, an emphasis on modeling the real world (or a "stronger
equivalence" with the RW than other methodologies), a consistent and seamless
OOA/OOD/OOP package, naturalness (our "object concept"), resistance to change,
encapsulation and abstraction (higher cohesion/lower coupling), and etc.

On resistance to change, system objects change infrequently while processes
and procedures (top-down) are frequently changed, providing object-oriented
systems with more resilient system organization.

[Harmon 93]:
  Faster development
  Increased Quality
  Easier maintenance
  Enhanced modifiability

[Booch 94]:
  Exploit power of OOPs
  Reuse of software and designs, frameworks
  Systems more change resilient, evolvable
  Reduced development risks for complex systems, integration spread out
  Appeals to human cognition, naturalness


1.24)  What Other FAQs Are Available?
-------------------------------------

FAQ's are cross-posted to news.answers and are archived on anonymous ftp from:

  rtfm.mit.edu:/pub/usenet        (also usenet-by-hierarchy, etc.)

rtfm archives several FAQs pertinent to OO (alternative/original sites are listed).

  comp.lang.ada         ajpo.sei.cmu.edu:public/comp-lang-ada/cla-faq[12]
  comp.lang.beta        ftp.daimi.aau.dk:pub/beta/faq/beta-language-faq.txt
  comp.lang.c++         sun.soe.clarkson.edu:pub/C++/FAQ [128.153.12.3]
  comp.lang.clos
  comp.lang.eiffel      ftp.cm.cf.ac.uk:/pub/eiffel/eiffel-faq
  comp.lang.modula3
  comp.lang.oberon
  comp.lang.objective-c http://www.marble.com/people/dekorte/Objective-C/objc.html
  comp.lang.sather      ftp.ICSI.Berkeley.EDU:pub/sather [not on rtfm]
  comp.lang.scheme      ftp.think.com:/public/think/lisp/scheme-faq.text
  comp.lang.smalltalk   xcf.Berkeley.EDU:misc/smalltalk/FAQ/SmalltalkFAQ.entire
  comp.object           zaphod.uchicago.edu:/pub/CompObj8.faq(.Z) (also www)
  comp.object.logic     ftp.cs.cmu.edu:(2)prg_1.faq,prg_2.faq  [128.2.206.173]
  comp.software-eng

Notes:
  1) xcf.Berkeley.EDU is 128.32.138.1
  2) /afs/cs.cmu.edu/project/ai-repository/ai/pubs/faqs/prolog/
  3) BETA FAQ www (most current): http://www.daimi.aau.dk/~beta/FAQ
                                  http://www.daimi.aau.dk/~beta/info
     Email: [e-mail] with body: send BETA beta-faq
  4) Modula-3: ftp.vlsi.polymtl.ca:pub/m3/m3-faq.ps.
               http://froh.vlsi.polymtl.ca/m3/m3-faq.html.
     Archives: gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3
     Newsgroup relay mailing list; message to [e-mail]
  5) comp.lang.eiffel archive: http://www.cm.cf.ac.uk/CLE/archive_index.html

See APPENDIX E:60 for a CDROM with Internet FAQs.

A new C++ libraries FAQ is posted monthly to comp.lang.c++ and should be on
rtfm soon.  Contact [e-mail].  It contains anonymous ftp
sites and commercial libraries and may be merged with this FAQ eventually.

Many FAQs are also available from mail-servers, however most can be accessed by
the rtfm mail-server.  Mail to [e-mail] with help and index in
the body with no leading spaces and on separate lines for more information.

Example Unix Command (will retrieve this FAQ in about 26 pieces (and growing)):
  mail [e-mail]
  Subject:
  send usenet/comp.object/*

There is also a great ftp site for sci.virtual-worlds on:
  stein.u.washington.edu (140.142.56.1)
          - home of sci.virtual-worlds, huge faq w/ great info!
          - if unable to use try ftp.u.washington.edu
          /public/virtual-worlds

[While VR may not be directly related to comp.object, it is most interesting!
   - The Author]


SECTION 2:  TYPING
==================

There are many definitions of type (and class and related concepts).  Many
authors define the terms as applied by their particular approach or language,
however we shall proceed in the face of this diversity.

  References
    [Blair 89]          Some Typing Topics.
    [Booch 91]          Small Section on Typing.
    [Cardelli 85]       Discussion on Object-Oriented Typing.
    [Gunter 94]         Theoretical Aspects of Object-Oriented Programming.
    [Kim 89, ch1]       Discussion on Some Research Topics.


2.1)  What Is Polymorphism?
---------------------------

Polymorphism is a ubiquitous concept in object-oriented programming and is
defined in many ways, so many definitions are presented from: Websters',
Author, Strachey, Cardelli and Wegner, Booch, Meyer, Stroustrup, and Rumbaugh.
Polymorphism is often considered the most powerful facility of an OOPL.

> Webster's New World Dictionary:

Polymorphism 1. State or condition of being polymorphous.  2. Cryall.
  crystallization into 2 or more chemically identical but
  crystallographically distinct forms.  3.  Zool., Bot. existence of an
  animal or plant in several forms or color varieties.

polymorphous adj. having, assuming, or passing through many or various forms,
  stages, or the like.  Also, polymorphic. [<Gk polymorphous multiform]


> Author's Definition:

Polymorphism is the ability of an object (or reference) to assume (be replaced
by) or become many different forms of object.  Inheritance (or delegation)
specifies slightly different or additional structure or behavior for an object,
and these more specific or additional attributes of an object of a base class
(or type) when assuming or becoming an object of a derived class characterizes
object-oriented polymorphism.  This is a special case of parametric
polymorphism, which allows an object (or reference) to assume or become any
object (possibly satisfying some implicit or explicit type constraints
(parametric type), or a common structure), with this common structure being
provided by base classes or types (subclass and subtype polymorphism,
respectively).

"Poly" means "many" and "morph" means "form".  The homograph polymorphism has
many uses in the sciences, all referring to objects that can take on or assume
many different forms.  Computer Science refers to Strachey's original
definitions of polymorphism, as divided into two major forms, parametric and
ad-hoc.  Cardelli and Wegner followup with another classification scheme,
adding inclusion polymorphism for subtyping and inheritance.


> Strachey's Original Definition [Strachey 67]:

"Parametric polymorphism is obtained when a function works uniformly on a range
of types; these types normally exhibit some common structure.  Ad-hoc
polymorphism is obtained when a function works, or appears to work, on several
different types (which may not exhibit a common structure) and may behave in
unrelated ways for each type."

Parametric polymorphism is also referred to as "true" polymorphism, whereas
ad-hoc polymorphism isn't (apparent polymorphism).


> Cardelli and Wegner's Definition [Cardelli 85]:

C+W refine Strachey's definition by adding "inclusion polymorphism" to model
subtypes and subclasses (inheritance).  Strachey's parametric polymorphism is
divided into parametric and inclusion polymorphism, which are closely related,
but separated to draw a clear distinction between the two forms, which are then
joined as specializations of the new "Universal" polymorphism.

                                 |-- parametric
                 |-- universal --|
                 |               |-- inclusion
  polymorphism --|
                 |               |-- overloading
                 |-- ad hoc    --|
                                 |-- coercion

Polymorphic Languages: some values and variables may have more than one type.

Polymorphic Functions: functions whose operands (actual parameters) can
  have more than one type.  [...] If we consider a generic function to be
  a value, it has many functional types and is therefore polymorphic.

Polymorphic Types: types whose operations are applicable to operands of more
  than one type.

Parametric Polymorphism: a polymorphic function has an implicit or explicit
  type parameter which determines the type of the argument for each
  application of that function.

Inclusion Polymorphism: an object can be viewed as belonging to many different
  classes that need not be disjoint; that is, there may be inclusion of
  classes.

The two forms of "Universal Polymorphism", parametric and inclusion are closely
related, but are distinct enough in implementation to justify separate
classifications.

Parametric polymorphism is referred to as generics.  Generics can be syntactic,
where each instantiation creates a specialized version of the code allowing
fast running execution, but in a "true polymorphic system", only a single
implementation is used.

On inheritance is subtype polymorphism:
"Subtyping on record types corresponds to the concept of inheritance
(subclass) in languages, especially if records are allowed to have functional
components."

Author's Notes:
Implicit parametric polymorphism can be implemented with type inferencing
schemes [Aho 85].  ML is prototypical in providing this facility.

Inclusion polymorphism is common and is found in languages such as Simula,
Ada95, C++, CLOS, Eiffel and etc. (subclass polymorphism).  Smalltalk also
uses inclusion polymorphism; its used in declaring classes, and subclass
polymorphism is used in practice but not enforced.  For inheritance, inclusion
polymorphism specifies an instance of a subclass can appear wherever an
instance of a superclass is required.  For subtyping (subtype polymorphism),
the same applies because all operations required by the supertype are present
in the subtype (subtype is subset of supertype).  Cardelli and Wegner view
classes as sets of objects (resulting in subtype objects are a subset of
supertype objects, or an extensional view), as contrasted with a feature based
(intensional) approach (where subtypes are supersets of (contain) supertypes).
MI provides an interesting example here, as it is set intersection with an
extensional view and set union with an intensional view.  Details are left as
an exercise for the reader.

Ada generics and C++ templates provide explicit syntactic generics.  While
Ada may infer some actual generic parameters (operations) and C++ doesn't
require explicit instantiation of its template functions, formal generic
parameters must still be declared and many bodies are generated.

Inclusion polymorphism can refer to subtyping, or having at least as much or
more than required.  Since derived classes can inherit structure and behavior
from base classes, such inheritance is an example of inclusion polymorphism
with respect to representation (subclassing).  An example of inclusion
polymorphism with respect to assignment (and initialization, or replacement if
viewed in an almost symbolic way) occurs when object types may be specified and
assignment is based on actual object membership in that type (often of the CLOS
is-a-member-of form in OO).  Emerald provides another example of an object-
oriented language using inclusion polymorphism with respect to replacement;
however, inclusion is with respect to subtyping only with abstract types
("bounded quantification" by C+W.  C+W's parameters are subtype polymorphic
but lose the inherent type).  Any object possessing all required operations is
acceptable and no inheritance relation is required (subtype polymorphism).
They refer to this as "best-fitting" types [Black 86].  The original Trellis/
Owl also had such a facility but with two separate inheritance hierarchies,
although it was abandoned in favor of a single class-based approach for
simplicity.  See also section 2.7.

[As inclusion polymorphism covers both subtype and subclass polymorphism,
 perhaps IP could be further divided in C+W's above classification.]


> Booch's Definition [Booch 91, p. 517]:

polymorphism  A concept in type theory, according to which a name (such as a
variable declaration) may denote objects of many different classes that are
related by some common superclass; thus, any object denoted by this name is
able to respond to some common set of operations in different ways.

Booch also has several sections devoted to polymorphism.

[The author notes Booch's definition above is clearly in the context of
 conventional, classical OO and subclass polymorphism.]


> Meyer's Definition [Meyer 88, sect. 10.1.5 Polymorphism]:

"Polymorphism" means the ability to take several forms.  In object-oriented
programming, this refers to the ability of an entity to refer at run-time to
instances of various classes.  In a typed environment such as Eiffel, this is
constrained by inheritance: ...

[The Author notes Meyer has a following section 10.1.7 on Static Type,
 dynamic type, which is relevant, but claims "... there is no way the type
 of an object can ever change.  Only a reference can be polymorphic: ...".
 Meyer is clear between the concept and the Eiffel realization in his
 polymorphism definition above, but here neglects the "becomes" facility
 as found in several dynamically typed OO languages such as Actors, CLOS,
 Self and Smalltalk, which allows an object (and not just a reference) to
 change its class.]


> Stroustrup's Definition [Stroustrup 90, p. 209]:

The use of derived classes and virtual functions is often called "object-
oriented programming".  Furthermore, the ability to call a variety of
functions using exactly the same interface - as is provided by virtual
functions - is sometimes called "polymorphism".

[The Author notes this is a functional view of polymorphism (as provided in
C++).  [Stroustrup 91, p. 136] has an example of polymorphism with void *'s,
but a newer template function is incomparably preferable, as implied in
[Stroustrup 90, ch 14]]


Rumbaugh's Definition [Rumbaugh 91, p. 2]:

"Polymorphism" means that the same operation may behave differently on
different classes.


2.2)  What Does Polymorphism Boil Down To In OO Programming Languages?
----------------------------------------------------------------------

In C++, virtual functions provide polymorphism.  This is because a polymorphic
object (pointer or reference (or such parameter)) is assignment compatible with
any object of a derived class.  Is this polymorphism in itself?  Objects
can take on objects of different forms (the derived classes), but of what use
is it?  To make any difference, the differing forms must have some effect.  In
dynamically typed languages, polymorphic objects are passed messages and will
respond in whatever way the object has defined (usually starting from its most
derived class and working its way up).  But for static objects, a virtual
function is invoked.  This is the stored method from the derived class that
overrode the virtual method from its base class, providing specialized behavior
for the polymorphic object; and hence, polymorphism.  This common pure
statically typed example is, of course, an example of inclusion polymorphism,
subclass polymorphism to be more specific (see section 2.1).  Pure statically
typed subtype polymorphism, as provided in Emerald, can be implemented
similarly [Black 86].


2.3)  What Is Dynamic Binding?
------------------------------

Dynamic binding has two forms, static and dynamic.  Statically-typed dynamic
binding is found in languages such as C++ (virtual functions) and Eiffel
(redefinition).  It is not known which function will be called for a virtual
function at run-time because a derived class may override the function, in
which case the overriding function must be called.  Statically determining all
possibilities of usage is undecidable.  When the complete program is compiled,
all such functions are resolved (statically) for actual objects. Formal object
usage must have a consistent way of accessing these functions, as achieved thru
vtables of function pointers in the actual objects (C++) or equivalent,
providing statically-typed dynamic binding (this is really just defining simple
function pointers with static typechecking in the base class, and filling them
in in the derived class, along with offsets to reset the receiver).

The run-time selection of methods is another case of dynamic binding, meaning
lookup is performed (bound) at run-time (dynamically).  This is often desired
and even required in many applications including databases, distributed
programming and user interaction (e.g. GUIs).  Examples can be found in
[Garfinkel 93, p80] and [Cox 91, pp 64-67].  To extend Garfinkels example with
multiple-polymorphism, a cut operation in an Edit submenu may pass the cut
operation (along with parameters) to any object on the desktop, each of which
handles the message in its own way (OO).  If an (application) object can cut
many kinds of objects such as text and graphical objects, multiple-polymorphism
comes into play, as many overloaded cut methods, one per type of object to be
cut, are available in the receiving object, the particular method being
selected based on the actual type of object being cut (which in the GUI case is
not available until run-time).

Again, various optimizations exist for dynamic lookup to increase efficiency
(such as found in [Agrawal 91] and [Chambers 92]).

Dynamic binding allows new objects and code to be interfaced with or added to
a system without affecting existing code and eliminates switch statements.
This removes the spread of knowledge of specific classes throughout a system,
as each object knows what operation to support.  It also allows a reduction in
program complexity by replacing a nested construct (switch statement) with a
simple call.  It also allows small packages of behavior, improving coherence
and loose coupling.  Another benefit is that code complexity increases not
linearly but exponentially with lines of code, so that packaging code into
methods reduces program complexity considerably, even further that removing
the nested switch statement!  [Martin 92] covers some of these issues.


2.4)  Is There A Difference Between Being A Member Or Instance Of A Class?
--------------------------------------------------------------------------

Yes (but be careful of context).  To use C++ terminology, an object (not
a reference) is defined to be an instance of exactly one class (in classical
OO), called its most derived class.  An object not directly contained in any
other is called the complete object [Stroustrup 90].  An object is a member
of several classes, including all of the classes its declared (or most derived)
class inherits from.  With static typing and inclusion polymorphism based on
class, if a polymorphic object (or reference) is made to refer to an object,
that object must be a member of the polymorphic object's class.

This also provides a good example of differing definitions among object-
oriented languages, since a member is defined as above in CLOS, but a member of
a class is one of its instance variables in C++.


2.5)  What Is The Difference Between Static And Dynamic Typing?
---------------------------------------------------------------

Static typing refers to types declared in a program at compile-time, so no type
information is available on objects at run-time.  Dynamic typing uses the
inherent types of polymorphic objects, keeping track of the types of objects at
run-time.  Statically typed dynamic binding is a compromise (usually
implemented with tables of function pointers and offsets), and is how
statically-typed OO languages provide polymorphism.  Some approaches provide
both static and dynamic typing, sometimes with static typing providing type-
safe programs and dynamic typing providing multiple-polymorphism [Agrawal 91]
[Mugridge 91].  See also section 2.3.

Static typing is more efficient and reliable, but loses power.  Typical
restrictions include only allowing a common set of base class functions (or
any common functions for the more general subtyping or parametric polymorphic
cases) to be available on formal objects and a lack of multiple-polymorphism
(see section 1.19), both of which are overcome with dynamic typing.

Many languages provide dynamic typing: Smalltalk, Self, Objective-C, and etc.
A limited dynamic typing scheme, called RTTI (Run Time Type Identification),
is even being considered for the C++ standard.  A similar facility to safe
downcasting (historically known as type narrowing), the thrust of RTTI, can
also be found in recent versions of Eiffel.

See section 3.4 for a categorization of common OO languages by type system.


2.6)  What Is This I Hear About ML And Functional Programming Languages?
------------------------------------------------------------------------

ML, Metalanguage, is a functional programming language with a strongly typed
polymorphic type system [Wikstrom 87].  Russell (see Appendix E) is a more
recent functional language and Haskell [Hudak 92] provides a more modern and
"pure" example.  Section 2.5 discusses why static typing has less power/
flexibility than dynamic typing and the same applies to ML (although see the
appendixes for an experimental dynamic extension to ML, Alcool-90 and [Cardelli
85] for a proper placement of ML's type system).  ML doesn't use inheritance
for polymorphism; unlike OO languages, but provides the prototypical example of
parametric polymorphism, so no inheritance is required.  This is "true" or
"pure" statically (or strongly) checked parametric polymorphism, by Strachey's
(and Cardelli and Wegner's) definitions.

Smalltalk is an example of a dynamically-typed language which does not check
types during assignment (and hence for parameters) and therefore provides
parametric polymorphism without static constraints (by Strachey's definition).
However, Smalltalk's style uses inclusion polymorphism in practise and
inheritance for subclassing (representation).


2.7)  What Is A Separation Between Type And Class (Representation)?
-------------------------------------------------------------------

For a short answer:
  Subtype Polymorphism, as opposed to Subclass Polymorphism, is the best answer
  in OO.  Parametric polymorphism is a related concept where this is also true,
  but is of a different flavor (and usually requires object attributes by use.
  See also section 2.1).

A type can be considered a set of values and a set of operations on those
values.  This can insure type-safe programming.  However, the representation of
types (classes in OO) can be separated from the notion of type allowing many
representations per type while still maintaining reasonable type-safety.

In many languages, a type has a single representation insuring all operations
performed on that type are well defined (statically bound) and providing for
efficiency by taking advantage of that representation wherever used.  In many
OO languages, subclassing and dynamic binding provides for greater flexibility
by providing object specialization.  However, in many OO languages classes are
used for assignment compatibility forcing an assigned object to inherit
(transitively) from any polymorphic object's class (inclusion polymorphism
based on class, or subclass polymorphism).  This insures all operations to be
performed on any polymorphic object are satisfied by any replacing objects.
This also insures all types share a common representation, or at least a
common base interface specification.

By separating type from class, or representation (or perhaps separating class
from type, by the aforementioned definition of type), a replacing object must
satisfy the operations or type constraints of a polymorphic object (subtype
polymorphism) but are not required to do to do so by an inheritance relation
(subclass polymorphism), as is typical in most OOPLs.  Dropping this
restriction is somewhat less type-safe, because accidental matches of method
signatures can occur, calling for greater care in use.  [Black 86] discusses
this issue in Emerald.  The same issue arises in parametric polymorphism
(generics/templates), as any method matching a required signature is accepted,
calling for careful matching of actual and formal generic parameters.  The
difference between static and dynamic binding in OO and dynamic binding and
subtyping seems similar.  A possible loss of semantic integrity/similarity is
contrasted with greater power.

It is possible to specify desired abstract properties of type specifications
with mechanisms similar to Eiffel's pre-, post-, and invariant conditions.
This helps to insure the semantic integrity of replacing objects and their
behavior.  [Liskov 93] provides a recent exposition.

Abstract classes ([Stroustrup 91] and [Meyer 88]) in typing provide a facility
similar to subtype polymorphism; however, ACs require type compatible classes
to inherit from them, providing a subclass polymorphism facility, and ACs can
also specify representation.  Subtyping is therefore most useful to avoid
spreading knowledge of classes throughout a system, which is a high priority
for loosely coupled modules and in distributed programming [Black 87].

The formal type system found in [Cardelli 85], Emerald/Jade [Black 86] and
[Raj 89], original trellis/Owl, an experimental C++ extension (See Appendix E,
Signatures), Sather (originally Eiffel-based), and an Eiffel superset
[Jones 92] are all examples of OO systems providing subtype polymorphism.
Functional languages such as ML, Russell, and Haskell provide a separation with
pure parametric polymorphism (as is also commonly found in OO languages in
addition to inclusion polymorphism).

See also [Cook 90], "Inheritance Is Not Subtyping", for a formal approach.


2.8)  What Are Generics And Templates?
--------------------------------------

Short Answer: Parametric Polymorphism (although various implementations
              provide various subsets).

Generics (or Templates in C++) refer to the ability to parameterize types
and functions with types.  This is useful for parameterized classes and
polymorphic functions as found in languages such as Ada, C++, Eiffel, and
etc., although these are "syntactic" or restricted forms [Cardelli 85].
Generics are orthogonal to inheritance, since types (and classes)
may be generically parameterized.  Generics provide for reusability in
programming languages.  An example is a Stack with a generically
parameterized base type.  This allows a single Stack class to provide
many instantiations such as a Stack of ints, a Stack of any fundamental
or user defined type, or even a Stack of Stacks of ...  Another example is
a polymorphic sort function taking a base type with a comparison operator.
The function can be called with any type (containing a comparison operator).
See [Booch 87b] for several examples in Ada and [Stroustrup xx] and [Murray
93] for examples in C++.

While generics have many advantages, typical limitations include a static
nature, which is an advantage for strong typechecking but a potential
disadvantage when causing dynamic compilation (leading to a time/space
efficiency tradeoff), and sources can cause inlining and create source code
dependencies and expand code size (unlike a single-body or "true"
parametrically polymorphic implementation.  Generics can also be viewed as a
special case of type variables.

Functions are typically generic in statically-typed parametrically-polymorphic
languages.  One such popular functional language is ML, in which all functions
are generic.  Russell and Haskel are more modern variants (references are
forthcoming, however see APPENDIX E).


SECTION 3:  GENERAL
===================

  References:   (many more are to come)
    [Coplien 92]    Covers C++, symbolic, exemplar (single-hierarchy), etc.
    [Kim 89]        Covers many OO systems.


3.1)  What Is The "Classical" Object-Oriented Paradigm?
-------------------------------------------------------

This refers to the usual class and object model.  Its any 2+ level system
as described in section 1.4.  See also [Coplien 92].


3.2)  What Is The "Delegation/Prototyping" Object-Oriented Paradigm?
--------------------------------------------------------------------

See [Kim 89, ch 1,3].

This is the 1 Level System as Described under Meta-Classes.  Delegation refers
to the delegating of responsibility and can be applied to inheritance.  When a
derived class does not have a desired attribute, it "delegates" responsibility
to one of its base classes.  In delegation systems, each object has a delegate
list instead of a parent list. Thus, delegation's primary emphasis is
on message passing where an object could delegate responsibility of a message
it couldn't handle to objects that potentially could (its delegates).  Any
object can be added to the delegate list, giving dynamic inheritance (of a
sort).  Typically, delegation and prototyping languages also have "part
inheritance" in which fields and methods can be added and deleted from objects.
This makes for easy "prototyping", which allows for objects to be constructed
piece by piece at run-time, although the term "prototyping" in the context of
delegation languages usually refers to objects serving as prototypes for
object instantiation, or exemplars.

Next's NextStep OS provides delegation using Objective-C, providing an example
of delegation in a class-based language [Garfinkel 93].


3.3)  Are There Any Other Object-Oriented Paradigms?
----------------------------------------------------

There are many alternatives in OO.  Emerald/Jade ([Black 86] and [Raj 89])
provides one, where inheritance is replaced with a roughly equivalent form
where reuse occurs at a finer degree of granularity - method and instance
variables - with subtype polymorphism making up the difference.

CLOS [Kim 89, ch 4] has a looser coupling of methods to classes and doesn't
distinguish a receiver, but packages can help make up the difference.

Object Specialization [Sciore 89] is an example of a hybrid approach between
delegation and classical systems, where parent classes have an extra level
of indirection and inheritance hierarchies are specified on a per object/class
basis.


3.4)  What Are The Major Object-Oriented Programming Languages Today?
---------------------------------------------------------------------

Statically-Typed:
  Add 1 To Cobol giving Cobol with Objects.
  C++
  Classic-Ada
  Dragoon
  Emerald/Jade
  Java (comp.lang.java, http://java.sun.com/, Java Report & Conf:
         http://www.sigs.com, See Anon FTP)
  Object Pascal
  Trellis/Owl

Dynamically-Typed:
  Actors Languages
  C+@
  Flavors
  Python (new WWW, see http://www.python.org/)
  Self
  Smalltalk

Both:
  Actor
  Ada95
  BETA
  C++ (With RTTI)
  Cecil
  CLOS
  Eiffel
  Modula-3
  Objective-C (http://www.marble.com/people/dekorte/Objective-C/objc.html)
  Sather


3.5)  What Are Object-Oriented Databases And Persistence?
---------------------------------------------------------

See also Appendices B and E and the comp.database.object newsgroup.
Refs to be included in future FAQs.

Object-Oriented Databases are databases that support objects and classes.  They
are different from the more traditional relational databases because they allow
structured subobjects, each object has its own identity, or object-id (as
opposed to a purely value-oriented approach) and because of support for methods
and inheritance.  It is also possible to provide relational operations on an
object-oriented database.  OODBs allow all the benefits of object-orientation,
as well as the ability to have a strong equivalence with object-oriented
programs, an equivalence that would be lost if an alternative were chosen, as
with a purely relational database.

Another way of looking at Object-Oriented Databases is as a persistent object
store with a DBMS.

Persistence is often defined as objects (and their classes in the case of
OODBs) that outlive the programs that create them.  Object lifetimes can be
viewed as a hierarchy, with locals/automatics having the shortest default
lifetime and objects stored indefinitely in an OODB (which are persistent)
having the longest.  Persistent object stores do not support query or
interactive user interface facilities, as found in a fully supported OODBMS.

Appendix B also contains references for object-oriented interfaces to
relational databases and see APPENDIX E, Papers, Persistent Operating Systems.

From the net:
From: [e-mail] (DBMSfacts)
Subject: ODMG Gopher and Web Addresses
Date: 24 Oct 1994 13:10:02 -0400

The Object Database Management Group (ODMG) has set up Gopher and Web
Servers at the following addresses:

  Gopher:  gopher.odmg.org, port 2073
  WWW:  http://www.odmg.org:3083

These are still under construction.  What you can find right now are
addresses and contact information for ODBMS vendors, ODMG membership
information, updates to Release 1.1 of The Object Database Standard:
ODMG-93 along with ODL lex and yacc files.  In the future, we will be
adding more links to related sites, bibliographies, and a FAQ for ODBMSs.

If you cannot access these servers, but would like information on the
ODMG, send an email message to [e-mail] and you will receive an
automated reply.

Doug Barry
ODMG Executive Director


3.6)  What Are Object-Oriented Operating Systems?
-------------------------------------------------

Refs to be included in future FAQs.  See also Appendix E.

Object-Oriented Operating Systems provide resources through objects, sometimes
all the way down to to the machine (OO architectures are found at the bottom).
They are almost always distributed systems (DOS or DPOS), allowing objects to
be passed freely between machines.  They are typically capability-based since
objects, and hence system resources, can only be accessed if a capability to
them is available to programs.

Here are some abstracts taken from several postings to the net.  This list is
by no means exhaustive.

Apertos (Meta-Object-based Mikro-Kernel.  See Appendix E, Papers:28)
Chorus Micro-kernel (written in C++, COOL, See Appendix E, Papers:63)
Choices (research OS, UofI, C++, supports SVR4, See Appendix E, Papers)
GEOS    (GeoWorks', written in Object Assembler, OO superset of 8086)
Mach    (CMU, supports BSD 4.3, really message-based)
NachOS  (written in C++, OS teaching/learning OS)
Ouverture Project (ESPRIT funded OMG IDL defines inter-module interfaces)
Peace    (OO family-based parallel OS, See Appendix E, General)
SOS
Spring      (Sun, written in C++)
PenPoint OS (Go, written in C++)

For the Spring Papers (free), Contact:
  Sun Microsystems Laboratories, Inc.
  M/S 29-01
  2550 Garcia Avenue
  Mountain View, CA USA  94043

See also APPENDIX E, PAPERS, Persistent Operating Systems entry.

From: [e-mail] ()

Insight ETHOS: On Object-Orientation in Operating Systems
ISBN 3 72811948 2

This thesis covers the design of an extensible object-oriented
operating systems. The language used was Oberon-2. It includes
a generalization of the Rider/Carrier principle, Object Directories
as well as basic OS issues such as memory, file, tasking management.
It covers extensible objected-oriented programming from hardware up.
It reviews other designs such as Clouds and Choices which where written
It reviews other designs such as Clouds and Choices which where written
on C++. [[ The lack of type-tests in C++ was a problem in other designs.]]
ETHOS was implemented as an operating system for the Ceres computers
at the ETH.


3.7)  What Are The Current Object-Oriented Methodologies?
---------------------------------------------------------

Here is a list of OOSE Methodologies:

  Berard                        [Berard 93]
  BON                           [Nerson 92]
  Booch                         [Booch 94]
  Coad/Yourdon                  [Coad 91]
  Colbert                       [Colbert 89]
  de Champeaux                  [de Champeaux 93]
  Embley                        [Embley 92]
  EVB                           [Jurik 92]
  FUSION                        [Coleman 94]
  HOOD                          [HOOD 89]
  IBM                           [IBM 90,91]
  Jacobson                      [Jacobson 92]
  Martin/Odell                  [Martin 92]
  Reenskaug (OOram, was OORASS) [Reenskaug 91]
  ROOM                          [Selic 94]
  Rumbaugh et al.               [Rumbaugh 91]
  Shlaer and Mellor             [Shlaer 88 and 92]
  Wasserman                     [Wasserman 90]
  Winter Partners (OSMOSYS)     [Winter Partners]
  Wirfs-Brock et al.            [Wirfs-Brock 90]

Further Ideas And Techniques:
  Meyer                         [Meyer 88]
  Stroustrup                    [Stroustrup 91]

See APPENDIX D for CASE systems supporting these methodologies (several from
the originators themselves).

See also section 1.21 for a discussion on OOA/OOD and etc.

Summaries and comparisons will be provided in future FAQs.  Suggestions for
inclusion of other major or new methodologies should be sent to the FAQ author.

Here are some comparison studies posted to the net:

Arnold, P., Bodoff, S., Coleman, D., Gilchrist, H., Hayes, F., An Evolution of
Five Object Oriented Development Methods, Research report, HP Laboratories,
June 1991

de Champeaux, Dennis and Faure, Penelope. A comparative study of object-
oriented analysis methods. Journal of Object Oriented Programming (JOOP), pp
21-32.  Vol.5, No. 1, 3/4-92

Fichman R.G. & Kemerer C.F.  OO and Conventional Analysis and Design
Methodologies.  Computer, Oct 1992, Vol 25, No. 10, p 22-40

Fichman, Robert and Kemerer, Chris. Object-Oriented and Conventional Analysis
and Design Methods - Comparison and Critique.  IEEE-Comp, Oct, 1992, pp 22-39.
OOA, OOD, conventional analysis, conventional design, DeMarco SA, Yourdon SA,
Bailin OO requirements specification, Coad-Yourdon OOA, Shlaer-Mellor OOA,
Yourdon-Constantine SD, Martin information engineering design, Wasserman OOSD,
Booch OOD, Wirfs-Brock responsibility-driven design.

The following 2 reports are out of print.

[van den Goor et.al., 1992]
G. van den Goor, S. Hong and S. Brinkkemper,
A Comparison of Six Object-oriented Analysis and Design Methods. Report
Center of Telematics and Information Technology, University of Twente,
the Netherlands, and Computer Information Systems Department, Georgia
State University, Atlanta, USA, 1992, 163 pages.

[Hong et.al. 1992]
S. Hong, G. van den Goor, S. Brinkkemper, A Formal Approach to the
Comparison of Object Oriented Analysis and Design Methodologies, Hawaii
International Conference on System Sciences (HICSS) (IEEE Computer Society
Press, Hawaii) 1993, Vol. IV, pp. 689-698.

 [From Shuguang...] readers may download the paper if they want, though they
 may continue to request hard copies.  We are currently extending the paper
 to compare ten OO methods and should be available shortly.
 My URL is: http://cis.gsu.edu/~shong

  ===================================================================
  *  Shuguang Hong, Ph.D.                    [e-mail] *
  *  Computer Information Systems Dept.      Tel: [phone]     *
  *  College of Business Administration      Fax: [phone]     *
  *  Georgia State University                                       *
  *  Atlanta, GA 30302-4015         www: http://cis.gsu.edu/~shong/ *
  ===================================================================

Monarchi, David and Puhr, Gretchen I. A Research Typology for Object-Oriented
Analysis and Design.  CACM/September 1992/Vol.35, No.9, pp35.

[Wilkie 93] summarizes, compares, and provides examples of Booch, Wirfs-Brock,
Hood, Coad and Yourdon, Winter Partners, Shlaer and Mellor, Jacobson,
Wasserman et al, Rumbaugh, Reenskaug et al, and Colbert.

Wirfs-Brock, R.J. and Johnson, R.E., "Surveying Current Research in Object-
Oriented Design," The Communications of ACM, (33, 9) Sept. 1990, pp. 104-1124.

Fowler, M.  "Describing and Comparing Object-Oriented Analysis and Design
Methods," In Object Development Methods, Carmichael, A. ed., SIGS Books,
(1994), pp.79-109.
A new version is going to be published soon.  Contact the author
<[e-mail]> for details on its availability'.

Also commercially available:

An Evaluation of Object-Oriented Analysis and Design Methodologies (9)
J. Cribbs, C Roe, S. Moon
SIGS Books
[phone]
$149.

Object-Oriented Methodology Comparison Study (10 methodologies)
Berard, Booch, Coad/Yourdon, Colbert, Embley, IBM, Martin/Odell, Rumbaugh,
Shlaer/Mellor, Wirfs-Brock.  Also contains refs to several previous studies.
Berard Software Engineering
101 Lakeforest Blvd., Suite 360, Gaithersburg, MD 20877
Contact Person: Jim Youlio
Phone:        [phone]
Fax:          [phone]
email:        [e-mail]

[Hong et.al. 1992], [van den Goor et.al., 1992]
The authors have prepared a revision (See above) that includes the following OO
methods:

Booch, G. - Object-oriented analysis and design with applications, 1994.
Champeaux, D. de - Object-oriented system development, 1993.
Coad, P., and Yourdon, E. - Object-oriented analysis (2nd edition), 1991a.
Coad, P., and Yourdon, E. - Object-oriented design, 1991b.
Coleman, D. - Object-oriented development, the Fusion method, 1994.
Henderson-Sellers, B. and Edwards, J.M. - Methodology for Object-oriented
Software
Engineering of Systems, draft manuscript, 1994.
Jacobson, I. - Object-oriented software engineering, 1993.
Martin, J., Odell, J. - Object-oriented analysis and design, 1992.
Martin, J., Odell, J. - Principles of object-oriented analysis and design,
1993.
Rumbaugh, J. et.al. - Object-oriented modeling and design, 1991.
Shlaer, S., Mellor, S.J. - Object-oriented systems analysis: Modeling the
world in states, 1992.
Wirfs-Brock, R. et.al. - Designing object-oriented software, 1990.

We are currently approaching publishers for the publication of this report
as a book. This book should be out in the spring of 1995.

If you are interested in obtaining this book you can send an e-mail to
Sjaak Brinkkemper ([e-mail]), which we will forward to the
publisher.

The authors, regretfully, cannot supply ftp, postscript, TEX, or
whatsoever.


3.8)  What Is the OMG/OMA/ORB/CORBA?
------------------------------------

Contents:
  (3.8.1)  Contact Information
  (3.8.2)  OMG Summary
  (3.8.3)  Mail Server Access
  (3.8.4)  OMG Publications
             - First Class (Bi-Monthly Newsletter)
             - Object Management Architecture Guide (OMA)
             - The Common Object Request Broker: Arch. and Spec. (Corba)
             - Pricing
  (3.8.5)  Implementations (Brief)
  (3.8.6)  Implementation Descriptions
  (3.8.7)  Books, Articles, And Literature


3.8.1  Contact Information
__________________________