Object Oriented Technology Object Oriented Technology The purpose of this page is to present an overview of Object Oriented Technology in the specific fields of:
None of the information presented should be taken as the gospel truth. We have merely attempted to gather whatever data we could find on the net and present it in an organized fashion. If you notice any discrepancies in any of the topics discussed, please e-mail us with the problem.
In general each OO system will be described briefly with emphasis on key terms used when referring to the system. Definitions and examples are provided, as well as selected commercial applications currently available on the market.
This entire presentation is also available for download in PowerPoint
7.0 format. Click here to get the zipped
version of it (120k).
"An object is any thing, real or abstract, about which we
store data and those operations that manipulate the data."
(Principles of Object Oriented Analysis and Design - James Martin)
Objects are software entities that combine data structures and
operations on the data. Together, these enable groups of objects
to model real-world entities based on their characteristics (represented
by data elements) and their behavior (represented by data manipulation
operations). In this way, objects can model concrete things such
as people, data entry forms and abstractions such as numbers or
geometrical concepts.
An object can be any one of the following:
So Object Oriented Technology(OOT) allows developers to solve
problems or create applications through a series of objects.
Object-oriented programming(OOP)is a programming style which incorporates three main characteristics:
These characteristics differentiate object-oriented programming
from the traditional structured programming model.
Object-oriented programming builds on the concept of reusing code
through the development and maintenance of object libraries. These
objects are available for building and maintaining other applications.
Some example of OOP languages are C++,
SmallTalk, and Eiffel.
When programming in a object oriented language, an objects is
called a class which is the software representation of an object.
A class packages all the attributes and methods of an object.
Attributes are the data associated with the object(Class) and
the methods are the functions and code which operate on the data
and express the behavior of the object. So basically a class is
a over glorified version of a structure in C.
An example of a class could be a car class. Some of the attributes
of the a car could be type of transmission and number of doors.
Methods could be acceleration and deceleration.
Inheritance allows you to create new objects(derived class) from
previously defined objects(base class).
When a derived class inherits from the base class, it will contain
all the attributes and methods of the base class plus any additional
specifications of the derived class.
Any changes which are made to base classes are propagated to all
derived classes unless explicitly overridden. This domino effect
has its advantages and disadvantages. Changes to a base class
could fix or break your application.
For example lets say we wanted to create a new class called sedan. We know that a sedan is a car so we would want to derive this new class from our base car class. Some of the data for this new class may be Horse Power and Top Speed and a function would be engine.
But because this is a derived class we would also have access
to the base class functions accelerations and deceleration plus
the data of the base class type of transmission and number of
doors.
Encapsulation is the hiding of information. It prevents users
from seeing the internal workings of an object. The main reason
for this is to protecting data that should not be manipulated
by the user. This makes the code more reliable and reusable.
For example in a sedan class here may be an engine function and data for the engine. You would want to protect the data for the engine to prevent the function form misbehaving. Another example would a link list class. You don't want to give the user access to the head or tail pointers because then they could break the link list.
Polymorphism means that different objects respond differently to the same message.
There are two types:
An example of early binding polymorphism would be to create two
acceleration functions in our base car class.
This application is called Rational Rose and was developed by
Rational Corporation. The
diagram you see inside is called a rose model or Class Diagram.
On the left we have our base class called car. The attributes
are NumDoors and Transmission. It has the methods Acceleration,
and deceleration which is early binding polymorphic function.
On the right we have our derived class, sedan. This class inherits
from the car class, which is indicated by the black arrow. It
has two methods Acceleration which is late binding polymorphic
and Engine which is encapsulated. Encapsulation is denoted by
two vertical bars beside the function name or data name. The data
associated with the engine is also encapsulated and there are
also some additional attributes HorsePower and TopSpeed.
From this model we can generate the code, which would produce
all the necessary files that contain prototypes, declarations
of data and function headers(.h and .cpp files).
If changes are made to the mode you can re-generate the code and
any code you have entered into your function bodies will not be
effected.
Object Linking and Embedding (OLE), is properly pronounced oh-lay,
however some people pronounce it oh-el-ee. OLE is a set of extensible
application protocols that enables one application to use the
services of another application in a nearly seamless manner.
Applications that follow the OLE protocols will be able to create
documents that contain linked or embedded information from documents
created by other applications. No longer do you need to worry
about file importing and data exchange. To place a table in your
page layout, simply drag a table from a spreadsheet or word processor
onto the page. OLE allows you to create multielement documents
effortlessly.
Before both linking and embedding can be defined, we must first
define a container document. A container document holds the objects
that are still connected to the original application that created
them. For example, a user can link or embed a spreadsheet into
a word-processing application. The word-processing application
would then be the container document.
Object linking is the case where the object in a container document
resides in another, separate document. Whenever this object is
modified outside the container application, the modifications
will be reflected within the container application as well. Changes
to OLE linked objects can be reflected in the container document
either manually or automatically. The linked object is symbolized
by a link to the physical location of the object.
Object embedding is where the object actually resides in the container
document. The object is only contained within that document itself
and can be shared with other applications only if the container
document containing the object is opened.
There are a wide variety of objects that are used as OLE objects.
However, anything that can be displayed or controlled by an application
can be an OLE object. With an OLE compliant document having the
ability to contain different object types, OLE facilitates multimedia
documents.
Examples of common OLE objects include:
Object Linking and Embedding was jointly developed by a group
of Independent Software Vendors including Microsoft, Aldus, Lotus,
Micrografx, and others. However, Microsoft has updated the protocol
and used OLE more than any of the other vendors listed.
The current version being used in industry is OLE version 2.0.
While OLE 2.0 can run on other platforms such as the Apple Macintosh
system, OLE has been predominantly used in Microsoft's Windows
X platforms (Windows 3.1, Windows NT, and Windows 95).
With OLE, users can concentrate on the task they are performing,
instead of the different applications required to complete the
task. If a user prefers using one application, they need never
leave that application. OLE brings other applications, to the
user, in the context that the user prefers.
Applications can specialize in performing one job. A drawing application
that implements OLE, for example, would not necessarily need any
text-editing capability. Users could put text into the drawing
and edit that text using any text editor that supports OLE.
Files can be more compact because linking objects allows a file
to use an object without having to store that object's data. Only
the location of the object and some other maintenance information
is stored in the container document. Linked objects in a file
can be updated dynamically and shared among multiple applications
or users. You could do a simple cut and paste, however when the
original object changes, you must perform the cut and paste again
(that is if you can find the object).
Embedded objects can be transferred easily to other users. Other
users can then edit the object without needing to know where the
original data resides.
Both the application which holds the container document and the
application which can modify the linked or embedded object must
both be loaded into memory for OLE. A computer system with OLE,
therefore requires 16Mb of RAM to get decent performance, with
both applications simultaneously open. To be comfortable and accustomed
to OLE, you will either have to get an upgrade on RAM or an upgrade
on patience.
In the example discussed in the last section (where a bitmap program
requires a OLE text editor to modify text in the bitmap) this
process would take much longer compared to a graphics application
that has built in text editing capabilities. There are situations
in which OLE should and should not be used. For very simple OLE
object situations, the overhead of OLE may outweigh its benefits.
A variety of problems can occur with the implementation (development) of OLE in an application,
starting at a high-level and eventually infesting the entire application.
Only when better developer education about OLE, and more efficient
planning on how to implement OLE are in place, will these complexities
be overcome.
Currently OLE is not available on UNIX and that leaves the many
CAD and CAM UNIX users and applications out in the cold when it
comes to OLE. In addition, OLE has not taken off in Apple systems.
However, OpenDoc (which will be discussed in the next section)
will incorporate OLE into the next generation Apple operating
system. In addition, even across computers with similar operating
systems, applications required to launch the objects are not always
present on each machine.
The major competitor to OLE in object technology is OpenDoc.
OpenDoc is supported by industry leaders (Apple, IBM, Adobe, Oracle,
Lotus, Novell, and the X Consortium). OpenDoc is cross-platform
and vendor neutral and is available on the Macintosh, Windows,
UNIX, and OS/2 operating systems. OpenDoc enables true component
software, by mixing & matching software components to create
custom solutions.
Unlike Microsoft's OLE, OpenDoc is not proprietary. The OpenDoc
source code will be licensed to developers through CI Labs. However,
Microsoft selectively licenses source code to only those developers
it chooses to work with. OpenDoc provides seamless interoperability
across various object technologies including OLE 2.0 itself, whereas
Microsoft is taking a proprietary stance, currently not intending
to support OpenDoc.
Although OLE technology requires a superior computer system to
operate effectively, its functionality is very useful for both
technical and average users. The ability to directly open an object
in its appropriate application within the container document,
relieves the user from searching for the appropriate application.
Companies such as Microsoft must find a way to make OLE less resource
intensive. In addition, developers must be better trained in designing
and developing OLE compliant applications. When these events happen,
OLE will appeal to a much wider audience.
In relation to other OpenDoc, OLE is technically inferior. OpenDoc
is considerably better at using system resources and will be available
on all major operating system platforms. Although, OpenDoc's features
are superior to OLE, OpenDoc is a new technology that not been
proven. In addition, it is always difficult to compete against
any Microsoft product, even if it is of a lower quality.
An Object Oriented Database (OODB) is a system combining characteristics of a database with the manipulation of objects typically available in object oriented languages. The following is a breakdown of the database and object oriented features inherent in such a database. Not all characteristics MUST be present for a system to be considered and OODB, but the more it has, the closer it gets to the ideal.
A simple example of the differences between the two database styles
is storing our car in the garage at the end of the day. An OODB
models this with an object for the car, one for the garage, and
one store operation. In an RDB, data must be flattened, normalized,
and stored by type in separate tables, so the car, in our example,
must be disassembled, with all the gears stored in one table,
pistons in another, wheels in another, etc. In the morning, before
driving to work, you must re-assemble your car. If you wish, you
may just as easily re-assemble it into an airplane, which might
be an advantage to some. Otherwise, there is a lot of extra overhead.
For applications with complex objects, this disassembly/reassembly
code can be expensive to write, error prone and very slow to execute.
Instead, in an OODB the structure of the car as a composite containing
the other objects via relationships is all modeled directly, naturally,
and efficiently.
Not every application or every user needs an OODB. Any of the
following three characteristics are a good indication that you
may benefit from an OODB.
small database results only | |||||
|---|---|---|---|---|---|
| DBMS | INGRES | UNIFY | RAD-UNIFY | VBASE | VBASE |
| Model Type | Relational | Relational | Relational | Relational | Object |
| Name LookUp | 35 ms | 60 ms | 9 ms | 11.4 ms | 9.8 ms |
| Range LookUp | 393 ms | 358 ms | 76 ms | 95.9 ms | 84.1 ms |
| Group LookUp | 116 ms | 85 ms | 24 ms | 6.0 ms | 5.1 ms |
| Reference LookUp | 165 ms | 50 ms | 6 ms | 30.6 ms | 9.8 ms |
| Record Insert | 56 ms | 230 ms | 43 ms | 95.44 ms | 24.3 ms |
| Sequential Scan | 2 ms | 11 ms | 3 ms | 1.53 ms | 1.6 ms |
| Database Open | 1300 ms | 580 ms | 580 ms | 1020 ms | 1036 ms |
| Actual Size | 6.3 Mb | 3.8 Mb | 3.8 Mb | 12.1 Mb | 10.4 Mb |
This table summarizes the results of the small version of the
Sun Benchmark, and allows for comparison of both Vbase models
to the existing relational versions. Vbase itself is the object-oriented
database platform developed by Ontos Inc
Overall, these numbers indicate that an object system can meet
and in many cases exceed the performance of a fast relational
system. However, it would be desired to make the assessment of
databases at a higher, more complex level. Furthermore, this application
benchmark would need to take into account the kinds of complex
modeling relationships object databases have been created to model.
The Sun Benchmark is intended for use across different kinds of
database systems. It attempts to provide generic, data model independent
definitions and benchmark tests that are suitable for benchmarking
databases of any data model.
The Benchmark is comprised of seven individual benchmark operations, defined as follows:
Sequential Scan: serially fetch records from the document table, fetching the title from each, but without performing any pattern match computation on the title.
Database Open: perform all operations necessary to open files, database schema information, etc, but not time to load the application program itself.
Each of these operations is performed a number of times. They
are measured in term of their time response, the elapsed time
between the invocation and run of the operation.
An object oriented operating system is an operating system that has the following characteristics:
Here are some of the advantages of object oriented operating systems:
Here are some of the disadvantages of object oriented operating systems:
It is easy to mistake Windows 95 and Windows NT for object oriented operating systems, but their subsystems are not fully constructed through the framework of classes. Here are three of the most popular distributed object oriented operating systems that are distributed:
Object oriented graphics systems are graphics systems which have
an architecture organized into frameworks of objects that are
hierarchically classified by function and performance. They allow
the user to implement complex graphics programs with the use of
objects and classes (polygon meshes, nurbs, ray shading,…).
They do, however, run quite a bit slower than the implementations
such as in C or assembly language. This is due to the object oriented
frame work.
Here are a few examples of object oriented graphics systems. All of them are built using C++ and Open-GL.
Although great strides have been made in the speed, look, and
feel of systems, little progress has been made in making systems
easy to use. Typical systems today still force the user to interact
with the system at a level of abstraction convenient to the machine,
rather than a level convenient to the user. By capitalizing on
the benefits of the object-oriented paradigm, many of the problems
in traditional systems can be overcome. Here are the most common
Pros and Cons about Object Oriented Systems: