eberard@ajpo.sei.cmu.edu (Edward Berard) (08/24/89)
I realize that, at present, there may be relatively few Ada applications which require the use of a database management system (DBMS), but I expect the number will grow. For those of you that like to think ahead, consider the ramifications of the following problem: You are about to begin a new development effort. This effort will require some form of a DBMS. You have selected Ada as the development language, and you have decided to use an object-oriented approach to the life-cycle. At some point during development, you realize that your software talks about object and classes, and your DBMS, being relational, doesn't understand these things. At first, you consider constructing an object-oriented interface to the DBMS. However, either the performance degradation introduced by the interface is intolerable, or you don't have the time or the resources to actually go about building the interface. Someone on your staff does a little bit of research and suggests that an object-oriented DBMS (OODBMS) potentially solves your problems. Your overall application now appears consistent, i.e., your software talks about objects and classes, and your DBMS also talks about objects and classes. There is no need to construct an object-oriented interface, and the possibilities of performance degradation is lessened. For the moment, let us ignore the (major) problems of introducing an OODBMS into your organization, e.g., staff training, changing of business practices, and what do you do with all those data modelers. What are you going to do about the following?: 1. Your search turns up a number of OODBMS vendors. However, none of these vendors has an Ada interface to their OODBMS. In fact, you can't seem to find anybody in the Ada community who is working with the OODBMS vendors on the possibility of such an interface. 2. You consider the possibility of writing your own Ada interface to a vendor's OODBMS. However, you soon discover that the vendor has been heavily influenced by C++. C++ has a few things that do not directly map into Ada, and lacks many object-oriented features that Ada provides, e.g., metaclasses. 3. Being in the Ada community you have a (possibly forced) reverence for standards. You discover that there are precious few standards for OODBMS, including such things as a standard query language. This means that you may have a lot of re-writing to do every time you consider switching OODBMS vendors, e.g., you need to go to a platform not currently supported by your OODBMS vendor. 4. You find ways to overcome most of the aforementioned problems, but suppose you are working on a government contract. The government has encouraged you in your choice of an object-oriented approach, but proceeds to throw up a bunch of roadblocks to your use of an OODBMS, e.g., many government standards require the use of a relational DBMS and SQL. I would strongly suggest that members of the Ada community become involved with OODBMS vendors, research, and standardization efforts. If some of you are already involved, and it doesn't violate company policy, it might be very worthwhile to publicize your efforts. [Of course, I assume that the Software Engineering Institute is already doing something with OODBMSs.] It might also be interesting to examine existing and planned government standards to see if they easily allow for the introduction of OODBMSs, and any associated changes in procedures and documentation. [Choice of an OODBMS will also impact such things as the choice of an independent verification and validation (IV&V) contractor, contractor qualifications assessment, and auditing procedures.] For those of you involved with computer aided software engineering (CASE): Many CASE products involve the use of some form of persistent information, and are thus based on some type of (possibly primitive) DBMS. If a CASE tool supposedly supports an object-oriented approach, there are some OODBMS related questions, e.g.: - If the CASE product makes use of some form of DBMS, and claims to truly support an object-oriented approach, there may be some significant performance penalties, and unnecessary complexity if the DBMS is not an OODBMS. - If the CASE product offers external interfaces to DBMSs, can the CASE product interface to an OODBMS. Discussions of these, and other, OODBMS issues are taking place with increasing frequency outside of the Ada community. I strongly believe that the Ada community needs more visibility and involvement with OODBMS issues. -- Ed Berard (301) 353-9652
tking@SRC.Honeywell.COM (Tim King) (08/26/89)
In article <560@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes: > I would strongly suggest that members of the Ada community become > involved with OODBMS vendors, research, and standardization efforts. There is a (relatively) new standards group that interested parties should consider. I'm not sure of this group's *exact* lineage/title/affiliations, but I believe it's something like: "The Object-Oriented Database Task Group of the ASC X3/SPARC Database Systems Study Group". The three stated objectives of this group (taken from a draft Plan and Organization document) are: 1) To establish a working definition for the term "Object-Oriented Database". 2) To establish the relationship between object-oriented database technology and object-oriented methods and technology from other fields, including programming languages, user interface methodologies, and information modeling methodologies. 3) To establish a framework for future data management standards activities, both extensions to ongoing SQL and IRDS development, and related future standards. If you're interested, contact: Tim Andrews Ontologic, Inc. 47 Manning Road Billerica, MA 01821 or Elizabeth Fong NIST Bldg. 225, Room A266 Gaithersburg, MD 20899 > If some of you are already involved, and it doesn't violate company > policy, it might be very worthwhile to publicize your efforts. [Of > course, I assume that the Software Engineering Institute is already > doing something with OODBMSs.] Over the past three years, we (at Honeywell SRC) have been developing a system called "Gaia". Gaia is an object-oriented framework for integrating engineering tools and data into comprehensive development enviroments. It is implemented entirely in Ada. One of Gaia's major components is an object management system to which we provide an extensible, OO, Ada interface. If anyone is interested, I have some outdated papers we've published. I'd also be glad to give more current details via email. ---------------------------------------------------------------------- Tim King | Honeywell Systems & Research Center | Are we having fun yet? Mpls, MN 55418 |
sommar@enea.se (Erland Sommarskog) (08/26/89)
Edward Berard (eberard@ajpo.sei.cmu.edu) writes: > At some point during development, you realize that your > software talks about object and classes, and your DBMS, being > relational, doesn't understand these things. Seems OK to me. Since Ada hardly can be said to be a object- oriented langauge it's 1-1. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se The law of gravity should be forbidden execpt in downhills.