| V | I Pace 66 This is the last in a series of articles on ob- Ject-oriented technigues, a new technology that is changing the wajj pro- grammers and users deal with computers. Object-oriented programming 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 it's inevitable that the tremen- dous productivity gains of object-orient: ed technigues soon will be applied in the commercial environment. The commercial programming applica- tion 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 to reap the benefits of object-oriented technigues. The languages and applications dis- cussed in previous articles use memory to slore 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- Jjectoriented 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- ing used by people building large docu- ment-handling systems, Again, the prob- lem is (he data model. The document, is mainly text, which PG WEEKNAPPLIGATION DEVELOPMENT APPLIED INTELLIGENCE OOP Justthe Ticket for Complex Commercial Programs does not lend itself to being stored in re- lational records. But iri 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 bbject-ori- ented database helps developers to mod- el the complex objects and relationships needed in a CASE environment. normalized relational records that are stored in the database system. Note, however, that nowhere in the database system is the concept of an or- defined. end 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- scribed last week, in which the program had no "knowledge" of the shapes, only of the individual bits on the screen. In the conventional a dsinoni after the programmer has defin ee normal- ipad database, it is then time to write the code that manipulates an order. This might include a guery and an update Three Applications Bettet Suited To Object-Oriented Databases Coriplex interrelationships between data are difficutt to inanage in a relational inodel, CASE Graphical symbols and their Interrelation- ships that represent soflwate dešign are defined as objects. Document Handlihg Systems Computet-Aided Engine: Data'oblects are complex || shapes that interact. | 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 Aueries for or- ders access the various records involved in the order. ; i 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 (procedures). The 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 i e programmer deals with a pro- ane odet 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 workstation 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 Smalitalk, an application-development tool made by Digitalk Inc. The other two systems are based on object-oriented C exten- sions; 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 accessing data. Next week [ll begin a series of arti- cles on the recently announced IBM re- A pnt: Hi zoinani component of s application-development, st for the 1990s. a mob ze To learn more about the subject of these articles, please call The James Martin Report, an information service updated guarterly, at (800) 242-1240, For information on seminars, please contact (in the United States and Can- ada) Technology Transfer Institute, 741 10th St, Santa. Monica, Calif. 90402 (213) 394-8305. Im Europe, con- tact Savant, 2 New St. Carnforth, Lancs., LA5 9BX United Kingdom (0524) 735 505.