From: rumpe@Informatik.TU-Muenchen.DE (Bernhard Rumpe)
Subject: A little glossary for objects
Originator: rumpe@sunbroy25.informatik.tu-muenchen.de
Organization: Technische Universitaet Muenchen, Germany
Date: Wed, 23 Dec 1992 15:12:38 GMT



Little glossary of object oriented software developement
========================================================

This paper is one result of a workshop over software development
of three partners from software industry and universities. The glossary
is a mixture of different views: a practical and a formal one, according
to the backgrounds of the partners.

This glossary aims at giving small, rather formal definitions of object
oriented notions. The definitions are neither exact mathematic definitions
nor do they correspond exactly to the definitions used in the area of
algebraic specifications. We do not claim to cover the whole area of
object orientation with our definitions (but we tried to cover a large part).


So what do you think of the following definitions?


responsible:  Peter Sommerlad, Alois Stritzinger, Bernhard Rumpe

-----------------------------------------------------------------------------

OBJECT

An object is characterized by the following properties:
   identity
   state
   behaviour


VALUE

A value is a value is a value.


STATE

The state of an object is represented by values and
references to objects. The state is constituted by the values 
and the states of all referenced objects.


MESSAGE

Objects communicate with each other by sending messages.
A message denotes a receiver, an operation and carries arguments.


OPERATION

An operation describes an algorithm that is executed whenever an object
receives an appropriate message. The operation may inspect and change
the state of the object and may send other messages.

Comment:
The operation processes the arguments carried by the message.


OBJECT SIGNATURE

An object signature is a description of the messages understood by
the object.

 
CLASS

A class is a description of the object signature,
behaviour and structure of objects. An object belongs to exactly one class.

Comments:
- The structure determines the set of possible states of the objects.
- The behaviour is determined by the operations of the objects.
- A class corresponds to an abstract data type.
- In some languages classes are also objects.
- In some languages "prototype objects" take the role of classes.


CLASS SPECIFICATION

A class specification consists of a signature and a description of the
semantics of all objects of a class.


INHERITANCE

Inheritance is a binary, transitive, acyclic relation on classes.
A subclass inherits the class specification (signature and behaviour)
of a superclass and may extend it.

Comments:
- A class may have one or several direct superclasses. This is called
  single or multiple inheritance respectively.

- In many languages a subclass inherits also the structure of a superclass
  and may extend it.

- The term "inheritance" is sometimes (mis-)used for code reuse violating
  the subfamily relation.


FAMILY

A family is the set of all objects that belong to the associated class or
one of its subclasses.

Comments:
- A family is a set of objects which satisfy at least the class specification
  of its associated class.
- A family associated to a subclass is called a subfamily.
- The inheritance relation among classes corresponds to the subfamily
  relation of the associated familys.
- The term "inheritance" is sometimes (mis-)used for code reuse violating
  the subfamily relation.


POLYMORPHISM

Polymorphism allows the binding of different meanings to the same name.

Comments:
- In object-oriented languages at least two kinds of polymorphism are
  possible: overloading and inheritance polymorphism.


OVERLOADING (ad hoc polymorphism)

Overloading denotes the use of the same name for different 
operations distinguished by number and kind of arguments (operation signature).


INHERITANCE POLYMORPHISM

An object of a subclass may be used whenever objects of any of its 
superclasses can be used.

Comments:
- This fact implies the use of the same message for different operations. 
- The selection of the operation is based on the actual class of the
  receiving object. 

-- 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bernhard Rumpe      Inst. f. Informatik (SB3), Technische Univ. Muenchen
                    Postfach 20 24 20,      8000 M"unchen 2,     Germany
rumpe@informatik.tu-muenchen.de     phone: ++49-89-2105-8129   fax -8183
Newsgroups: comp.object