home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / object-faq / part5 < prev    next >
Text File  |  1996-04-05  |  52KB  |  1,387 lines

  1. Newsgroups: comp.object,comp.answers,news.answers
  2. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!howland.reston.ans.net!newsfeed.internetmci.com!ncar!uchinews!news
  3. From: Bob Hathaway <rjh@geodesic.com>
  4. Subject: Comp.Object FAQ Version 1.0.9 (04-02) Part 5/13
  5. X-Nntp-Posting-Host: ford.uchicago.edu
  6. Message-ID: <Dp9qCu.AFE@midway.uchicago.edu>
  7. Followup-To: comp.object
  8. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  9. Sender: news@midway.uchicago.edu (News Administrator)
  10. Organization: Geodesic Systems
  11. References: <Dp9prv.92t@midway.uchicago.edu>
  12. Date: Wed, 3 Apr 1996 04:12:30 GMT
  13. Approved: news-answers-request@MIT.Edu
  14. Lines: 1370
  15. Xref: senator-bedfellow.mit.edu comp.object:46932 comp.answers:17964 news.answers:68637
  16.  
  17. Archive-name: object-faq/part5
  18. Last-Modified: 04/02/96
  19. Version: 1.0.9
  20.  
  21. [Stroustrup 91] Stroustrup, B.  The C++ Programming Language (2nd edition).
  22.  
  23.   Has the ARM, better reference for the use of C++ (recommended by bs).
  24.   Contains sections on object-oriented software engineering.
  25.  
  26. [Tasker 93]  Dan Tasker.  The Problem Space, Practical Techniques for
  27.   Gathering & Specifying Requirements. ISBN: 0-646-12524-9.  Avail only from
  28.   author, dant@swdev.research.otc.com.au.
  29.  
  30.   Object-oriented requirements definition.  Hypertext.  Uses Rumbaugh's OMT as
  31.   a base.  See also APPENDIX D.
  32.  
  33. [Ungar 87] D. Ungar and R.B. Smith.  The Self Papers. [Entry To Be Completed]
  34.  
  35.   The documents on Self; a delegation/prototyping language.  Also covers Self
  36.   implementation and optimization.  See also APPENDIX E, PAPERS section.
  37.  
  38. [Wasserman 90] A.I. Wasserman et al. The Object-Oriented Software Design
  39.  Notation for Software Design Representation. IEEE Computer, 23(3).
  40.  
  41.   Presents the Object-Oriented Structured Design (OOSD) OOSE methodology.
  42.   Traditional structured techniques to OO, hybrid containing structured
  43.   design and Booch.
  44.  
  45. [Wegner 87] Peter Wegner. "Dimensions of Object-Based Language Design",
  46.   Proceedings of OOPSLA '87, October 4-8 1987, SIGPLAN Notices
  47.   (Special Issue), V22, No 12, pp168-182, 1987.
  48.  
  49. [Wikstrom 87] Ake Wikstrom.  Functional Programming Using Standard ML.
  50.  Prentice Hall, ISBN 0-13-331661-0, 1987.
  51.  
  52.   ML reference.
  53.  
  54. [Wilkie 93] George Wilkie. Object-Oriented Software Engineering - The
  55.  Professional Developer's Guide. Addison Wesley.
  56.  
  57.   Covers OOSE, 11 popular analysis and design methodologies with examples,
  58.   comparisons, and analysis, information systems (OODB), and case studies.
  59.  
  60. [Winter Partners]  Winter Partners 
  61.  
  62.   A proprietary toolset (OSMOSYS) for OOA and OOD.
  63.   Winter Partners
  64.     London Office:                 Zurich Office:
  65.       West Wing, The Hop Exchange
  66.       24a Southwark Street           Florastrasse 44
  67.       London SE1 1TY                 CH-8008 Zurich
  68.       England                        Switzerland
  69.       Tel. +44-(0)71-357-7292        Tel. +41-(0)1-386-95 11
  70.       Fax. +44-(0)71-357-6650        Fax. +41-(0)1-386-95 00
  71.  
  72. [Wirfs-Brock 90] Rebecca Wirfs-Brock, Brian Wilkerson, Lauren Wiener.
  73.  Designing Object Oriented Software, Englewood Cliffs, NJ. Prentice Hall.
  74.  
  75.   Presents a "Responsibility Driven Design" (RDD) with "Class, Responsibility,
  76.   Collaboration" (CRC) technique, a modern and new OOA/OOD methodology.
  77.  
  78. [Yaoqing 93]  Gao Yaoqing and Yuen Chung Kwong.  A Survey of Implementations
  79.  of Parallel, Concurrent, and Distributed Smalltalk.  ACM SIGPLAN Notices.
  80.  Vol 28, No. 9, Sept 93.
  81.  
  82.   Covers implementations of Parallel, Concurrent, and Distributed Smalltalk.
  83.  
  84. [Yourdon 92]  Edward Yourdon.  Decline and Fall of the American Programmer.
  85.  YPCS.
  86.  
  87.   Excellent coverage of modern software engineering practice and world-class
  88.   software development organizations.
  89.  
  90.  
  91.  
  92. APPENDICES
  93. ==========
  94.  
  95.  
  96. APPENDIX A  VIPS
  97. ================
  98.  
  99. These are individuals whose names appear in comp.object most often. 
  100. Please send recommendations for *major* VIPS often cited or referenced.
  101.  
  102. Booch, Grady <egb@rational.com>
  103. -------------------------------
  104.  
  105. Grady Booch has been an object- based/oriented advocate for some time.  He's
  106. written books such as Software Engineering with Ada [Booch 87], Software
  107. Components with Ada [Booch 87b], and OOA/D with Applications [Booch 91, 94].
  108. His latest notations are often referred to as simply the "Booch" method or
  109. notation and he is Chief Scientist at Rational, a company providing training
  110. and automated support for the method with a tool named "Rose" (See Appendix D).
  111. The Booch method now incorporates many modern methods, including OMT, and Dr.
  112. Rumbaugh has recently joined forces with Grady at Rational.
  113.  
  114.  
  115. Cox, Brad
  116. ---------
  117.  
  118. Founder of Objective-C, which grafts the Smalltalk facilities of an
  119. Object id and a messaging mechanism onto C.  Author of [Cox 87].
  120.  
  121.  
  122. Goldberg, Adele  (Alan Kay, Dan Ingalls)
  123. ----------------------------------------
  124.  
  125. One of the founders of Smalltalk (with Alan Kay and Dan Ingalls).  Coauthor
  126. of [Goldberg 83, ??], "Smalltalk-80 The Language and its Implementation".
  127. Smalltalk was invented by a group at Xerox PARC; and a spinoff, ParcPlace, is
  128. now marketing Smalltalk environments (see APPENDIX C).
  129.  
  130.  
  131. Meyer, Bertrand <bertrand@eiffel.com>
  132. -------------------------------------
  133.  
  134. Founder of Eiffel, author of [Meyer 88].  Often posts to comp.lang.eiffel
  135. and comp.object [what a FAQ writer notices].  His company, Interactive
  136. Software Engineering, has a case tool called EiffelCase (see APPENDIX D).
  137.  
  138.  
  139. Nygaard, Kristen (and Dahl, Ole-Johan)
  140. --------------------------------------
  141.  
  142. Inventor of Simula, the first object-oriented programming language.  Also
  143. inventor of object oriented design, for which Simula-67 was considered an
  144. implementation technique.  Now B.B. Kristensen, O.L. Madsen, B. Moller-
  145. Pedersen, and K. Nygaard are working on BETA, their successor to Simula.
  146.  
  147.  
  148. Rumbaugh, Dr. James
  149. -------------------
  150.  
  151. Part of Rumbaugh, Blaha, Premerlani, Eddy and Lorenson, the authors of
  152. [Rumbaugh 91].  They all work for GE Corporate Research and Development Center
  153. in Schenectady New York (See below) and have an OOA/OOD notation/methodology
  154. called the "Object Modeling Technique" (OMT).  It is a rather formal and
  155. complete method often discussed in comp.object.  OMTool is the name of the
  156. CASE system provided by Martin Marietta which supports OMT.  See APPENDIX D.
  157.  
  158. Recently, Dr. Rumbaugh has joined forces with Chief Scientist Grady Booch at
  159. Rational: Rumbaugh@rational.com 
  160.  
  161.  
  162. Shlaer, Sally (and Mellor, Stephen J.)
  163. --------------------------------------
  164.  
  165. >Sally Shlaer            sally@projtech.com
  166. >Project Technology      Training and Consulting using Shlaer-Mellor OOA/RD
  167. >Berkeley, CA            (510) 845 1484
  168. Also: steve@projtech.com
  169.  
  170. Cofounder of the Shlaer/Mellor OOA/RD method, president of Project Technology.
  171. As shown above, occasionally posts to comp.object [what a FAQ writer notices].
  172.  
  173.  
  174. Stroustrup, Bjarne (bs@alice.att.com)
  175. -------------------------------------
  176.  
  177. Inventor of C++, a C superset, which has probably gained the most widespread
  178. use of any object-oriented language today.  Often found in comp.lang.c++ and
  179. comp.object.
  180.  
  181.  
  182. APPENDIX B  OBJECT-ORIENTED DATABASES AND VENDORS
  183. =================================================
  184.  
  185. This is a list of available Object-Oriented databases.  Thanks go to Stewart
  186. Clamen, who's survey on schema evolution provided a good start.  The list
  187. was updated March 1996 by Tim Harvey who keeps the mini-FAQ of object and
  188. object-relational vendors for the sister News group comp.object.databases. 
  189.  
  190. Additional short entries and corrections are encouraged; please send them 
  191. to the author of the FAQ or Tim Harvey at:
  192.  
  193. Email:  timh@plaza.ds.adp.com
  194.     rwi@teleport.com
  195.     Voice:  (503) 294-4200, Ext. 3313
  196.  
  197. The most recent copy of Stewart Clamen's summary on available databases
  198. support for schema evolution will be available indefinitely via anonymous
  199. FTP from BYRON.SP.CS.CMU.EDU:/usr/anon/OODBMS/evolution-summary.
  200.  
  201. [Kim 89] covers a few of the research systems below in depth.
  202.  
  203. Starred entries also have an entry in "APPENDIX E  ANONYMOUS FTP SITES".
  204.  
  205. See also section 3.5 for an Object Database Management Group (ODMG) reference.
  206.  
  207.  
  208. TABLE OF CONTENTS
  209.  
  210. Extended Relational Database Model
  211.  Research Systems
  212.   POSTGRES*     [marketed by Montage]
  213.   Starburst     [IBM almaden, entry NYI]
  214.  Commercial Systems
  215.   Illustra
  216.   Montage       [Research System POSTGRES]
  217.   Omniscience ORDBMS
  218.   Raima Database Manager/Velocis/Raima Object Manager
  219.   Total ORDB    [Cincom Systems]
  220.  
  221. Object-Oriented Data Model
  222.  Research Systems
  223.   AVANCE
  224.   CLOSQL
  225.   ConceptBase*
  226.   COOL/COCOON
  227.   Encore*
  228.   Exodus*
  229.   Machiavelli
  230.   MOOD4-PC*
  231.   OBST/STONE*
  232.   Ode*
  233.   Oggetto
  234.   Orion [marketed as ITASCA, see Entry]
  235.   OTGen
  236.   PLOB
  237.   VODAK
  238.  Commercial Systems
  239.   ArtBASE
  240.   EasyDB (Basesoft Open Systems, Sweden)
  241.   GemStone
  242.   IDB Object Database
  243.   ITASCA
  244.   Matisse
  245.   NeoAccess
  246.   OBST+
  247.   O2
  248.   Objectivity/DB
  249.   ObjectStore
  250.   Ontos [formerly VBase]
  251.   Odapter/OpenODB program (HP)
  252.   OOFILE
  253.   Phyla
  254.   POET
  255.   Statice
  256.   UniSQL
  257.   Unisys Universal Repository
  258.   Versant
  259.   VisualWorks
  260.  
  261. Other Models
  262.  Research Systems  
  263.   GRAS*
  264.   IRIS
  265.  Commercial Systems  
  266.   IDL
  267.   Kala
  268.   Pick
  269.  
  270. Interfaces
  271.  Research Systems
  272.   Penguin
  273.  Commercial Systems
  274.   AllegroStore (Franz)
  275.   DBTools.h++
  276.   Object Gateway
  277.   Persistence
  278.   Subtleware
  279.   Synchronicity (Smalltalk)
  280.  
  281.  
  282. EXTENDED RELATIONAL DB MODEL
  283. ----------------------------
  284.  
  285. Research Systems
  286. ________________
  287.  
  288.  
  289. > POSTGRES (Berkeley)
  290.  
  291. POSTGRES is an extended-relational database manager that supports
  292. inheritance, user-defined types, functions, and operators, ad-hoc
  293. queries, time travel, a rules system, tertiary storage devices,
  294. and very large typed objects, among other things.  POSTGRES speaks
  295. postquel, a derivative of the quel query language originally
  296. designed at berkeley for the ingres database system.  User functions
  297. may be written in C or in postquel.  C functions will be dynamically
  298. loaded into the database server on demand, and either kind of function
  299. may be executed from the query language.
  300.  
  301. POSTGRES and the papers that describe it are available free of charge
  302. from toe.CS.Berkeley.EDU (128.32.149.117) in directory pub/postgres.
  303. The code is stored in a directory named after the latest release; at
  304. the time of this writing, that directory is postgres-v4r1.  The list
  305. of officially-supported ports is short (decstations running ultrix 4.x
  306. and sparcstations).  Unofficially, many more are supported -- people
  307. elsewhere have done the ports and distribute their versions of the
  308. code.  The list of unofficial ports is available in pub/postgres as
  309. file UNOFFICIAL-PORT-LIST.
  310.  
  311. On Type Evolution:
  312. You ask explicitly about type evolution.  We support schema
  313. modification on all classes, including user classes.  This means that
  314. you can add attributes (instance slots) and methods at any time.
  315. Further, since postgres is a shared database system, such changes are
  316. instantly visible to any other user of the class.
  317.  
  318. The language syntax supports attribute deletion, but the system won't
  319. do it yet.  Since all data is persistent, removing attributes from a
  320. class requires some work -- you need to either get rid of or ignore
  321. all the values you've already stored.
  322.  
  323. Contact:
  324. Paul Aoki <aoki@cs.berkeley.edu>
  325.  
  326. The postgres code from uc berkeley is being commercialized by
  327. Miro Systems, Inc.        [This seems to have been updated to Montage]
  328.  
  329. Contact:
  330.   paula hawthorn (paula@miro.com) 
  331.   dave segleau (dave@miro.com)
  332.  
  333.  
  334. Commercial Systems
  335. ------------------
  336.  
  337. > Illustra
  338.  
  339. Illustra Information Technologies Ltd.
  340.  
  341. Illustra is an Object-Relational Database Management System (ORDBMS).  It
  342. supports SQL-3 and standard relational syntax and operations on tables.
  343. In addition, programmers may define new classes and methods inside the
  344. database server, and use them from client programs.  Customers may build
  345. their own class extensions, or purchase extensions called DataBlades
  346. from Illustra and its partners.  Illustra offers a wide collection of
  347. DataBlade modules, including time series support, spatial data handling,
  348. web publishing, document management, video and image support, and others.
  349.  
  350. Illustra originated from Postgres.
  351.  
  352. NOTE: Can use with Visual Basic.
  353.  
  354.  
  355. Illustra Information Technologies, Inc.
  356. 1111 Broadway Suite 2000
  357. Oakland, CA  94607
  358. U.S.A.
  359.  
  360. Voice: (510) 652 8000
  361. Fax:   (510) 869 6388
  362. Email: info@illustra.com
  363.        sales@illustra.com
  364.        resellers-info@illustra.com
  365.        training-info@illustra.com
  366. Web:   http://www.illustra.com    Note: This web server uses Illustra
  367.                                         OODBMS for backend.
  368. Ftp:   ftp://ftp.illustra.com
  369.  
  370. Illustra Information Technologies Ltd.
  371. 150 Minories
  372. London  EC3N 1LS
  373. United Kingdom
  374. Voice: 0171-264-2185
  375. Fax:   0171-264-2193
  376. Email: 100436.1264@compuserve.com
  377.  
  378.  
  379. > Montage (ORDBMS) [Research System POSTGRES]
  380.  
  381. >From: markh@montage.com (Mark Helfen)
  382. Subject: Montage Database - brief product announcement
  383. Followup-To: sales@montage.com 
  384. Organization: Montage Software, Inc.
  385. Date: Wed, 10 Nov 1993 23:05:03 GMT
  386.  
  387. The Montage object-relational database management system 
  388. (ORDBMS) is now available from Montage Software, Inc. 
  389.  
  390. The Montage object-relational database management system 
  391. includes the Montage Server(tm) database engine, the Montage 
  392. Viewer(tm) -- a new visualization tool that simplifies queries of 
  393. complex data -- and Montage DataBlades(tm), specialized modules 
  394. that extend the capabilities of the database for specific applications.  
  395. Montage represents the commercialization of the seven-year 
  396. POSTGRES research project.   
  397.  
  398. The Montage Server extends the relational database model through 
  399. its ability to handle complex information, and the inclusion of object-
  400. oriented facilities and capabilities.  It uses the familiar relational row-
  401. column metaphor for all data, so that text, numbers and complex data 
  402. are all viewed, managed, manipulated and queried the same way.   
  403. The relational metaphor is extended to allow data of any size and 
  404. complexity to be stored and accessed in the way that is most 
  405. effective.   SQL, used to access and manage data, is extended with 
  406. SQL3-based capabilities to allow the definition of user data types and 
  407. functions.
  408.  
  409. The Montage Viewer uses visualization technology to organize 
  410. information in visual terms -- by location, shape, color and intensity, 
  411. for example.  Similar to a "flight simulator," the Montage Viewer allows 
  412. the user to visually navigate through data, refining each step by 
  413. "panning" and "zooming" with a mouse.  
  414.  
  415. A DataBlade is a combination of data types and functions that are 
  416. designed to support a specific application.   Text, Spatial, and Image 
  417. are the first of many DataBlades that will comprise a full-range of 
  418. industry-specific products created by Montage, third parties and 
  419. users based upon their own expertise.    
  420.  
  421. o     The Text DataBlade expands the database's functionality by 
  422. adding new data types and functions that manage text and document 
  423. libraries, as well as a providing a new access method (Doc-Tree) 
  424. which provides exceptional search performance for text.  
  425.  
  426. o     The Image DataBlade supports image conversion, storage, 
  427. manipulation, enhancement and management of more than 50 image 
  428. formats, and performs automatic conversion of formats at the user's 
  429. discretion.  
  430.  
  431. o     Points, lines, polygons and their spatial relationships are now 
  432. supported in the relational model with the Spatial DataBlade.  The 
  433. DataBlade defines nine basic spatial types and makes over 200 SQL 
  434. functions available for use on spatial data, as well as supports the 
  435. R-Tree access method for high speed navigation of spatial data.    
  436.  
  437. Montage Software was co-founded by Gary Morgenthaler of 
  438. Morgenthaler Ventures and Dr. Michael Stonebraker of the University 
  439. of California, Berkeley, .  Morgenthaler is Montage Software's 
  440. chairman of the board and Stonebraker serves as the company's 
  441. chief technology officer.    Morgenthaler and Stonebraker co-
  442. founded Ingres Corporation (then called Relational Technology, 
  443. Inc.), in 1980.    
  444.  
  445. FOR ADDITIONAL INFORMATION:
  446.  
  447. Montage Software Inc. can be contacted at:
  448.  
  449. email:                        sales@montage.com
  450. phone:                        (510) 652-8000
  451. fax:                          (510) 652-9688
  452.  
  453. Mailing Address:
  454.  
  455. Montage Software, Inc.
  456. 2000 Powell Street, Suite 1405
  457. Emeryville, CA  94608
  458.  
  459.  
  460. > Omniscience ORDBMS
  461.  
  462. Omniscience Object Technology, Inc.
  463.  
  464. Omniscience ORDBMS is a light weight scalable database managment system
  465. with a very small footprint suitable for small systems such as notebook
  466. computers running Microsoft Windows.  It is built on top of a compact
  467. object kernal that supports programs written in SQL and Object-Oriented
  468. programming languages.  Available for most platforms.  Single user
  469. version costs $99.
  470.  
  471. Omniscience Object Technology, Inc.
  472. 3080 Olcott Street, Suite 100-C
  473. Mountain View, CA  95054
  474. U.S.A.
  475.  
  476. Voice: (408) 562-0799
  477. Fax:   (408) 562-0757
  478. Email: info@oot.com
  479.  
  480.  
  481. > Raima Database Manager/Velocis/Raima Object Manager
  482.  
  483. Raima Corporation
  484.  
  485. Offer the Raima Database Manager and Velocis as well as Raima Object
  486. Manager, a C++ programming interface/class library that lets developers
  487. interface their application with a Raima embedded database engine.
  488.  
  489. Raima Database Manager (formerly db_VISTA) is a very efficient high
  490. performance database engine for C and C++ developers.  The proven C-API
  491. includes over 200 functions for database manipulation and control.
  492. Available with source, RDM supports combined relation and network model
  493. database designs, transaction processing, and portability.  Single-user
  494. versions start at $595, and multi-user versions begin at $1995.
  495.  
  496. Velocis is an embeddable high performance, SQL client/server database
  497. engine for C and C++ programmers.  It provides high through-put
  498. transaction processing, support for multiple API's and compliance with
  499. industry standards including ANSI SQL, Microsoft ODBC, and SAG CLI.
  500. Several unique features support development of very high performance,
  501. scalable applications.  Velocis is available for Windows, Windows NT,
  502. Netware, OS/2, SCO, HP/UX, Solaris, and AIX.  Prices start at $595 for
  503. Windows Standalone.
  504.  
  505. Raima Object Manager is a class library that encapsulates object storage
  506. and database navigation into C++ class definitions to provide a consistent,
  507. object oriented interface to Velocis or Raima Database Manager.  Combined,
  508. Raima Object Manager and Velocis provide a comprehensive feature set for
  509. your object oriented C++ database development.  Includes source and
  510. supports popular operating systems.  Priced at $495.
  511.  
  512.  
  513. Raima Corporation
  514. 1605 N.W. Sammamish Road
  515. Issaquah, WA 98027
  516. U.S.A.
  517.  
  518. Toll Free: 1-800-327-2462
  519. Direct:    (206) 557-0200
  520. Email:     dmorse@raima.com
  521. Web:       http://www.raima.com
  522.  
  523.  
  524. > Total ORDB
  525.  
  526. Cincom Systems, Inc. produce Total ORDB, a integrated set of object
  527. technology software products and services.  Features include an 
  528. object-relational data model, ANSI SQL with object-oriented extensions.
  529. Cost ranges from $2,400-$60,000 depending in usage.
  530.  
  531. The TOTAL ORDB that CINCOM markets is a re-badged version of the UniSQL
  532. product, but there is a long-term technology agreement betwen the two
  533. organizations that will allow improvements made by one to the product
  534. to be shared with the other.
  535.  
  536. Cincom Systems also produce TOTAL FrameWork, a business application
  537. development environment that integrates an object-relational database,
  538. object develoment tools and workflow automation tehncology.
  539.  
  540. Cincom Systems, Inc.
  541. Cincinnati, OH
  542. U.S.A.
  543.  
  544. Voice: (513) 662-2300
  545. Email: info@cincom.com
  546. Web:   http://www.cincom.com/
  547.  
  548.  
  549.  
  550. OO DATA MODEL
  551. -------------
  552.  
  553. Research Systems
  554. ________________
  555.  
  556. > AVANCE (SYSLAB)
  557.  
  558. An object-oriented, distributed database programming language.  Its
  559. most interesting feature is the presence of system-level version
  560. control, which is used to support schema evolution, system-level
  561. versioning (as a way of improving concurrency), and objects with their
  562. own notion of history.  System consists of programming language (PAL)
  563. and distributed persistent object manager. 
  564.  
  565. REFERENCES: 
  566.         Anders Bjornerstedt and Stefan Britts. "AVANCE: An
  567.         Object Management System".  Proceedings of OOPSLA88.
  568.  
  569.  
  570.  
  571. > CLOSQL (University of Lancaster)
  572.  
  573. Status:-
  574. CLOSQL is a research prototype OODB designed primarily for prototyping 
  575. various schema evolution and view mechanisms based on class versioning.
  576. The system is built using CommonLISP. It would really only be of interest
  577. to other parties as a research tool.
  578.  
  579. Requirements:-
  580. Common LISP including CLOS standard. The Graphical user interface requires
  581. the Harlequin LispWorks Tool-kit. The system was built on a Sun4 and
  582. has not been tested on any other platform.
  583.  
  584. Features:-
  585. As a prototype, CLOSQL is not robust enough to sell. The system is single
  586. user and does not properly support persistence - that is, the data has to
  587. be loaded and saved explicitly. The query language is quite good 
  588. making good use of the functional nature of the environment. 
  589. Methods (LISP and query language only), class versioning and
  590. multiple inheritance are all supported in the data model. Type checking
  591. information is held in the database, but is NOT enforced at present. The
  592. GUI is notable for its support for schema evolution, but otherwise rather
  593. ordinary.
  594.  
  595. Availability:-
  596. Probably freely available, but as the project was part funded by an
  597. industrial partner, some consultation with them would be necessary before
  598. the system could be released.
  599.  
  600. References:-
  601. [1]  Monk, S. R. and I. Sommerville, "A Model for Versioning of Classes 
  602. in Object-Oriented Databases", Proceedings of BNCOD 10, Aberdeen. 
  603. pp.42-58. 1992.
  604.  
  605. [2]  Monk, S. "The CLOSQL Query Language". Technical report No. SE-91-15. 
  606. Computing Dept, Lancaster University, Lancaster, LA1 4YR, UK. 1991.
  607.  
  608. [3]  Monk, S., "A Model For Schema Evolution In Object-Oriented Database 
  609. Systems", PhD thesis, Dept of Computing, Lancaster University, Lancaster
  610. LA1 4YR, UK. 1992.
  611.  
  612. On Schema evolution (from original survey):
  613. CLOSQL implements a class versioning scheme (like ENCORE), but employs a
  614. conversion adaptation strategy.  Instances are converted when there is a
  615. version conflict, but unlike ORION and GemStone, CLOSQL can convert instances
  616. to older versions of the class if necessary.
  617.  
  618.         Aberdeen, Scotland. July, 1992.
  619.  
  620. Contacts;
  621. Simon Monk:      srm@computing.lancaster.ac.uk
  622. Ian Sommerville: is@computing.lancaster.ac.uk 
  623.  
  624.  
  625. > ConceptBase - A Deductive Object Manager for Meta Data Bases
  626.  
  627. ConceptBase is a multi-user deductive object manager mainly 
  628. intended for conceptual modeling and the coordination of design 
  629. environments. The system implements a dialect of Telos which 
  630. amalgamates properties of deductive and object-oriented languages. 
  631.  
  632. Key features are 
  633.  
  634.    hybrid representation with frame-like objects, 
  635.    semantic nets and logical specifications 
  636.  
  637.    unlimited extensibility by metaclass 
  638.    hierarchies (useful for IRDS, schema evolution etc.) 
  639.  
  640.    deductive rules & integrity constraints 
  641.  
  642.    queries as classes with membership constraints 
  643.  
  644.    persistent object management with the ability to interrogate 
  645.    past states of the database 
  646.  
  647. ConceptBase follows a client-server architecture. Client programs 
  648. can connect to the ConceptBase server and exchange data via 
  649. interprocess communication. The X11-based ConceptBase user 
  650. interface offers a palette of graphical, tabular and textual tools 
  651. for editing and browsing the object base. The ConceptBase 
  652. programming interface allows the users to create their own 
  653. client programs in C or Prolog. 
  654.  
  655. The system can be obtained for free from ftp.informatik.rwth-aachen.de in 
  656.       /pub/CB/CB_3.2.4 (released 26-Apr-1994 for Sun/SPARC, SunOS 4.1.3) 
  657.       /pub/CB/CB_3.3 (released 26-Apr-1994 for Sun/SPARC, Solaris 2.3) 
  658. Both versions are functionally equivalent. They only differ in the 
  659. operating system platform.Please read file /pub/CB/doc/InstallationGuide 
  660. (resp. /pub/CB/doc/InstallationGuide_3.2.4) before downloading the software. 
  661. For running the ftp version you must ask for a key by email.
  662.  
  663. Contact
  664. ConceptBase-Team
  665. RWTH Aachen - Informatik V
  666. D-52056 Aachen - Germany
  667.  
  668. Tel./Fax: +49-241 80 21 501 / +49-241-8888321
  669. email: CB@picasso.informatik.rwth-aachen.de 
  670. href="http://www.informatik.rwth-aachen.de/I5/CBdoc/cbflyer.html"
  671.  
  672.  
  673. > COOL/COCOON (Ulm Universitaet)
  674.  
  675. The COCOON project was intended to extend the concepts and the
  676. architecture of relational database management systems (DBMSs) beyond
  677. nested relational to object-oriented ones. Based upon the nested
  678. relational DBMS kernel DASDBS, we have built a prototype implementation
  679. of the COCOON model. Key characteristics of COCOON are: generic,
  680. set-oriented query and update operators similar to relational algebra
  681. and SQL updates, respectively; object-preserving semantics of query
  682. operators, which allows for the definition of updatable views; a
  683. separation of the two aspects of programming language "classes": type
  684. vs. collection; predicative description of collections, similar to
  685. "defined concepts" in KL-One--like knowledge representation
  686. languages; automatic classification of objects and views (positioning
  687. in the class hierarchy); physical clustering of subobjects via the use
  688. of nested relations as the internal storage structures; support for the
  689. optimization of both, the physical DB design and query transformation,
  690. by corresponding optimizers.
  691.  
  692. Project goals are:
  693.  
  694. - to develop a general formal framework for investigations of all
  695.   kinds of schema changes in object-oriented database systems
  696.   (including schema design, schema modification, schema tailoring, and
  697.   schema integration);
  698. - to find implementation techniques for evolving database schemas,
  699.   such that changes on the logical level propagate automatically to
  700.   adaptations of the physical level (without the need to modify all
  701.   instances, if possible).
  702.  
  703. In their current paper [see below], schema evolution is used as
  704. example of a general framework for change in OODBs, supporting change
  705. on three levels of database objects: data objects, schema objects, and
  706. meta-schema objects.
  707.  
  708. Contact: Markus Tresch <tresch@informatik.uni-ulm.de>
  709.  
  710.  
  711. REFERENCES:
  712.         M. Tresch and M.H. Scholl. "Meta Object Management
  713.         and its Application to Database Evolution."  In
  714.         _Proceedings of the Eleventh International
  715.         Conference on the Entity-Relationship Approach",
  716.         Karlsruhe, Germany, Oct 1992.  Springer Verlag (to
  717.         appear).
  718.  
  719.  
  720.  
  721. > Encore (Brown University)
  722. email:bpe@browncs.brown.edu
  723.  
  724. Encore is an object-oriented database system targeted at large scale
  725. software engineering applications which are involved in data modeling.
  726. It was developed at Brown University in the late 1980s.  It is notable
  727. for its special support for long-lived (ie. cooperative) transactions,
  728. popular in design applications, and its support for class versioning.
  729. Objects are never converted, rather, classes are versioned, and the
  730. user can specify filters to make old-style instances appear as new
  731. instances to new applications (and vice versa).
  732.  
  733.  
  734. References/Additional Information:
  735.  
  736.  [] Mary F. Fernandez. OBSERVER: A storage system
  737.     object-oriented applications. Technical Report CS-90-27,
  738.     Brown University, Providence, RI, 1990.
  739.  
  740.  [] Mark F. Hornick and Stanley B. Zdonik. A shared, segmented
  741.     memory system for an object-oriented database. ACM
  742.     Transactions on Office Information Systems, 5(1):70--95,
  743.     January 1987.
  744.  
  745.  [] Andrea H. Skarra and Stanley B. Zdonik. Type evolution in an
  746.     object-oriented database. In Research Directions in
  747.     Object-Oriented Programming, MIT Press Series in Computer
  748.     Systems, pages 393--415. MIT Press, Cambridge, MA, 1987. An
  749.     early version of this paper appears in the OOPSLA '86
  750.     proceedings.
  751.  
  752.  [] Andrea H. Skarra and Stanley B. Zdonik. Concurrency control
  753.     for cooperating transactions in an object-oriented database.
  754.     In Won. Kim and Frederick H. Lochovsky, editors,
  755.     Object-Oriented Concepts, Databases and Applications.
  756.     Addison-Wesley, Reading, MA, 1989.
  757.  
  758. FTP: Complete source can be found in wilma.cs.brown.edu/pub/encore.tar.Z
  759. See also APPENDIX E.
  760.  
  761.  
  762. > Exodus (University of Wisconsin)
  763.  
  764. EXODUS is a DBMS from the University of Wisconsin.  An overview,
  765. excerpted from the abstract of [CDG+90] reads:
  766.  
  767.     EXODUS,   an   extensible database    system  project that is
  768.     addressing  data management problems  posed  by  a variety of
  769.     challenging new applications.  The  goal of the project is to
  770.     facilitate   the   fast    development of   high-performance,
  771.     application-specific  database  systems.     EXODUS  provides
  772.     certain  kernel facilities,   including  a versatile  storage
  773.     manager.  In addition, it provides an architectural framework
  774.     for building  application-specific database systems; powerful
  775.     tools   to  help  automate the  generation   of such systems,
  776.     including  a   rule-based query optimizer generator    and  a
  777.     persistent  programming  language;  and libraries  of generic
  778.     software components (e.g., access methods) that are likely to
  779.     be useful for many application domains.
  780.  
  781. The programming language is called E, an extension of C++. [RC89]
  782.  
  783. REFERENCES:
  784. (see "ftp.cs.wisc.edu:exodus/bibliography" for a complete list)
  785.  
  786. [CDG+90] Michael J. Carey, David J. DeWitt, Goetz Graefe,
  787.          David M. Haight, Joel E. Richardson, Daniel T. Schuh,
  788.          Eugene J. Skekita, and Scott L. Vandenberg. The EXODUS
  789.          extensible DBMS project:  An overview. In Stanley B.
  790.          Zdonik and David Maier, editors, Readings in
  791.          Object-Oriented Database Systems, Data Management
  792.          Series. Morgan Kaufmann, San Mateo, CA, 1990. Also
  793.          available as WISC-CS-TR 808.
  794.  
  795. [CDRS89] Michael J. Carey, David J. DeWitt, Joel E. Richardson,
  796.          and Eugene J. Skekita. Storage management for objects
  797.          in EXODUS. In Won. Kim and Frederick H. Lochovsky,
  798.          editors, Object-Oriented Concepts, Databases and
  799.          Applications, chapter 14. Addison-Wesley, Reading, MA,
  800.          1989. After Carey et al. Object and File Management in
  801.          the EXODUS Database System, Proceedings of the Twelveth
  802.          International Conference on Very Large Data Bases,
  803.          1986.
  804.  
  805. [GD87]   G. Graefe and D. DeWitt. The EXODUS optimizer
  806.          generator. In U. Dayal and I. Traiger, editors,
  807.          Proceedings of the SIGMOD International Conference on
  808.          Management of Data, San Francisco, CA, May 1987.
  809.  
  810. [RC89]   Joel E. Richardson and Michael J. Carey. Persistence in
  811.          the E language:  Issues and implementation. Software --
  812.          Practice and Experience, 19(12):1115--1150, December
  813.          1989.
  814.  
  815.  
  816. FTP: source code, documentation and a complete bibliography can be
  817.      found at ftp.cs.wisc.edu:exodus/
  818.  
  819. See also APPENDIX E.
  820.  
  821.  
  822. On Schema Evolution (from original survey):
  823. No solution for the problem of schema evolution is provided.
  824. Emulation is rejected by the authors, who claim that the addition of a
  825. layer between the EXODUS Storage Manager and the E program would
  826. seriously reduce efficiency.  Automatic conversion, whether lazy or
  827. eager, is also rejected, as it does not mesh well with the C++ data
  828. layout.  To implement immediate references to other classes and
  829. structures, C++ embeds class and structure instances within its
  830. referent.  The resulting change in the size of the object might
  831. invalidate remote pointer references.
  832.  
  833.         Joel E.  Richardson and Michael J.  Carey.  "Persistence
  834.         in the E language: Issues and Implementation."  Appeared
  835.         in "Software -- Practice and Experience",
  836.         19(12):1115-1150, December 1989.
  837.  
  838.  
  839. > Machiavelli (University of Pennsylvania)
  840.  
  841. Machiavelli is a statically-typed programming language developed
  842. at the University of Pennsylvania. Its most outstanding innovation 
  843. is the use of conditional typing scheme in its type inference system. 
  844. It does not address type evolution.
  845.  
  846. [communication with limsoon@saul.cis.upenn.edu]
  847.  
  848. [Note: Machiavelli is included in this summary because it
  849.        previously incorporated persistence in its data model.]
  850.  
  851.  
  852.  
  853. > MOOD4-PC: Material's/Miniature Object-Oriented Database Prototype for
  854.              NEC/IBM-PC
  855.  
  856. is an object-oriented database system(OODBS) program developed in the
  857. course of our research project MOOD. The aim of the project MOOD is to
  858. develop a material database system to handle raw material data which
  859. are produced and accumulated in materials research and referred to by
  860. material experts when they face scientific or engineering problems
  861. where the expected behavior of particular materials in particular
  862. environments are crucial importance. We all know that the conventional
  863. database systems do not fulfill this requirement, though they serves
  864. well for bibliographic databases or fact databases which deals with
  865. the standard properties of standard materials.
  866.  
  867. MOOD4-PC is written in Arity/Prolog and available in source and
  868. executable form via anonymous ftp from:
  869.  
  870.    ~/pub/mood/mood4
  871.    at mood.mech.tohoku.ac.jp [130.34.88.61]
  872.    
  873.     ~/pub/database/mood
  874.     at ftp.uu.net [192.48.96.9]
  875.  
  876.     ~/pub/computing/databases/mood
  877.     at src.doc.ic.ac.uk [146.169.2.1]
  878.  
  879. Although it is true enough to say that MOOD4 is a general purpose
  880. OODBS, it may be appropriate to point out that MOOD4 is significantly
  881. different from what is generally meant by the term, the
  882. Object-Oriented Database System.
  883.  
  884. That is, OODBSs, in general, consist of two parts:
  885.  
  886.    (1) Disk storage manager
  887.    (2) Database language to define and manipulate data objects to
  888.        be stored to and retrieved from the disk.
  889.  
  890. The database language of OODBS is akin to the object-oriented
  891. programming language such as Smalltalk or C++. You can enjoy the full
  892. versatility of these general purpose programming language in writing
  893. application programs with the database language.
  894.  
  895. As apparent from these, OODBSs, in general, are for programmers who
  896. write application programs which serve end users' needs. MOOD, on the
  897. other hands, is not; it is for end users. It is provided with a user
  898. interface named the object editor or OE in short. With OE, we can;
  899.  
  900.   (1) Edit class definition objects and save them. This replaces the
  901.       data definition language.
  902.  
  903.   (2) Edit data objects and save them.
  904.  
  905.   (3) Create query objects, let the system select data objects which
  906.       match the queries, and browse them.
  907.  
  908. In the other words, we can do everything necessary to manage and use
  909. database with OE. MOOD, therefore, needs no programming language and,
  910. in fact, has none. In this regard, MOOD may better be categorized to
  911. the OODBS application.
  912.  
  913. The architecture of MOOD as such is the consequence of the nature of
  914. information to be dealt with in material database. If we describe the
  915. nature with a single word, "variety" will be the one most appropriate. 
  916. No fixed data structure can handle a handful of material data because
  917. their contents differ from one to another. The feature of OODBS
  918. relevant here is not the intimacy with programming languages but the
  919. flexibility of data structure which allows us to construct data
  920. objects with a variety of structures which match the variety in the
  921. information to be dealt with. Upon inputting and retrieving data
  922. objects, end users are forced to face this variety in data structure
  923. since significant information is born in the structures of individual
  924. representations.
  925.  
  926. Yet, we say that MOOD is a general purpose OODBS. This is not in the
  927. sense that we can develop application programs on it, but in the
  928. sense that it generally supports the essential capabilities of OODBS;
  929.  
  930.   (1) The abstract data type.
  931.  
  932.   (2) The nesting of structured data objects.
  933.  
  934.   (3) The class hierarchy.
  935.  
  936.   (4) The inheritance of attributes along the hierarchy.
  937.  
  938.   (5) Matching between objects along their structures with the
  939.       knowledge of the class hierarchy.
  940.  
  941. For additional features of MOOD4, please consult its manual available
  942. with the program. Although they are biased to the processing of
  943. material data (or, more generally, scientific and technical data),
  944. MOOD with these capabilities can be used in any application domain at
  945. least by the stage where you are to examine how well the pieces of
  946. information of interest are represented in OODBS and how well specific
  947. items of interest are discriminated out from the database as such.
  948.  
  949. Questions and suggestions on this software which are ever welcome
  950. indeed may be addressed to;
  951.  
  952.      Noboru Ono                                             
  953.      Dept. of Machine Intelligence and Systems Engineering, 
  954.      Faculty of Engineering, Tohoku University.            
  955.      Tel:++22-216-8111,
  956.      Fax:++22-216-8156,
  957.      E-mail:ono@mood.mech.tohoku.ac.jp
  958.  
  959.  
  960.  
  961. > OBST/STONE (Forschungszentrum Informatik [FZI], Karlsruhe, Germany)
  962.  
  963. OBST3-4 is now available at ftp.fzi.de under /pub/OBST/OBST3-4.
  964. (Please do not confuse this new release with the older OBST3-3.4).
  965.  
  966. Experienced users will notice that we've changed the structure of
  967. our ftp directory tree somewhat: compressed and gzip'ed files are
  968. now cleanly separated. By sending
  969.     echo 'info ftp_listing' | mail obst-listserv@fzi.de
  970. you will get a directory listing from our ftp server.
  971.  
  972. OBST3-4 is a major release with a new meta schema interface
  973. that enables schema modifications. A graphical schema browser
  974. (USE) based on tclOBST is now also available. Please note that this
  975. new tool has not yet been tested outside the FZI and that it
  976. is currently not part of the OBST core cdistribution.
  977.  
  978. Beside bug fixes and performance improvements, we have added support
  979. for IBM AIX and FreeBSD and improved the installation on LINUX PCs.
  980.  
  981. We would like to thank all OBST users who have helped us by testing a 
  982. beta version of OBST, most notably:
  983.   Naresh Sharma (N.Sharma@LR.TUDelft.NL)
  984.   Michael Reifenberger (root@rz-wb.fh-sw.de)
  985.   Hans-Ulrich Kobialka (kobi@borneo.gmd.de) 
  986.   Jean Safar (jsafar@lehman.com)
  987.   Gabor Karsai (gabor@vuse.vanderbilt.edu)
  988.   Stefan Bohm (bohm@math.uni-muenster.de)
  989.  
  990. The installation of OBST requires a C++ compiler
  991. (GNU g++ 2.3.3/2.4.5/2.5.8, or AT&T 2.1/3.01).
  992.  
  993. The OBST graphical tools run under the X-Windows
  994. system (currently X11R4, X11R5 and X11R6). 
  995. Installation has been tested for SunOS4.1.3 and LINUX only.
  996.  
  997. Best regards and happy OBST programming. 
  998.  
  999.    The OBST Team
  1000.  
  1001. ------------------------------------------------------------------------------
  1002. README of OBST3-4
  1003. -----------------
  1004.  
  1005. Version: OBST3-4
  1006. Date:    11/4/94
  1007.  
  1008. The OBject system of STONE --- OBST
  1009. -----------------------------------
  1010.  
  1011. The persistent object management system OBST was developed by
  1012. Forschungszentrum Informatik (FZI) as a contribution to the STONE
  1013. project (supported by grant no. ITS8902A7 from the BMFT, i.e. the
  1014. German Ministry for Research).
  1015.  
  1016. OBST was originally designed to serve as the common persistent
  1017. object store for the tools in software engineering environments.
  1018.  
  1019.  
  1020. Data Model
  1021. ---------
  1022.  
  1023. The OBST data model can be characterized by the following properties:
  1024.  
  1025.  * Schema definition language syntactically similar to C++
  1026.  * Support of multiple inheritance
  1027.  * Generic classes
  1028.  * Abstract classes and methods
  1029.  * Distinction between public, protected, and private methods
  1030.  * Redefinition of methods
  1031.  * Overloading of methods
  1032.  
  1033. Schemas and Containers
  1034. ----------------------
  1035.  
  1036. Schemas are compiled by the OBST schema compiler. The compilation
  1037. results are instances of classes of the meta schema. From these
  1038. instances in a next step interfaces to different programming languages
  1039. can be generated. At present the C++ language binding is implemented.
  1040.  
  1041. Objects are stored in so-called containers. The container an object
  1042. belongs to is determined at the time of object creation and fixed
  1043. throughout the object's lifetime. Containers are the units of 
  1044. clustering, synchronization, and recovery. Objects can be referenced
  1045. by other objects across container boundaries.
  1046.  
  1047. Incremental Loading
  1048. -------------------
  1049.  
  1050. OBST provides a mechanism to incrementally load methods. This enables
  1051. programs to deal with objects whose type is defined after the program 
  1052. itself has been developed. This is useful in systems that provide for 
  1053. inheritance and it supports schema evolution. We used it e.g. for
  1054. programs that interpret the object base and call methods of the
  1055. found objects (for example the below mentioned browser).
  1056.  
  1057. Prototype
  1058. ---------
  1059.  
  1060. Since end 1990 the first prototype of OBST is available and is shipped
  1061. to interested universities and research institutions. The current
  1062. version is publicly available via FTP (see below) since March '92.
  1063. There is a mailing list (see below) with >>100 subscribers.
  1064.  
  1065. The system comes with the schema compiler, a library of predefined
  1066. classes (like Set<Entity>, List<Entity>, String, ...), a graphical
  1067. object browser (more a shell than a browser), a graphical schema
  1068. designer (USE), the structurer and flattener (STF), tclOBST,
  1069. and all manuals.
  1070. For USE, STF and tclOBST see below.
  1071.  
  1072. Schema Evolution Support Environment (USE)
  1073. ------------------------------------------
  1074.  
  1075. This environment consists of a graphical schema designer built with
  1076. tclOBST (see below). It can be used to inspect existing class hierarchies
  1077. and to modify these hierarchies; it allows the addition of new classes
  1078. as well as the modification of existing ones.
  1079.  
  1080. Structurer and Flattener (STF)
  1081. ------------------------------
  1082.  
  1083. This is a tool to build objects from bytestrings and flatten objects
  1084. down to bytestrings. It is intended to be used when coupling UNIX
  1085. tools to the object management system. The user defines a grammar that
  1086. describes her objects. Afterwards, the structurer parses an ascii 
  1087. text according to the given grammar and creates an OBST object
  1088. structure that represents the corresponding parse tree.
  1089. The flattener does the inverse transformation, that means it generates
  1090. an ascii text from a given OBST object structure according to the given
  1091. grammar.
  1092.  
  1093. tclOBST
  1094. -------
  1095.  
  1096. tclOBST is a library which provides an embedding of OBST into the
  1097. interactive tool command language tcl, developed by John Ousterhout
  1098. at the University of Berkeley.
  1099. Based on the standard tcl shells, which are also comprised in the
  1100. tclOBST distribution, tclOBST offers interactive access to the complete
  1101. functionality modelled by OBST schemata.
  1102.  
  1103.  
  1104. System Requirements
  1105. -------------------
  1106.  
  1107. For the prototype's installation a C++ compiler
  1108. (GNU g++ 2.3.3/2.4.5/2.5.7 or AT&T 2.0/2.1/3.01) and the
  1109. X-Windows system (currently X11R4 or X11R5) for the graphical tools
  1110. are required.
  1111. Installation is well-tried on SUN Sparc stations and should be no
  1112. problem on other UNIX machines, too. You can find a more detailed
  1113. description of the supported platforms in the README.install.OBST*.
  1114.  
  1115. --------------------------------------------------------------------
  1116.  
  1117. For more information please mail to:
  1118.  
  1119.                 Forschungszentrum Informatik (FZI)
  1120.                        OBST Projekt
  1121.                  Haid-und-Neu-Strasse 10-14
  1122.                      D-76131 Karlsruhe
  1123.                           Germany
  1124.  
  1125. or email to:  obst@fzi.de
  1126.  
  1127. Phone:        ++49-721-9654-701
  1128. Fax:          ++49-721-9654-709
  1129. Teletex:      721 190 fziKA
  1130.  
  1131. The OBST system is available via anonymous FTP from
  1132. ftp.fzi.de [141.21.4.3] and some mirror servers.
  1133.  
  1134. The system as well as some overview papers, documentation
  1135. (User's Guide, Language Reference Manual, Tutorial, ...),
  1136. and lots of manual pages can be found in the directory /pub/OBST.
  1137.  
  1138. There are mailing lists for announcing OBST enhancements,
  1139. new versions, porting hints, etc. as well as for exchanging experiences
  1140. with other OBST users.
  1141.  
  1142. Send a mail with content 'LONGINDEX' to obst-listserv@fzi.de to learn about
  1143. the mailing lists which are currently installed:
  1144.     echo LONGINDEX | mail obst-listserv@fzi.de
  1145.  
  1146. The mailing lists are maintained by an automatic list processor.
  1147. Use 'HELP' to learn about the commands understood by this processor:
  1148.     echo HELP | mail obst-listserv@fzi.de
  1149.  
  1150. Bug reports should contain a small example program with which the
  1151. bug can be reproduced, or at least a detailed description of the
  1152. observed phenomenon. They should also mention:
  1153.      o OBST version 
  1154.      o configuration parameters for your OBST version
  1155.        (from file config.status)
  1156.      o kind and version of C++ compiler 
  1157.      o machine
  1158.      o operating system
  1159.  
  1160. Besides bug reports we are strongly interested in all experiences
  1161. our users make with OBST (e.g. sufficiency of data model, performance,
  1162. ...) and in our users' application areas and the applications as
  1163. well. So, please don't hesitate to send us a short note.
  1164.  
  1165. Best regards and happy OBST programming.
  1166.  
  1167.    The OBST Team,
  1168.  
  1169.     Boris Boesler, Dirk Eichberg, Frank Fock, Axel Freyberg,
  1170.     Michael Gravenhorst, Ingolf Mertens, Michael Pergande, Christian Popp,
  1171.     Bernhard Schiefer, Dietmar Theobald, Axel Uhl, Walter Zimmer
  1172.  
  1173. ---
  1174.  
  1175. BTW "Obst" is the German word for "fruit",
  1176.     so have a fruitful time with OBST!
  1177.  
  1178.  
  1179. > Ode
  1180.  
  1181.                                  Ode 2.0
  1182.                        An Object-Oriented Database
  1183.  
  1184.        C++ Compatible, Fast Queries, Complex Application Modeling,
  1185.        Multimedia Support, and more
  1186.  
  1187. See APPENDIX E, Databases, for description.
  1188. Note: Ode version 3.0 is now available.
  1189.  
  1190.  
  1191. > Oggetto, University of Lancaster, UK.
  1192.  
  1193. Developed at the University of Lancaster, UK.  Summary NYI.
  1194.  
  1195. "Oggetto: An Object Oriented Database Layered on a Triple Store",
  1196. J.A. Mariani, The Computer Journal, V35, No 2, pp108-118, April 1992.
  1197.  
  1198.  
  1199. > IDB Object Database
  1200.  
  1201. Produce IDB Object Database, a distributed object database with an
  1202. interactive schema designer and browser.  Supports most platforms.
  1203. Single developer's licenses range form $995-$4000.  A IDB introductory
  1204. package is available for Macintosh and Windows for $99 including working
  1205. application and tutorial.
  1206.  
  1207. Persistent Data Systems, Inc.
  1208. P.O. Box 38415
  1209. Pittsburgh, PA  15238
  1210. U.S.A.
  1211.  
  1212. Voice:  (412) 963-1843
  1213. Email:  info@persist.com
  1214.  
  1215.  
  1216. > ORION (Now marketed as ITASCA)
  1217.  
  1218. ORION was a prototype OODBMS developed at MCC, an American consortium by Won
  1219. Kim and his group.  Won Kim has left MCC and formed a new company, UniSQL, in
  1220. Austin, with a new product of the same name.
  1221.  
  1222. See also entry under "ITASCA".
  1223.  
  1224. REFERENCES:
  1225.  
  1226. I have found nearly a dozen papers published by the ORION folks.
  1227. Overviews at various stages in its development and commercialization
  1228. can be found in:
  1229.  
  1230. [KBGW91] Won Kim, N. Ballou, J.F. Garza, and D.; Woelk. A
  1231.          distributed object-oriented database system supporting
  1232.          shared and private databases. ACM Transactions on
  1233.          Information Systems, 9(1):31--51, January 1991.
  1234.  
  1235. [KGBW90] W. Kim, J.F. Garza, N. Ballou, and D. Woelk.
  1236.          Architecture of the orion next-generation database
  1237.          system. IEEE Transactions on Knowledge and Data
  1238.          Engineering, 2(1):109--24, March 1990.
  1239.  
  1240. [KBCG89] Won Kim, Nat Ballou, Hong-Tai Chou, and Darrell Garza,
  1241.          Jorge F. Woelk. Features of the ORION object-oriented
  1242.          database system. In Won. Kim and Frederick H.
  1243.          Lochovsky, editors, Object-Oriented Concepts, Databases
  1244.          and Applications, chapter 11. Addison-Wesley, Reading,
  1245.          MA, 1989.
  1246.  
  1247. [KBC+88] Won Kim, N. Ballou, Hong-Tai Chou, J.F. Garza,
  1248.          D. Woelk, and J. Banerjee. Integrating an
  1249.          object-oriented programming system with a database
  1250.          system. In Proceedings of the ACM Conference on
  1251.          Objected-Oriented Programming:  Systems, Languages and
  1252.          Applications (OOPSLA), pages 142--152, San Diego, CA,
  1253.          September 1988. Published as ACM SIGPLAN Notices
  1254.          23(11).
  1255.          [Pointers to the previous papers documenting each of the
  1256.           advanced features listed above are cited therein.]
  1257.  
  1258.  
  1259. The paper most relevant to the issue of schema evolution is the
  1260. following:
  1261.  
  1262. [BKKK87] J. Banerjee, W. Kim, H-J. Kim, and H.F. Korth.
  1263.          Semantics and implementation of schema evolution in
  1264.          object-oriented databases. In U. Dayal and I. Traiger,
  1265.          editors, Proceedings of the SIGMOD International
  1266.          Conference on Management of Data, San Francisco, CA,
  1267.          May 1987.
  1268.  
  1269.  
  1270. You might also like to look at Kim's book, which provides a good
  1271. introduction to OODBMS, while focusing on the ORION work:
  1272.  
  1273. [Kim90]  Won Kim. Introduction to Object-Oriented Databases.
  1274.          Computer Systems. MIT Press, Cambridge, MA, 1990.
  1275.  
  1276.  
  1277. > OTGen (Carnegie Mellon University/UMass Amherst)
  1278.  
  1279. OTGen is a design for a system to support schema evolution in
  1280. object-oriented databases.  The chief contribution of OTGen is support
  1281. for programmer extensibility of transformation functions to allow a
  1282. system to support a wide range of schema changes, not just those that
  1283. can be easily automated.  While OTGen was never implemented, it is
  1284. based on the implementation of TransformGen, a system to support the
  1285. evolution of the specialized databases used by Gandalf programming
  1286. environments.  For more information on OTGen and TransformGen, please
  1287. see: 
  1288.  
  1289. Barbara Staudt Lerner and A. Nico Habermann, "Beyond Schema Evolution
  1290.     to Database Reorganization", in Proceedings of the Joint ACM 
  1291.     OOPSLA/ECOOP '90 Conference on Object-Oriented Programming:
  1292.     Systems, Languages, and Applications, Ottawa, Canada, October
  1293.     1990, 67-76. 
  1294.  
  1295. Barbara Staudt, Charles Krueger, and David Garlan, TransformGen:
  1296.     Automating the Maintenance of Structure-Oriented Environments, 
  1297.     Computer Science Department Carnegie-Mellon University, Technical 
  1298.     Report CMU-CS-88-186, November 1988.
  1299.  
  1300. David Garlan, Charles W. Krueger, and Barbara J. Staudt, "A Structural
  1301.     Approach to the Maintenance of Structure-Oriented Environments",
  1302.     in Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering
  1303.     Symposium on Practical Software Development Environments, Palo
  1304.     Alto, California, December 1986, 160-170.
  1305.  
  1306. Contact:
  1307. Barbara Lerner
  1308. blerner@cs.umass.edu
  1309.  
  1310.  
  1311. ontact:
  1312. Best regards, Heiko
  1313. --
  1314. Labor fuer Kuenstliche Intelligenz              Heiko Kirschke  | |
  1315. Fachbereich Informatik                 Tel: +49 (40) 54715-612  | | ||// ||
  1316. Universitaet Hamburg                   Fax: +49 (40) 54715-572  | | ||\\ ||
  1317. Vogt-Koelln-Strasse 30      kirschke@informatik.uni-hamburg.de  |  ---------
  1318. D 22527 Hamburg                                      Raum R017   -----------
  1319. World Wide Web: http://lki-www.informatik.uni-hamburg.de/~kirschke/home.html
  1320.  
  1321.  
  1322. > PLOB! (Hamburg University)
  1323.  
  1324. What is PLOB?
  1325.  
  1326. * The sound to be heared when a bottle of sparkling wine (champagne,
  1327.   cidre, etc.) is opened.
  1328. * A system for Persistent Lisp OBjects.
  1329.  
  1330. Please check the first point by yourself (this can be rather
  1331. delightful); I will concentrate here on the second point. PLOB! offers
  1332. persistent objects for LispWorks Common LISP.
  1333.  
  1334. It is the result of my diploma thesis in computer science.  Here are
  1335. some topics which I had in mind when designing PLOB! and which are
  1336. working features of it:
  1337.  
  1338. * Orthogonal persistency
  1339. -- Type completeness
  1340. -- Persistency independent of an object's type
  1341.  
  1342. * PLOB!'s data modelling adapted to Common LISP's data modelling
  1343. -- Persistent symbols
  1344. -- Persistent packages
  1345. -- Mapping between transient class metaobjects and persistent class
  1346.    description objects
  1347. -- Schema evolution
  1348.  
  1349. * Integration of useful database functions
  1350. -- Transactions
  1351. -- Hierarchical object locking
  1352. -- Indices
  1353. -- Selection queries
  1354.  
  1355. * Efficency
  1356. -- Efficient object representation
  1357. -- Possibility of direct access to objects in the persistent memory
  1358.  
  1359. For details, see 
  1360. http://lki-www.informatik.uni-hamburg.de/~kirschke/diplom/arbeit-eng.html
  1361.  
  1362. Contact:
  1363. Heiko Kirschke
  1364. Labor fuer Kuenstliche Intelligenz
  1365. Fachbereich Informatik
  1366. Universitaet Hamburg
  1367. Vogt-Koelln-Strasse 30
  1368. D 22527 Hamburg      Raum R017
  1369. kirschke@informatik.uni-hamburg.de 
  1370. Tel: +49 (40) 54715-612
  1371. Fax: +49 (40) 54715-572
  1372. World Wide Web: http://lki-www.informatik.uni-hamburg.de/~kirschke/home.html
  1373.  
  1374.  
  1375. > VODAK
  1376.  
  1377. Research in the framework of VODAK focuses on an extensible data
  1378. model and database programming language, an advanced transaction
  1379. odel, object-oriented query language, and support for multimedia data.
  1380.  
  1381. The VODAK Data Model Language VML
  1382.  
  1383. Usually database models lack mechanisms for extending them with
  1384. additional modeling primitives. This limitation does not allow the
  1385. adaptation of the models for specific application needs, e.g. database
  1386. integration, multimedia document handling, hypertext modeling, etc.
  1387.