|
|
k
|

PAGE 66

in a series of
articles on ob-
technigues, a
new technology
that is changing
the way pro-
grammers and
com puters.
Object-oriented
programuming
technigues are
becoming gener-
ally available to
programmers and are finding use in
such applications as user interfaces,
word processing, graphics programs and
databases.
— These technigues haven't made a big
impact, on commercial applications,
which usually are slow to embrace the
available technology.

But its inevitable that the tremen-
dous productivity gains of object-orient:
ed technigues soon will be applied in
the commercial environment.

The commercial programming applica-

(on backlog has been attacked with
fourth-generation languages, application
generalors, relational databases and ex-
pert systems.

However, information-systems depart:-
ments are still unable to keep up with
the demand for newer, more powerful
and more complex applications.

The object-oriented paradigm prom-
ises to be a major step toward reducing
the application backlog, but professional
programmers still need tools if they are
lo reap the benefits of object-oriented
technigues.

The languages and applications dis-
cussed in previous articles use memory
lo store objects. When the program has
stopped running, the objects disappear.
The objects defined are specific to each
program and cannot, be used elsewhere
in the system.

But what if the objects were stored
on disks and could be accessed from run
to run? This is exactly what's happen-
ing, and there are a number of such ob-
ject-oriented databases just coming to
market. They promise to vastly decrease
the work needed to solve certain
problems.

The early users of these object-based
database systems are mostly those in-
volved in computer-aided engineering
(CAE), who face complex data-manage-
ment problems.

The data objects they use are complex
shapes that interact with one another.
These objects can be viewed indepen-
dently or as a group. The CAE tool must
be able to store drawing information, re-
trieve it and manipulate it.

These are all database-management
tasks, but the data does not fit easily
into a relational format. Object-oriented
databases provide a way to deal with
this complexity, just as in the graphics
programs | described last, week.
Object-oriented databases are also be-
ng used by people building large docu-
ment-handling systems. Again. the prob-
lem is (he data model. |

The document is mainly text, which

x a RE
jr sn z

does not lend itself to being stored in re-
lational records. But in an object-orient-
ed database, the text, sections and head-
ings are all objects. The interrelation-
ships are modeled in the objects. —

While this isn t relevant for simple
word-processing applications, it can be
important for applications that store
large amounts of text, such as those
that keep track of all of IBM s manuals.

Computer-aided software engineering
(CASE) is another area that can benefit
from an object-oriented database. The is-
sue again is complexity. An object-ori-
ented database helps developers to mod-
el the complex objects and relationships
needed in a CASE environment.

PG WEEKNAPPLIGATION DEV
S APPIJED INTELLIGENCE

OOP Just the Ticketfor Complex Co:

Three Applications Better Suited

ELOPMENT

normalized relational records that are
stored in the database system.
Note, however, that nowhere in the

database system is the concept of an or-

der defined.

Instead, the individual relational
records that make up an order are de-
fined. This is very similar to the prob-
lem with the basic paint, programs de-
seribed last week, in which the program
had no "knowledge" of the shapes, only
of the individual bits on the screen.

In the conventional approach, after
the programmer has defined the normal:
ized database, it is then time to write
the code that manipulates an order. This
might include a guery and an update

To Object-Oriented Databases %
Cornplex interrelationships between data are difficult
to ttandge in a relational itodel.

CASE

Graphical symbols and their Intetrelation-
ships that represent software dešign
are defined as objects.

ma ui A, |
ui "a, k

a ii

Docuieht
Handlihg Systems

| Computek-Aided Engiebting ||

a vs Zda zap Data objects are complex |

shapes that interact.

i
J La
I
k: |
|
L
hi
- di
s v
Pa, i
. ubr« »4
iN sam;
ne: TRE
ri a k
mol bi sd i
l 4
"
7 H a h
al k H
ko biu
4
ipd!
ia
ki

Tekl, sections arid headings ate delined as objects.

John Avakian

The object-oriented paradigm promises to be a major step
toward reducing the application backlog, but professional

programmers still need tools if they are to reap its benefits.

The early acceptance of object-orient:
ed databases for applications with se-
vere data-modeling problems indicates
that such systems bring big benefits.

The same technigues can be brought
to bear on commercial applications in
the future. Consider the current way in
which database applications are de-
veloped. |

The user of a new system describes
some data object, such as an order, to
the systems analyst or programmer. The
user already views the order as an ob-
Ject with associated behaviors, The pro-
grammer then goes through the pains-
taking process reguired to break down
the user s concept of an order into the

procedure. The code must take into ac-
count how updates and gueries for or-

ders access the various records involved .

in the order.

In other words, all of the knowledge
on how to handle an order is stored in
process code and not in the database.

An object-oriented database allows
the complex order object to be built up
from simple forms. The methods for
handling an order are stored in the da-
tabase in the form of properties (data)
and behavior (procedura) mo order re-
sponds to gueries and update messages,
and so it is an object that can be manip-
ulated by the system. The user deals
with a familiar object and manipulates

SEPTEMBER 25, 1989

ercia Programs

t. The programmer deals with a pro-
rami ea! that is closer to the us-
er's view of the world.

Other programmers only need to send
messages to the order object and do not
have to worry about the structure of
the order or the database semantics in-
volved in an update of the order.

New types of orders could easily be
built from the existing order. For exam-
ple, a purchase order is just like a regu-
lar order, except that it has outside ven-
dor information in it as well.

A manufacturing order has details on
how to satisfy the order on the factory
floor, but the basic structure remains
the same.

A Cure for Complexity

Modern applications are reaching the
limits of complexity imposed by rela-
tional-database technology.

One mainframe manufacturing appli-
cation s code handles orders by breaking
them down into approximately 30
record types. The logic for manipulating
the order reguires maintaining the se-
mantic integrity of all those records. The
manufacturing order is just one small
part of the system.

No wonder deadlines are missed, and
the size of the application grows out of
control.

An object-oriented database's ap-
proach to the same problem would
bring this complexity into a more man-
ageable form.

The manufacturing order would prob-
ably be a subclass three to four levels
down in the class hierarchy. It would be
abstracted to the point where it was
easy to handle. If a user wanted to cus-
tomize the software, the changes could
be localized to the object, definition.

Early commercial object-oriented data-
base systems are available on workstatjon
platforms. Servio-Logic (Portland, Ore.),
Ontologic (Billerica, Mass.) and Graphael
(Waltham, Mass.) are three vendors of
object-oriented database systems.

The first system is based on Smalltalk,
an application-development; tool made
by Digitalk Inc. The other two systems
are based on object-oriented C exten-
Slons; in these, the user defines the data-
base as objects in C. When the system
runs, the objects are stored on disk.

These object-oriented extensions are
called persistent object, languages to dis-
tinguish them from the pure languages
from which they were derived. They
also handle such standard database ac-
tivities as storing and acc« data.

Next week [ll begin a series of arti-
cles on the recently announced IBM re-
pository, a significant component of
IBM s application-development strategy FE
for the 19905. gi ke

these articles, pleas me
Martin Report, an information service
updated guarterly, at (800) 2421240.

For information on semžinars, please

contact (in the United States and Can-
ada.) Technology Transfer | nstitute,
74 10th St, Santa, Monica, Calif.
90402 (213) 394-8305. In Europe, con-
tact Savant, 2 New St., Carnforth,
Lancs., LA5 9BX United Kingdom
(0524) 734 505.

ia em ML
pa ui 4 -
i je k — 3
? z ) š nie
pe sn Pa a? $ stal s
h mi A IM m i " k E
o SM a NG
Ožje. casi A NI une K:
d "aa s . ma; Pn S Hale —s ii
o ine gb

p ze
' mila MET ai a izdih ai rala bi a, La ša ge h Me. |
7 ze Ni se a Poj gi si s ij