The potential of an object-oriented approach, obviously,
lies in the opportunities for reuse,
both of code and design.
However, reuse requires a common understanding of
the basic principles underlying the technology and its application.
More particularly, the reuse of code requires
(a much more strict)
agreement with respect to the components from which
an application will be constructed and the
language constructs used to implement them.
In this section, we will look at
the object linking and embedding facilities
offered by Microsoft OLE,
and the standardization efforts
undertaken by the OMG (Object Management Group)
directed towards the interoperability of object components.
In addition, we will look at the efforts of the
ODMG (Object Database Management Group)
undertaken to develop a standard for persistent objects.
And, finally we will discuss the duality between
object and events,
which both play an important role in the design
and realization of component-based systems.
Object linking and embedding
Reuse is not necessarily code sharing.
In effect, there seems to be a trend
towards sharing components at a higher level
of granularity, as possibly independent applications.
This approach has, for example, been taken by the
Microsoft object linking and embedding
facility (OLE), which offers support for
embedding (a copy) of a component in a (container)
component, for including a link to another component,
and for storing compound objects.
See slide [11-ole].
Object-enabling technology
OLE
- document centered
-- text, graphics, reports
- component software
-- standard programmatic interface
- distributed object systems
-- component object model
DCE
Features
- linking, embedding, storage
Alternatives
- IBM SOM/DSOM, Apple OpenDoc
slide: Object-enabling technology -- OLE
The OLE technology is characterized by
its developers as object-enabling
technology, to contrast it with
a more classical language-dependent object oriented
approach relying on inheritance.
The object linking technology allows
the user to maintain a link from one application
to another,
so that for example a text processor may
directly employ the results of a spreadsheet.
Moreover, object linking is dynamic and allows to reflect
any updates in the spreadsheet application
directly in the outcome of the text processor.
In contrast, object embedding works more as
the traditional cut and paste techniques
in that it results in including only a copy
of the material.
To be embedded or linked,
applications must satisfy a standard programmatic interface.
In effect, the interface must provide facilities
to request an update of the display
of the information contained in the application.
In this respect, the OLE technology may be characterized
as document-centered.
The component object model underlying OLE
allows for distribution along the DCE standard
discussed in section [DCE].
The commercial competitors are currently
the Apple OpenDoc framework and the IBM SOM/DSOM
realization of the OMG CORBA standard.
It is interesting to note that future releases of
OLE are also promised to be compatible with the CORBA standard.
Distribution {\em -- OMG}
The ultimate goal of object technology
may be phrased as the development of
plug-compatible software that allows one
to construct a particular application
from off-the-shelf components.
To achieve this goal, it is necessary to
develop standards with respect to object
interaction and communication interfaces
that support information sharing
between distinct components.
Such standards are (being) developed by
the OMG (the Object Management Group, in
which the leading vendors of software systems
participate, including Digital Equipment Corporation,
Hewlett-Packard Company, HyperDesk Corporation, NCR Corporation,
Object Design Inc. and Sunsoft Inc.).
The OMG aims at defining standards for information
sharing in widely distributed, heterogeneous
(multi-vendor) networks
to support the reusability and portability of
commercially available components,
and more generally, to develop the technology and
guidelines that allow the interoperability of applications.
See slide [11-standards].
Standardization -- system integration
OMG
- information sharing -- technology, policy
Object Management Architecture -- interface standards
IDL
- Object Services
- Object Request Broker
CORBA
- Common Facilities -- file manipulation, print queuing, email
- Application Objects -- spreadsheets, word processor
slide: The OMG standardization effort
The OMG proceeds from the assumption that
object technology (including encapsulation, polymorphism
and inheritance) provides the mechanism necessary for
language-, platform- and vendor-independent,
system integration.
The OMG has proposed an abstract object model
and discusses technical and political objectives
in the OMA Guide (Object Management Architecture Guide).
The architecture specified in OMA
provides a generic description of the components
that constitute a system and defines
the interface standards to which the components
must comply.
An important aspect of OMA is the
interface description language (IDL)
that is introduced as a standard to describe object
interfaces in a language independent manner.
According to OMA, a system must support a number
of Object Services
(dealing with the lifecycle of objects, persistence,
naming an event notification),
and a so-called Object Request Broker
(which is an intermediary between the object providing
a service and the client requesting a service).
Also a system will need, generally,
Common Facilities
(such as file manipulation and print queuing),
and in addition will contain
a number of Application Objects
(such as a spreadsheet or word-processor)
that constitute the proper application.
The OMG is primarily concerned with the adoption of technology
by the producers and vendors of common facilities
and application objects.
Its contribution in this respect is the definition of a set of
common object services and a standard interface
to invoke such services by means
of an object request broker.
This standard has been adopted in CORBA
(the Common Object Request Broker Architecture)
which allows for the interaction between
an application and distinct object request brokers.
The object services envisioned in OMA
are intended to deal with objects in a language-
and platform-independent manner.
See slide [11-services].
Object Services
- life cycle -- creation and deletion
- persistence -- management of object storage
- naming -- mapping names to references
- event notification -- registration of events
Future
- transactions, concurrency, relationships,...,time
slide: The OMG Object Services
These services encompass the creation and deletion
of objects, the management of object storage,
the mapping of names to references
and the registration of events as triggers
for actions.
In addition, services will be defined that
allow transactions, concurrency,
relationships between objects and time-based properties
of objects to be specified.
To a large extent, such services are provided by individual
languages (such as C++ or Smalltalk)
with their accompanying libraries
and development frameworks (such as the X-window environment
or the Unix operating system).
However, the efforts of the OMG are directed towards
(the ambitious goal of) providing such services
in a generic fashion, independent of a particular
language or environment.
Persistent objects -- ODMG
In a similar vein as the OMG,
a number of vendors of object database management
systems (including SunSoft,
Object Design, Ontos, Technology, Versant,
Objectivity, Hewlett Packard, POET Software,
Itasca, Intellitic, Digital Equipment Corporation,
Servio, Texas Instruments)
have participated in the ODMG
(Object Database Management systems Group)
to develop a standard for the definition and manipulation
of persistent objects.
The standards proposal of the ODMG encompasses
an object definition language ODL,
which is intended as an extension of the OMG/IDL
standard,
an object manipulation language, OML
and an object query language, OQL,
that provides SQL-like facilities for
the retrieval of information.
The advantage of employing an object database
system over employing a relational database system
is that, in principle, the application programmer
may work within a unified type system,
encompassing both persistent and transient objects.
See slide [11-ODMG].
Persistent objects
ODMG
- database extension -- unified type system
Object Definition Language
ODL
- standard types objects and literals
- references -- Ref \zline{\c{see} section
[smart]}
- collections -- List , Bag, Set
Object Manipulation Language
OML
- create, delete, modify, reference
Object Query Language
OQL
- oql(type& value,const char* query,...)
slide: The ODMG-93 standardization efforts
The extensions to the various languages,
which currently include only C++ and Smalltalk,
involve the definition of persistent objects,
the creation and use of objects and
facilities to pose queries concerning
their attributes and relations.
These extensions are proposed as language-specific
bindings for respectively ODL, OML and OQL.
The object model proposed by the ODMG
supports objects
(which may have attributes and methods),
literals
(which may be considered as primitive values),
relationships between objects
(including m-n relations),
extents
(which contain the collection of instances of
a particular type),
and named objects
(to facilitate retrieval).
To define objects and literals,
the programmer may employ the standard
types offered by the language,
as well as a number of additional
parametrized types to define references and collections.
For references the ODMG-93 proposal employs
the construct discussed in section [smart].
For dealing with collections a number of generic
collection classes such as ,
and must be provided by a standard
library.
(To provide a binding for Smalltalk,
which does not have a type system,
type annotations must be employed
to define the properties of persistent objects.)
The manipulation of persistent objects
conforms with the manipulation of ordinary
objects as far as attribute access and method
invocation are concerned.
However, the language-specific OML bindings
must take precautions for the creation,
deletion and modification of objects.
In particular, when employing a reference
to a persistent object, the implementation must
check whether the referenced object has
been modified.
The C++ binding for the object query language OQL
in the ODMG-93 proposal is quite simple.
It consists merely of a function that allows
the programmer to pass an extended SQL-like
query as a string.
The query may contain symbolic variables
that are bound in a similar way as allowed
by the C printf function.
The design principle guiding the ODMG effort
has been to promote that
the programmer feels that there is one language.
However, there are a number of difficulties
that arise when defining a particular language
binding for the ODMG object model,
as for example for C++.
See slide [11-binding].
Design principles
\zline{\fbox{object model}}
- the programmer feels that there is one language
Language binding
\zline{\fbox{C++ODL/OML}}
- objects and literals --
embedded objects are literals
- relationships --
not directly supported by C++
- extents --
must be maintained by programmer
- keys --
simulated by C++ data members
slide: Language binding -- C++ ODL/OML
Embedded objects which are defined in C++ as
object data members,
must be taken as literals in the ODMG object model,
whereas embedded references to objects are
to be taken as objects.
Relationships are not directly supported in C++.
In the ODMG-93 proposal, the programmer is required
to employ an explicit data structure for
updating and traversing a relation.
Extents, which contain the collection of instances
of a type, must explicitly be maintained by
the programmer.
Extents may conveniently be stored in a collection
that is associated with a static data member of the class.
Keys, which are needed for efficient retrieval
must be simulated by C++ data members.
Support for indexing and retrieval by key
requires additional compiler support, for
which no provision is made in the ODMG-93 proposal.
Other problems that arise in defining a binding
to C++ involve the naming of objects,
the restriction that C++ allows for only one
implementation of a particular type
and the duality between arrays and pointers.
Discussion
Both the OMG and ODMG standardization efforts
aim at the portability of software.
The ODMG proposal not only entails
the portability of design and source code,
but also includes object code, in the form
of persistent objects.
The ODMG-93 proposal is inadequate due,
partially,
to the self-imposed restrictions with respect
to the compiler support required.
C++ODL/OML binding -- future
- no distinction between persistent and transient
objects
- better integration of the query sublanguage
Modifications to C++
- overloading dot (access operator), r/l values, ...
Standardization efforts -- de facto market share
- PDES/STEP, ODA, PCTE, OSI/NMF, ISO ODP, ANSI X3
slide: Future standardization efforts
The future C++ODL/OML binding will probably no longer
distinguish between references to persistent
and transient objects, and will provide a better
integration of the query language OQL.
To realize these goals, however,
extended compiler support is needed
and perhaps also modifications of
C++ to allow the incorporation of code for
integrity checking.
It is worth noting that there are a number
of additional efforts at defining
a standard object model.
See slide [11-efforts].
The ODMG proposal is explicitly meant
as a superset of the object model
proposed by the OMG, in order to become
what they aptly phrase as a standard
enforced by a de facto market share.
The object/event duality
One of the major problems in software engineering
that must be resolved for each software development
project is to obtain a proper modular decomposition
of a system.
Object orientation, supporting a component-based
approach, is a big step, as it provides
the mechanisms necessary to address this problem.
However, as argued in our historical aside below,
it provides only part of the solution.
What is still lacking, somehow, is a proper
solution to the problem of characterizing
the interaction between collections of objects.
A (partial) solution to this problem, however,
is suggested by
employing events to define the interaction between
objects.
See also
sections [systems] and [events].
In the OOPSLA'92 panel, with the title
The heresy of event-orientation in a world of objects,
several speakers observed a discomfort
with respect to the notion of events
in the object-oriented community.
A reason for this discomfort is the
tension between objects and events,
a tension which is known as the
object/event duality.
Traditionally, events are actions operating on passive entities,
whereas objects are meant explicitly to
integrate data and operations thereupon.
Events -- actions involving objects
- requirements -- user actions
- design -- object compositions
- implementation -- action callbacks
- broadcasts -- talker/listener pattern
slide: Objects and events
Why not abolish events altogether, then?
The title of the panel, obviously indicates
the reluctance of many software developers
to part from events in modeling the behavior of
(object-oriented) systems.
This reluctance may be explained (partly) as
a drive for continuity,
a natural opposition to throwing away techniques that
have proven to be beneficial in the past.
(This is probably also the reason that event-based
techniques also occur in modernized,
read object-oriented, versions of structured
development methods, as examined in section [methods].)
However, there are also strong arguments in favor
of the position that events
(which are extraneous to objects)
are an essential ingredient (in modeling the behavior)
of object-oriented systems.
See also sections [perspectives] and [events].
The notion of events may play a role in requirements
analysis, as well as in design and implementation.
As for requirements analysis,
the first author of [Jacobs92],
who was one of the speakers of the panel,
observed that use case analysis
(which is part of Objectory) in essence comes
down to listing all possible events occurring in
the interaction with the user.
Such an analysis specifies the functional
properties of a system whose behavior will
be realized by an appropriate object model.
As for design, we may note that events
may be used to characterize the interaction between
objects in a generic fashion.
In section [events], we discussed an example
demonstrating the use of event-driven control
as a means to manage the complexity of object compositions.
Event-driven control also underlies the implementation
of many window-based systems.
An event coming from the user or window manager
may trigger an action that is defined as a callback
function associated with the event.
See slide [11-events].
In the next chapter we will look in more detail
at the way in which control is handled by objects
in response to events occurring in a window-based
system.
Some history
In sections [what] and [abstraction], we have sketched the history
underlying the development of object-oriented
programming languages, as directed towards
increasingly powerful abstractions and constructs
for developing reliable software.
}
\setlength{\unitlength}{0.0050in}%
\begin{picture}(135,298)(40,485)
\thicklines
\put(175,565){\vector( 0,-1){ 60}}
\put(150,660){\vector( 0,-1){ 55}}
\put(100,760){\vector( 0,-1){ 65}}
\put(150,485){\makebox(0,0)[lb]{\raisebox{0pt}[0pt][0pt]Ravioli code}}
\put( 85,580){\makebox(0,0)[lb]{\raisebox{0pt}[0pt][0pt]Object Oriented Programming}}
\put( 40,770){\makebox(0,0)[lb]{\raisebox{0pt}[0pt][0pt]Spaghetti code}}
\put( 85,670){\makebox(0,0)[lb]{\raisebox{0pt}[0pt][0pt]Structured Programming}}
\end{picture}
slide: Some history
In short, we may characterize the genesis of
structured programming as the outcome of the
war against the goto and its associated
spaghetti code.
The subsequent development of object-oriented
programming may then be understood as
the realization that data is as important
as control.
Ironically, the disciplined use of encapsulation
and inheritance (as mechanisms for data abstraction)
may lead to another proliferation of control,
threatening the integrity and manageability of
object-oriented code.
One part of the control problem of object orientation
is known as ravioli code,
which expresses depictively the existence of
a large number of (small) objects with well-defined
interfaces, which interact in a complex way.
See slide [11-history].
The other part of the control problem
is known as the yo-yo problem,
which characterizes the difficulty of locating control
in a class hierarchy with virtual functions.
These problems are notoriously hard to solve,
yet lie at the core of good library design.
As a partial solution to the problem of structuring
the interaction between objects we have
discussed the notion of events to define
generic interactions.
However, essential to a successful component-based
approach, we need sufficiently high-level components
to start with.