home *** CD-ROM | disk | FTP | other *** search
/ Peanuts NeXT Software Archives / Peanuts-1.iso / CDROM / FAQs / object-faq < prev    next >
Encoding:
Internet Message Format  |  1996-09-29  |  631.3 KB

  1. Path: senator-bedfellow.mit.edu!faqserv
  2. From: Bob Hathaway <rjh@geodesic.com>
  3. Newsgroups: comp.object,comp.answers,news.answers
  4. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Announcement
  5. Supersedes: <object-faq/announce_805979999@rtfm.mit.edu>
  6. Followup-To: comp.object
  7. Date: 31 Aug 1995 15:32:29 GMT
  8. Organization: Geodesic Systems, Inc.
  9. Lines: 60
  10. Approved: news-answers-request@MIT.Edu
  11. Expires: 29 Oct 1995 15:31:54 GMT
  12. Message-ID: <object-faq/announce_809883114@rtfm.mit.edu>
  13. NNTP-Posting-Host: bloom-picayune.mit.edu
  14. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  15. X-Last-Updated: 1995/06/01
  16. Originator: faqserv@bloom-picayune.MIT.EDU
  17. Xref: senator-bedfellow.mit.edu comp.object:37582 comp.answers:13970 news.answers:51851
  18.  
  19. Archive-name: object-faq/announce
  20. Last-Modified: 05/31/95
  21. Version: 1.0.8
  22.  
  23. This announces the May version 1.0.8 of the Comp.Object FAQ!  It has many
  24. new questions, entries, and updates and has several very up-to-date appendices
  25. on object-oriented methodologies and systems, with a new Appendix on Commercial
  26. Object-Oriented Libraries and Systems.  This document may very well comprise
  27. the latest and most up-to-date collection of object-oriented systems and terms
  28. in the world today!  There is also a potential upcoming merge with the new C++
  29. Libraries FAQ.
  30.  
  31. I will try to update the FAQ monthly with system entries and information from
  32. the net.  I have a new TQM system in place which should proceed from the
  33. old Level 1 to Level 5 in no time - not hard for a one man job.  *Many*
  34. thanks to the patience of those sending system updates and corrections,
  35. my new system should provide fast acknowledgement, inclusion (within a few
  36. weeks) and tracking, and 6 sigma quality should provide essentially defect
  37. free performance for the FAQ.  Perhaps I'll even go for ISO 9001 certification!
  38.  
  39. Sending comments, suggestions, additions, updates, corrections, and new
  40. systems and site entries is strongly encouraged and should be directed to
  41. the author at rjh@geodesic.com.
  42.  
  43. The FAQ is posted to the comp.object, comp.answers and news.answers newsgroups
  44. and is available via anonymous ftp from zaphod.uchicago.edu and rtfm.mit.edu,
  45. although new versions may take a short period of time to be installed.
  46.  
  47.  
  48. Anonymous FTP Sites and Hypertext Server:
  49.   anonymous@zaphod.uchicago.edu:/pub/CompObj8.faq(.Z)     (128.135.72.61)
  50.   anonymous@rtfm.mit.edu:/pub/usenet/comp.object/*_Part_* (18.181.0.24 Tmp)
  51.   http://iamwww.unibe.ch/~scg/OOinfo/FAQ/index.html       (new IAM location)
  52.  
  53. Mail Server:  (See also section 1.24)
  54.   mail mail-server@rtfm.mit.edu
  55.   Subject:
  56.   send usenet/comp.object/*
  57.  
  58. Zaphod is preferred over rtfm for anonymous ftp retrieval, as it provides a
  59. single file.  Rtfm contains the FAQ as posted.
  60.  
  61. To use the hypertext system, see APPENDIX E, entries 27.
  62.  
  63. Comp.Object Archive:
  64.   A new and workable comp.object archive is now available on the www, with
  65.   much thanks to Markus A. Beckmann, beckmann@informatik.mathematik.uni-mainz.de.
  66. http://aaimzb.mathematik.uni-mainz.de/Personal/Mitarbeiter/comp.object.idx.html
  67.  
  68.  
  69. Again, a short period of time may be required to retrieve the latest version
  70. from anonymous ftp, allowing the posted version to propagate and get out as
  71. quickly as possible.
  72.  
  73. Thank you to the many people who have contributed their time and effort to
  74. help this document spread the word about object-oriented technology and
  75. available systems!  It is hoped it will be most useful in that endeavor.
  76.  
  77. Best Regards!
  78. bob
  79.  
  80. ############################################################################
  81.  
  82.  
  83. Path: senator-bedfellow.mit.edu!faqserv
  84. From: Bob Hathaway <rjh@geodesic.com>
  85. Newsgroups: comp.object,comp.answers,news.answers
  86. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Part 1/13
  87. Supersedes: <object-faq/part1_805979999@rtfm.mit.edu>
  88. Followup-To: comp.object
  89. Date: 31 Aug 1995 15:32:31 GMT
  90. Organization: Geodesic Systems
  91. Lines: 952
  92. Approved: news-answers-request@MIT.Edu
  93. Distribution: world
  94. Expires: 14 Oct 1995 15:31:54 GMT
  95. Message-ID: <object-faq/part1_809883114@rtfm.mit.edu>
  96. References: <object-faq/announce_809883114@rtfm.mit.edu>
  97. NNTP-Posting-Host: bloom-picayune.mit.edu
  98. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  99. X-Last-Updated: 1995/06/01
  100. Originator: faqserv@bloom-picayune.MIT.EDU
  101. Xref: senator-bedfellow.mit.edu comp.object:37583 comp.answers:13971 news.answers:51852
  102.  
  103. Archive-name: object-faq/part1
  104. Last-Modified: 05/31/94
  105. Version: 1.0.8
  106.  
  107. COMP.OBJECT FAQ
  108. Version: 1.0.8
  109. Date:    5/31/1995
  110.  
  111.  
  112. Author:
  113.   Bob Hathaway
  114.   Geodesic Systems, Inc.
  115.   Cyberdyne Systems Corporation
  116.   rjh@geodesic.com
  117.   http://www.geodesic.com
  118.   75027.1663@compuserve.com
  119.  
  120. Copyright 1992-1995  Bob Hathaway
  121. All rights reserved.
  122.  
  123. Permission is granted to freely copy and distribute this document but only
  124. with this full header attached and at no cost to others with the exception
  125. of a nominal distribution fee, if any.  No sale, resale or reprinting is
  126. granted without the explicit written permission of the author.
  127.  
  128.  
  129. Anonymous FTP Sites and Hypertext Server:
  130.   anonymous@zaphod.uchicago.edu:/pub/CompObj8.faq(.Z)     (128.135.72.61)
  131.   anonymous@rtfm.mit.edu:/pub/usenet/comp.object/*_Part_* (18.181.0.24 Tmp)
  132.   http://iamwww.unibe.ch/~scg/OOinfo/FAQ/index.html       (new IAM location)
  133.  
  134. Mail Server:  (See also section 1.24)
  135.   mail mail-server@rtfm.mit.edu
  136.   Subject:
  137.   send usenet/comp.object/*
  138.  
  139. Zaphod is preferred over rtfm for anonymous ftp retrieval, as it provides a
  140. single file.  Rtfm contains the FAQ as posted.
  141.  
  142. To use the hypertext system, see APPENDIX E, entries 27.
  143.  
  144. Comp.Object Archive:
  145.   A new and workable comp.object archive is now available on the www, with
  146.   much thanks to Markus A. Beckmann, beckmann@informatik.mathematik.uni-mainz.de.
  147. http://aaimzb.mathematik.uni-mainz.de/Personal/Mitarbeiter/comp.object.idx.html
  148.  
  149. Contributors:  Per Abrahamsen, Margaret Burnett, Edwardo Casais, Stewart
  150.   Clamen, Dennis De Champeaux, Mike DeVaney, Eric Dujardin, Piercarlo Grandi,
  151.   Brian Henderson-Sellers, Urs Hoelzle, Paul Johnson, Bill Kinnersley, Oscar
  152.   Nierstrasz, James Odell, David Wheeler, Eoin Woods, and many others whose
  153.   contributions have helped this document to fulfull its objective of bringing
  154.   object-oriented concepts and systems to everyone.
  155.   
  156.   Special thanks to Object Systems, Geodesic Systems and Cyberdyne Systems for
  157.   providing the support and resources needed to make this effort possible.
  158.   Object Systems was primarily a "think tank" and producer of object-oriented
  159.   technologies, Geodesic Systems brings the latest in object-oriented theory
  160.   and technique to practical and widespread use, as does Cyberdyne.
  161.  
  162.   And to kick off the new Appendix G, Commercial OO Libraries and Systems, I'm
  163.   introducing our own new product (partly developed by me:-), the Great Circle
  164.   (TM) automatic memory management system for C and C++.  I've used it on
  165.   several of my own projects where it automatically fixed all memory leaks
  166.   instantly.
  167.   
  168.   New formatted and submitted entries for Appendix G are most welcome.
  169.  
  170. Objective:
  171.   In the spirit of other FAQs, to provide a simple document to answer the most
  172.   frequently asked and recurring questions and to allow new users to understand
  173.   frequently discussed topics and terms used in comp.object.   This should
  174.   bring new comp.object readers and/or writers to at least an introductory
  175.   level of comprehension as soon as possible.  Other goals (hopes) are to
  176.   provide a quick and current reference on available systems such as object-
  177.   oriented languages, CASE, OODB and etc. and to provide good references to
  178.   current and relevant OO systems, groups, texts and literature.
  179.  
  180. Disclaimer:
  181.   This document does not necessarily reflect the opinions of the author's or
  182.   any contributor's companies.  There are no explicit or implicit guarantees
  183.   implied by this document.
  184.  
  185. While object systems are a constantly changing and moving target with a broad
  186. diversity of often conflicting methodologies, constructs, terminologies,
  187. approaches, languages, implementations and etc. and comp.object has a wide
  188. diversity of readers and writers ranging from students, professors and
  189. researchers in academia to beginners, professionals, top-notch experts and
  190. leaders in industry with a broad range of experience and backgrounds ranging
  191. across many paradigms, this FAQ can certainly not aspire to satisfy all of them
  192. completely but instead attempts to provide the most well-rounded treatment of
  193. object-oriented concepts and realizations primarily from the mainstream and
  194. popular authors and systems and further to provide a collection of available
  195. systems and tools in the appendices.
  196.  
  197. Several improvements are planned for future FAQs, including a glossary.
  198.  
  199.  
  200. SECTION 1:  BASICS
  201.   1.1)  What Is An Object?
  202.   1.2)  What Is Object Encapsulation (Or Protection)?
  203.   1.3)  What Is A Class?
  204.   1.4)  What Is A Meta-Class?
  205.   1.5)  What Is The Infinite Regress Of Objects And Classes?
  206.   1.6)  What are MOPs and Reflection?
  207.   1.7)  What Is Inheritance?
  208.   1.8)  What Is Multiple Inheritance?
  209.   1.9)  Does Multiple Inheritance Pose Any Additional Difficulties?
  210.   1.10) What Is Dynamic Inheritance?
  211.   1.11) What Is Shared (Repeated) Inheritance?
  212.   1.12) Why Use Inheritance?
  213.   1.13) Why Don't Some People Like Inheritance?
  214.   1.14) What Is Specialization/Generalization/Overriding?
  215.   1.15) What Is The Difference Between Object-Based And Object-Oriented?
  216.   1.16) Is A Class An Object?
  217.   1.17) Is An Object A Class?
  218.   1.18) What Is A Method? (And Receiver And Message)
  219.   1.19) What Are Multi-Methods And Multiple-Polymorphism?
  220.   1.20) What Is OOP?
  221.   1.21) What Is OOA/OOD (And Where Can I Get What I Need On It)?
  222.   1.22) Where Did Object-Orientation Come From?
  223.   1.23) What Are The Benefits Of Object-Orientation?
  224.   1.24) What Other FAQs Are available?
  225.  
  226. SECTION 2:  TYPING
  227.   2.1)  What Is Polymorphism?
  228.   2.2)  What Does Polymorphism Boil Down To In OO Programming Languages?
  229.   2.3)  What Is Dynamic Binding?
  230.   2.4)  Is There A Difference Between Being A Member Or Instance Of A Class?
  231.   2.5)  What Is This I Read About ML And Functional Programming Languages?
  232.   2.6)  What Is the Difference Between Static And Dynamic Typing?
  233.   2.7)  What Is A Separation Between Type And Class (Representation)?
  234.   2.8)  What Are Generics And Templates?
  235.  
  236. SECTION 3:  GENERAL
  237.   3.1)  What Is The "Classical" Object-Oriented Paradigm?
  238.   3.2)  What Is The "Delegation/Prototyping" Object-Oriented Paradigm?
  239.   3.3)  Are There Any Other Object-Oriented Paradigms?
  240.   3.4)  What Are The Major Object-Oriented Programming Languages Today?
  241.   3.5)  What Are Object-Oriented Databases And Persistence?
  242.   3.6)  What Are Object-Oriented Operating Systems?
  243.   3.7)  What Are The Current Object-Oriented Methodologies?
  244.   3.8)  What Is The OMG/OMA/ORB/CORBA?
  245.   3.9)  Why Is Garbage Collection A Good Thing?
  246.   3.9b) Why is Garbage Collection Necessary For Object-Oriented Programming?
  247.   3.10) What Can I Do To Teach OO To The Kids?
  248.   3.11) What Is Available On Object-Oriented Testing?
  249.   3.12) What Distributed Systems Are Available?
  250.   3.13) What Is The MVC Framework?
  251.   3.14) What Is Real-Time?
  252.   3.15) What Is Available on OO Metrics?
  253.   3.16) What Are Visual Object-Oriented Programming Systems?
  254.   3.17) What Tutorials Are Available On Object-Oriented Concepts and Languages?
  255.  
  256. SECTION 4:  COMMONLY ASKED LANGUAGE SPECIFIC QUESTIONS
  257.   4.1)  What Is Downcasting?
  258.   4.2)  What Are Virtual Functions?
  259.   4.3)  Can I Use Multiple-Polymorphism Or Multi-Methods In C++?
  260.   4.4)  Can I Use Dynamic Inheritance In C++?
  261.  
  262. ANNOTATED BIBLIOGRAPHY
  263.  
  264. APPENDIXES
  265.   APPENDIX A  VIPS
  266.   APPENDIX B  OBJECT-ORIENTED DATABASES AND VENDORS
  267.   APPENDIX C  OBJECT-ORIENTED LANGUAGES AND VENDORS
  268.   APPENDIX D  OBJECT-ORIENTED CASE (OOA/D/P TOOLS) AND VENDORS
  269.   APPENDIX E  ANONYMOUS FTP SITES
  270.   APPENDIX F  MAGAZINES, JOURNALS AND NEWSLETTERS
  271.   APPENDIX G  COMMERCIAL OBJECT-ORIENTED LIBRARIES AND SYSTEMS
  272.  
  273. [Another appendix on commercial object-oriented class libraries should be
  274.  added soon]
  275.  
  276.  
  277. SECTION 1:  BASICS
  278. ==================
  279.  
  280. Suggested Readings:
  281.   [Booch 91, 94]
  282.   Others to be added...
  283.  
  284.  
  285. 1.1) What Is An Object?
  286. -----------------------
  287.  
  288. There are many definitions of an object, such as found in [Booch 91, p77]:
  289. "An object has state, behavior, and identity; the structure and behavior of
  290. similar objects are defined in their common class; the terms instance and
  291. object are interchangeable".  This is a "classical languages" definition, as
  292. defined in [Coplien 92, p280], where "classes play a central role in the
  293. object model", since they do not in prototyping/delegation languages.  
  294. "The term object was first formally applied in the Simula language, and
  295. objects typically existed in Simula programs to simulate some aspect of
  296. reality" [Booch 91, p77].  Other definitions referenced by Booch include
  297. Smith and Tockey: "an object represents an individual, identifiable item,
  298. unit, or entity, either real or abstract, with a well-defined role in the
  299. problem domain." and [Cox 91]: "anything with a crisply defined boundary"
  300. (in context, this is "outside the computer domain".  A more conventional
  301. definition appears on pg 54).  Booch goes on to describe these definitions
  302. in depth.  [Martin 92, p 241] defines: "An "object" is anything to which a
  303. concept applies", and "A concept is an idea or notion we share that applies
  304. to certain objects in our awareness".  [Rumbaugh 91] defines: "We define an
  305. object as a concept, abstraction or thing with crisp boundaries and meaning for
  306. the problem at hand." [Shlaer 88, p 14] defines: "An object is an abstraction
  307. of a set of real-world things such that:
  308.   * all of the real-world things in the set - the instances - have the same
  309.     characteristics
  310.   * all instances are subject to and conform to the same rules"
  311. and on identifying objects: "What are the *things* in this problem?  Most of
  312. the things are likely to fall into the following five categories: Tangible
  313. things, Roles, Incidents, Interactions, and Specifications."  [Booch 91, 4.3]
  314. covers "Identifying Key Abstractions" for objects and classes based on an
  315. understanding of the problem domain and [Jacobson 92] provides a novel approach
  316. to identifying objects through use-cases (scenarios), leading to a use-case
  317. driven design.  Jacobson also calls for managing complexity with specialized
  318. object categories [Jacobson 94]:
  319.   Ordinary Objects     - Typical OOPL objects
  320.   Use-Cases and Actors - Actors <--> Use-Cases <--> Object Model Objects
  321.   Megaobjects          - Composite objects (~ subsystems with inheritance)
  322.     Frameworks*(Typical) - Abstract MO meant for reuse and extension
  323.     Patterns** (Typical) - Framework-like, crsp. classes and comm patterns only
  324.   Application Objects  - In the Object Model
  325.     Interface            - E.g. GUI
  326.     Control              - Introduced in design for control purposes
  327.     Entity               - Correspond to real-world objects
  328.   Component Objects    - Utility and Implementation hiding objects
  329.     Utility              - Set, Array, ...
  330.     Impl. Hiding         - Distr. Arch., specific DBMS, OS
  331.  
  332.   Unrelated to Ivar Jacobson but relevant to the topic:
  333.   * There was a Software Frameworks Assoc. and magazine until last year, but
  334.     a review of their last conference is available by email thanks to Adam
  335.     Wildavsky, send requests to adamw@panix.com.
  336.   **There is a patterns mailing list, email: patterns-request@cs.uiuc.edu.
  337.     See also st.cs.uiuc.edu for some info on patterns.
  338.  
  339. The implementation of objects could roughly be categorized into descriptor-
  340. based, capability-based, and simple static-based approaches.  Descriptor-
  341. based approaches (e.g. Smalltalk handles) allow powerful dynamic typing, as
  342. do the capability-based approaches which are typically found in object-
  343. oriented databases and operating systems (object id's).  A "proxy" based
  344. approach with an added layer of indirection to Smalltalk's handles is found
  345. in Distributed Smalltalk which allows transparent, distributed, and migrating
  346. objects [Kim 89, ch 19 and Yaoqing 93].  Simple static approaches are found in
  347. languages such as C++, although the new RTTI facility will supply simple
  348. dynamic typing (checked downcasting) similar to those introduced by Eiffel
  349. in 1989 through the notion of assignment attempt, also known as type narrowing.
  350.  
  351. Descriptor-based approaches can have pointer semantics and can be statically
  352. typeless (or just "typeless", as in Smalltalk) where references (variables)
  353. have no type, but the objects (values) they point to always do.  An untyped
  354. pointer (such as void* in C++) and an embedded dynamic typing scheme are used
  355. in more conventional languages to fully emulate this style of dynamically typed
  356. programming (see sections 2.3, 4.3, and [Coplien 92]).
  357.  
  358. Below is a simple example to show a most trivial case of OO implementation.
  359. It is primarily intended to introduce new terms.  See [Cardelli 85] for
  360. another semantic definition of OO using functions for methods and for
  361. a view of types as sets of values.
  362.  
  363. Simple statically-typed objects (static and auto vars and temps in C++ and
  364. expanded types in Eiffel) can be viewed as instances of a record type,
  365. whose record fields are called instance variables (Smalltalk) or member data
  366. (C++).  The record (class) may also contain operations which are called
  367. methods (Smalltalk) or member functions (C++) which are equivalent to a
  368. function taking an object of the record type, called the receiver, as the
  369. first parameter.  The receiver is called self (Smalltalk) or this (C++).
  370. Members will denote both instance variables and methods.  Inheritance is
  371. roughly equivalent to a loosely coupled variant record, with derived classes
  372. as variant parts and with multiple-inheritance concatenating several records
  373. to serve as a base.
  374.  
  375. A virtual member in statically typed languages is a base class member that can
  376. be set or respecified by a derived class.  This is roughly equivalent to a
  377. pointer or function pointer in the base class being set by the derived class.
  378. [Stroustrup 90] covers the implementation details of virtual member functions
  379. in C++, which also involve an offset for the receiver to handle multiple-
  380. inheritance.  This is an example of dynamic binding, which replaces a
  381. switch statement on variant parts with a single call, reducing code size
  382. and program complexity (fewer nested programming constructs) and allowing
  383. variants to be added without modifying client code (which causes higher defect
  384. injection rates during maintanance and debugging).
  385.  
  386. Virtual members in dynamically typed languages are more flexible because
  387. static typechecking requirements are dropped.  See section 2.5.
  388.  
  389. The terms method/member function, instance variable/member data, subclass/
  390. derived class, parent class/base class, and etc. will be used interchangeably.
  391. As pointed out in [Stroustrup 90, p197], the base/derived class terminology
  392. may be preferable to the sub/super-class terminology, and is preferred in
  393. this document also.
  394.  
  395. Delegation/prototyping languages [Kim 89, ch3; Ungar 87, Sciore 89] have a more
  396. flexible kind of object which can play the role of classes in classical OO
  397. languages.  Since there is no separate class construct in these languages, and
  398. only objects, they are referred to as single-hierarchy, or 1 Level systems.
  399. Objects contain fields, methods and delegates (pseudo parents), whereas
  400. classical object-oriented languages associate method, field and parent
  401. definitions with classes (and only associate state and class with objects,
  402. although vtables of function pointers for dynamic binding is an exception).
  403. However, one-level objects often play the role of classes to take advantage of
  404. sharing and often instances will simply delegate to parents to access methods
  405. or shared state, otherwise idiosyncratic objects, a powerful and natural
  406. concept, will result.  Typical 1 Level objects can contain any number of
  407. fields, methods and parents and any object can be used as a template/exemplar,
  408. thus performing the classical role of a class.  In typical prototyping systems,
  409. parents (as any other member) can be added or changed dynamically, providing
  410. dynamic multiple inheritance (or more typically simple delegation).  Here, the
  411. term "Prototype" usually refers to prototype theory, a recent theory of
  412. classification where any object can be inherited from or cloned to serve as a
  413. prototype for newly created instances.  [The Author also uses the term for
  414. languages providing high quality support for rapid prototyping, although this
  415. usage is atypical]  See [Booch 94, pp 154-155] for a brief discussion of
  416. prototype theory in the context of OOA and OOD.
  417.  
  418. It is common in such systems for an object to "become" another kind of object
  419. by changing its parent.  A good example is a window becoming an icon, as
  420. window and icon objects display different behavior (although cognitive
  421. differences are significant too:-)  Delegation refers to delegating the
  422. search for an attribute to a delegate, and is therefore more of a pure
  423. message passing mechanism (as with dynamic scoping) than inheritance, which
  424. also typically specifies non-shared state when used for representation.
  425.  
  426. Chambers has proposed an interesting variation called "Predicate Classes"
  427. [Chambers 93] as a part of his Cecil language.  These classes will only be
  428. parents when certain predicates are true.  This can support a types/classes
  429. as collections of objects view, which is the same as the types as sets of
  430. values view taken by [Cardelli 85].  [Martin 92] provides some examples of
  431. this view applied during OOA.
  432.  
  433. 1 level systems therefore provide the most flexible and powerful capabilities.
  434. Self is a good example of a delegation-based single hierarchy language [Ungar
  435. 87].
  436.  
  437.  
  438. 1.2)  What Is Object Encapsulation (Or Protection)?
  439. ---------------------------------------------------
  440.  
  441. [Booch 91, p. 45] defines: "Encapsulation is the process of hiding all of the
  442. details of an object that do not contribute to its essential characteristics."
  443.  
  444. [Coad 91, 1.1.2] defines: "Encapsulation (Information Hiding).  A principle,
  445. used when developing an overall program structure, that each component of a 
  446. program should encapsulate or hide a single design decision...  The interface
  447. to each module is defined in such a way as to reveal as little as possible
  448. about its inner workings.  [Oxford, 1986]"
  449.  
  450. Some languages permit arbitrary access to objects and allow methods to be
  451. defined outside of a class as in conventional programming.  Simula and
  452. Object Pascal provide no protection for objects, meaning instance variables
  453. may be accessed wherever visible.  CLOS and Ada allow methods to be defined
  454. outside of a class, providing functions and procedures.  While both CLOS
  455. and Ada have packages for encapsulation, CLOS's are optional while Ada's
  456. methodology clearly specifies class-like encapsulation (Adts).
  457.  
  458. However most object-oriented languages provide a well defined interface to
  459. their objects thru classes.  C++ has a very general encapsulation/protection
  460. mechanism with public, private and protected members.  Public members (member
  461. data and member functions) may be accessed from anywhere.  A Stack's Push and
  462. Pop methods will be public.  Private members are only accessible from within
  463. a class.  A Stack's representation, such as a list or array, will usually be
  464. private.  Protected members are accessible from within a class and also from
  465. within subclasses (also called derived classes).  A Stack's representation
  466. could be declared protected allowing subclass access.  C++ also allows a
  467. class to specify friends (other (sub)classes and functions), that can access
  468. all members (its representation).  Eiffel 3.0 allows exporting access to
  469. specific classes.
  470.  
  471. For another example, Smalltalk's class instance variables are not accessible
  472. from outside of their class (they are not only private, but invisible).
  473. Smalltalk's methods are all public (can be invoked from anywhere), but a
  474. private specifier indicates methods should not be used from outside of the
  475. class.  All Smalltalk instance variables can be accessed by subclasses, 
  476. helping with abstract classes and overriding.
  477.  
  478. Another issue is per-object or per-class protection.  Per-class protection
  479. is most common (e.g. Ada, C++, Eiffel), where class methods can access any
  480. object of that class and not just the receiver.  Methods can only access the
  481. receiver in per-object protection.  This supports a subtyping model, as any
  482. object other than the receiver is only satisfying an abstract type interface,
  483. whereby no method or object structure can be inferred in the general case.
  484.  
  485.  
  486. 1.3  What Is A Class?
  487. --------------------
  488.  
  489. A class is a general term denoting classification and also has a new meaning
  490. in object-oriented methods.  Within the OO context, a class is a specification
  491. of structure (instance variables), behavior (methods), and inheritance
  492. (parents, or recursive structure and behavior) for objects.  As pointed out
  493. above, classes can also specify access permissions for clients and derived
  494. classes, visibility and member lookup resolution.  This is a feature-based or
  495. intensional definition, emphasizing a class as a descriptor/constructor of
  496. objects (as opposed to a collection of objects, as with the more classical
  497. extensional view, which may begin the analysis process).
  498.  
  499. Original Aristotlean classification defines a "class" as a generalization of
  500. objects:
  501. [Booch 91, p93]
  502.   "a group, set, or kind marked by common attributes or a common attribute; a
  503.    group division, distinction, or rating based on quality, degree of
  504.    competence, or condition".
  505.    
  506. [Booch's definition in the context of OOD]
  507.   "A class is a set of objects that share a common structure and a common
  508.   behavior."  "A single object is simply an instance of a class."
  509.  
  510. The intension of a class is its semantics and its extension is its instances
  511. [Martin 92].
  512.  
  513. [Booch 94, 4.2] proposes 3 views of classification as useful in OO analysis and
  514. design: classical categorization (common properties), conceptual clustering
  515. (conceptual descriptions), and prototype theory (resemblance to an exemplar).
  516. He advocates starting with the former approach, turning to the second approach
  517. upon unsatisfactory results, and finally the latter if the first two approaches
  518. fail to suffice.
  519.  
  520.  
  521. 1.4)  What Is A Meta-Class?
  522. ---------------------------
  523.  
  524. [See also section 1.6]
  525.  
  526. A Meta-Class is a class' class.  If a class is an object, then that object
  527. must have a class (in classical OO anyway).  Compilers provide an easy way to
  528. picture Meta-Classes.  Classes must be implemented in some way; perhaps with
  529. dictionaries for methods, instances, and parents and methods to perform all
  530. the work of being a class.  This can be declared in a class named "Meta-Class".
  531. The Meta-Class can also provide services to application programs, such as
  532. returning a set of all methods, instances or parents for review (or even
  533. modification).  [Booch 91, p 119] provides another example in Smalltalk with
  534. timers.  In Smalltalk, the situation is more complex.  To make this easy, refer
  535. to the following listing, which is based on the number of levels of distinct
  536. instantiations:
  537.  
  538. 1 Level System
  539.   All objects can be viewed as classes and all classes can be viewed as
  540.   objects (as in Self).  There is no need for Meta-Classes because objects
  541.   describe themselves.  Also called "single-hierarchy" systems.
  542.   There is only 1 kind of object.
  543. 2 Level System
  544.   All Objects are instances of a Class but Classes are not accessible to
  545.   programs (no Meta-Class except for in the compiler and perhaps for type-safe
  546.   linkage, as in C++).
  547.   There are 2 kinds of distinct objects: objects and classes.
  548. 3 Level System
  549.   All objects are instances of a class and all classes are instances of
  550.   Meta-Class.  The Meta-Class is a class and is therefore an instance of
  551.   itself (really making this a 3 1/2 Level System).  This allows classes to
  552.   be first class objects and therefore classes are available to programs.
  553.   There are 2 kinds of distinct objects (objects and classes), with a
  554.   distinguished class, the metaclass.
  555. 5 Level System
  556.   What Smalltalk provides.  Like a 3 Level System, but there is an extra level
  557.   of specialized Meta-Classes for classes.  There is still a Meta-Class as in 
  558.   a 3 Level System, but as a class it also has a specialized Meta-Class, the
  559.   "Meta-Class class" and this results in a 5 Level System: 
  560.     object
  561.     class
  562.     class class (Smalltalk's Meta-Classes)
  563.     Meta-Class
  564.     Meta-Class class
  565.  
  566.   The "class class"es handle messages to classes, such as constructors and
  567.   "new", and also "class variables" (a term from Smalltalk), which are
  568.   variables shared between all instances of a class (static member data in
  569.   C++).  There are 3 distinct kinds of objects (objects, classes, and
  570.   metaclasses).
  571.  
  572.  
  573. 1.5)  What Is The Infinite Regress Of Objects And Classes?
  574. ----------------------------------------------------------
  575.  
  576. In the authors opinion, a myth.  The story goes an object is an instance of a
  577. class (Meta-Object), a class is an instance of a Meta-Class, which must also
  578. be an instance of a Meta-Meta-Class, which must also be an instance of a Meta-
  579. Meta-Meta-Class, ...  Closure can be achieved with an instance-of loop, as with
  580. a Meta-Class being an instance of itself or with a "Meta-Class - Meta-Class
  581. class" instance-of loop (as in Smalltalk).
  582.  
  583.  
  584. 1.6)  What Are MOPs And Reflection?
  585. -----------------------------------
  586.  
  587. MOP is an acronym for Meta-Object Protocol.  This is a system with
  588. Meta-Classes accessible to users [Kiczales 92, Paepcke 93].  In CLOS
  589. terminology, an introspective protocol provides a read only capability (e.g.
  590. what is this object's class, give info on this class, etc.) and an
  591. intercessory protocol provides a write capability which allows system
  592. modification (e.g. add the following method or instance to this class,
  593. perform inheritance this way, etc.).  Because inheritance can be used to
  594. perform differential changes, intercessory protocols allow users to not
  595. only define new frameworks but to specialize existing system frameworks
  596. differentially without affecting them and their extant objects.  Thus, many
  597. frameworks can interoperate together simultaneously.  This is a good example
  598. of object-oriented reuse, since the compiler itself is reused thru
  599. specialization to provide new frameworks.
  600.  
  601. "Reflective" systems are systems with MOPs (not to be confused with reflexive
  602. systems, which often refer to systems implemented in terms of themselves, or
  603. bootstrapped).  Reflective systems are inevitably reflexive (as are most
  604. quality compilers), providing a direct program interface to the system.
  605.  
  606.  
  607. 1.7)  What Is Inheritance?
  608. --------------------------
  609.  
  610. Inheritance provides a natural classification for kinds of objects and allows
  611. for the commonality of objects to be explicitly taken advantage of in modeling
  612. and constructing object systems.  Natural means we use concepts,
  613. classification, and generalization to understand and deal with the complexities
  614. of the real world.  See the example below using computers.
  615.  
  616. Inheritance is a relationship between classes where one class is the parent
  617. (base/superclass/ancestor/etc.) class of another.  Inheritance provides
  618. programming by extension (as opposed to programming by reinvention
  619. [LaLonde 90]) and can be used as an is-a-kind-of (or is-a) relationship or
  620. for differential programming.  Inheritance can also double for assignment
  621. compatibility (see section 2.7).
  622.  
  623. In delegation languages, such as Self, inheritance is delegation where objects
  624. refer to other objects to respond to messages (environment) and do not
  625. respecify state by default.
  626.  
  627. Inherited parents can specify various flavors of state.  Delegation languages
  628. don't specify new state by default (to do so requires cloning), C-based (C++,
  629. Objective-C, etc.), lisp-based (CLOS, Flavors, Scheme, etc.), and Pascal-based
  630. (Ada95, Modula-3, Object Pascal, etc.) OO languages do, but with multiple-
  631. inheritance can also share parents within a class lattice (CLOS and Eiffel
  632. provide this as a default at the level of slots and features, respectively).
  633.  
  634. Inheritance also provides for member lookup, or internal environment.  Various
  635. schemes exist, for example C++ finds the closest match within a scope but
  636. causes an ambiguity error iff more than one parent has match, CLOS creates
  637. a linear precedence list, Self provides parent priorities, and Eiffel forces
  638. renaming for any parent member conflicts.
  639.  
  640. Defining inheritance (with a thorough description or denotational semantic
  641. definition, or both) can avoid confusion about which inheritance scheme is
  642. being used (especially in OOD), because inheritance has many variations and
  643. combinations of state and environment (sometimes with complex rules).
  644. Inheritance can also be used for typing, where a type or class can be used to
  645. specify required attributes of a matching object (see sections 2.1, 2.7 and
  646. [Cardelli 85]).  It would be more judicious to have discussions on how
  647. inheritance should be defined instead of over what it is, since it has many
  648. existing uses and semantics.
  649.  
  650. An example of the is-a-kind-of relationship is shown below.  Is-a is often
  651. used synonymously, but can be used to show the "object is-a class"
  652. instantiation relationship.  In classical OO, inheritance is a relationship
  653. between classes only.  In one-level systems, is-a (object instantiation) and
  654. is-a-kind-of (inheritance) are merged into one [Ungar 87, Madsen 93, Sciore
  655. 89].
  656.  
  657.                                Computer
  658.                               /    |     \
  659.                        Mainframe  Mini    Personal
  660.                         /    \    ...       /   \
  661.                   Data Proc  Scientific   PC    Workstation
  662.  
  663. Class hierarchies are subjective [Booch 91, 4.2; Lakoff 87] and usually drawn
  664. with the parent class on top, but more demanding graphs (as is often the case
  665. in [Rumbaugh 91]) allow any topology, with the head of an arrow indicating the
  666. base class and the tail indicating the derived class.
  667.  
  668. Differential programming is the use of inheritance to reuse existing classes
  669. by making a small change to a class.  Creating a subclass to alter a method
  670. or to add a method to a parent class is an example.
  671.  
  672.  
  673. 1.8)  What Is Multiple Inheritance?
  674. -----------------------------------
  675.  
  676. Multiple Inheritance occurs when a class inherits from more than one parent.
  677. For example, a person is a mammal and an intellectual_entity, and a document
  678. may be an editable_item and a kind of literature.
  679.  
  680. Mixin's is a style of MI (from flavors) where a class is created to provide
  681. additional attributes or properties to other classes.  They are intended to be
  682. inherited by any class requiring them.  Method combination, or calling
  683. sequences of before, after, and around methods or even several primary methods
  684. [Kim 89, ch 4], make good use of mixins by invoking their methods without
  685. explicitly calling them, allowing client class code to remain unchanged [Booch
  686. 91, p 113].
  687.  
  688.  
  689. 1.9)  Does Multiple Inheritance Pose Any Additional Difficulties?
  690. -----------------------------------------------------------------
  691.  
  692. Yes, it does.  Any name can be simply resolved to a class member with single
  693. inheritance by simply accessing the first name encountered for data members
  694. and by accessing the first signature match (or ambiguity) encountered for
  695. methods (at least one way, C++ hides some member functions).  Since several
  696. distinct parents can declare a member within a multiple inheritance hierarchy,
  697. which to choose becomes an issue.  Eiffel forces derived classes to rename
  698. parent members that conflict.  Self prioritizes parents.  CLOS merges member
  699. "slots" (instance variables) with the same name into a single slot, as did
  700. the earlier flavors.  C++ declares an error iff a conflict arises, but a
  701. class qualifier can be used to explicitly disambiguate.  Smalltalk renders
  702. same names for instance variables of subclasses illegal.
  703.  
  704. On the other hand, multiple-inheritance can be seen as required for basic
  705. object-oriented programming, because many objects in the real world belong to
  706. several classes.  In classical systems without MI, a class which should inherit
  707. from more than one class must textually include all but one of those classes in
  708. its interface, causing code duplication (and a messy interface).
  709.  
  710.  
  711. 1.10)  What Is Dynamic Inheritance?
  712. -----------------------------------
  713.  
  714. Dynamic inheritance allows objects to change and evolve over time.  Since base
  715. classes provide properties and attributes for objects, changing base classes
  716. changes the properties and attributes of a class.  A previous example was a
  717. window changing into an icon and then back again, which involves changing a
  718. base class between a window and icon class.
  719.  
  720. More specifically, dynamic inheritance refers to the ability to add, delete,
  721. or change parents from objects (or classes) at run-time.  Actors, CLOS, and
  722. Smalltalk provide dynamic inheritance in some form or other.  Single hierarchy
  723. systems, such as Self, provide dynamic inheritance in the form of delegation
  724. [Ungar 87].
  725.  
  726. See also [Kim 89, chs 1, 3] for a discussion and [Coplien 92] for some
  727. implementation discussion in C++.
  728.  
  729.  
  730. 1.11)  What Is Shared (Repeated) Inheritance?
  731. ---------------------------------------------
  732.  
  733. Multiple Inheritance brings up the possibility for a class to appear as a
  734. parent more than once in a class graph (repeated inheritance), and there is
  735. then a potential to share that class.  Only one instance of the class will
  736. then appear in the graph (as is always the case in CLOS, because all *members*
  737. with the same name will be shared (receive a single slot) with the greatest
  738. common subtype as its type).  C++ provides an alternative, where only parents
  739. specified as virtual (virtual bases) are shared within the same class lattice,
  740. allowing both shared and non-shared occurrences of a parent to coexist.  All
  741. "features" in Eiffel (C++ members) of a repeated parent that are not to be
  742. shared must be renamed "along an inheritance path", else they are shared by
  743. default.  This allows a finer granularity of control and consistent name
  744. resolution but requires more work for parents with many features.
  745.  
  746.  
  747. 1.12)  Why Use Inheritance?
  748. ---------------------------
  749.  
  750. Inheritance is a natural way to model the world or a domain of discourse,
  751. and so provides a natural model for OOA and OOD (and even OOP).  This is
  752. common in the AI domain, where semantic nets use inheritance to understand
  753. the world by using classes and concepts for generalization and categorization,
  754. by reducing the real-world's inherent complexity.
  755.  
  756. Inheritance also provides for code and structural reuse.  In the above Computer
  757. class diagram, all routines and structure available in class Computer are
  758. available to all subclasses throughout the diagram.  All attributes available
  759. in Personal computers are also available to all of its subclasses.  This kind
  760. of reuse takes advantage of the is-a-kind-of relationship.  Class libraries
  761. also allow reuse between applications, potentially allowing order-of-magnitude
  762. increases in productivity and reductions in defect rates (program errors),
  763. as library classes have already been tested and further use provides further
  764. testing providing even greater reliability.
  765.  
  766. With differential programming, a class does not have to be modified if it is
  767. close to what's required; a derived class can be created to specialize it.
  768. This avoids code redundancy, since code would have to be copied and modified
  769. otherwise.  See [Raj 89] for an alternative approach as found in Jade.
  770.  
  771. Polymorphism is often explicitly available in many OO languages (such as C++,
  772. CLOS, Eiffel, etc.) based on inheritance when type and class are bound together
  773. (typing based on subclassing, or subclass polymorphism), since only an object
  774. which is a member of (inherits from) a class is polymorphically assignment
  775. compatible with (can be used in place of) instances or references of that
  776. class.  Such assignment can result in the loss of an object's dynamic type in
  777. favor of a static type (or even loss of an object's representation to that of
  778. the static class, as in C++ slicing).  Maintaining the dynamic type of objects
  779. can be provided (and preferred); however, C++ provides both sliced and non-
  780. sliced replacement in a statically typed environment (see section 2.1).
  781.  
  782.  
  783. 1.13)  Why Don't Some People Like Inheritance?
  784. ----------------------------------------------
  785.  
  786. Some people complain that inheritance is hierarchical (which is what most
  787. object-oriented languages provide).  They would also like to see more
  788. operations available (set operations are quite common in specialized systems).
  789. The former is a kind of language dependent feature commonly found in object-
  790. oriented languages which are then associated with the term "inheritance"
  791. (although they don't need to be.  For example, delegation languages allow graph
  792. inheritance stuctures).  Some don't like the coupling of classes (as in Jade),
  793. but in the author's opinion many of their complaints are easily answered.  In
  794. systems that provide inheritance, inheritance provides a simple and elegant way
  795. to reuse code and to model the real world in a meaningful way.
  796.  
  797. Others complain multiple inheritance is too complicated because it brings up
  798. the issues of shared bases and member conflict resolution.  But most modern
  799. systems support Multiple Inheritance by employing semantic resolution
  800. strategies or renaming, and most consider MI to be highly desirable.  See the
  801. latter part of section 1.9 for an example of why MI is important.
  802.  
  803. Some prefer association to MI, claiming "roles" (as defined in [Rumbaugh 91])
  804. should be associations and inheritance should be reserved for a single
  805. hierarchy "creation" mechanism, however this loses polymorphism and loses the
  806. use of inheritance for typical classification.  Representation "roles" can be
  807. supported by dynamic multiple inheritance (DMI) in many situations.
  808.  
  809.  
  810. 1.14)  What Is Specialization/Generalization/Overriding?
  811. --------------------------------------------------------
  812.  
  813. To create a subclass is specialization, to factor out common parts of
  814. derived classes into a common base (or parent) is generalization [Booch 91,
  815. p56].  Overriding is the term used in Smalltalk and C++ for redefining a
  816. (virtual in Simula and C++) method in a derived class, thus providing
  817. specialized behavior.  All routines in Smalltalk are overridable and non-
  818. "frozen" features in Eiffel can be "redefined" in a derived class.  Whenever
  819. a method is invoked on an object of the base class, the derived class method
  820. is executed overriding the base class method, if any.  Overriding in Simula
  821. is a combination of overloading and multiple-polymorphism because parameters do
  822. not have to be declared.  Eiffel and BETA are examples of languages allowing
  823. any member to be redefined and not just methods, as is typical.
  824.  
  825.  
  826. 1.15)  What Is The Difference Between Object-Based And Object-Oriented?
  827. -----------------------------------------------------------------------
  828.  
  829. Object-Based Programming usually refers to objects without inheritance
  830. [Cardelli 85] and hence without polymorphism, as in '83 Ada and Modula-2.
  831. These languages support abstract data types (Adts) and not classes, which
  832. provide inheritance and polymorphism.  Ada95 and Modula-3; however, support
  833. both inheritance and polymorphism and are object-oriented.  [Cardelli 85, p481]
  834. state "that a language is object-oriented if and only if it satisfies the
  835. following requirements:
  836.  
  837.   - It supports objects that are data abstractions with an interface of named
  838.     operations and a hidden local state.
  839.   - Objects have an associated type.
  840.   - Types may inherit attributes from supertypes.
  841.  
  842.   object-oriented = data abstractions + object types + type inheritance
  843.  
  844. These definitions are also found in [Booch 91, Ch2 and Wegner 87].
  845.  
  846. [Coad 91] provides another model:
  847.  
  848.   Object-Oriented = Classes and Objects 
  849.                     + Inheritance 
  850.                     + Communication with messages
  851.  
  852. Stroustrup's first edition of [Stroustrup 91, '86 p. 37] defines object based
  853. as: "... storing type identification in each object, brings us to a style of
  854. programming often referred to as "object based"", which is quite different
  855. from C+W's.
  856.  
  857. A more modern definition of "object-oriented" includes single-hierarchy
  858. languages and perhaps object id's for unique objects.  Object id's support the
  859. modern notion of relocatable, persistent and distributed objects that can
  860. even migrate across machines.  Distributed Smalltalk's proxy objects [Kim 89,
  861. ch 19 and Yaoqing 93] provide another example of a distributable and migratable
  862. object facility.  Separate type system support is another extension.
  863.  
  864. [Booch 94, 2.2] proposes 7 "Elements of the Object Model"; 4 major and 3 minor:
  865.   Major:
  866.     Abstraction
  867.     Encapsulation
  868.     Modularity
  869.     Hierarchy  (Inheritance)
  870.   Minor:
  871.     Typing
  872.     Concurrency
  873.     Persistence
  874.  
  875.  
  876. 1.16)  Is A Class An Object?
  877. ----------------------------
  878.  
  879. In C++ no, because C++ classes are not instances of an accessible class (a
  880. Meta-Class) and because C++ classes are not accessible to programs.  Classes
  881. are objects in 3 Level Systems and above because classes are instances of
  882. meta-classes.  But classes play a dual role, because objects can only be
  883. declared to be instances of a class (and class objects instances of a
  884. meta-class).  In 1 Level (single-hierarchy) systems, all classes are objects.
  885.  
  886.  
  887. 1.17)  Is An Object A Class?
  888. ----------------------------
  889.  
  890. In a Level 3 System and above yes, but only instances of a Meta-Class are
  891. Classes.  Instances of a Class (ordinary objects) are not classes (excluding
  892. hybrid systems).  However, all objects may be classes in single hierarchy
  893. systems, since any object may act as a class (provide object instantiation or
  894. act as a shared parent).
  895.  
  896.  
  897. 1.18)  What Is A Method? (And Receiver And Message)
  898. ---------------------------------------------------
  899.  
  900. A method implements behavior, which is defined by [Booch 91, p80]:
  901.  
  902.   Behavior is how an object acts and reacts, in terms of its state changes
  903.   and message passing.
  904.  
  905. A method is a function or procedure which is defined in a class and typically
  906. can access the internal state of an object of that class to perform some
  907. operation.  It can be thought of as a procedure with the first parameter as
  908. the object to work on.  This object is called the receiver, which is the object
  909. the method operates on.  An exception exists with C++'s static member functions
  910. which do not have a receiver, or "this" pointer.  The following are some common
  911. notations for invoking a method, and this invocation can be called a message
  912. (or message passing, see below):
  913.  
  914.   receiver.message_name(a1, a2, a3)   
  915.   receiver message_name: a1 parm1: a2 parm3: a3
  916.  
  917. Selector would be another good choice for message_name in the above examples,
  918. although keywords (or formal parameter names, like named parameters) are
  919. considered part of the selector in Smalltalk (and hence Objective-C).
  920.  
  921. If done statically, this can be referred to as invocation, and message passing
  922. if done dynamically (true dynamic binding).  Statically typed dynamic binding
  923. (e.g. C++ and Eiffel) is really in between (checked function pointers).
  924.  
  925. See also section 1.19 below for a discussion on the functional (prefix) verses
  926. message based (receiver based) notation.
  927.  
  928.  
  929. 1.19)  What Are Multi-Methods And Multiple-Polymorphism?
  930. --------------------------------------------------------
  931.  
  932. Multi-methods involve two primary concepts, multiple-polymorphism and lack of
  933. encapsulation.  These issues are orthogonal.  Multiple-polymorphism implies
  934. more than one parameter can be used in the selection of a method.  Lack of
  935. encapsulation implies all arguments can be accessed by a multi-method (although
  936. packages can be used to restrict access, as in CLOS).  Multi-methods can also
  937. imply a functional prefix notation, although the CLOS designers (who coined the
  938. term "multi-method") consider the functional and receiver based forms
  939. (messages) equivalent.  Functional syntax was chosen "in order to minimize the
  940. number of new mechanisms added to COMMON LISP" [Kim ch 4, p70 (D. Moon)].
  941. [Chambers 93] discusses multi-methods in his new OO language, Cecil.
  942.  
  943. Multiple-polymorphism allows specialized functions or methods to be defined to
  944. handle various cases:
  945.  
  946.   +(int, int)
  947.   +(int, float)
  948.   +(int, complex)
  949.   +(int, real)
  950.   +(float, complex)
  951.   +(float, real)
  952.   +(float, float)
  953.  
  954. The above functions are specialized to each of the cases required allowing
  955. single, highly cohesive and loosely coupled functions to be defined.  This is
  956. also the true essence of object-oriented polymorphism, which allows objects to
  957. define methods for each specific case desired.  In addition to better coupling
  958. and cohesion, multiple-polymorphism reduces program complexity by avoiding
  959. coding logic (switch statements) and because small methods further reduce
  960. complexity, as code complexity doesn't grow linearly with lines of code per
  961. method, but perhaps exponentially.  This should be distinguished from double
  962. dispatch, a fancy name for single dispatch after a call, which only provides
  963. switching on a single argument per call (but for 2 levels), consistently
  964. ignoring the inherent type of parameters in messaging.  Double dispatch is
  965. used in languages with static typing for simplicity and efficiency
  966. considerations.
  967.  
  968. If all of the above types are Numbers, code can be written without concern for
  969. the actual classes of objects present:
  970.  
  971.   fn(one, two: Number): Number
  972.     return one + two;
  973.  
  974. The addition expression above will invoke the correct "+" function based on the
  975. inherent (true, actual, or dynamic) types of one and two.  Only the inherent
  976. type of "one" would be used with double dispatch!  In the author's opinion,
  977. this is a serious shortcoming.  Further, double dispatch would only allow
  978. switching to the "fn" function based on the type of "one" also.  This could
  979. lead to the use of switch statements based on type or complex coding in many
  980. real-world programming situations, unnecessarily.  In the author's opinion,
  981. this should only be used as necessary, e.g. if the implementation language
  982. doesn't support multiple-polymorphism and either efficiency considerations
  983. dominate and double dispatch can be suffered, or an embedded dynamic typing
  984. scheme is used.
  985.  
  986. Why do multi-methods allow open access to parameters?  It allows efficient
  987. handling, like C++ friends, usually by allowing representation details of more
  988. than one object to be exposed.  See [Kim ch 4, pp70-71 (D. Moon)] for an
  989. alternative explanation.  While open access can be useful in some cases, it
  990. typically isn't recommended as a general OO practice (see section 1.15, C+W's
  991. requirement 1 for OO languages and Section 1.2 on Encapsulation) and also
  992. violates subtype polymorphism, because only subclass polymorphism is based on
  993. representation and not type.
  994.  
  995. Polymorphic languages can be statically typed to provide strong type checking,
  996. efficiency, and to support a static programming idiom, but require restrictions
  997. in many cases, such as requiring overriding methods to have identical
  998. signatures with the methods they substitute (as in C++) or allowing covariant
  999. parameters but limiting base class usage (as in Eiffel).  If these restrictions
  1000. are dropped, multiple-polymorphism results.  Thus a single overridable function
  1001. declared in a base class may have several functions overriding it in a derived
  1002. class differentiated only by their formal argument types.  This therefore
  1003. requires both static and dynamic typing, because no formal argument
  1004. differentiation is possible without static types, as in Smalltalk, and no
  1005. actual argument differentiation is possible without dynamic types (as in C++
  1006. and Eiffel).  See section 2.3 for another example of multiple-polymorphism.
  1007.  
  1008. There is some concern about the efficiency of run-time method selection as
  1009. can occur with multiple-polymorphism (or even dynamic message passing).
  1010. However, static analysis optimizations are commonly available in the
  1011. literature, potentially providing a single static selection in many cases
  1012. [See Agrawal 91, Chambers 92, Mugridge 91, and etc.].
  1013.  
  1014. But coupling the two cases of selector variables (as found in CLOS,
  1015. Objective-C, and etc.) and several possible known selectors together with the
  1016. general undecidability of dynamic types at compile-time renders dynamic typing
  1017. and run-time selection (or checking) as unavoidable in the general case [a
  1018. point often mistaken in comp.object.  E.g. simple statically/strongly typed
  1019. multi-methods still require dynamic types!]
  1020.  
  1021. See [Booch 91], multiple-polymorphism, for a good CLOS example.
  1022.  
  1023.  
  1024. 1.20)  What Is OOP?
  1025. -------------------
  1026.  
  1027. OOP stands for Object-Oriented Programming, the usual programming/hacking and
  1028. etc. most programmers think of.  Modern software engineering methodologies;
  1029. however, consider OOP as the implementation/evolution of an OOD.
  1030.  
  1031.  
  1032. 1.21)  What Is OOA/OOD (And Where Can I Get What I Need On It)?
  1033. ---------------------------------------------------------------
  1034.  
  1035.   See also section 3.7, the Annotated Bibliography, and APPENDIX D.  The
  1036.   classified bibliography in [Booch 94] also contains entries on OOA(B), OOD(F)
  1037.   and OOP(G).
  1038.  
  1039. [Booch 91]
  1040.   "In OOA, we seek to model the world by identifying the classes and objects
  1041.   that form the vocabulary of the problem domain, and in OOD, we invent the
  1042.   abstractions and mechanisms that provide the behavior that this model
  1043.   requires."
  1044.  
  1045. [Coad 91]
  1046.   "OOA is the challenge of understanding the problem domain, and then the
  1047.   system's responsibilities in that light".
  1048.   "To us, analysis is the study of a problem domain, leading to a specification
  1049.   of externally observable behavior; a complete, consistent, and feasible
  1050.   statement of what is needed; a coverage of both functional and quantified
  1051.   operational characteristics (e.g. reliability, availability, performance)".
  1052.   "Design.  The practise of taking a specification of externally available
  1053.   behavior and adding details needed for actual computer system implementation,
  1054.   including human interaction, task management, and data management details."
  1055.  
  1056. ############################################################################
  1057.  
  1058.  
  1059. Path: senator-bedfellow.mit.edu!faqserv
  1060. From: Bob Hathaway <rjh@geodesic.com>
  1061. Newsgroups: comp.object,comp.answers,news.answers
  1062. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Part 2/13
  1063. Supersedes: <object-faq/part2_805979999@rtfm.mit.edu>
  1064. Followup-To: comp.object
  1065. Date: 31 Aug 1995 15:32:33 GMT
  1066. Organization: Geodesic Systems
  1067. Lines: 1003
  1068. Approved: news-answers-request@MIT.Edu
  1069. Distribution: world
  1070. Expires: 14 Oct 1995 15:31:54 GMT
  1071. Message-ID: <object-faq/part2_809883114@rtfm.mit.edu>
  1072. References: <object-faq/part1_809883114@rtfm.mit.edu>
  1073. NNTP-Posting-Host: bloom-picayune.mit.edu
  1074. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  1075. X-Last-Updated: 1995/06/01
  1076. Originator: faqserv@bloom-picayune.MIT.EDU
  1077. Xref: senator-bedfellow.mit.edu comp.object:37584 comp.answers:13972 news.answers:51853
  1078.  
  1079. Archive-name: object-faq/part2
  1080. Last-Modified: 05/31/94
  1081. Version: 1.0.8
  1082.  
  1083. And on Domain Analysis:
  1084.  
  1085.   "Whereas OOA typically focuses upon one specific problem at a time, domain
  1086.    analysis seeks to identify the classes and objects that are common to all
  1087.    applications within a given domain, [...]".  - [Booch 91]
  1088.  
  1089.   [The following quotes on domain analysis are from [Berard 93]]
  1090.  
  1091.   "An investigation of a specific application area that seeks to identify the
  1092.    operations, objects, and structures that commonly occur in software systems
  1093.    within this area.  - Dan McNicholl
  1094.  
  1095.   "Systems analysis states what is done for a specific problem in a domain
  1096.    while domain analysis states what can be done in a range of problems in a
  1097.    domain.  ...A domain analysis is only useful in many similar systems are to
  1098.    be built so that the cost of the domain analysis can be amortized over the
  1099.    cost of all the systems.
  1100.  
  1101.    The key to reusable software is captured in domain analysis in that it
  1102.    stresses the reusability of analysis and design, not code. - Jim Neighbors
  1103.  
  1104.   "The process of identifying, collecting, organizing, and representing the
  1105.   relevant information in a domain based on the study of existing systems and
  1106.   their development histories, knowledge captured from domain experts,
  1107.   underlying theory, and emerging technology within the domain."  - Kang et al.
  1108.  
  1109.   Object-oriented domain analysis (OODA) seeks to identify reusable items
  1110.   localized around objects, e.g., classes, instances, systems of interacting
  1111.   objects, and kits [frameworks]. OORA analysts and OOD designers will
  1112.   interact on a fairly frequent basis with the domain analysis effort.
  1113.  
  1114.  
  1115. OOA and OOD stand for Object-Oriented Analysis and Object-Oriented Design,
  1116. respectively.  OOA strives to understand and model, in terms of object-oriented
  1117. concepts (objects and classes), a particular problem within a problem domain
  1118. (from its requirements, domain and environment) from a user-oriented or domain
  1119. expert's perspective and with an emphasis on modeling the real-world (the
  1120. system and its context/(user-)environment).  The product, or resultant model,
  1121. of OOA specifies a complete system and a complete set of requirements and
  1122. external interface of the system to be built, often obtained from a domain
  1123. model (e.g. FUSION, Jacobson), scenarios (Rumbaugh), or use-cases (Jacobson).
  1124.  
  1125. [Shlaer 88] is often credited as the first book on OOA, although their method
  1126. adds OO techniques to the traditional structured analysis principles of Yourdon
  1127. and Constantine. Their complete approach ([Shlaer 88, 92]) consists of
  1128. information modeling and recursive design, or OOA/RD and represents a recent
  1129. addition to the structured analysis family (as does Martin and Odell).
  1130. [Yourdon 92] provides a critique, although may only refer to their earlier
  1131. work.  Many other methodologies including Rumbaugh's OMT, Martin and Odell's
  1132. OOA/D, and many others, also share common ground with SA and other existing
  1133. analysis methodologies with such constructs as associations (E-R), functional
  1134. models, and even DFD's.  Booch, Jacobson, and Wirfs-Brock are examples of OO
  1135. methodologies representing a greater departure from the conventional
  1136. "structured" techniques, with greater emphasis on objects.  OOram [Reenskaug
  1137. 91] provides support and emphasis on types and roles as guiding principles,
  1138. which is quite powerful.  [Booch 94] presents a methodology which is an
  1139. evolutionary step beyond the first edition by incorporating a collection of the
  1140. best features from several of the major OO methodologies, as does HP's new
  1141. FUSION methodology.
  1142.  
  1143. The usual progression is from OOA to OOD to OOP (implementation) and this
  1144. Universal Process Model roughly corresponds to the Waterfall Model [Royce 70].
  1145. See [Humphrey 89] and [Yourdon 92] for a few of many discussions on software
  1146. life-cycle models and their use.  Humphrey also details Worldy and Atomic
  1147. Process Models for finer grained analysis and design in the Defined Process
  1148. (see below) and discusses other alternatives to the task oriented models.  He
  1149. also provides the following critisisms on the Waterfall Model which had led to
  1150. Boehm's seminal work on the Spiral Model:
  1151.  
  1152.   * It does not adequately address changes
  1153.   * It assumes a relatively uniform and orderly sequence of development steps
  1154.   * It does not provide for such methods as rapid prototyping or advanced
  1155.     languages
  1156.  
  1157. Modern OO methodologies directly address these points and emphasize the
  1158. incremental, iterative, evolutionary, concurrent and situational nature of
  1159. software development.  [Boehm 86] presents a seminal spiral life-cycle model
  1160. with a risk-driven incremental prototyping approach.  [Booch 91, 6.1]
  1161. proposes a "round-trip gestalt" design with analyze-design iterations and
  1162. an overall system perspective and [Berard 93] proposes an (incremental)
  1163. "parallel-recursive design" with analyze-design-implement-test iterations.
  1164. [Coad 91b] presents the following development cycle breakdown:
  1165.  
  1166.   Waterfall-
  1167.     Analysis
  1168.     Design
  1169.     Programming
  1170.  
  1171.   Spiral-
  1172.     Analysis, prototyping, risk management
  1173.     Design, prototyping, risk management
  1174.     Programming, prototyping, risk management
  1175.     [Boehm, 1988]  
  1176.  
  1177.   Incremental-
  1178.     A little analysis
  1179.     A little design
  1180.     A little programming
  1181.     Repeat
  1182.     [Gilb, 1988]
  1183.  
  1184. [Author's note: The spiral model is often incremental and may waterfall if
  1185.  called for.]
  1186.  
  1187. Since classes and objects are used in all phases of the OO software life-cycle,
  1188. the process is often referred to as seamless, meaning there is no conceptual
  1189. gap between the phases as is often the case in other software development
  1190. methodologies, such as the analysis (DFD's) to design (structure charts) to
  1191. programming gaps found in traditional structured analysis and design.
  1192. Seamlessness together with naturalness is a big advantage for consistency.
  1193.  
  1194. A problem domain has many realizations, or differing OOAs.  An OOA has many
  1195. realizations, or differing OODs, but a similar notation is often used for
  1196. the two.  An OOD also has many realizations, or differing OOPs, but allows a
  1197. selection from among various languages for implementation (choosing the best
  1198. language to implement the design).  But some, such as Bjarne Stroustrup, don't
  1199. like OOA and OOD getting too far from OOP (implementation independent), for
  1200. fear that great discrepancies could occur between OOD and OOP by losing sight
  1201. of the implementation language, which in some cases is predetermined.  See also
  1202. [Stroustrup 91].
  1203.  
  1204. From a greater perspective, the SEI has developed the Capability Maturity Model
  1205. (CMM), a process-based TQM model for assessing the level of an organization's
  1206. software development and which is often required of government contractors
  1207. in the US [Humphrey 89].  The CMM also serves as a 5 level improvement process
  1208. by specifying steps for organizations to progress to the next level, ultimately
  1209. leading to statistical (process) control and sustained improvement.  Watts S.
  1210. Humphrey is now working on the Personal Software Process (PSP), a scaled down
  1211. version of the CMM for individuals [Humphrey 95].  Next should follow a team-
  1212. based software process (TSP?).  Other CMM's in the works at the SEI include a
  1213. personnel management CMM (PM-CMM).
  1214.  
  1215.  Level 1: Initial:    Every project is handled differently; ad hoc and chaotic.
  1216.  Level 2: Repeatable: Every project is handled similarly.
  1217.  Level 3: Defined:    Standard processes are defined and used for all projects.
  1218.  Level 4: Managed:    A measurable basis for all improvements to the process.
  1219.  Level 5: Optimizing: Emphasis on defect prevention and optimizing/continually
  1220.                       improving the process.
  1221.  
  1222. See also:
  1223. Kitson, D.H. and Masters, S. "An Analysis of SEI Software Process Assessment
  1224. Results 1987-1991", CMU/SEI-92-TR-24
  1225.  
  1226. Humphrey, W., Snyder, T. and Willis, R. "Software Process Improvement at
  1227. Hughes Aircraft", IEEE Software, July 1991
  1228.  
  1229. Dion, R., "Elements of a Process Improvement Program," IEEE Software, July
  1230. 1992.
  1231.  
  1232. "Concepts on Measuring the Benefits of Software Process Improvement,"
  1233. CMU/SEI-93-TR-9.
  1234.  
  1235. See also [Yourdon 92], [Wilkie 93], and [Booch 94] for discussions on this
  1236. often cited model.  There is also an ISO 9000 standard applicable to software
  1237. quality and ami working group in Europe creating the SPICE standard (among
  1238. other work), which is similar in scope to the CMM.  To join the ami mailing
  1239. list email to:
  1240.   ami-request@aut.alcatel.at 
  1241. with the following message: 
  1242.   subscribe firstname, lastname, e-mail address.
  1243.  
  1244. Object-oriented analysis now includes "Enterprise Modeling" [Martin 92], also
  1245. found in [Jacobson 92], and along with recent business process "reengineering"
  1246. efforts places information systems within an organizational perspective by
  1247. modeling entire organizations or a large part of them, with the information
  1248. processing system and software products development as integrated components.
  1249. [Yourdon 92] even calls for "global modeling"!
  1250.  
  1251.  
  1252. 1.22)  Where Did Object-Orientation Come From?
  1253. ----------------------------------------------
  1254.  
  1255. Simula was the first object-oriented language providing objects, classes,
  1256. inheritance, and dynamic typing in 1967 (in addition to its Algol-60 subset).
  1257. It was intended as a conveyance of object-oriented design.  Simula 1 was a
  1258. simulation language, and the later general-purpose language Simula 67 is now
  1259. referred to as simply Simula.  Smalltalk was the next major contributor
  1260. including classes, inheritance, a high-powered graphical environment and a
  1261. powerful dynamic typing mechanism (although these existed to some extent in
  1262. Simula).  Self is somewhat of a Smalltalk-based next generation language, as is
  1263. BETA a followup to Simula (by its original designers).
  1264.  
  1265. [Meyer 88] contains a brief summary and history of Simula and Smalltalk, among
  1266. other OO languages.
  1267.  
  1268.  
  1269. 1.23)  What Are The Benefits Of Object-Orientation?
  1270. ---------------------------------------------------
  1271.  
  1272. Reuse, quality, an emphasis on modeling the real world (or a "stronger
  1273. equivalence" with the RW than other methodologies), a consistent and seamless
  1274. OOA/OOD/OOP package, naturalness (our "object concept"), resistance to change,
  1275. encapsulation and abstraction (higher cohesion/lower coupling), and etc.
  1276.  
  1277. On resistance to change, system objects change infrequently while processes
  1278. and procedures (top-down) are frequently changed, providing object-oriented
  1279. systems with more resilient system organization.
  1280.  
  1281. [Harmon 93]:
  1282.   Faster development
  1283.   Increased Quality
  1284.   Easier maintenance
  1285.   Enhanced modifiability
  1286.  
  1287. [Booch 94]:
  1288.   Exploit power of OOPs
  1289.   Reuse of software and designs, frameworks
  1290.   Systems more change resilient, evolvable
  1291.   Reduced development risks for complex systems, integration spread out
  1292.   Appeals to human cognition, naturalness
  1293.  
  1294.  
  1295. 1.24)  What Other FAQs Are Available?
  1296. -------------------------------------
  1297.  
  1298. FAQ's are cross-posted to news.answers and are archived on anonymous ftp from:
  1299.  
  1300.   rtfm.mit.edu:/pub/usenet        (also usenet-by-hierarchy, etc.)
  1301.  
  1302. rtfm archives several FAQs pertinent to OO (alternative/original sites are listed).
  1303.  
  1304.   comp.lang.ada         ajpo.sei.cmu.edu:public/comp-lang-ada/cla-faq[12]
  1305.   comp.lang.beta        ftp.daimi.aau.dk:pub/beta/faq/beta-language-faq.txt
  1306.   comp.lang.c++         sun.soe.clarkson.edu:pub/C++/FAQ [128.153.12.3]
  1307.   comp.lang.clos
  1308.   comp.lang.eiffel      ftp.cm.cf.ac.uk:/pub/eiffel/eiffel-faq
  1309.   comp.lang.modula3
  1310.   comp.lang.oberon
  1311.   comp.lang.objective-c
  1312.   comp.lang.sather      ftp.ICSI.Berkeley.EDU:pub/sather [not on rtfm]
  1313.   comp.lang.scheme      ftp.think.com:/public/think/lisp/scheme-faq.text
  1314.   comp.lang.smalltalk   xcf.Berkeley.EDU:misc/smalltalk/FAQ/SmalltalkFAQ.entire
  1315.   comp.object           zaphod.uchicago.edu:/pub/CompObj8.faq(.Z) (also www)
  1316.   comp.object.logic     ftp.cs.cmu.edu:(2)prg_1.faq,prg_2.faq  [128.2.206.173]
  1317.   comp.software-eng
  1318.  
  1319. Notes:
  1320.   1) xcf.Berkeley.EDU is 128.32.138.1
  1321.   2) /afs/cs.cmu.edu/project/ai-repository/ai/pubs/faqs/prolog/
  1322.   3) BETA FAQ www (most current): http://www.daimi.aau.dk/~beta/FAQ
  1323.                                   http://www.daimi.aau.dk/~beta/info
  1324.      Email: info@mjolner.dk with body: send BETA beta-faq
  1325.   4) Modula-3: ftp.vlsi.polymtl.ca:pub/m3/m3-faq.ps.
  1326.                http://froh.vlsi.polymtl.ca/m3/m3-faq.html.
  1327.      Archives: gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3
  1328.      Newsgroup relay mailing list; message to m3-request@src.dec.com
  1329.   5) comp.lang.eiffel archive: http://www.cm.cf.ac.uk/CLE/archive_index.html
  1330.  
  1331. See APPENDIX E:60 for a CDROM with Internet FAQs.
  1332.  
  1333. A new C++ libraries FAQ is posted monthly to comp.lang.c++ and should be on
  1334. rtfm soon.  Contact cpplibs@trmphrst.demon.co.uk.  It contains anonymous ftp
  1335. sites and commercial libraries and may be merged with this FAQ eventually.
  1336.  
  1337. Many FAQs are also available from mail-servers, however most can be accessed by
  1338. the rtfm mail-server.  Mail to mail-server@rtfm.mit.edu with help and index in
  1339. the body with no leading spaces and on separate lines for more information.
  1340.  
  1341. Example Unix Command (will retrieve this FAQ in about 26 pieces (and growing)):
  1342.   mail mail-server@rtfm.mit.edu
  1343.   Subject:
  1344.   send usenet/comp.object/*
  1345.  
  1346. There is also a great ftp site for sci.virtual-worlds on:
  1347.   stein.u.washington.edu (140.142.56.1)
  1348.           - home of sci.virtual-worlds, huge faq w/ great info!
  1349.           - if unable to use try ftp.u.washington.edu
  1350.           /public/virtual-worlds
  1351.  
  1352. [While VR may not be directly related to comp.object, it is most interesting!
  1353.    - The Author]
  1354.  
  1355.  
  1356. SECTION 2:  TYPING
  1357. ==================
  1358.  
  1359. There are many definitions of type (and class and related concepts).  Many
  1360. authors define the terms as applied by their particular approach or language,
  1361. however we shall proceed in the face of this diversity.
  1362.  
  1363.   References
  1364.     [Blair 89]          Some Typing Topics.
  1365.     [Booch 91]          Small Section on Typing.
  1366.     [Cardelli 85]       Discussion on Object-Oriented Typing.
  1367.     [Gunter 94]         Theoretical Aspects of Object-Oriented Programming.
  1368.     [Kim 89, ch1]       Discussion on Some Research Topics.
  1369.  
  1370.  
  1371. 2.1)  What Is Polymorphism?
  1372. ---------------------------
  1373.  
  1374. Polymorphism is a ubiquitous concept in object-oriented programming and is
  1375. defined in many ways, so many definitions are presented from: Websters',
  1376. Author, Strachey, Cardelli and Wegner, Booch, Meyer, Stroustrup, and Rumbaugh.
  1377. Polymorphism is often considered the most powerful facility of an OOPL.
  1378.  
  1379. > Webster's New World Dictionary:
  1380.  
  1381. Polymorphism 1. State or condition of being polymorphous.  2. Cryall.
  1382.   crystallization into 2 or more chemically identical but
  1383.   crystallographically distinct forms.  3.  Zool., Bot. existence of an
  1384.   animal or plant in several forms or color varieties.
  1385.  
  1386. polymorphous adj. having, assuming, or passing through many or various forms,
  1387.   stages, or the like.  Also, polymorphic. [<Gk polymorphous multiform]
  1388.  
  1389.  
  1390. > Author's Definition:
  1391.  
  1392. Polymorphism is the ability of an object (or reference) to assume (be replaced
  1393. by) or become many different forms of object.  Inheritance (or delegation)
  1394. specifies slightly different or additional structure or behavior for an object,
  1395. and these more specific or additional attributes of an object of a base class
  1396. (or type) when assuming or becoming an object of a derived class characterizes
  1397. object-oriented polymorphism.  This is a special case of parametric
  1398. polymorphism, which allows an object (or reference) to assume or become any
  1399. object (possibly satisfying some implicit or explicit type constraints
  1400. (parametric type), or a common structure), with this common structure being
  1401. provided by base classes or types (subclass and subtype polymorphism,
  1402. respectively).
  1403.  
  1404. "Poly" means "many" and "morph" means "form".  The homograph polymorphism has
  1405. many uses in the sciences, all referring to objects that can take on or assume
  1406. many different forms.  Computer Science refers to Strachey's original
  1407. definitions of polymorphism, as divided into two major forms, parametric and
  1408. ad-hoc.  Cardelli and Wegner followup with another classification scheme,
  1409. adding inclusion polymorphism for subtyping and inheritance.
  1410.  
  1411.  
  1412. > Strachey's Original Definition [Strachey 67]:
  1413.  
  1414. "Parametric polymorphism is obtained when a function works uniformly on a range
  1415. of types; these types normally exhibit some common structure.  Ad-hoc
  1416. polymorphism is obtained when a function works, or appears to work, on several
  1417. different types (which may not exhibit a common structure) and may behave in
  1418. unrelated ways for each type."  
  1419.  
  1420. Parametric polymorphism is also referred to as "true" polymorphism, whereas
  1421. ad-hoc polymorphism isn't (apparent polymorphism).
  1422.  
  1423.  
  1424. > Cardelli and Wegner's Definition [Cardelli 85]:
  1425.  
  1426. C+W refine Strachey's definition by adding "inclusion polymorphism" to model
  1427. subtypes and subclasses (inheritance).  Strachey's parametric polymorphism is
  1428. divided into parametric and inclusion polymorphism, which are closely related,
  1429. but separated to draw a clear distinction between the two forms, which are then
  1430. joined as specializations of the new "Universal" polymorphism.
  1431.  
  1432.                                  |-- parametric
  1433.                  |-- universal --|
  1434.                  |               |-- inclusion
  1435.   polymorphism --|
  1436.                  |               |-- overloading
  1437.                  |-- ad hoc    --|
  1438.                                  |-- coercion
  1439.  
  1440. Polymorphic Languages: some values and variables may have more than one type.
  1441.  
  1442. Polymorphic Functions: functions whose operands (actual parameters) can
  1443.   have more than one type.  [...] If we consider a generic function to be
  1444.   a value, it has many functional types and is therefore polymorphic.
  1445.  
  1446. Polymorphic Types: types whose operations are applicable to operands of more
  1447.   than one type.
  1448.  
  1449. Parametric Polymorphism: a polymorphic function has an implicit or explicit
  1450.   type parameter which determines the type of the argument for each
  1451.   application of that function.
  1452.  
  1453. Inclusion Polymorphism: an object can be viewed as belonging to many different
  1454.   classes that need not be disjoint; that is, there may be inclusion of
  1455.   classes.
  1456.  
  1457. The two forms of "Universal Polymorphism", parametric and inclusion are closely
  1458. related, but are distinct enough in implementation to justify separate
  1459. classifications.
  1460.  
  1461. Parametric polymorphism is referred to as generics.  Generics can be syntactic,
  1462. where each instantiation creates a specialized version of the code allowing
  1463. fast running execution, but in a "true polymorphic system", only a single
  1464. implementation is used.
  1465.  
  1466. On inheritance is subtype polymorphism:
  1467. "Subtyping on record types corresponds to the concept of inheritance
  1468. (subclass) in languages, especially if records are allowed to have functional
  1469. components."
  1470.  
  1471. Author's Notes:
  1472. Implicit parametric polymorphism can be implemented with type inferencing
  1473. schemes [Aho 85].  ML is prototypical in providing this facility.
  1474.  
  1475. Inclusion polymorphism is common and is found in languages such as Simula,
  1476. Ada95, C++, CLOS, Eiffel and etc. (subclass polymorphism).  Smalltalk also
  1477. uses inclusion polymorphism; its used in declaring classes, and subclass
  1478. polymorphism is used in practice but not enforced.  For inheritance, inclusion
  1479. polymorphism specifies an instance of a subclass can appear wherever an
  1480. instance of a superclass is required.  For subtyping (subtype polymorphism),
  1481. the same applies because all operations required by the supertype are present
  1482. in the subtype (subtype is subset of supertype).  Cardelli and Wegner view
  1483. classes as sets of objects (resulting in subtype objects are a subset of
  1484. supertype objects, or an extensional view), as contrasted with a feature based
  1485. (intensional) approach (where subtypes are supersets of (contain) supertypes).
  1486. MI provides an interesting example here, as it is set intersection with an
  1487. extensional view and set union with an intensional view.  Details are left as
  1488. an exercise for the reader.
  1489.  
  1490. Ada generics and C++ templates provide explicit syntactic generics.  While
  1491. Ada may infer some actual generic parameters (operations) and C++ doesn't
  1492. require explicit instantiation of its template functions, formal generic
  1493. parameters must still be declared and many bodies are generated.
  1494.  
  1495. Inclusion polymorphism can refer to subtyping, or having at least as much or
  1496. more than required.  Since derived classes can inherit structure and behavior
  1497. from base classes, such inheritance is an example of inclusion polymorphism
  1498. with respect to representation (subclassing).  An example of inclusion
  1499. polymorphism with respect to assignment (and initialization, or replacement if
  1500. viewed in an almost symbolic way) occurs when object types may be specified and
  1501. assignment is based on actual object membership in that type (often of the CLOS
  1502. is-a-member-of form in OO).  Emerald provides another example of an object-
  1503. oriented language using inclusion polymorphism with respect to replacement;
  1504. however, inclusion is with respect to subtyping only with abstract types
  1505. ("bounded quantification" by C+W.  C+W's parameters are subtype polymorphic
  1506. but lose the inherent type).  Any object possessing all required operations is
  1507. acceptable and no inheritance relation is required (subtype polymorphism).
  1508. They refer to this as "best-fitting" types [Black 86].  The original Trellis/
  1509. Owl also had such a facility but with two separate inheritance hierarchies,
  1510. although it was abandoned in favor of a single class-based approach for
  1511. simplicity.  See also section 2.7.
  1512.  
  1513. [As inclusion polymorphism covers both subtype and subclass polymorphism,
  1514.  perhaps IP could be further divided in C+W's above classification.]
  1515.  
  1516.  
  1517. > Booch's Definition [Booch 91, p. 517]:
  1518.  
  1519. polymorphism  A concept in type theory, according to which a name (such as a
  1520. variable declaration) may denote objects of many different classes that are
  1521. related by some common superclass; thus, any object denoted by this name is
  1522. able to respond to some common set of operations in different ways.
  1523.  
  1524. Booch also has several sections devoted to polymorphism.
  1525.  
  1526. [The author notes Booch's definition above is clearly in the context of
  1527.  conventional, classical OO and subclass polymorphism.]
  1528.  
  1529.  
  1530. > Meyer's Definition [Meyer 88, sect. 10.1.5 Polymorphism]:
  1531.  
  1532. "Polymorphism" means the ability to take several forms.  In object-oriented
  1533. programming, this refers to the ability of an entity to refer at run-time to
  1534. instances of various classes.  In a typed environment such as Eiffel, this is
  1535. constrained by inheritance: ...
  1536.  
  1537. [The Author notes Meyer has a following section 10.1.7 on Static Type,
  1538.  dynamic type, which is relevant, but claims "... there is no way the type
  1539.  of an object can ever change.  Only a reference can be polymorphic: ...".
  1540.  Meyer is clear between the concept and the Eiffel realization in his
  1541.  polymorphism definition above, but here neglects the "becomes" facility
  1542.  as found in several dynamically typed OO languages such as Actors, CLOS,
  1543.  Self and Smalltalk, which allows an object (and not just a reference) to
  1544.  change its class.]
  1545.  
  1546.  
  1547. > Stroustrup's Definition [Stroustrup 90, p. 209]:
  1548.  
  1549. The use of derived classes and virtual functions is often called "object-
  1550. oriented programming".  Furthermore, the ability to call a variety of
  1551. functions using exactly the same interface - as is provided by virtual
  1552. functions - is sometimes called "polymorphism".
  1553.  
  1554. [The Author notes this is a functional view of polymorphism (as provided in
  1555. C++).  [Stroustrup 91, p. 136] has an example of polymorphism with void *'s,
  1556. but a newer template function is incomparably preferable, as implied in
  1557. [Stroustrup 90, ch 14]]
  1558.  
  1559.  
  1560. Rumbaugh's Definition [Rumbaugh 91, p. 2]:
  1561.  
  1562. "Polymorphism" means that the same operation may behave differently on
  1563. different classes.
  1564.  
  1565.  
  1566. 2.2)  What Does Polymorphism Boil Down To In OO Programming Languages?
  1567. ----------------------------------------------------------------------
  1568.  
  1569. In C++, virtual functions provide polymorphism.  This is because a polymorphic
  1570. object (pointer or reference (or such parameter)) is assignment compatible with
  1571. any object of a derived class.  Is this polymorphism in itself?  Objects
  1572. can take on objects of different forms (the derived classes), but of what use
  1573. is it?  To make any difference, the differing forms must have some effect.  In
  1574. dynamically typed languages, polymorphic objects are passed messages and will
  1575. respond in whatever way the object has defined (usually starting from its most
  1576. derived class and working its way up).  But for static objects, a virtual
  1577. function is invoked.  This is the stored method from the derived class that
  1578. overrode the virtual method from its base class, providing specialized behavior
  1579. for the polymorphic object; and hence, polymorphism.  This common pure
  1580. statically typed example is, of course, an example of inclusion polymorphism,
  1581. subclass polymorphism to be more specific (see section 2.1).  Pure statically
  1582. typed subtype polymorphism, as provided in Emerald, can be implemented
  1583. similarly [Black 86].
  1584.  
  1585.  
  1586. 2.3)  What Is Dynamic Binding?
  1587. ------------------------------
  1588.  
  1589. Dynamic binding has two forms, static and dynamic.  Statically-typed dynamic
  1590. binding is found in languages such as C++ (virtual functions) and Eiffel
  1591. (redefinition).  It is not known which function will be called for a virtual
  1592. function at run-time because a derived class may override the function, in
  1593. which case the overriding function must be called.  Statically determining all
  1594. possibilities of usage is undecidable.  When the complete program is compiled,
  1595. all such functions are resolved (statically) for actual objects. Formal object
  1596. usage must have a consistent way of accessing these functions, as achieved thru
  1597. vtables of function pointers in the actual objects (C++) or equivalent,
  1598. providing statically-typed dynamic binding (this is really just defining simple
  1599. function pointers with static typechecking in the base class, and filling them
  1600. in in the derived class, along with offsets to reset the receiver).
  1601.  
  1602. The run-time selection of methods is another case of dynamic binding, meaning
  1603. lookup is performed (bound) at run-time (dynamically).  This is often desired
  1604. and even required in many applications including databases, distributed
  1605. programming and user interaction (e.g. GUIs).  Examples can be found in
  1606. [Garfinkel 93, p80] and [Cox 91, pp 64-67].  To extend Garfinkels example with
  1607. multiple-polymorphism, a cut operation in an Edit submenu may pass the cut
  1608. operation (along with parameters) to any object on the desktop, each of which
  1609. handles the message in its own way (OO).  If an (application) object can cut
  1610. many kinds of objects such as text and graphical objects, multiple-polymorphism
  1611. comes into play, as many overloaded cut methods, one per type of object to be
  1612. cut, are available in the receiving object, the particular method being
  1613. selected based on the actual type of object being cut (which in the GUI case is
  1614. not available until run-time).
  1615.  
  1616. Again, various optimizations exist for dynamic lookup to increase efficiency
  1617. (such as found in [Agrawal 91] and [Chambers 92]).
  1618.  
  1619. Dynamic binding allows new objects and code to be interfaced with or added to
  1620. a system without affecting existing code and eliminates switch statements.
  1621. This removes the spread of knowledge of specific classes throughout a system,
  1622. as each object knows what operation to support.  It also allows a reduction in
  1623. program complexity by replacing a nested construct (switch statement) with a
  1624. simple call.  It also allows small packages of behavior, improving coherence
  1625. and loose coupling.  Another benefit is that code complexity increases not
  1626. linearly but exponentially with lines of code, so that packaging code into
  1627. methods reduces program complexity considerably, even further that removing
  1628. the nested switch statement!  [Martin 92] covers some of these issues.
  1629.  
  1630.  
  1631. 2.4)  Is There A Difference Between Being A Member Or Instance Of A Class?
  1632. --------------------------------------------------------------------------
  1633.  
  1634. Yes (but be careful of context).  To use C++ terminology, an object (not
  1635. a reference) is defined to be an instance of exactly one class (in classical
  1636. OO), called its most derived class.  An object not directly contained in any
  1637. other is called the complete object [Stroustrup 90].  An object is a member
  1638. of several classes, including all of the classes its declared (or most derived)
  1639. class inherits from.  With static typing and inclusion polymorphism based on
  1640. class, if a polymorphic object (or reference) is made to refer to an object,
  1641. that object must be a member of the polymorphic object's class.
  1642.  
  1643. This also provides a good example of differing definitions among object-
  1644. oriented languages, since a member is defined as above in CLOS, but a member of
  1645. a class is one of its instance variables in C++.
  1646.  
  1647.  
  1648. 2.5)  What Is The Difference Between Static And Dynamic Typing?
  1649. ---------------------------------------------------------------
  1650.  
  1651. Static typing refers to types declared in a program at compile-time, so no type
  1652. information is available on objects at run-time.  Dynamic typing uses the
  1653. inherent types of polymorphic objects, keeping track of the types of objects at
  1654. run-time.  Statically typed dynamic binding is a compromise (usually
  1655. implemented with tables of function pointers and offsets), and is how
  1656. statically-typed OO languages provide polymorphism.  Some approaches provide
  1657. both static and dynamic typing, sometimes with static typing providing type-
  1658. safe programs and dynamic typing providing multiple-polymorphism [Agrawal 91]
  1659. [Mugridge 91].  See also section 2.3.
  1660.  
  1661. Static typing is more efficient and reliable, but loses power.  Typical
  1662. restrictions include only allowing a common set of base class functions (or
  1663. any common functions for the more general subtyping or parametric polymorphic
  1664. cases) to be available on formal objects and a lack of multiple-polymorphism
  1665. (see section 1.19), both of which are overcome with dynamic typing.
  1666.  
  1667. Many languages provide dynamic typing: Smalltalk, Self, Objective-C, and etc.
  1668. A limited dynamic typing scheme, called RTTI (Run Time Type Identification),
  1669. is even being considered for the C++ standard.  A similar facility to safe
  1670. downcasting (historically known as type narrowing), the thrust of RTTI, can
  1671. also be found in recent versions of Eiffel.
  1672.  
  1673. See section 3.4 for a categorization of common OO languages by type system.
  1674.  
  1675.  
  1676. 2.6)  What Is This I Hear About ML And Functional Programming Languages?
  1677. ------------------------------------------------------------------------
  1678.  
  1679. ML, Metalanguage, is a functional programming language with a strongly typed
  1680. polymorphic type system [Wikstrom 87].  Russell (see Appendix E) is a more
  1681. recent functional language and Haskell [Hudak 92] provides a more modern and
  1682. "pure" example.  Section 2.5 discusses why static typing has less power/
  1683. flexibility than dynamic typing and the same applies to ML (although see the
  1684. appendixes for an experimental dynamic extension to ML, Alcool-90 and [Cardelli
  1685. 85] for a proper placement of ML's type system).  ML doesn't use inheritance
  1686. for polymorphism; unlike OO languages, but provides the prototypical example of
  1687. parametric polymorphism, so no inheritance is required.  This is "true" or
  1688. "pure" statically (or strongly) checked parametric polymorphism, by Strachey's
  1689. (and Cardelli and Wegner's) definitions.
  1690.  
  1691. Smalltalk is an example of a dynamically-typed language which does not check
  1692. types during assignment (and hence for parameters) and therefore provides
  1693. parametric polymorphism without static constraints (by Strachey's definition).
  1694. However, Smalltalk's style uses inclusion polymorphism in practise and
  1695. inheritance for subclassing (representation).
  1696.  
  1697.  
  1698. 2.7)  What Is A Separation Between Type And Class (Representation)?
  1699. -------------------------------------------------------------------
  1700.  
  1701. For a short answer:
  1702.   Subtype Polymorphism, as opposed to Subclass Polymorphism, is the best answer
  1703.   in OO.  Parametric polymorphism is a related concept where this is also true,
  1704.   but is of a different flavor (and usually requires object attributes by use.
  1705.   See also section 2.1).
  1706.  
  1707. A type can be considered a set of values and a set of operations on those
  1708. values.  This can insure type-safe programming.  However, the representation of
  1709. types (classes in OO) can be separated from the notion of type allowing many
  1710. representations per type while still maintaining reasonable type-safety.
  1711.  
  1712. In many languages, a type has a single representation insuring all operations
  1713. performed on that type are well defined (statically bound) and providing for
  1714. efficiency by taking advantage of that representation wherever used.  In many
  1715. OO languages, subclassing and dynamic binding provides for greater flexibility 
  1716. by providing object specialization.  However, in many OO languages classes are
  1717. used for assignment compatibility forcing an assigned object to inherit
  1718. (transitively) from any polymorphic object's class (inclusion polymorphism
  1719. based on class, or subclass polymorphism).  This insures all operations to be
  1720. performed on any polymorphic object are satisfied by any replacing objects.
  1721. This also insures all types share a common representation, or at least a
  1722. common base interface specification.
  1723.  
  1724. By separating type from class, or representation (or perhaps separating class
  1725. from type, by the aforementioned definition of type), a replacing object must
  1726. satisfy the operations or type constraints of a polymorphic object (subtype
  1727. polymorphism) but are not required to do to do so by an inheritance relation
  1728. (subclass polymorphism), as is typical in most OOPLs.  Dropping this
  1729. restriction is somewhat less type-safe, because accidental matches of method
  1730. signatures can occur, calling for greater care in use.  [Black 86] discusses
  1731. this issue in Emerald.  The same issue arises in parametric polymorphism
  1732. (generics/templates), as any method matching a required signature is accepted,
  1733. calling for careful matching of actual and formal generic parameters.  The
  1734. difference between static and dynamic binding in OO and dynamic binding and
  1735. subtyping seems similar.  A possible loss of semantic integrity/similarity is
  1736. contrasted with greater power.
  1737.  
  1738. It is possible to specify desired abstract properties of type specifications
  1739. with mechanisms similar to Eiffel's pre-, post-, and invariant conditions.
  1740. This helps to insure the semantic integrity of replacing objects and their
  1741. behavior.  [Liskov 93] provides a recent exposition.
  1742.  
  1743. Abstract classes ([Stroustrup 91] and [Meyer 88]) in typing provide a facility
  1744. similar to subtype polymorphism; however, ACs require type compatible classes
  1745. to inherit from them, providing a subclass polymorphism facility, and ACs can
  1746. also specify representation.  Subtyping is therefore most useful to avoid
  1747. spreading knowledge of classes throughout a system, which is a high priority
  1748. for loosely coupled modules and in distributed programming [Black 87].
  1749.  
  1750. The formal type system found in [Cardelli 85], Emerald/Jade [Black 86] and
  1751. [Raj 89], original trellis/Owl, an experimental C++ extension (See Appendix E,
  1752. Signatures), Sather (originally Eiffel-based), and an Eiffel superset
  1753. [Jones 92] are all examples of OO systems providing subtype polymorphism.
  1754. Functional languages such as ML, Russell, and Haskell provide a separation with
  1755. pure parametric polymorphism (as is also commonly found in OO languages in
  1756. addition to inclusion polymorphism).
  1757.  
  1758. See also [Cook 90], "Inheritance Is Not Subtyping", for a formal approach.
  1759.  
  1760.  
  1761. 2.8)  What Are Generics And Templates?
  1762. --------------------------------------
  1763.  
  1764. Short Answer: Parametric Polymorphism (although various implementations
  1765.               provide various subsets).
  1766.  
  1767. Generics (or Templates in C++) refer to the ability to parameterize types
  1768. and functions with types.  This is useful for parameterized classes and
  1769. polymorphic functions as found in languages such as Ada, C++, Eiffel, and
  1770. etc., although these are "syntactic" or restricted forms [Cardelli 85].
  1771. Generics are orthogonal to inheritance, since types (and classes)
  1772. may be generically parameterized.  Generics provide for reusability in
  1773. programming languages.  An example is a Stack with a generically
  1774. parameterized base type.  This allows a single Stack class to provide
  1775. many instantiations such as a Stack of ints, a Stack of any fundamental
  1776. or user defined type, or even a Stack of Stacks of ...  Another example is
  1777. a polymorphic sort function taking a base type with a comparison operator.
  1778. The function can be called with any type (containing a comparison operator).
  1779. See [Booch 87b] for several examples in Ada and [Stroustrup xx] and [Murray
  1780. 93] for examples in C++.
  1781.  
  1782. While generics have many advantages, typical limitations include a static
  1783. nature, which is an advantage for strong typechecking but a potential
  1784. disadvantage when causing dynamic compilation (leading to a time/space
  1785. efficiency tradeoff), and sources can cause inlining and create source code
  1786. dependencies and expand code size (unlike a single-body or "true"
  1787. parametrically polymorphic implementation.  Generics can also be viewed as a
  1788. special case of type variables.
  1789.  
  1790. Functions are typically generic in statically-typed parametrically-polymorphic
  1791. languages.  One such popular functional language is ML, in which all functions
  1792. are generic.  Russell and Haskel are more modern variants (references are
  1793. forthcoming, however see APPENDIX E).
  1794.  
  1795.  
  1796. SECTION 3:  GENERAL
  1797. ===================
  1798.  
  1799.   References:   (many more are to come)
  1800.     [Coplien 92]    Covers C++, symbolic, exemplar (single-hierarchy), etc.
  1801.     [Kim 89]        Covers many OO systems.
  1802.  
  1803.  
  1804. 3.1)  What Is The "Classical" Object-Oriented Paradigm?
  1805. -------------------------------------------------------
  1806.  
  1807. This refers to the usual class and object model.  Its any 2+ level system
  1808. as described in section 1.4.  See also [Coplien 92].
  1809.  
  1810.  
  1811. 3.2)  What Is The "Delegation/Prototyping" Object-Oriented Paradigm?
  1812. --------------------------------------------------------------------
  1813.  
  1814. See [Kim 89, ch 1,3].
  1815.  
  1816. This is the 1 Level System as Described under Meta-Classes.  Delegation refers
  1817. to the delegating of responsibility and can be applied to inheritance.  When a
  1818. derived class does not have a desired attribute, it "delegates" responsibility
  1819. to one of its base classes.  In delegation systems, each object has a delegate
  1820. list instead of a parent list. Thus, delegation's primary emphasis is 
  1821. on message passing where an object could delegate responsibility of a message
  1822. it couldn't handle to objects that potentially could (its delegates).  Any
  1823. object can be added to the delegate list, giving dynamic inheritance (of a
  1824. sort).  Typically, delegation and prototyping languages also have "part
  1825. inheritance" in which fields and methods can be added and deleted from objects.
  1826. This makes for easy "prototyping", which allows for objects to be constructed
  1827. piece by piece at run-time, although the term "prototyping" in the context of
  1828. delegation languages usually refers to objects serving as prototypes for
  1829. object instantiation, or exemplars.
  1830.  
  1831. Next's NextStep OS provides delegation using Objective-C, providing an example
  1832. of delegation in a class-based language [Garfinkel 93].
  1833.  
  1834.  
  1835. 3.3)  Are There Any Other Object-Oriented Paradigms?
  1836. ----------------------------------------------------
  1837.  
  1838. There are many alternatives in OO.  Emerald/Jade ([Black 86] and [Raj 89])
  1839. provides one, where inheritance is replaced with a roughly equivalent form
  1840. where reuse occurs at a finer degree of granularity - method and instance
  1841. variables - with subtype polymorphism making up the difference.
  1842.  
  1843. CLOS [Kim 89, ch 4] has a looser coupling of methods to classes and doesn't
  1844. distinguish a receiver, but packages can help make up the difference.
  1845.  
  1846. Object Specialization [Sciore 89] is an example of a hybrid approach between
  1847. delegation and classical systems, where parent classes have an extra level
  1848. of indirection and inheritance hierarchies are specified on a per object/class
  1849. basis.
  1850.  
  1851.  
  1852. 3.4)  What Are The Major Object-Oriented Programming Languages Today?
  1853. ---------------------------------------------------------------------
  1854.  
  1855. Statically-Typed:
  1856.   Add 1 To Cobol giving Cobol with Objects.
  1857.   C++
  1858.   Classic-Ada
  1859.   Dragoon
  1860.   Emerald/Jade
  1861.   Object Pascal
  1862.   Trellis/Owl
  1863.  
  1864. Dynamically-Typed:
  1865.   Actors Languages
  1866.   C+@
  1867.   Flavors
  1868.   Self
  1869.   Smalltalk
  1870.  
  1871. Both:
  1872.   Actor
  1873.   Ada95
  1874.   BETA
  1875.   C++ (With RTTI)
  1876.   Cecil
  1877.   CLOS
  1878.   Eiffel
  1879.   Modula-3
  1880.   Objective-C
  1881.   Sather
  1882.  
  1883.  
  1884. 3.5)  What Are Object-Oriented Databases And Persistence?
  1885. ---------------------------------------------------------
  1886.  
  1887. See also Appendices B and E and the comp.database.object newsgroup.
  1888. Refs to be included in future FAQs.
  1889.  
  1890. Object-Oriented Databases are databases that support objects and classes.  They
  1891. are different from the more traditional relational databases because they allow
  1892. structured subobjects, each object has its own identity, or object-id (as
  1893. opposed to a purely value-oriented approach) and because of support for methods
  1894. and inheritance.  It is also possible to provide relational operations on an
  1895. object-oriented database.  OODBs allow all the benefits of object-orientation,
  1896. as well as the ability to have a strong equivalence with object-oriented
  1897. programs, an equivalence that would be lost if an alternative were chosen, as
  1898. with a purely relational database.
  1899.  
  1900. Another way of looking at Object-Oriented Databases is as a persistent object
  1901. store with a DBMS.
  1902.  
  1903. Persistence is often defined as objects (and their classes in the case of
  1904. OODBs) that outlive the programs that create them.  Object lifetimes can be
  1905. viewed as a hierarchy, with locals/automatics having the shortest default
  1906. lifetime and objects stored indefinitely in an OODB (which are persistent)
  1907. having the longest.  Persistent object stores do not support query or
  1908. interactive user interface facilities, as found in a fully supported OODBMS.
  1909.  
  1910. Appendix B also contains references for object-oriented interfaces to
  1911. relational databases and see APPENDIX E, Papers, Persistent Operating Systems.
  1912.  
  1913. From the net:
  1914. From: dbmsfacts@aol.com (DBMSfacts)
  1915. Subject: ODMG Gopher and Web Addresses
  1916. Date: 24 Oct 1994 13:10:02 -0400
  1917.  
  1918. The Object Database Management Group (ODMG) has set up Gopher and Web
  1919. Servers at the following addresses:
  1920.  
  1921.   Gopher:  gopher.odmg.org, port 2073
  1922.   WWW:  http://www.odmg.org:3083
  1923.  
  1924. These are still under construction.  What you can find right now are
  1925. addresses and contact information for ODBMS vendors, ODMG membership
  1926. information, updates to Release 1.1 of The Object Database Standard:
  1927. ODMG-93 along with ODL lex and yacc files.  In the future, we will be
  1928. adding more links to related sites, bibliographies, and a FAQ for ODBMSs. 
  1929.  
  1930. If you cannot access these servers, but would like information on the
  1931. ODMG, send an email message to info@odmg.org and you will receive an
  1932. automated reply.
  1933.  
  1934. Doug Barry
  1935. ODMG Executive Director
  1936.  
  1937.  
  1938. 3.6)  What Are Object-Oriented Operating Systems?
  1939. -------------------------------------------------
  1940.  
  1941. Refs to be included in future FAQs.  See also Appendix E.
  1942.  
  1943. Object-Oriented Operating Systems provide resources through objects, sometimes
  1944. all the way down to to the machine (OO architectures are found at the bottom).
  1945. They are almost always distributed systems (DOS or DPOS), allowing objects to
  1946. be passed freely between machines.  They are typically capability-based since
  1947. objects, and hence system resources, can only be accessed if a capability to
  1948. them is available to programs.
  1949.  
  1950. Here are some abstracts taken from several postings to the net.  This list is
  1951. by no means exhaustive.
  1952.  
  1953. Apertos (Meta-Object-based Mikro-Kernel.  See Appendix E, Papers:28)
  1954. Chorus Micro-kernel (written in C++, COOL, See Appendix E, Papers:63)
  1955. Choices (research OS, UofI, C++, supports SVR4, See Appendix E, Papers)
  1956. GEOS    (GeoWorks', written in Object Assembler, OO superset of 8086) 
  1957. Mach    (CMU, supports BSD 4.3, really message-based)
  1958. NachOS  (written in C++, OS teaching/learning OS)
  1959. Ouverture Project (ESPRIT funded OMG IDL defines inter-module interfaces)
  1960. Peace    (OO family-based parallel OS, See Appendix E, General)
  1961. SOS
  1962. Spring      (Sun, written in C++)
  1963. PenPoint OS (Go, written in C++)
  1964.  
  1965. For the Spring Papers (free), Contact:
  1966.   Sun Microsystems Laboratories, Inc.
  1967.   M/S 29-01
  1968.   2550 Garcia Avenue
  1969.   Mountain View, CA USA  94043
  1970.  
  1971. See also APPENDIX E, PAPERS, Persistent Operating Systems entry.
  1972.  
  1973. From: whitney@oberon.Meakins.McGill.CA ()
  1974.  
  1975. Insight ETHOS: On Object-Orientation in Operating Systems
  1976. ISBN 3 72811948 2
  1977.  
  1978. This thesis covers the design of an extensible object-oriented 
  1979. operating systems. The language used was Oberon-2. It includes
  1980. a generalization of the Rider/Carrier principle, Object Directories
  1981. as well as basic OS issues such as memory, file, tasking management. 
  1982. It covers extensible objected-oriented programming from hardware up.
  1983. It reviews other designs such as Clouds and Choices which where written
  1984. It reviews other designs such as Clouds and Choices which where written
  1985. on C++. [[ The lack of type-tests in C++ was a problem in other designs.]]
  1986. ETHOS was implemented as an operating system for the Ceres computers
  1987. at the ETH. 
  1988.  
  1989.  
  1990. 3.7)  What Are The Current Object-Oriented Methodologies?
  1991. ---------------------------------------------------------
  1992.  
  1993. Here is a list of OOSE Methodologies:
  1994.  
  1995.   Berard                        [Berard 93]
  1996.   BON                           [Nerson 92]
  1997.   Booch                         [Booch 94]
  1998.   Coad/Yourdon                  [Coad 91]
  1999.   Colbert                       [Colbert 89]
  2000.   de Champeaux                  [de Champeaux 93]
  2001.   Embley                        [Embley 92]
  2002.   EVB                           [Jurik 92]
  2003.   FUSION                        [Coleman 94]
  2004.   HOOD                          [HOOD 89]
  2005.   IBM                           [IBM 90,91]
  2006.   Jacobson                      [Jacobson 92]
  2007.   Martin/Odell                  [Martin 92]
  2008.   Reenskaug (OOram, was OORASS) [Reenskaug 91]
  2009.   ROOM                          [Selic 94]
  2010.   Rumbaugh et al.               [Rumbaugh 91]
  2011.   Shlaer and Mellor             [Shlaer 88 and 92]
  2012.   Wasserman                     [Wasserman 90]
  2013.   Winter Partners (OSMOSYS)     [Winter Partners]
  2014.   Wirfs-Brock et al.            [Wirfs-Brock 90]
  2015.  
  2016. Further Ideas And Techniques:
  2017.   Meyer                         [Meyer 88]
  2018.   Stroustrup                    [Stroustrup 91]
  2019.  
  2020. See APPENDIX D for CASE systems supporting these methodologies (several from
  2021. the originators themselves).
  2022.  
  2023. See also section 1.21 for a discussion on OOA/OOD and etc.
  2024.  
  2025. Summaries and comparisons will be provided in future FAQs.  Suggestions for
  2026. inclusion of other major or new methodologies should be sent to the FAQ author.
  2027.  
  2028. Here are some comparison studies posted to the net:
  2029.  
  2030. Arnold, P., Bodoff, S., Coleman, D., Gilchrist, H., Hayes, F., An Evolution of 
  2031. Five Object Oriented Development Methods, Research report, HP Laboratories, 
  2032. June 1991
  2033.  
  2034. de Champeaux, Dennis and Faure, Penelope. A comparative study of object-
  2035. oriented analysis methods. Journal of Object Oriented Programming (JOOP), pp
  2036. 21-32.  Vol.5, No. 1, 3/4-92
  2037.  
  2038. Fichman R.G. & Kemerer C.F.  OO and Conventional Analysis and Design
  2039. Methodologies.  Computer, Oct 1992, Vol 25, No. 10, p 22-40
  2040.  
  2041. Fichman, Robert and Kemerer, Chris. Object-Oriented and Conventional Analysis
  2042. and Design Methods - Comparison and Critique.  IEEE-Comp, Oct, 1992, pp 22-39.
  2043. OOA, OOD, conventional analysis, conventional design, DeMarco SA, Yourdon SA,
  2044. Bailin OO requirements specification, Coad-Yourdon OOA, Shlaer-Mellor OOA,
  2045. Yourdon-Constantine SD, Martin information engineering design, Wasserman OOSD,
  2046. Booch OOD, Wirfs-Brock responsibility-driven design.
  2047.  
  2048. The following 2 reports are out of print. 
  2049.  
  2050. [van den Goor et.al., 1992]
  2051. G. van den Goor, S. Hong and S. Brinkkemper, 
  2052. A Comparison of Six Object-oriented Analysis and Design Methods. Report
  2053. Center of Telematics and Information Technology, University of Twente,
  2054. the Netherlands, and Computer Information Systems Department, Georgia 
  2055. State University, Atlanta, USA, 1992, 163 pages.
  2056.  
  2057. [Hong et.al. 1992]
  2058. S. Hong, G. van den Goor, S. Brinkkemper, A Formal Approach to the 
  2059. Comparison of Object Oriented Analysis and Design Methodologies, Hawaii 
  2060. International Conference on System Sciences (HICSS) (IEEE Computer Society 
  2061. Press, Hawaii) 1993, Vol. IV, pp. 689-698.
  2062.  
  2063.  [From Shuguang...] readers may download the paper if they want, though they
  2064.  may continue to request hard copies.  We are currently extending the paper
  2065.  to compare ten OO methods and should be available shortly.
  2066.  My URL is: http://cis.gsu.edu/~shong
  2067.  
  2068.   ===================================================================
  2069.   *  Shuguang Hong, Ph.D.                    cisssh@gsusgi2.gsu.edu *
  2070.   *  Computer Information Systems Dept.      Tel: (404)651-3887     *
  2071.   *  College of Business Administration      Fax: (404)651-3842     *
  2072.   *  Georgia State University                                       *
  2073.   *  Atlanta, GA 30302-4015         www: http://cis.gsu.edu/~shong/ *
  2074.   ===================================================================
  2075.  
  2076. Monarchi, David and Puhr, Gretchen I. A Research Typology for Object-Oriented
  2077. Analysis and Design.  CACM/September 1992/Vol.35, No.9, pp35.
  2078.  
  2079. [Wilkie 93] summarizes, compares, and provides examples of Booch, Wirfs-Brock,
  2080. Hood, Coad and Yourdon, Winter Partners, Shlaer and Mellor, Jacobson,
  2081. Wasserman et al, Rumbaugh, Reenskaug et al, and Colbert.
  2082.  
  2083. ############################################################################
  2084.  
  2085.  
  2086. Path: senator-bedfellow.mit.edu!faqserv
  2087. From: Bob Hathaway <rjh@geodesic.com>
  2088. Newsgroups: comp.object,comp.answers,news.answers
  2089. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Part 3/13
  2090. Supersedes: <object-faq/part3_805979999@rtfm.mit.edu>
  2091. Followup-To: comp.object
  2092. Date: 31 Aug 1995 15:32:35 GMT
  2093. Organization: Geodesic Systems
  2094. Lines: 1173
  2095. Approved: news-answers-request@MIT.Edu
  2096. Distribution: world
  2097. Expires: 14 Oct 1995 15:31:54 GMT
  2098. Message-ID: <object-faq/part3_809883114@rtfm.mit.edu>
  2099. References: <object-faq/part2_809883114@rtfm.mit.edu>
  2100. NNTP-Posting-Host: bloom-picayune.mit.edu
  2101. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  2102. X-Last-Updated: 1995/06/01
  2103. Originator: faqserv@bloom-picayune.MIT.EDU
  2104. Xref: senator-bedfellow.mit.edu comp.object:37585 comp.answers:13973 news.answers:51854
  2105.  
  2106. Archive-name: object-faq/part3
  2107. Last-Modified: 05/31/94
  2108. Version: 1.0.8
  2109.  
  2110. Wirfs-Brock, R.J. and Johnson, R.E., "Surveying Current Research in Object-
  2111. Oriented Design," The Communications of ACM, (33, 9) Sept. 1990, pp. 104-1124.
  2112.  
  2113. UNICOM. Approaches to Object-Oriented Analysis and Design.
  2114. tel: l 44 895 256 484. Ask the TOC and have a look at it.
  2115.  
  2116.  
  2117. Also commercially available:
  2118.  
  2119. An Evaluation of Object-Oriented Analysis and Design Methodologies (9)
  2120. J. Cribbs, C Roe, S. Moon
  2121. SIGS Books
  2122. (212) 274-0640
  2123. $149.
  2124.  
  2125. Object-Oriented Methodology Comparison Study (10 methodologies)
  2126. Berard, Booch, Coad/Yourdon, Colbert, Embley, IBM, Martin/Odell, Rumbaugh,
  2127. Shlaer/Mellor, Wirfs-Brock.  Also contains refs to several previous studies.
  2128. Berard Software Engineering
  2129. 101 Lakeforest Blvd., Suite 360, Gaithersburg, MD 20877
  2130. Contact Person: Jim Youlio
  2131. Phone:        301-417-9884
  2132. Fax:          301-417-0021
  2133. email:        info@bse.com
  2134.  
  2135. [Hong et.al. 1992], [van den Goor et.al., 1992]
  2136. The authors have prepared a revision (See above) that includes the following OO 
  2137. methods:
  2138.  
  2139. Booch, G. - Object-oriented analysis and design with applications, 1994.
  2140. Champeaux, D. de - Object-oriented system development, 1993.
  2141. Coad, P., and Yourdon, E. - Object-oriented analysis (2nd edition), 1991a.
  2142. Coad, P., and Yourdon, E. - Object-oriented design, 1991b.
  2143. Coleman, D. - Object-oriented development, the Fusion method, 1994. 
  2144. Henderson-Sellers, B. and Edwards, J.M. - Methodology for Object-oriented 
  2145. Software 
  2146. Engineering of Systems, draft manuscript, 1994.
  2147. Jacobson, I. - Object-oriented software engineering, 1993.
  2148. Martin, J., Odell, J. - Object-oriented analysis and design, 1992.
  2149. Martin, J., Odell, J. - Principles of object-oriented analysis and design, 
  2150. 1993.
  2151. Rumbaugh, J. et.al. - Object-oriented modeling and design, 1991.
  2152. Shlaer, S., Mellor, S.J. - Object-oriented systems analysis: Modeling the 
  2153. world in states, 1992.
  2154. Wirfs-Brock, R. et.al. - Designing object-oriented software, 1990.
  2155.  
  2156. We are currently approaching publishers for the publication of this report 
  2157. as a book. This book should be out in the spring of 1995.
  2158.  
  2159. If you are interested in obtaining this book you can send an e-mail to 
  2160. Sjaak Brinkkemper (sjbr@cs.utwente.nl), which we will forward to the 
  2161. publisher.
  2162.  
  2163. The authors, regretfully, cannot supply ftp, postscript, TEX, or 
  2164. whatsoever.
  2165.  
  2166.  
  2167. 3.8)  What Is the OMG/OMA/ORB/CORBA?
  2168. ------------------------------------
  2169.  
  2170. Contents:
  2171.   (3.8.1)  Contact Information
  2172.   (3.8.2)  OMG Summary
  2173.   (3.8.3)  Mail Server Access
  2174.   (3.8.4)  OMG Publications
  2175.              - First Class (Bi-Monthly Newsletter)
  2176.              - Object Management Architecture Guide (OMA)
  2177.              - The Common Object Request Broker: Arch. and Spec. (Corba)
  2178.              - Pricing
  2179.   (3.8.5)  Implementations (Brief)
  2180.   (3.8.6)  Implementation Descriptions
  2181.   (3.8.7)  Books, Articles, And Literature
  2182.  
  2183.  
  2184. 3.8.1  Contact Information
  2185. __________________________
  2186.  
  2187. Contact Person: Richard Soley (technical director) soley@omg.com
  2188.  
  2189. FTP Sites: 
  2190.   omg.org:pub/*
  2191.   omg.org:pub/NEC_DII/93-1-2.tar...            *CORBA (DII) (corba.ps.Z)
  2192.   omg.org:pub/OMG_IDL_CFE_1.2/bin*              idl.SunOS4.x, idl.Solaris2.x
  2193.   claude.ifi.unizh.ch:under pub/standards/spec  CORBA Spec
  2194.  
  2195. Headquarters:                            Marketing Office:
  2196.   492 Old Connecticut Path                 3823 Birchwood Drive
  2197.   Framingham, MA 01701                     Boulder, CO  80304
  2198.   Tel: 508-820-4300                        Tel: 303-444-8129
  2199.   Fax: 508-820-4303                        Fax: 303-444-8172
  2200.  
  2201.  
  2202. 3.8.2  OMG Summary
  2203. __________________
  2204.  
  2205. From: soley@emerald.omg.ORG (Richard Mark Soley)
  2206. Subject: OMG
  2207.  
  2208. In answer to your general question about the OMG, here's a brief overview.
  2209. Feel free to call, fax or email for more information.
  2210.  
  2211.         -- Richard Soley
  2212.            Vice President & Technical Director
  2213.            Object Management Group, Inc.
  2214.            and coincidentally, MIT '82, SM '85, PhD '89 (EECS)
  2215.  
  2216. The Object Management Group (OMG) is an international software industry
  2217. consortium with two primary aims:
  2218.  
  2219. (*) promotion of the object-oriented approach to software engineering
  2220.     in general, and
  2221.  
  2222. (*) development of command models and a common interface for the development
  2223.     and use of large-scale distributed applications (open distributed
  2224.     processing) using object-oriented methodology.
  2225.  
  2226. In late 1990 the OMG published its Object Management Architecture
  2227. (OMA) Guide document. This document outlines a single terminology for
  2228. object-oriented languages, systems, databases and application
  2229. frameworks; an abstract framework for object-oriented systems; a set
  2230. of both technical and architectural goals; and an architecture
  2231. (reference model) for distributed applications using object-oriented
  2232. techniques.  To fill out this reference model, four areas of
  2233. standardization have been identified:
  2234.  
  2235. 1) the Object Request Broker, or key communications element, for
  2236.    handling distribution of messages between application objects in
  2237.    a highly interoperable manner;
  2238.  
  2239. 2) the Object Model, or single design-portability abstract model for
  2240.    communicating with OMG-conforming object-oriented systems;
  2241.  
  2242. 3) the Object Services, which will provide the main functions for
  2243.    realising basic object functionality using the Object Request Broker -
  2244.    the logical modeling and physical storage of objects; and
  2245.  
  2246. 4) the Common Facilities will comprise facilities which are useful in
  2247. many application domains and which will be made available through OMA
  2248. compliant class interfaces.
  2249.  
  2250. The OMG adoption cycle includes Requests for Information and
  2251. Proposals, requesting detailed technical and commercial availability
  2252. information from OMG members about existing products to fill
  2253. particular parts of the reference model architecture.  After passage
  2254. by Technical and Business committees to review these responses, the
  2255. OMG Board of Directors makes a final determination for technology adoption.
  2256. Adopted specifications are available on a fee-free basis to members and
  2257. non-members alike.
  2258.  
  2259. In late 1991 OMG adopted its first interface technology, for the Object
  2260. Request Broker portion of the reference model.  This technology, adopted
  2261. from a joint proposal (named "CORBA") of Hewlett-Packard, NCR Corp.,
  2262. HyperDesk Corp., Digital Equipment Corp., Sun Microsystems and Object
  2263. Design Inc. includes both static and dynamic interfaces to an inter-
  2264. application request handling software "bus."
  2265.  
  2266. Unlike other organizations, the OMG itself does not and will not
  2267. develop nor sell software of any kind.  Instead, it selects and promulgates
  2268. software interfaces; products which offer these interfaces continue to be
  2269. developed and offered by commercial companies.
  2270.  
  2271. In order to serve OMG membership interested in other object-oriented systems
  2272. arenas besides the distributed system problem, the Group supports Special
  2273. Interest Groups for discussion of possible standards in other areas.  These
  2274. groups at present are:
  2275.  
  2276.         1) Object Oriented Databases;
  2277.         2) OO Languages;
  2278.         3) End-User Requirements;
  2279.         4) Parallel Processing;
  2280.         5) Analysis & Design Methodologies;
  2281.         6) Smalltalk; and
  2282.         7) Class Libraries.
  2283.  
  2284. Any company, university/research institution or individual, whether
  2285. end-user or vendor, can become a member of this body.  Administrative
  2286. details are given at the end of this paper.
  2287.  
  2288.  
  2289. 3.8.3  Mail Server Access
  2290. _________________________
  2291.  
  2292. Information via Mail Server:
  2293.   Send the following commands in a letter to the mail server.
  2294.  
  2295. mail omg_server@omg.org
  2296. help                             (how to use file server)
  2297. index                            (return a list of all available files)
  2298. get <file>                       (get files returned by  index)
  2299. log <info>                       (logs info on server)
  2300. address <e-mail address)         (use this address instead of sender)
  2301. list <directory> [match]         (index a directory, pattern 'match' files)
  2302. size <segment size>              (max file size to send)
  2303.  
  2304. list mail
  2305. list docs
  2306. get docs/doclist.txt             
  2307. get docs/91-12-1.ps               CORBA spec [although it looks a little old]
  2308.  
  2309.  
  2310. Recommended (from the net):
  2311.  
  2312. mail omg_server@omg.org
  2313. Subject: 
  2314. help
  2315. index
  2316. list
  2317. list mail
  2318. list docs
  2319. get docs/doclist.txt
  2320.  
  2321.  
  2322. 3.8.4  OMG Publications
  2323. _______________________
  2324.  
  2325. Below is from omg.org:pub/CORBA
  2326.  
  2327.  
  2328. > First Class (Bi-Monthly Newsletter)
  2329.  
  2330. First Class is OMG's non-commercial bi-monthly 28-page
  2331. newsletter. First Class provides current information on Object
  2332. Technology developments, both technically and commercially. First
  2333. Class offers an open editorial forum on numerous Object
  2334. Technology topics and issues.  This publication features
  2335. commentaries from software industry leaders, informative user
  2336. case histories, OT training information and the latest object-
  2337. oriented product announcements.  All OMG activities and the
  2338. ongoing development of the Object Management Architecture are
  2339. regularly reported.
  2340.  
  2341.  
  2342. > Object Management Architecture Guide (OMA)
  2343.  
  2344. The members of the OMG have a shared goal of developing and using
  2345. integrated software systems.  These systems should be built using
  2346. a methodology that supports modular production of software;
  2347. encourages reuse of code; allows useful integration across lines
  2348. of developers, operating systems and hardware; and enhance long-
  2349. range maintenance of that code.  As an organization, OMG believes
  2350. that the object-oriented approach to software construction best
  2351. supports their goals.  The OMA publication outlines the
  2352. groundwork for technology response to Request for Proposals (RFP)
  2353. and the adoption of specifications.
  2354.  
  2355.  
  2356. > The Common Object Request Broker: Arch. and Spec. (Corba)
  2357.  
  2358. The CORBA, as defined by the OMG's Object Request Broker (ORB),
  2359. provides the mechanisms by which objects transparently make
  2360. requests and receive responses. The ORB provides interoperability
  2361. between applications on different machines in heterogeneous
  2362. distributed environments and seamlessly interconnects multiple
  2363. object systems. The Common Object Request Broker Architecture and
  2364. Specification described in this published document is a self-
  2365. contained response to the Request for Proposals (RFP) issued by
  2366. the ORB Task Force of the OMG.
  2367.  
  2368. > Pricing
  2369.  
  2370. [Here's why you don't see the specifications posted to the net or available via
  2371.  ftp!  These are from the list of literature and periodicals listed in
  2372.  omg.org:pub/CORBA]
  2373.  
  2374. o I would like a one year subscription to First Class
  2375.     ______ for $40 U.S.,  ______ for $50 outside U.S.
  2376.  
  2377. o I would like to order  ______ copy(s) of the Object Management
  2378.   Architecture (OMA) Guide for $50 each.
  2379.  
  2380. o I would like to order  ______ copy(s) of the CORBA for $50 each.
  2381.  
  2382. o [Combinations]
  2383.  
  2384. Contact documents@omg.org or omg_documents@omg.org for more of the same...
  2385.  
  2386.  
  2387. 3.8.5  Implementations (Brief)
  2388. ______________________________
  2389.  
  2390. > DEC ObjectBroker Version 2.5  (Version 2.1 was ACA)
  2391.   Full implementation of OMG CORBA 1.1.  Digital's ObjectBroker is a 100 %
  2392.   compliant implementation of CORBA and is available on these  platforms:
  2393.   IBM AIX, IBM MVS(port in progress), HP-UX, Macintosh, MS-Windows 3.1, NT,
  2394.   OSF/1, SunOS, ULTRIX, Digital  VAX/VMS, Digital OpenVMS
  2395. Contact:
  2396.   Andrew Comas
  2397.   comas@nyo.dec.com  (212) 856-2507
  2398.   Digital Equipment Corporation.
  2399.   ObjectBroker
  2400.   110 Spit Brook Road
  2401.   Nashua, New Hampshire  03062-2698
  2402.  
  2403. > HP ORB Plus and HP Distributed Smalltalk
  2404.    Full implementation of the OMG CORBA 1.1 Object Request Broker. Also DOMF.
  2405.    Hewlett-Packard
  2406.    Distributed Computing Group
  2407.    19447 Pruneridge Avenue
  2408.    Cupertino, CA 95014-9974 (USA)
  2409.    Ian Fuller ian@cup.hp.com (408) 447-4722
  2410.  
  2411. > HyperDesk (Westborough MA) HD-DOMS, rich_fraser@hyperdesk.com
  2412.    Runs on SPARC, HP/UX, IBM RS-6000, Data General Aviion, MS-Windows (client
  2413.    API only), NetWare (planned, Novell owns part of HyperDesk).
  2414.  
  2415. > IBM SOM (System Object Model)
  2416.    Available on AIX and OS/2.  See Distributed Computing Monitor, March 93 for
  2417.    a detailed review.
  2418.  
  2419. > ILU (free, see APPENDIX E entry 59)
  2420.    Object RPC compatible with OMG CORBA 1.2 spec (will compile OMG IDL and
  2421.    generate OMG compliant code for OMG-specified languages).
  2422.    parcftp.parc.xerox.com:/pub/ilu/ilu.html
  2423.  
  2424. > IONA Technologies, Dublin Orbix, info@iona.ie
  2425.   First full and complete implementation of OMG's CORBA.
  2426.  
  2427. > NCR 'Cooperative Frameworks' -- a Distributed Object Foundation
  2428.   (1) C++ ORB toolkit consisting of over 300 C++ classes and runtime libraries
  2429.   (2) CORBA 1.1 toolkit
  2430.  
  2431. > ORBELINE - The SMART Object Request Broker - PostModern Computing
  2432.   Complete implementation of CORBA.  Free academic; com. eval licence avail.
  2433.   SunOS 4.x, Solaris 2.3, and OSF/1 versions of ORBeline available; will
  2434.   consider making other platforms available if enough interest. See Appendix E.
  2435.  
  2436. > ROLSCH CONSULTING (RC-ORB)
  2437.   Implements ORB spec, DOS/Windows 3.1, 12 user license: $99.
  2438.   Ref: Datamation, LOOK AHEAD Section, August 1.  German Company.
  2439.  
  2440. > Object Oriented Technologies (SuiteDOME)
  2441.     runs on VAX/VMS, Unix, PC
  2442.  
  2443. > Sun DOE
  2444.  
  2445. > Tivoli
  2446.  
  2447. > CS Dept. University of Zurich, Switzerland.  maffeis@ifi.unizh.ch
  2448.     The ELECTRA Toolkit (not finished)
  2449.  
  2450.  
  2451. 3.8.6  Implementation Descriptions
  2452. ___________________________________
  2453.  
  2454. The OMG also has a (Corporate) Membership list and "known CORBA supporters"
  2455. list with their info package.
  2456.  
  2457.  
  2458. > The ELECTRA Toolkit
  2459.  
  2460. CS Dept. University of Zurich, Switzerland.  maffeis@ifi.unizh.ch
  2461. The ELECTRA Toolkit
  2462.  
  2463. Subject: ORB Implementations
  2464. Date: Tue, 4 May 1993 13:12:36 +0200 (MET DST)
  2465. From: Silvano Maffeis <maffeis@ifi.unizh.ch>
  2466.  
  2467.   something like an Object Broker, but it is *not* CORBA compatible (yet).
  2468.   Electra is a research project and not available yet.
  2469.  
  2470.   Its a toolkit for building failure resilient, distributed applications
  2471.   in C++. It supports object-groups, virtual synchrony, multithreading
  2472.   etc. Electra is based on the HORUS toolkit (which is "the new ISIS
  2473.   implementation" developed at Cornell, Ithaca NY.)
  2474.   An overview paper to electra is available from:
  2475.   ftp.ifi.unizh.ch: pub/techreports/electra.ps.Z
  2476.  
  2477.  
  2478. > HD_DOMS
  2479.  
  2480. HD-DOMS (HyperDesk Distributed Object Management System).  A
  2481. CORBA-compliant DOMS.  Includes a GUI API driver for prototyping and
  2482. exercising objects, a bundled object database for persistent object
  2483. storage, a Kerberos-based authentication service, a location service, a
  2484. set of base classes to speed development, and a test script language.
  2485. Revision 1.0 has been shipping since beginning of '92.  Revision 1.1
  2486. (which includes support for CORBA's static client interface) is available
  2487. now, and a NetWare version is in the works.  Submitted a C++ language
  2488. mapping for IDL to the OMG recently.
  2489.  
  2490. HyperDesk Corporation
  2491. 2000 West Park Drive
  2492. Westboro, MA 01581
  2493. (508)366-5050
  2494.  
  2495.  
  2496. > HP ORB Plus and HP Distributed Smalltalk
  2497.  
  2498.   ============================================================================
  2499.   SUBJECT:  HP INTRODUCES DISTRIBUTED-COMPUTING SOLUTION FOR BUILDING
  2500.             SCALABLE, OBJECT-ORIENTED APPLICATIONS
  2501.   DATE:     September 27, 1993
  2502.   ----------------------------------------------------------------------------
  2503.  
  2504.    PALO ALTO, Calif.--(BUSINESS WIRE) via First! -- Hewlett-Packard Company
  2505.  today introduced a distributed-computing solution for building scalable,
  2506.  object-oriented applications.
  2507.  
  2508.    With HP ORB Plus, programmers can develop scalable, object-based
  2509.  applications that can be distributed throughout the enterprise.  HP also
  2510.  introduced an enhanced version of HP Distributed Smalltalk.
  2511.  
  2512.    HP ORB Plus and HP Distributed Smalltalk are major components of HP's
  2513.  overall distributed-computing strategy, which is designed to give customers
  2514.  integrated, desktop access to enterprise-wide information and resources in
  2515.  distributed heterogeneous systems environments.  Of all computer companies,
  2516.  HP believes it is best positioned to help customers take advantage of
  2517.  distributed computing. HP provides a wide variety of distributed-computing
  2518.  products, understands how to help customers adopt new technology for maximum
  2519.  business benefit, and offers worldwide support and training programs,
  2520.  ranging from analysis and design to deployment.
  2521.  
  2522.    HP ORB PLUS:  CORBA AND DCE COMBINED
  2523.  
  2524.    HP ORB Plus is the only environment that combines the complete CORBA 1.1
  2525.  specification from the Object Management Group with the DCE standard from
  2526.  the Open Software Foundation(tm) as its transport mechanism.  DCE is
  2527.  designed to let developers write one application and then deploy it --
  2528.  without modification -- on any other system that supports DCE.  HP ORB Plus
  2529.  reduces the complexity of developing distributed applications so programmers
  2530.  can concentrate on the application itself without needing to know multiple
  2531.  operating systems, networking protocols or where application objects are
  2532.  stored.
  2533.  
  2534.    The DCE (Distributed Computing Environment) standard provides an
  2535.  integrated set of services that can be used separately or together to
  2536.  provide a distributed computing environment that's easy to administer.  The
  2537.  CORBA (common-object-request-broker architecture) specification provides a
  2538.  standard for how objects (in applications, repositories or class libraries)
  2539.  make requests and receive responses across a distributed network.
  2540.  
  2541.    HP ORB PLUS DETAILS
  2542.  
  2543.    HP ORB Plus consists of several components: the Distributed Object
  2544.  Management Facility (DOMF), object services, developers' and administrative
  2545.  tools, and sample applications.  HP's DOMF provides a location-transparent
  2546.  object-communication mechanism across heterogeneous networks by using the
  2547.  DCE standard.  This object- enabling technology specification was jointly
  2548.  developed with SunSoft. By following a common specification, HP and SunSoft
  2549.  have made it easier for their customers to port applications between their
  2550.  platforms.
  2551.  
  2552.    In addition, HP is working with IBM to integrate HP's DOMF with IBM's
  2553.  System Object Model with extensions for distribution.  This integration will
  2554.  eventually provide users with complete scalability, portability and
  2555.  interoperability of distributed applications across HP and IBM platforms.
  2556.  This is part of the companies' planned approach toward a standards-based,
  2557.  "plug-and-play"  object-oriented environment.  This will give developers,
  2558.  system administrators and end users language-neutral, enterprise-wide,
  2559.  heterogeneous support for building, managing and using distributed object-
  2560.  oriented applications.
  2561.  
  2562.    "We're so convinced of the value of object technology that we're staking
  2563.  our entire company on it,"  said Richard Tanler, president and chief
  2564.  executive officer of Information Advantage, Inc.  "Our object-based
  2565.  applications for retailers provide the means to a competitive business edge.
  2566.  We plan to use HP ORB Plus to develop new object-based products that
  2567.  retailers can distribute to end users throughout headquarters, all chain
  2568.  stores, and warehousing and distribution operations."
  2569.  
  2570.    HP DISTRIBUTED SMALLTALK 2.0
  2571.  
  2572.    In a related announcement, HP introduced Version 2.0 of HP Distributed
  2573.  Smalltalk.  This toolset works with VisualWorks from ParcPlace Systems to
  2574.  provide programmers with a rapid development environment for creating and
  2575.  running distributed applications.  These applications can use object
  2576.  databases (currently OpenODB from HP and Gemstone from Servio) as their
  2577.  storage mechanism to facilitate the reuse of objects.
  2578.  
  2579.    Applications built using HP Distributed Smalltalk currently run without
  2580.  modification on HP, Sun and IBM UNIX(R) system-based workstations.  They
  2581.  also will run on Apple Macintosh computers and on any PC running the Windows
  2582.  3.1 or Windows NT operating systems from Microsoft(R) Corp., once
  2583.  VisualWorks 2.0 is released (expected within two months.)
  2584.  
  2585.    New HP Distributed Smalltalk 2.0 features include the following:
  2586.  
  2587.    --  easier deployment, with the ability to run multiple HP
  2588.        Distributed Smalltalk-based applications on a single system;
  2589.    --  up to 400 percent increased performance, through quicker
  2590.        sending and receiving of remote messages, and reusable
  2591.        object libraries;
  2592.    --  run-time version, for full production deployment; and
  2593.    --  easier development, with remote object browsing so
  2594.        developers can find and use objects more quickly.
  2595.  
  2596.    TECHNICAL DETAILS AND AVAILABILITY
  2597.  
  2598.    HP's DOMF includes the object request broker, interface- definition-
  2599.  language compiler, static and dynamic invocation interface and interface
  2600.  repository.  In addition to these OMG-specific features, most developers
  2601.  writing distributed, object-oriented applications require additional
  2602.  interfaces to use objects effectively.  So developers don't need to create
  2603.  their own, HP has supplied several object-service interfaces for developers
  2604.  to use. That's why HP ORB Plus includes OMG interfaces and implementations
  2605.  for properties, life cycle, associations, event notification and naming.
  2606.  
  2607.    HP's limited release of HP ORB Plus to key developers is designed so that
  2608.  customer input can be incorporated into the product early in its development
  2609.  cycle.  The initial version will work with the C++ programming language.
  2610.  For the generally available Developer's Kit, C++, C and Smalltalk
  2611.  interoperability is planned so objects written in different languages can be
  2612.  combined into one application.  The Developer's Kit is scheduled to be
  2613.  available mid- 1994; prices will be announced then.  HP ORB Plus runs on the
  2614.  HP Apollo 9000 Series 700 workstations and HP 9000 Series 800 business
  2615.  servers.
  2616.  
  2617.    Hewlett-Packard Company is an international manufacturer of measurement
  2618.  and computation products and systems recognized for excellence in quality
  2619.  and support.  The company's products and services are used in industry,
  2620.  business, engineering, science, medicine and education in approximately 110
  2621.  countries.  HP has 94,900 employees and had revenue of $16.4 billion in its
  2622.  1992 fiscal year.
  2623.  
  2624.  EDITORIAL CONTACTS:
  2625.     Hewlett-Packard Company
  2626.     Lynne Hanson, 408/447-1415, Cupertino, Calif.
  2627.     Jill Kramer, 408/447-4275, Cupertino, Calif.
  2628.  
  2629.  ==================
  2630.    For more information about HP ORB Plus, contact Kathy Litch
  2631.    (litch_k@apollo.hp.com).
  2632.  
  2633.    For more information about HP Distributed SmallTalk, contact
  2634.    Jerry Boortz (jerry_boortz@hp4000.desk.hp.com).
  2635.  
  2636.  
  2637. > Iris RDOM
  2638.  
  2639. From: rcbc@cs.cornell.edu (Robert Cooper)
  2640. Subject: Re: DCE vs. CORBA
  2641. Reply-To: rcbc@isis.com
  2642. Product: Isis Reliable Distributed Object Manager(tm) (RDOM)
  2643. Company: Isis Distributed Systems, Inc., Ithaca NY, USA.
  2644.  
  2645. Isis RDOM(tm) is a fault tolerant distributed ORB platform for reliable
  2646. multi-lingual object-oriented applications. RDOM provides an "object group"
  2647. paradigm for constructing complex applications out of collections of
  2648. cooperating objects. RDOM is built on top of the Isis Distributed
  2649. Toolkit(tm). RDOM provides interfaces from Smalltalk (Parcplace),
  2650. Objective-C, and C++, and runs on most Unix workstations. RDOM is currently
  2651. not CORBA compliant, but will be brought to compliance during 3Q93.
  2652.  
  2653. Status: 
  2654.  
  2655. RDOM has been at beta test sites since January. General release of
  2656. the Smalltalk and Objective-C language interfaces is expected in June.
  2657. The C++ interface in August. Customers include AMD, Consilium and Swiss
  2658. Bank Corp).  
  2659.  
  2660.  
  2661. > ORBELINE - The SMART Object Request Broker
  2662.  
  2663. ORBeline is a complete implementation of OMG's Common Object Request
  2664. Broker Architecture (CORBA).  ORBeline goes beyond the standard 
  2665. specification to provide a SMART communication framework allowing
  2666. you to easily develop large distributed applications that are robust,
  2667. scalable, flexible and maintainable.  ORBeline incorporates PostModern's
  2668. proven communication framework that links thousands of nodes.
  2669.  
  2670. See Appendix E:65 for a complete description and anon FTP info.
  2671.  
  2672.  
  2673. > Orbix
  2674.  
  2675. Orbix
  2676. Iona Technologies Ltd.
  2677. 8-34 Percy Place
  2678. Dublin 4
  2679. Ireland
  2680.  
  2681. The latest release of Orbix, Version 1.2, includes an Object Loader function 
  2682. for the first time, as well as an upgraded Interface Repository, a new
  2683. approach to filtering, and more code examples to guide programmers. 
  2684.  
  2685. Orbix was launched in June 1993 as the first full and complete implementation 
  2686. of the Object Management Group's (OMG's) Common Object Request Broker
  2687. Architecture (CORBA) standard.  With Orbix, programmers can develop
  2688. distributed, object oriented applications following a consistent and
  2689. straightforward, standards-based model. 
  2690.  
  2691. With Orbix Version 1.2 IONA has added the ability to dynamically load objects 
  2692. at runtime through its Object Loader function. This enables developers to more 
  2693. easily integrate Orbix applications with existing data stores be they 
  2694. traditional flat file databases, relational databases or object oriented
  2695. databases. 
  2696.  
  2697. The improved Interface Repository is an integral part of IONA's CORBA 
  2698. implementation. The Interface Repository operates as a dynamic browser which is
  2699. populated with all objects or services available at runtime keeping programmers
  2700. informed of the functions, attributes and characteristics of objects and 
  2701. services. 
  2702.  
  2703. In version 1.2 IONA has also extended the whole approach to filtering of 
  2704. requests, and has made it easier for users to integrate Orbix with their
  2705. security systems providing for improved reliability of distributed systems
  2706. built using Orbix. IONA has also extensively extended the number, and scope, of
  2707. code examples it ships with the product to help developers learning how to use
  2708. the system. 
  2709.  
  2710. IONA released Orbix for SunSoft Solaris and SunOS at the Object World 
  2711. exhibition in San Francisco, Calif., June 1993.  Since then it has rolled
  2712. out versions of Orbix for Microsoft Windows NT,  Silicon Graphics IRIX  and
  2713. HP/UX. IONA demonstrated a version of Orbix for Microsoft Windows 3.1 at
  2714. Object World in London, England last October.  Orbix for Microsoft Windows
  2715. 3.1 is now in beta.  In January 1994, IONA and SunSoft Inc. signed an
  2716. agreement to align their implementations of CORBA. The two companies
  2717. demonstrated interoperability between IONA's Orbix running on Microsoft
  2718. Windows 3.1 and SunSoft's Distributed Objects Everywhere (DOE) on Solaris.
  2719.  
  2720. In addition Orbix-TP, integration with Tuxedo for transaction processing, has 
  2721. just entered beta testing. Work is underway on Orbix-FT, integration with
  2722. the Isis distributed system, will deliver a fault-tolerant ORB.
  2723.  
  2724. Paul Hickey,                                        tel: +353-1-6686522
  2725. Iona Technologies Ltd.,                             fax: +353-1-6686573
  2726. 8-34 Percy Place,                                   email: pth@iona.ie
  2727. Dublin 4
  2728. Ireland
  2729.  
  2730. Availability
  2731. ------------
  2732.  
  2733. The full Orbix availability and release schedule looks like:
  2734.  
  2735. Operating System    C++ Compiler        Release
  2736.                         Date 
  2737. -------------------------------------------------------
  2738. SunOS 4.1             SPARCompiler 2.1    NOW
  2739. SunOS 4.1             SPARCompiler 3.0.2  NOW
  2740. SunOS 4.1             Lucid 3.1           NOW
  2741. SunOS 4.1             GNU 2.5.8           NOW
  2742. Solaris 2.x           SPARCompiler 3.0.2  NOW
  2743. Solaris 2.x           SPARCompiler 4.0    NOW
  2744. Solaris 2.x           GNU 2.5.7           NOW
  2745. IRIX 4.0.5H           Native              NOW
  2746. IRIX 5.x              Native              NOW
  2747. HP-UX                 Native              NOW
  2748. Microsoft Windows NT  Visual C++          NOW
  2749. Microsoft Windows NT  Borland             NOW
  2750. Microsoft Windows 3.1 Visual C++          In Beta
  2751. IBM AIX               C Set++             4th Qtr
  2752. OSF/1                 DEC C++             4th Qtr
  2753. SCO                   Native              4th Qtr
  2754. UnixWare              Computer Innovations 4th Qtr
  2755. Ultrix                DEC C++             4th Qtr
  2756.  
  2757. Release of Orbix on OS/2 is also imminent.
  2758.  
  2759. Documents Available from IONA
  2760. -----------------------------
  2761.  
  2762.     electronic mail server     - server@iona.ie
  2763.     anonymous ftp file server  - ftp ftp.iona.ie
  2764.     World Wide Web             - http://www.iona.ie/
  2765.  
  2766.  
  2767. > NCR 'Cooperative Frameworks' -- a Distributed Object Foundation
  2768.  
  2769. From: Randy Volters <randy.volters@columbiasc.ncr.com>
  2770. Subject: re-post: NCR Cooperative Frameworks (new phone no.)
  2771.  
  2772. November 19, 1993
  2773.  
  2774. NCR ANNOUNCES BETA AVAILABILITY
  2775. OF 'Cooperative Frameworks' -- 
  2776. a Distributed Object Foundation
  2777.  
  2778. Product Background -
  2779. NCR Cooperative Frameworks(TM) were first released for sale 
  2780. in 10/1991 as "the frameworks" part of the NCR COOPERATION(TM) 
  2781. product, and are based on NCR's submission to OMG.  
  2782. Cooperative Frameworks release 3.0 makes the product 
  2783. available apart from COOPERATION. 
  2784.  
  2785. Product Description -
  2786. Cooperative Frameworks is a distributed object foundation 
  2787. for building computing applications and services on networks 
  2788. of heterogeneous computers.
  2789.  
  2790. Cooperative Frameworks consists of an integrated suite of 
  2791. C++ class libraries that:
  2792.  
  2793.     -    defines and implements a comprehensive enterprise 
  2794.         architecture and methodology for creating 
  2795.         distributed implementations of C++ classes over 
  2796.         networks
  2797.  
  2798.     -    allows customers to build and use object services 
  2799.         over a network 
  2800.  
  2801.     -    supports TCP/IP, NetBIOS, Lan Manager NetBEUI and 
  2802.         OSI protocols, X.25
  2803.  
  2804. NCR Cooperative Frameworks currently has two portable ORB 
  2805. toolkits (others are planned for future release) -- 
  2806. (1) C++ ORB toolkit consisting of over 300 C++ classes and 
  2807.     runtime libraries
  2808.  
  2809. (2) CORBA 1.1 toolkit  Both are for:
  2810.  
  2811.     -    wrapping existing databases and legacy 
  2812.         applications for improved availability
  2813.         and maintainability on systems of heterogeneous 
  2814.         computers, operating systems and networks
  2815.  
  2816.     -    building next-generation, object-oriented, 
  2817.         distributed computing applications for
  2818.         networks of heterogeneous computers, operating 
  2819.         systems and network operating systems
  2820.  
  2821. Cooperative Frameworks come with predefined object services 
  2822. for implementing distributed systems:
  2823.  
  2824.     -    Naming - network implementation of X.500 directory 
  2825.         provides object naming service
  2826.  
  2827.     -    Logging - provides local and server based error 
  2828.         logging
  2829.  
  2830.     -    Fine-grain Data Management - class libraries are 
  2831.         designed around fine grained objects, developers can 
  2832.         build distributed objects as large or as small as 
  2833.         needed
  2834.  
  2835.     -    Persistence - the same object stream model for 
  2836.         communication between internal ORB functions is used to 
  2837.         support object persistence.  Persistent objects can be 
  2838.         files, relational or object databases
  2839.  
  2840.     -    Dynamic Service Location - provides a mechanism for 
  2841.         registering services and entities in a distributed 
  2842.         system and invoking targeted services based on service 
  2843.         characteristics -- rather than names
  2844.  
  2845.     -    Dynamic Service Activation - provides a mechanism for 
  2846.         object activation when method invocations are required, 
  2847.         and deactivation when not needed
  2848.  
  2849.     -    Event Service (Release 3.1) - Implements an OMG/JOSS 
  2850.         compliant event service
  2851.  
  2852.     -    Network Configuration Tools - simplifies creation of 
  2853.         directory entries required for cross domain operation 
  2854.         in a multiple domain heterogeneous network.
  2855.  
  2856. NCR Cooperative Frameworks run on multiple UNIX platforms, 
  2857. including HP-UX, Sun Solaris, NCR 3000 UNIX and NCR 
  2858. StarServer UNIX SVR4; and on MS Windows 3.1.  Cooperative 
  2859. Frameworks has been demonstrated on Novell NetWare v3.11, 
  2860. and was originally developed on MS OS/2 v1.x.  Development 
  2861. environments supported include CFRONT and C++ Workbench from 
  2862. NCR, HP Softbench Sun SPARCworks and Borland IDE.
  2863.  
  2864. Implementation - implementation is for client/server system 
  2865. architectures as a set of DLL and shared libraries
  2866.  
  2867. Languages used for IDL mapping - IDL bindings for C, (or 
  2868. object services can be implemented directly in C++)
  2869.  
  2870. Release date - Release 3.0 is available now to early 
  2871. developers with general availability set for December, 1993; 
  2872. Release 3.1 will be available to early developers 1Q 1994 
  2873. with general availability set for 2Q 1994
  2874.  
  2875. Product interoperability - Full interoperability between NCR 
  2876. Cooperative Framework implementations on supported platforms 
  2877. is available now; interoperability with selected CORBA 1.1 
  2878. ORBs and CORBA 2.0 ORBs is planned
  2879.  
  2880. Company Name -
  2881. NCR Corporation (An AT&T Company)
  2882.  
  2883. Address --    Software Products Division-Columbia
  2884.             3245 Platt Springs Road
  2885.             West Columbia SC 29170
  2886.  
  2887.             Phone
  2888.             (803) 939-7500
  2889.             FAX
  2890.             (803) 939-7745
  2891.             Contact Name
  2892.             Randy Volters, Sr. Product Manager
  2893.             Cooperative Frameworks
  2894.             Email: Randy.Volters@ColumbiaSC.NCR.COM
  2895.             Ext. 7774
  2896.  
  2897. Company Description -
  2898. NCR, AT&T's computer business, brings computing and 
  2899. communications solutions together to provide people easy 
  2900. access to information and to each other -- anytime, 
  2901. anywhere.
  2902.  
  2903.  
  2904. > SuiteDOME
  2905.  
  2906. Product:  DOME - Distributed Object Management Environment
  2907.  
  2908. Company:  Enquiries: info@oot.co.uk     
  2909.       Object Oriented Technologies Ltd,
  2910.       1st Floor, Lawrence House, 1A Morrell St, Leamington Spa, England CV32 5SZ
  2911.       Telephone: +44 (0) 1926 833488 Fax: +44 (0) 1926 883370.
  2912.  
  2913. Short Description:
  2914.         DOME provides heterogenous distribution across many platforms
  2915.         and networks, including:
  2916.             UNIX, Windows, Windows NT, OS/2, OSF/1 (AXP), OpenVMS, 
  2917.             SunOs, Solaris, HP-UX, SGI Unix, Stratus FTX,
  2918.             TCP/IP, NetBIOS, XTI
  2919.         As a fully peer-to-peer product DOME can be used to build systems
  2920.         using any combination of the above.
  2921.  
  2922. Long Description:
  2923.         DOME is an ORB toolkit for the production of user-configured
  2924.         ORBs and servers. It is a multi-threaded high performance ORB
  2925.         suitable for use in large scale commercial systems and embedded 
  2926.         real-time systems.
  2927.  
  2928.         DOME is non-intrusive, meaning that the application development
  2929.         is separated from the means of distribution and the problem of
  2930.         distributed object management; this allows the application to
  2931.         be built and tested on a single machine using local resources.
  2932.         Existing software can also be incorporated easily, providing
  2933.         integration for legacy systems.
  2934.  
  2935.         DOME is constructed as a C++ class library, from which ORBs
  2936.         can be configured and constructed to best suit the runtime
  2937.         environment. This provides great flexibility since new classes
  2938.         can be derived from existing ones and the resulting configurations 
  2939.         implemented to user-specific requirements.
  2940.  
  2941.         Database distribution can be as simple persistent files, 
  2942.         RDBMSs, OODMS, or a combination of these.
  2943.  
  2944.         DOME has a CORBA-conformant interface, and is CORBA 1.0 compliant
  2945.         with the following divergences -
  2946.         additions:
  2947.         - full C++ binding,
  2948.         - integral support for GUI development,
  2949.         - network monitoring & analysis,
  2950.         - transaction management,
  2951.         - location broking,
  2952.         - enhanced security;
  2953.         ommissions:
  2954.         - dynamic invocation, which is seen as detrimental to performance 
  2955.           and network security; however, DOME does allow stream operators 
  2956.           to perform the same function.
  2957.  
  2958.         DOME was first released in August 1993; version 2 in May 1994.
  2959.  
  2960.  
  2961. 3.8.7  Books, Articles, And Literature
  2962. --------------------------------------
  2963.  
  2964. This section is expected to grow considerably in the future.
  2965.  
  2966. "Distributed Object Computing With CORBA", C++ Report, July/August 1993
  2967.  
  2968. The Object Database Standard: ODMG-93
  2969. edited by: R.G.G. Cattell
  2970. published by Morgan Kaufmann Publishers, San Mateo, California
  2971. [Covers CORBA standards with respect to OODBs]
  2972.  
  2973.  
  2974. 3.9)  Why is Garbage Collection A Good Thing?
  2975. -------------------------------------------------------------------------
  2976.  
  2977. There are two entries on garbage collection, the first is an excellent entry
  2978. written for the FAQ by Paul Johnson and the second is from the FAQ author's
  2979. company on the necessity of garbage collection for object-oriented programming
  2980. and technique.
  2981.  
  2982.   From: Paul Johnson (paj@gec-mrc.co.uk)
  2983.  
  2984. Garbage collection (GC) is a facility in the run-time system associated with a
  2985. language which will automatically reclaim objects which are no longer used.
  2986. OO Languages which require garbage collection include Eiffel, Smalltalk and
  2987. CLOS.  C and C++ can have garbage collection retrofitted (see [3] and [4]
  2988. below).  [Ada has switchable GC, too -bob]
  2989.  
  2990. Without GC programmers must explicitly deallocate dynamic storage when
  2991. it is no longer needed (in C this is done by a call to free(3)).
  2992. There are a number of problems with this:
  2993.  
  2994. 1: Bugs due to errors in storage deallocation are very hard to find,
  2995.    although products are available which can help.
  2996.  
  2997. 2: In some circumstances the decision about whether to deallocate
  2998.    storage cannot be made by the programmer.  Drawing editors and
  2999.    interpreters often suffer from this.  The usual result is that the
  3000.    programmer has to write an application-specific garbage collector.
  3001.  
  3002. 3: An object which is responsible for deallocating storage must be
  3003.    certain that no other object still needs that storage.  Thus many
  3004.    modules must co-operate closely.  This leads to a tight binding
  3005.    between supposedly independent modules.
  3006.  
  3007. 4: Libraries with different deallocation strategies are often
  3008.    incompatible, hindering reuse.
  3009.  
  3010. 5: In order to avoid problems 3 and 4, programmers may end up copying
  3011.    and comparing whole objects rather than just references.  This is a
  3012.    particular problem with temporary values produced by C++ overloaded
  3013.    operators.
  3014.  
  3015. 6: Because keeping track of storage is extra work, programmers often
  3016.    resort to statically allocated arrays.  This in turn leads to
  3017.    arbitrary restrictions on input data which can cause failure when
  3018.    the assumptions behind the chosen limits no longer apply.  For
  3019.    instance many C compilers limit expression nesting, identifier
  3020.    length, include file nesting and macro stack depth.  This causes
  3021.    problems for programs that generate C.
  3022.  
  3023. One partial solution to a lack of GC is reference counting.  In this
  3024. scheme each object keeps a count of references to it.  When this count
  3025. drops to zero the object is automatically deallocated.  However this
  3026. is inefficient (swapping two references will result in three
  3027. decrements, three increments and six comparisons) and cannot reclaim
  3028. circular data structures.  Two systems that use a reference count GC
  3029. are the Interviews C++ graphics library and the Unix file system (the
  3030. link count).
  3031.  
  3032. Opponents of GC reply that it introduces an overhead which is
  3033. unacceptable in some applications.  However the overhead of manual
  3034. storage deallocation is probably as high as GC.  GC algorithms are
  3035. also available with good real-time behaviour.
  3036.  
  3037. [Further, GC can perform compaction improving locality of reference.]
  3038.  
  3039. Further Reading:
  3040.  
  3041. [1] "Object-Oriented Software Construction" by Meyer puts the argument
  3042. for GC.
  3043.  
  3044. [2] "Uniprocessor Garbage Collection Techniques," by Paul R. Wilson,
  3045. in Memory Management (proceedings of 1992 Int'l Workshop on Memory 
  3046. Management, Sept. 1992, St. Malo, France, Yves Bekkers and Jacques Cohen, 
  3047. eds.), Springer Verlag Lecture Notes in Computer Science #637.
  3048.  
  3049. This is an excellent summary of the state of the art in GC algorithms.  This
  3050. and other papers about garbage collection are available in PostScript via
  3051. anonymous ftp (cs.utexas.edu:pub/garbage/gcsurvey.ps.  [See APPENDIX E]
  3052.  
  3053. [3] "Garbage Collection in an Uncooperative Environment" by Boehm and
  3054. Weiser.  Software --- Practise and Experience vol 18(9), pp 807-820.
  3055. Sept 1988.  This describes GC in C and C++.
  3056. ftp://parcftp.xerox.com/pub/gc/gc.html
  3057.  
  3058. [4] Geodesic Systems provides GC for C and C++.  See http://www.geodesic.com
  3059.   and Appendix G.
  3060.  
  3061.  
  3062. 3.9b) Why is Garbage Collection Necessary for Object-Oriented Programming?
  3063. --------------------------------------------------------------------------
  3064.               Michael Spertus 
  3065.               Geodesic Systems
  3066.               mps@geodesic.com
  3067.  
  3068. There are several reasons why true object-oriented programming requires garbage
  3069. collection. 
  3070.  
  3071. 1. Manual Memory Management Breaks Encapsulation.
  3072.  
  3073.   Program components frequently need knowledge of an entire program to
  3074.   determine the last use of an object and provide deletion.  This makes reuse
  3075.   of the component nearly impossible. For example, methods and functions
  3076.   taking a container as an argument need to know of or make assumptions 
  3077.   about the rest of the program to determine ownership of the objects in the 
  3078.   container.
  3079.  
  3080.   Attempts to encapsulate memory management with reference counting, the "poor 
  3081.   man's garbage collector", are usually misguided. Reference counting has worse
  3082.   performance than GC, awkward syntax, and poor semantics, which typically 
  3083.   include failure to reclaim cycles, inability to handle stack and static 
  3084.   objects, lack of polymorphism, and problems with interior pointers (e.g. 
  3085.   arrays and multiple inheritance). Intensive research [1] in garbage
  3086.   collection has completely solved the above problems and made reference
  3087.   counting an inadequate substitute for true GC.
  3088.  
  3089. 2. Implementation Hiding is not Compatible with Manual Memory Management
  3090.  
  3091.   Implementation hiding is a pillar of object-oriented programming,
  3092.   but explicit memory management requires implementation-dependent
  3093.   low-level knowledge of how memory is structured. For example, programmers
  3094.   often use "copy on write" to efficiently implement pass-by-value semantics.
  3095.   However, to manage memory explicitly, a program has to know if it has a copy
  3096.   of an object or the object itself. Programmers sometimes use reference 
  3097.   counting to encapsulate copy-on-write memory management. However, this only
  3098.   works well in simple cases like strings where the data is not polymorphic
  3099.   and does not contain pointers.
  3100.  
  3101. 3. Message Passing Leads to Dynamic Execution Paths
  3102.  
  3103.    Manual memory management must make assumptions about a program's order of
  3104.    execution to make a compile-time determination of the last user of an
  3105.    object. While this is often possible in procedural languages, the object-
  3106.    oriented paradigm of objects sending messages to each other (possibly from
  3107.    different threads) makes it impossible to statically determine the last user
  3108.    of an object. For example, event driven GUI programs frequently have no
  3109.    clear order of execution. Other dynamic control structures, such as
  3110.    exceptions, also make static analysis of memory usage at compile-time
  3111.    impossible.
  3112.  
  3113. 4. Differing Memory Management Schemes Hinder Reuse
  3114.  
  3115.   Because no memory management scheme is universal enough for all applications,
  3116.   manually managed components and libraries often use incompatible memory
  3117.   management schemes. For example, there are common container libraries using 
  3118.   each of the following schemes:
  3119.  
  3120.   a) Doubly specified empty and remove methods with one including a memory
  3121.      delete, placing the memory management burden on the client, who must call
  3122.      the appropriate method.
  3123.      
  3124.   b) Switches indicating deletion. Many applications must clear the switch to
  3125.      support long-lived data and keep track of ownership of data shared by
  3126.      multiple containers, leaving many memory management issues unaddressed.
  3127.  
  3128.   c) Value semantics store objects rather than references, inhibiting data
  3129.      sharing and carrying expensive performance costs when complex objects are
  3130.      copied by value.
  3131.  
  3132.   d) Reference counting, which was already discussed.
  3133.      
  3134.   Any components or libraries that use containers with different memory 
  3135.   management strategies are difficult to use with each other.
  3136.  
  3137.  
  3138. 5. Garbage Collection Works
  3139.  
  3140.   It is not enough to merely find fault with manual memory management. One also 
  3141.   has to show that garbage collection provides a better alternative. Early 
  3142.   versions of garbage collection were merely crude implementations of 
  3143.   mark-and-sweep that left much to be desired. However, garbage collection has 
  3144.   advanced as rapidly as most computer-related technologies and is now a robust, 
  3145.   mature technology.[1] Many object-oriented languages specify garbage
  3146.   collection for all or part of their memory. Even C and C++ have at least one
  3147.   commercially supported garbage collector that can transparently and
  3148.   compatibly manage both new and existing programs. [2] 
  3149.  
  3150.   Garbage collected programs are usually as fast and responsive as
  3151.   their manually managed brethren. [3] In fact, multi-media programmers
  3152.   sometimes choose treadmill collectors [4] over hand-management because of its
  3153.   superior real-time performance as manual management usually has difficulty
  3154.   scheduling destructor calls smoothly. Of course, garbage collected programs
  3155.   are generally more reliable and easier to develop, maintain, and reuse than
  3156.   manually managed programs. Finally, garbage collection can be mixed with
  3157.   manual management to provide the programmer with the broadest set of tools,
  3158.   and garbage collection is much too important a tool to be absent from any
  3159.   object-oriented programmer's toolbox.
  3160.  
  3161. References
  3162. [1] Paul R. Wilson, "Uniprocessor Garbage Collection Techniques", 1992
  3163.   International Workshop on Memory Management, Springer-Verlag Lecture Notes in
  3164.   Computer Science series.
  3165.  
  3166. [2] Geodesic Systems, Great Circle(TM) Automatic Memory Management System.
  3167.   http://www.geodesic.com/GreatCircle/index.html.
  3168.  
  3169. [3] Detlefs, Dosser, and Zorn, "Memory Allocation Costs in Large C and C++
  3170.   Programs".  ftp://cs.colorado.edu/pub/techreports/zorn/CU-CS-665-93-ps.Z.
  3171.  
  3172. [4] Henry Baker, "The Treadmill: Real-Time Garbage Collection without Motion
  3173.   Sickness".  ftp://ftp.netcom.com/pub/hb/hbaker/NoMotionGC.html
  3174.  
  3175.  
  3176. 3.10)  What Can I Do To Teach OO To The Kids?
  3177. ---------------------------------------------
  3178.  
  3179. Smalltalk (in its original 1972 version) was initially intended to make
  3180. computer programming easy enough for children.  The idea was that manipulating
  3181. objects was something more intuitive and natural than coding procedures.
  3182.  
  3183. Other entries or suggestions are welcome, please send to the author of the FAQ.
  3184.  
  3185.  
  3186. 3.11) What Is Available On Object-Oriented Testing?
  3187. ---------------------------------------------------
  3188.  
  3189. [This entry was donated by Doug Shaker and is certainly a FAQ]
  3190.  
  3191. Testing of Object-Oriented Programming (TOOP) FAQ/Resource Summary
  3192.  
  3193. Posted to comp.object, comp.lang.c++, comp.lang.smalltalk and
  3194. comp.software.testing.
  3195.  
  3196. Last revised on 93.10.27.  The most notable change is in the additions
  3197. to the Software section.  Also a couple of articles added to the
  3198. Written Material section.
  3199.  
  3200.  
  3201. > What?
  3202.  
  3203. This is a summary of resources on the Testing of Object-Oriented
  3204. Programming that have been mentioned to me over the net, in email,
  3205. or other means.  Sections include Written Material, Courses, and
  3206. Software.  It is kind of like an FAQ, though it isn't organized 
  3207. that way.
  3208.  
  3209. > Who?
  3210.  
  3211. I work for a Unix software house, Qualix Group, in the US.   Here is
  3212. my sig:
  3213.  - Doug Shaker
  3214.     voice:    415/572-0200
  3215.     fax:    415/572-1300
  3216.     email:    dshaker@qualix.com
  3217.     mail:    Qualix Group
  3218.         1900 S. Norfolk St., #224
  3219.         San Mateo, CA 94403
  3220. I am NOT a researcher on the testing of object-oriented programming.
  3221. I just collate the stuff that is sent to me by people who REALLY know
  3222. something.  See the section "ACKs" at the end.
  3223.  
  3224. I just think it is important.
  3225.  
  3226. > Why?
  3227.  
  3228. Why is this important? If classes are really to be reused in
  3229. confidence, they must be blatantly correct.  The classes must be easily
  3230. testable during initial evaluation by the client programmer.  They must
  3231. also be testable under different OS configurations, different compiler
  3232. optimizations, etc.  This means that testing modules must be
  3233. constructed in a way which is recognized as correct and the modules
  3234. must be shipped with the class libraries.  
  3235.  
  3236. As soon as one major class library vendor starts to ship real test code
  3237. with their libraries, all of the other vendors will be forced, by
  3238. market pressure, to do so as well, or face market share erosion.  Think
  3239. about it.  If you had to recommend a class library to a committee that
  3240. was choosing a basis for the next five years of work, wouldn't you feel
  3241. safer with a class library that could be auto-tested in your
  3242. environment?
  3243.  
  3244.  
  3245. > Written Material
  3246.  
  3247. Berard, Edward.  Essays on Object-Oriented Software Engineering.  
  3248.     Prentice-Hall, Englewood Cliffs, NJ. $35.
  3249.     This book has two chapters on testing of object-oriented software, 
  3250.     focusing on how to do it.
  3251.  
  3252. Berard, Edward.  Project Management Handbook.  Must be purchased
  3253.     direct from Berard Software Engineering, Ltd., 902 Wind River
  3254.     Lane, Suite 203, Gaithersburg, Maryland 20878.  $225.
  3255.     The book focuses on the management of OOP projects.  It
  3256.     includes one chapter on testing OO software and one chapter
  3257.     on quality assurance.
  3258.  
  3259. Bezier, Boris, "Software Testing Techniques", 2nd edition, Van Nostrand
  3260.     Reinhold, 1990, 503pp, $43, ISBN 0-442-20672-0.  While this is
  3261.     not specifically about testing of OOP, it is mentioned so often
  3262.     by so many people as a definitive software testing work, that
  3263.     I have to mention it anyway.
  3264.  
  3265. Cheatham Thomas J., and Lee Mellinger, "Testing Object-Oriented
  3266.     Software Systems",  Proceedings of the 18th ACM Annual Computer
  3267.     Science Conference, ACM, Inc., New York, NY, 1990, pp. 161-165.
  3268.  
  3269. Doong, Roong-Ko and Phyllis G. Frankl, "Case Studies on Testing 
  3270.     Object-Oriented Programs", Proceedings of the 4th Symposium on
  3271.     Testing, Analysis, and Verification (TAV4), 1991, ACM, Inc.,
  3272.     New York, NY, 1991, pp. 165-177.
  3273.  
  3274. Fiedler, Steven P., "Object-Oriented Unit Testing", Hewlett-Packard 
  3275.     Journal, April, 1989, pp. 69-74.
  3276.  
  3277. Firesmith, D.G., "Testing Object-Oriented Software", Proceedings 
  3278.     of 11th. TOOLS USA Conference, Santa Barbara, Aug 1993, pp 407-426.
  3279.  
  3280. ############################################################################
  3281.  
  3282.  
  3283. Path: senator-bedfellow.mit.edu!faqserv
  3284. From: Bob Hathaway <rjh@geodesic.com>
  3285. Newsgroups: comp.object,comp.answers,news.answers
  3286. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Part 4/13
  3287. Supersedes: <object-faq/part4_805979999@rtfm.mit.edu>
  3288. Followup-To: comp.object
  3289. Date: 31 Aug 1995 15:32:37 GMT
  3290. Organization: Geodesic Systems
  3291. Lines: 1234
  3292. Approved: news-answers-request@MIT.Edu
  3293. Distribution: world
  3294. Expires: 14 Oct 1995 15:31:54 GMT
  3295. Message-ID: <object-faq/part4_809883114@rtfm.mit.edu>
  3296. References: <object-faq/part3_809883114@rtfm.mit.edu>
  3297. NNTP-Posting-Host: bloom-picayune.mit.edu
  3298. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  3299. X-Last-Updated: 1995/06/01
  3300. Originator: faqserv@bloom-picayune.MIT.EDU
  3301. Xref: senator-bedfellow.mit.edu comp.object:37586 comp.answers:13974 news.answers:51855
  3302.  
  3303. Archive-name: object-faq/part4
  3304. Last-Modified: 05/31/94
  3305. Version: 1.0.8
  3306.  
  3307. Frankl, Phyllis G. and Roong-Ko Doong, "Tools for Testing 
  3308.     Object-Oriented Programs", Proceedings of the 8th Pacific
  3309.     Northwest Conference on Software Quality, 1990, pp. 309-324.
  3310.     One author can be reached at pfrankl@polyof.poly.edu.
  3311.  
  3312. Graham, J.A., Drakeford, A.C.T., Turner, C.D. 1993. The Verification, 
  3313.     Validation and Testing of Object Oriented Systems, BT Technol
  3314.     J.  Vol 11, No 3. One author's email address is
  3315.     jgraham@axion.bt.co.uk.
  3316.  
  3317. Harrold, Mary Jean, John D. McGregor, and Kevin J. Fitzpatrick, 
  3318.     "Incremental Testing of Object-Oriented Class Structures",
  3319.     International Conference on Software Engineering, May, 1992,
  3320.     ACM, Inc., pp. 68 - 80.
  3321.  
  3322. Hoffman, Daniel and Paul Strooper.  A Case Study in Class Testing.
  3323.     To be Presented at the IBM Center for Advanced Studies Fall
  3324.     Conference, October 1993, Toronto.  Email addresses for authors
  3325.     are dhoffman@csr.uvic.ca and pstropp@cs.uq.oz.au.  Describes an
  3326.     approach to testing which the authors call Testgraphs.  An
  3327.     example is worked out in C++ which tests a commercial class.
  3328.  
  3329. Hoffman, D. M.  A CASE Study in Module Testing.  In Proc. Conf. Software
  3330.     Maintenance, pp. 100-105. IEEE Computer Society, October 1989.
  3331.  
  3332. Hoffman, D.M. and P.A. Strooper.  Graph-Based Class Testing.  In 
  3333.     7th Australian Software Engineering Conference (to appear), 1993.
  3334.  
  3335. Klimas, Edward "Quality Assurance Issues for Smalltalk Based Applications", 
  3336.     The Smalltalk Report, Vol. 1, No. 9, pp.3-7.  The author's
  3337.     email address is "ac690@cleveland.freenet.edu".
  3338.  
  3339. Lakos, John S.  "Designing-In Quality in Large C++ Projects" Presented
  3340.     at the 10th Annual Pacific Northwest Software Quality Conference,
  3341.     Portland, Oregon, October 21, 1993.  Abstract:
  3342.         The focus of this paper is on ensuring quality by
  3343.         designing software that avoids acyclic component
  3344.         dependencies.  This in-turn permits incremental,
  3345.         hierarchical testing.  The importance of good physical
  3346.         design becomes a key factor only for large and very
  3347.         large projects.  Intuition gained from smaller projects
  3348.         leads to errors in large designs.  Compile-coupling
  3349.         ("Insulation") is also discussed.
  3350.     Copies of the postscript file can be obtained by sending email
  3351.     to "john_lakos@warren.mentorg.com".
  3352.  
  3353. Leavens, G. T., "Modular Specification and Verification of 
  3354.     Object-Oriented Programs", IEEE Software, July 1991, pp. 72-80.
  3355.  
  3356. Love, Tom.  Object Lessons.  SIGS Books, 588 Broadway #604, New York, NY 
  3357.     10012. $49.
  3358.     This book eloquently elucidates the need for testing of object-
  3359.     oriented code and has a chapter on how it was done at Stepstone
  3360.     during the first release of their initial class library.
  3361.  
  3362. Marick, Brian.  The Craft of Software Testing, Prentice-Hall, in press.
  3363.     Makes the argument that testing of object-oriented software is
  3364.     simply a special case of testing software which retains state
  3365.     and which is reused.  The author can be reached at 
  3366.     info@testing.com.
  3367.  
  3368. Narick, Brian. "Testing Software that Reuses", Technical Note 2, Testing
  3369.     Foundations, Champaign, Illinois, 1992. Copies may be obtainable 
  3370.     via email. The author can be reached at info@testing.com.
  3371.  
  3372. Murphy, G.C., Wong, P. 1992, Towards a Testing Methodology for 
  3373.     Object Oriented Systems, M.P.R Teltech Ltd. A poster at the
  3374.     Conference on Object Oriented Programming Systems, Languages
  3375.     and Applications ACM. Copies of this paper can be obtained
  3376.     through townsend@mprgate.mpr.ca.
  3377.  
  3378. Murphy, G. and P. Wong.  Object-Oriented Systems Testing Methodology: An
  3379.     Overview.  Techical Report TR92-0656, MPR Teltech Ltd., October 
  3380.     1992.
  3381.  
  3382. Perry, D.E. and G.E. Kaiser, "Adequate Testing and Object-Oriented 
  3383.     Programming", Journal of Object-Oriented Programming, 
  3384.     2(5):13-19, Jan/Feb 1990.
  3385.  
  3386. Purchase, Jan A. and Russel L. Winder, "Debugging tools for 
  3387.     object-oriented programming", Journal of Object-Oriented 
  3388.     Programming, June, 1991, Vol. 4, No. 3, pp. 10 - 27.
  3389.  
  3390. Smith, M. D. and D. J. Robson, " A Framework for Testing Object-Oriented 
  3391.     Programs", JOOP, 5(3):45-53, June 1992.
  3392.     Describes ways in which the usual approach to software testing
  3393.     could be adapted for object-oriented software.
  3394.     This paper, or one with the same title and authors, is
  3395.     available by anonymous ftp from vega.dur.ac.uk as
  3396.     "/pub/papers/foot.dvi".
  3397.  
  3398. Smith, M. D. and D. J. Robson, "Object-Oriented Programming - the 
  3399.     Problems of Validation",  Proceedings of the 6th International 
  3400.     Conference on Software Maintenance 1990, IEEE Computer Society 
  3401.     Press, Los Alamitos, CA., pp. 272-281.
  3402.  
  3403. Taylor, David. "A quality-first program for object technology", Object 
  3404.     Magazine, Vol. 2, No. 2, July-August 1992, pp17-18. SIGs
  3405.     Publications.  The article talks some about why testing is
  3406.     important for OOP and describes one quality program.
  3407.  
  3408. Theilen, David.  "No Bugs.  Delivering error free code in C and C++.",
  3409.     Addison-Wesley, 1992, ISBN:0-201-60890-1.
  3410.  
  3411. Turner, C. D. and D. J. Robson, "The Testing of Object-Oriented Programs",
  3412.     Technical Report TR-13/92, Computer Science Division, School of
  3413.     Engineering and Computer Sciences (SECS), University of Durham,
  3414.     England.
  3415.     Includes a survey of existing literature on testing of OO
  3416.     programs.  Testing of OOP is compared with traditional software
  3417.     testing.  A state-based approach is described.
  3418.     This paper is available by anonymous ftp from vega.dur.ac.uk in
  3419.     /pub/papers. Get "toop.ps.Z" for A4 paper and "toopus.ps.Z" for
  3420.     US letter paper formatting.
  3421.  
  3422. Turner, C. D. and D. J. Robson, "A Suite of Tools for the State-Based
  3423.     Testing of Object-Oriented Programs", Technical Report
  3424.     TR-14/92, Computer Science Division, School of Engineering and
  3425.     Computer Science (SECS), University of Durham, Durham,
  3426.     England.  Describes a series of tools for the generation and
  3427.     execution of test cases for OOP.  These tools assume a
  3428.     state-based testing approach.
  3429.     This paper is available by anonymous ftp from vega.dur.ac.uk in
  3430.     /pub/papers.  Get "tools.ps.Z" for A4 paper formatting or get
  3431.     "toolsus.ps.Z" for US letter formatting.
  3432.  
  3433. Turner, C. D. and D. J. Robson, "Guidance for the Testing of Object-
  3434.     Oriented Programs", Technical Report TR-2/93, Computer Science
  3435.     Division, School of Engineering and Computer Science (SECS),
  3436.     University of Durham, Durham, England.  Discusses different
  3437.     methods of making class declarations and the implications of
  3438.     those methods for testing.
  3439.     This paper is available by anonymous ftp from vega.dur.ac.uk in
  3440.     /pub/papers.  Get "guide.ps.Z" for A4 paper formatting or get
  3441.     "guideus.ps.Z" for US letter formatting.
  3442.  
  3443. Turner, C. D. and D. J. Robson, "State-Based Testing and Inheritance",
  3444.     Technical Report TR-1/93, Computer Science Division, School of
  3445.     Engineering and Computer Science (SECS), University of Durham,
  3446.     Durham, England.
  3447.     Discusses the implications of inheritance for testing,
  3448.     particularily incremental testing.
  3449.     This paper is available by anonymous ftp from vega.dur.ac.uk in
  3450.     /pub/papers.  Get toopinht.ps.Z" for A4 paper formatting or get
  3451.     "toopinhtus.ps.Z" for US letter formatting.
  3452.  
  3453. Wong, P. Automated Class Exerciser (ACE) User's Guide.  Technical
  3454.     Report TR92-0655, MPR Teltech Ltd., September 1992.
  3455.  
  3456. > Courses
  3457.  
  3458. Berard Software Engineering, Inc. teaches a seminar on Testing of
  3459. Object-Oriented Software (TOOS).  The next one scheduled that I know of
  3460. is November 8-12, in Washington.  Call 301-417-9884 for details.
  3461.  
  3462. Quality Fractals, Inc. has a course called "Testing Object-Oriented
  3463. Software".  Contact: 508-359-7273 (Box 337, Medfield, MA 02052).  The
  3464. course is taught by Shel Siegel of YESS!, Inc.  Contact: 916-944-1032.
  3465.  
  3466.  
  3467. > Software
  3468.  
  3469. There is a smalltalk class library in the Univ. of Illinois archives
  3470. which includes a simple Tester class written by Bruce Samuelson
  3471. (bruce@utafll.uta.edu). It is a general superclass for application
  3472. specific classes that test non-interactive objects such as trees,
  3473. collections, or numbers. It is not suitable for testing user interface
  3474. components such as windows, cursors, or scroll bars. The filein
  3475. includes Tree classes, Tester itself, and subclasses of Tester that are
  3476. used to validate the Tree classes. For ParcPlace Smalltalk (ObjectWorks
  3477. 4.1 and VisualWorks 1.0). To get it ftp the file
  3478. "/pub/st80_vw/TreeLW1.1" from st.cs.uiuc.edu.
  3479.  
  3480. IPL Ltd. (in the UK) has a testing tool called Cantata which allows for
  3481. testing C++, but as far as I am able to determine, it has no special
  3482. features for C++ testing.  From the product literature:
  3483.     Cantata allows testing to be performed in an intuitive way
  3484.     making the tool exceptionally easy to use and productive in
  3485.     operation. Cantata is suitable for testing software written in
  3486.     either C or C++.
  3487.  
  3488.     Cantata provides comprehensive facilities for all forms of
  3489.     dynamic testing, including: functional testing, structural
  3490.     testing, unit testing and integration testing. Cantata has been
  3491.     specifically designed to operate in both host and target
  3492.     systems and so allow full portability of tests between these
  3493.     environments.
  3494. For more information contact IPL:
  3495.     IPL Ltd.
  3496.     Eveleigh House, Grove Street, 
  3497.     Bath  BA1 5LR
  3498.     UK
  3499.     (0225) 444888
  3500.     (0225) 444400 (FAX)
  3501.     email: shaun@iplbath.demon.co.uk
  3502.  
  3503. TestCenter from CenterLine will do coverage testing of C++ (and C)
  3504. code.  Also does some memory debugging (similar to Purify) and regression
  3505. testing.  Highlights from CenterLine literature:
  3506.   *Automatic run-time error-checking on executables to enhance quality 
  3507.   *Automatic memory leak detection on executables to optimize memory use
  3508.   *Graphical test coverage to highlight any code not executed during test runs
  3509.   *Intuitive GUI for easy test analysis 
  3510.   *Programmatic interface to output files and cumulative code coverage 
  3511.    to support batch-mode and regression testing
  3512.   *No recompilation needed, resulting in quick turnaround
  3513.   *Complete C and C++ language support
  3514.   *Integration with leading programming tools for maximum productivity gains
  3515.  
  3516. MicroTech Pacific Research (mpr.ca) has a C++ class testing tool called
  3517. ACE (Automated Class Exerciser) which is available under non-disclosure
  3518. agreement.  It is not currently for sale.  If you are interested,
  3519. contact Paul Townsend, townsend@mprgate.mpr.ca.
  3520.  
  3521. Software Research Inc. (625 Third St, San Francisco, CA 94107-1997,
  3522. voice: 1-415-957-1441, email: info@soft.com) has a coverage tool for C++
  3523. that is called tcat++.  It is an extension of SRI's tcat program.
  3524.  
  3525. Quality Assured Software Engineering (938 Willowleaf Dr., Suite 2806,
  3526. San Jose, CA 95128, voice: 1-408-298-3824 ) has a coverage tool for
  3527. C and C++ called MetaC.  It also dones some syntax checking and memory
  3528. allocation checking.
  3529.  
  3530. A group of volunteers is building a C++ test harness for the automated
  3531. testing of C++, C and Perl programs.  The system is called ETET (Extended
  3532. Test Environment Toolkit).  To join the group of volunteers, send email to
  3533.     etet_support@uel.co.uk
  3534. The software is available via anonymous FTP from bright.ecs.soton.ac.uk
  3535. (152.78.64.201) as "/pub/etet/etet1.10.1.tar.Z".  They are looking for
  3536. other FTP sites - sned email to the above address if you can provide
  3537. one.  This is a beta release and _should_ compile on any POSIX.1 system.
  3538. As much of this work is being done by SunSoft, my guess is that the
  3539. software will have the fewest problems on SunOS or Solaris releases.
  3540.  
  3541. > ACKs
  3542.  
  3543. Thanks to the following for helping assemble this list:
  3544.     Benjamin C. Cohen, bcohen@scdt.intel.com
  3545.     Brian Marick, marick@hal.cs.uiuc.edu
  3546.     Bruce Samuleson, bruce@utafll.uta.edu
  3547.     Daniel M. Hoffman, dhoffman@uvunix.uvic.ca
  3548.     Edward Klimas, ac690@cleveland.freenet.edu
  3549.     John Graham, J.Graham@axion.bt.co.uk
  3550.     Jim Youlio, jim@bse.com
  3551.     Jeffery Brown, jeffrey.brown@medtronic.com
  3552.     Lars Jonsson, konlajo@etna.ericsson.se
  3553.     Manfred Scheifert, ch_schie@rcvie.co.at
  3554.     Mark Swanson, mswanson@mechmail.cv.com
  3555.     Mary L. Schweizer, mary@gdwest.gd.com
  3556.     Michael Einkauf, Michael_Einkauf@iegate.mitre.org
  3557.     Paul Townsend, townsend@mprgate.mpr.ca
  3558.     Phyllis G. Frankl, pfrankl@polyof.poly.edu
  3559.     Rachel Harrison, rh@ecs.soton.ac.uk
  3560.     Risto Hakli, rkh@tko.vtt.fi
  3561.     Russ Hopler, russ@bse.com
  3562.     Stephane Barbey, barbey@di.epfl.ch
  3563.     Tony Reis, tonyr@hpsadln.sr.hp.com
  3564.     Yawar Ali, yali@bnr.ca
  3565.  
  3566.  
  3567. 3.12) What Distributed Systems Are Available?
  3568. ---------------------------------------------
  3569.  
  3570. The following post helps to provide some answers with at least a partial list.
  3571. See also Appendix E.
  3572.  
  3573. From: rmarcus@bcsaic.boeing.com (Bob Marcus)
  3574. Newsgroups: comp.object,comp.client-server
  3575. Subject: Distributed Computing Products Overview
  3576. Date: 17 Sep 93 00:02:40 GMT
  3577. Organization: Boeing Computer Services
  3578.            
  3579.              DISTRIBUTED COMPUTING PRODUCTS OVERVIEW
  3580.  
  3581.   There was a recent posting concerning the relationship between OMG's CORBA
  3582.  and Distributed Transaction Processing Monitors. In general, there is a lot of
  3583.  uncertainty as to how the various distributed computing tools, products and
  3584.  environments might work together.  Below is the outline of an eight-page
  3585.  posting to the Corporate Facilitators of  Object-Oriented Technology (CFOOT)
  3586.  mailing list addressing these issues. Let me know if you would like a copy
  3587.  of the posting and/or to be added to the CFOOT mailing list. 
  3588.      
  3589.                                           Bob Marcus 
  3590.                                           rmarcus@atc.boeing.com
  3591.  -----------------------------------------------------------------------
  3592.  SOME GENERAL REFERENCES FOR ADDITIONAL INFORMATION 
  3593.  -----------------------------------------------------------------------
  3594.  MULTIPROTOCOL NETWORK TRANSPORTS
  3595.  
  3596.   Peer Logic (PIPES)
  3597.   ATT (Transport Layer Interface) 
  3598.  -----------------------------------------------------------------------
  3599.  MICROKERNELS
  3600.  
  3601.   OSF(Mach)
  3602.   Chorus Systems (Chorus)
  3603.   Microsoft (NT)
  3604.  -----------------------------------------------------------------------
  3605.  REMOTE PROCEDURE CALLS
  3606.  
  3607.   NobleNet (EZ-RPC)
  3608.   Netwise (Netwise-RPC) 
  3609.   ATT/Sun (TI-RPC)
  3610.   OSF (DCE/RPC)
  3611.  -----------------------------------------------------------------------
  3612.  CONVERSATIONAL PROGRAMMING
  3613.  
  3614.   IBM(Common Programming Interface-Communications)
  3615.  -----------------------------------------------------------------------
  3616.  MESSAGING PRODUCTS
  3617.  
  3618.   System Strategies/IBM (MQ Series)
  3619.   Horizon Strategies (Message Express) 
  3620.   Covia Systems(Communications Integrator)
  3621.   Momentum Software(X-IPC)
  3622.   Creative System Interface (AAI)
  3623.   Digital (DECmessageQ)
  3624.   HP (Sockets)(BMS)
  3625.   IBM (DataTrade)(DAE)
  3626.   Suite Software (SuiteTalk)
  3627.   Symbiotics (Networks)
  3628.  -----------------------------------------------------------------------
  3629.  PUBLISH AND SUBSCRIBE MESSAGING 
  3630.  
  3631.   Sun(Tooltalk)
  3632.   Teknekron (Teknekron Information Bus)
  3633.   ISIS(Distributed News)
  3634.   Expert Database Systems (Rnet)
  3635.  ----------------------------------------------------------------------
  3636.  DISTRIBUTED COMPUTING ENVIRONMENTS
  3637.  
  3638.   OSF/DCE
  3639.   ISIS(Distributed Toolkit)
  3640.  -----------------------------------------------------------------------
  3641.  TRANSACTION PROCESSING MANAGERS 
  3642.  
  3643.   Unix Systems Lab (Tuxedo) 
  3644.   Information Management Company (Open TransPort) 
  3645.   NCR (TopEnd)
  3646.   Transarc (Encina)
  3647.   IBM/HP/Transarc (Open CICS)
  3648.  -----------------------------------------------------------------------
  3649.  DISTRIBUTED WORKSTATION EXECUTION SYSTEMS
  3650.  
  3651.   Aggregate Systems (NetShare)
  3652.   Platform Computing(Utopia)
  3653.   ISIS(Resource Manager)
  3654.  -----------------------------------------------------------------------
  3655.  OBJECT REQUEST BROKERS 
  3656.  
  3657.   Hyperdesk (Distributed Object Manager)
  3658.   IBM Distributed System Object Model(DSOM)
  3659.   Microsoft (Distributed OLE)
  3660.   Iona Technologies Ltd. (Orbix) 
  3661.   BBN (Cronus)
  3662.   ISIS (RDOM)
  3663.   Qualix (NetClasses)
  3664.   Symbiotics (Networks!)
  3665.   Digital(ACA Services) 
  3666.   Object-Oriented Technologies (SuiteDOME)
  3667.  -----------------------------------------------------------------------
  3668.  SYSTEM MANAGEMENT  
  3669.  
  3670.   OSF (Distributed Management Environment)
  3671.   Legent
  3672.   Digital Analysis (HyperManagement)
  3673.  -----------------------------------------------------------------------
  3674.  DISTRIBUTED DEVELOPMENT/EXECUTION PRODUCTS   
  3675.  
  3676.   Texas Instruments (Information Engineering Facility)
  3677.   HP (SoftBench)
  3678.   Digital (COHESIONworX) 
  3679.  -----------------------------------------------------------------------
  3680.  DISTRIBUTED DEVELOPMENT/EXECUTION PRODUCTS   
  3681.  
  3682.   Independence Technologies (iTRAN)
  3683.   Intellicorp(Kappa) 
  3684.   ISIS Distributed Systems (RDOM) 
  3685.   Early, Cloud & Company (Message Driven processor)
  3686.   Expersoft(XShell)
  3687.   Cooperative Solutions(Ellipse)
  3688.  -----------------------------------------------------------------------
  3689.  
  3690.  
  3691. 3.13) What Is The MVC Framework?
  3692. --------------------------------
  3693.  
  3694. MVC stands for Model-View-Controller.  This framework was originally adopted
  3695. in Smalltalk to support Graphical User Interfaces.  Views support graphical
  3696. interfacing, controllers handle interaction, and models are the application
  3697. objects.  See [Krasner 88] and [LaLonde 90b].
  3698.  
  3699. From: Carl Petter Swensson <cepe@taskon.no>
  3700.   Prof. Trygve Reenskaug is generally cited as being the creator of
  3701.   the MVC concept. He worked with the Smalltalk group at Xerox PARC
  3702.   as a visiting scientist in 78/79. During this stay at Xerox PARC 
  3703.   he developed the MVC. I know him well and have talked to him about
  3704.   this. He confirms it, although stating that it was a collaborative
  3705.   effort at Xerox PARC.
  3706.  
  3707.   The implementation of MVC in Smalltalk-80 has since been further
  3708.   developed by ParcPlace Systems.
  3709.  
  3710.   He has worked with Smalltalk in a commercial and research
  3711.   environments since then. His group at the Centre for Industral
  3712.   Research in Oslo (now part of the SINTEF group) had the only
  3713.   Smalltalk-78 implementation outside Xerox PARC.  He is now working
  3714.   with Taskon AS.
  3715.  
  3716.   The ideas that initially gave MVC has been developed further and 
  3717.   is the basis of the work Trygve is currently doing on the
  3718.   OOram methodology.
  3719.  
  3720.  
  3721. 3.14) What is Real-Time?
  3722. ------------------------
  3723.  
  3724. Real-time is our linear extrapolation/perception of imaginary time (along the
  3725. quantum wave function (OTU) in ten dimensions, of course).
  3726.  
  3727. [This section is YTBI]
  3728.  
  3729.  
  3730. 3.15) What Is Available on OO Metrics?
  3731. --------------------------------------
  3732.  
  3733. This section is still building.
  3734.  
  3735. [Berard 93] contains an elaborate bibliography and section on OO metrics.
  3736. [Booch 94] also contains some coverage.
  3737.  
  3738. Also:
  3739. Object Oriented Software development
  3740. Mark Lorenz ISBN 0-13-726928-5
  3741. Prentice Hall
  3742.  
  3743. Software Metrics
  3744. Grady-Caswell ISBN 0-13-821844-7
  3745. Prentice Hall
  3746.  
  3747. Measuring Software Design Quality
  3748. Card-Glass ISBN 0-13-568593-1
  3749. Prentice Hall
  3750.  
  3751. From: trilk@informatik.tu-muenchen.de (Joern Trilk)
  3752. Newsgroups: comp.object,comp.lang.c++,comp.lang.smalltalk,comp.databases.object
  3753. Subject: Re: In search of OO Metrics
  3754. Date: 20 Jun 1994 14:29:27 GMT
  3755. Organization: Technische Universitaet Muenchen, Germany
  3756.  
  3757. >...
  3758. Here are some references:
  3759.  
  3760. @article{inheriting:1993,
  3761.     author  = {G. Michael Barnes and Bradley R. Swim},
  3762.     title   = {Inheriting software metrics},
  3763.     journal = {JOOP},
  3764.     year    = {1993},
  3765.     month   = {Nov./Dec.},
  3766.     volume  = {6},
  3767.     number  = {7},
  3768.     pages   = {27-34}
  3769. }
  3770.  
  3771.  
  3772. @article{a-new-metr:1993,
  3773.     author  = {J.-Y. Chen and J.-F. Lu},
  3774.     title   = {A new metric for object-oriented design},
  3775.     journal = {Information and Software Technology},
  3776.     year    = {1993},
  3777.     month   = apr,
  3778.     volume  = {35},
  3779.     number  = {4},
  3780.     pages   = {232-240}
  3781. }
  3782.  
  3783.  
  3784. @inproceedings{towards-a-:1991,
  3785.     author  = {Shyam R. Chidamber and Chris F. Kemerer},
  3786.     title   = {Towards a Metrics Suite for Object Oriented Design},
  3787.     booktitle = {OOPSLA '91 Proceeedings},
  3788.     year    = {1991},
  3789.     pages   = {197-211}
  3790. }
  3791.  
  3792.  
  3793. @inproceedings{software-m:1992,
  3794.     author  = {J. Chris Coppick and Thomas J. Cheatham},
  3795.     title   = {Software Metrics for Object-Oriented Systems},
  3796.     booktitle = {CSC '92 Proceedings},
  3797.     year    = {1992},
  3798.     pages   = {317-322}
  3799. }
  3800.  
  3801.  
  3802. @inproceedings{some-metri:1991,
  3803.     author  = {B. Henderson-Sellers},
  3804.     title   = {Some metrics for object-oriented software engineering},
  3805.     booktitle = {TOOLS Proceedings},
  3806.     year    = {1991},
  3807.     pages   = {131-139}
  3808. }
  3809.  
  3810.  
  3811. @article{object-ori:1993,
  3812.     author  = {Wei Li and Sallie Henry},
  3813.     title   = {Object-Oriented Metrics that Predict Maintainability},
  3814.     journal = {J. Systems Software},
  3815.     year    = {1993},
  3816.     volume  = {23},
  3817.     pages   = {111-122}
  3818. }
  3819.  
  3820.  
  3821. @inproceedings{workshop-r:1992,
  3822.     author  = {Teri Roberts},
  3823.     title   = {Workshop Report - Metrics for Object-Oriented Software Development},
  3824.     booktitle = {OOPSLA '92 (Addendum to the Proceedings)},
  3825.     year    = {1992},
  3826.     pages   = {97-100}
  3827. }
  3828.  
  3829.  
  3830. @techreport{softwareme:1991,
  3831.     author  = {A. Buth},
  3832.     title   = {Softwaremetriken f{\"u}r objekt-orientierte Programmiersprachen},    institution = {Gesellschaft f{\"u}r Mathematik und Datenverarbeitung},
  3833.     year    = {1991},
  3834.     month   = jun,
  3835.     number  = {545},
  3836.     type    = {Arbeitspapiere der GMD}
  3837. }
  3838.  
  3839.  
  3840. The Software Engineering FAQ lists the following references concerning
  3841. metrics for object-oriented systems:
  3842.  
  3843. Date: 26 Jan 1993 Originally collected by: ZUSE%DB0TUI11.BITNET@vm.gmd.de
  3844. (Horst Zuse) 
  3845.  
  3846. a. Morris Kenneth L.  Metrics for Object-Oriented Software Development
  3847.    Environments (master's thesis). 1989, MIT.
  3848. b. Rocacher, Daniel: Metrics Definitions for Smalltalk.  Project ESPRIT 1257,
  3849.    MUSE WP9A, 1988.
  3850. c. Rocacher, Daniel: Smalltalk Measure Analysis Manual.  Project ESPRIT 1257,
  3851.    MUSE WP9A, 1989.
  3852. d. Lake, Al: A Software Complexity Metric for C++.  Annual Oregon Workshop on
  3853.    Software Metrics, March 22-24, 1992, Silver Falls, Oregon, USA.
  3854. e. Bieman, J.M.: Deriving Measures of Software Reuse in Object Oriented
  3855.    Systems.  Technical Report #CS91-112, July 1991, Colorado State Universty,
  3856.    Fort Collins/ Colorado, USA.
  3857.  
  3858. Hope this helps,
  3859.     Joern
  3860.  
  3861. ----------------------------------------------------------------------
  3862. Joern Trilk            Phone: ++49-89-2105-2391
  3863. Institut fuer Informatik (H1)    Fax:   ++49-89-2105-5296
  3864. TU Muenchen            Email: trilk@informatik.tu-muenchen.de
  3865. 80290 Muenchen                    
  3866. ----------------------------------------------------------------------
  3867.  
  3868.  
  3869. Newsgroups: comp.software-eng
  3870. From: scottw@advsysres.com (Scott A. Whitmire)
  3871. Subject: Re: Any good OO metrics?
  3872. Organization: Advanced Systems Research
  3873. Date: Mon, 28 Nov 1994 05:58:29 GMT
  3874.  
  3875. In <3baqhn$crg@newsbf01.news.aol.com>, cjdavies@aol.com (Cjdavies) writes:
  3876. >Has anyone come up with metrics that work realistically for OO
  3877. >development?  The old lines of code, cyclomatic complexity and Halstead
  3878. >metrics don't work so well with OO languages such as Smalltalk (or any
  3879. >language that facilitates reuse).  Also, has anyone adapted function
  3880. >points to OO languages?  Any ideas would be most welcome.
  3881. >Thanks,
  3882. >Colin Davies.
  3883.  
  3884. Several people have been working in metrics for oo development.  For a quick
  3885. synopsis, check out my article in the "Encyclopedia of Software Engineering"
  3886. edited by John Marciniak and published by John Wiley & Sons.  The article
  3887. gives an overview of the work being done in the field, and what needs to be
  3888. done.  It is a couple of years old now, but there really isn't that much going
  3889. on.
  3890.  
  3891. I did run into one book called "Object-Oriented Software Metrics" (I forget the
  3892. authors), but I didn't think much of it.
  3893.  
  3894. Your assessment of LOC, cyclomatic complexity, and Halsted are right on the
  3895. money.
  3896.  
  3897. As for function points and OO, I think you'll find two papers useful.  The first
  3898. is a chapter I wrote for the "Software Engineering Productivity Handbook" edited
  3899. by Jessica Keyes and published by McGraw-Hill.  It applies standard function points
  3900. to OO software.  I suspect you'll find standard function points wanting.  I use
  3901. an extension I developed a couple of years ago called 3D function points.  I have
  3902. an electronic (plain text) version of the paper I can send if you like.
  3903.  
  3904. Metrics and OO development are fairly new to each other.  I am working on ways to
  3905. measure such design characteristics as cohesion, coupling, complexity, similarity
  3906. and the like.  I haven't been too thrilled with the work that has been done so far.
  3907. Much of it has serious theoretical and technical flaws.
  3908.  
  3909. Scott A. Whitmire             scottw@advsysres.com
  3910. Advanced Systems Research     
  3911. 25238 127th Avenue SE         tel:(206)631-7868
  3912. Kent Washington 98031         fax:(206)630-2238
  3913.  
  3914. Consultants in networking, network-based applications, and software metrics.
  3915.  
  3916.  
  3917. 3.16) What Are Visual Object-Oriented Programming Systems?
  3918.  
  3919. See also http://union.ncsa.uiuc.edu/HyperNews/get/computing/visual.html.
  3920. There is also a comp.lang.visual and FAQ, similar to the www html above.
  3921.  
  3922. Visual programming is the use of graphics and graphical techniques in
  3923. computer programming.  It is becoming more common to see many
  3924. approaches to visual/graphical programming languages emerging that
  3925. incorporate the object-oriented programming philisophy.  Toward this
  3926. end, developers of new programming languages and programming
  3927. environments are exploring how to combine visual programming with
  3928. object-oriented programming by investigating how the basic concepts of
  3929. OOP -- data abstraction, instantiation, composition, and
  3930. specialization -- create new opportunities for programming using
  3931. visual means of construction.
  3932.  
  3933. A workshop on this topic was conducted at the 1993 OOPSLA, and a
  3934. workshop summary appeared as part of the 1993 OOPSLA Addendum.  Several
  3935. of the presenters at the workshop developed full versions of their
  3936. presentations, which are available in book form:
  3937.  
  3938.     Visual Object-Oriented Programming: Concepts and Environments,
  3939.     Margaret Burnett, Adele Goldberg, and Ted Lewis, editors,
  3940.     Prentice-Hall/Manning Publications, Englewood Cliffs, NJ, 1995.
  3941.  
  3942.     http://www.cs.orst.edu/techpub/vlib/vlib/Visual-OOP/CARD.html
  3943.  
  3944. -----
  3945. Margaret Burnett        .       e-mail: burnett@cs.orst.edu
  3946. Assistant Professor       .       WWW page: http://www.cs.orst.edu/~burnett/
  3947. Computer Science Dept.      .        
  3948. Oregon State University       .
  3949. Corvallis, Oregon 97331 USA     .
  3950.  
  3951.  
  3952. 3.17) What Tutorials Are Available On Object-Oriented Concepts and Languages?
  3953.  
  3954. Date: Thu, 25 May 95 17:31:21 EDT
  3955. From: wheeler@ida.org (David Wheeler)
  3956.  
  3957. A list of C/C++ tutorials, including online tutorials, is maintained at:
  3958.   http://vinny.csd.mu.edu/learn.html
  3959.  
  3960. Note that C and C++ are treated together.  One of the tutorials listed is the
  3961. course: "Introduction to Object Oriented Programming Using C++", a self-paced
  3962. class within the Globewide Network Academy [GNA]; this course may be found at:
  3963.   http://uu-gna.mit.edu:8001/uu-gna/text/cc/index.html
  3964.  
  3965. Another course listed is the Coronado Enterprises C++ Tutorial, which assumes
  3966. that the user is already familiar with C (not necessarily ANSI C).  It may be
  3967. downloaded from:
  3968.   anonymous@oak.oakland.edu:simtel/msdos/cpluspls/cptuts22.zip
  3969.   anonymous@oak.oakland.edu:simtel/msdos/cpluspls/cptutt22.zip
  3970.  
  3971. One Ada 95 on-line tutorial is Lovelace, which is intended for those who are
  3972. already familiar with other algorithmic programming languages and are somewhat
  3973. familiar with object orientation.  Lovelace is available at:
  3974.   anonymous@lglftp.epfl.ch:/pub/Ada/HTML/lovelace.zip
  3975.   http://lglwww.epfl.ch/Ada/Tutorials/Lovelace/lovelace.html
  3976.  
  3977. Other Ada tutorials are listed in:
  3978.   http://lglwww.epfl.ch/Ada/Tutorials/Lovelace/othert.html
  3979.  
  3980. The Sather home page includes a list of Sather tutorials in its "Getting
  3981. Started" section:
  3982.   http://http.icsi.berkeley.edu/Sather/
  3983.  
  3984. The BETA language is introduced in:
  3985.  http://www.daimi.aau.dk/~beta/Tutorials/BETAintroduction/BETAintroduction.html
  3986.  
  3987. A large list of SELF-related papers available electronically is at:
  3988.   http://self.stanford.edu/papers/papers.html
  3989.  
  3990. The Booch design method is briefly described in
  3991.   http://www.itr.ch/tt/case/BoochReferenz/
  3992.  
  3993. For a list of many different resources of computer-language-specific
  3994. information, see the YAHOO list of computer languages at:
  3995.   http://www.yahoo.com/Computers/Languages/
  3996.  
  3997.  
  3998.  
  3999.  
  4000. SECTION 4:  COMMONLY ASKED LANGUAGE SPECIFIC QUESTIONS
  4001. ======================================================
  4002.  
  4003. 4.1)  What is Downcasting?
  4004. --------------------------
  4005.  
  4006. Downcasting is the term used in C++ for casting a pointer or reference to
  4007. a base class to a derived class.  This should usually be checked with an
  4008. embedded dynamic typing scheme if such a scheme is not present in the
  4009. language, such as with a typecase (Modula-3) or inspect (Simula) construct.
  4010. In C++, it is even possible to use conversion functions to perform some
  4011. checks, although the proposed RTTI will perform checked downcasting as
  4012. its primary ability.
  4013.  
  4014.  
  4015. 4.2)  What are Virtual Functions?
  4016. ---------------------------------
  4017.  
  4018. Look under "Dynamic Binding" and "Polymorphism".
  4019.  
  4020.  
  4021. 4.3)  Can I Use Multiple-Polymorphism Or Multi-Methods In C++?
  4022. ---------------------------------------------------------------
  4023.  
  4024. Yes, but you'll need to embed a dynamic typing scheme to do it.  With dynamic
  4025. types in place, an overriding method in a derived class can explicitly check
  4026. argument types in a switch statement and invoke the desired method emulating
  4027. multiple-polymorphism [See Coplien 92].  
  4028.  
  4029. For true CLOS multi-methods, the above technique implemented as a base function
  4030. (CLOS defgeneric), switching to specialized functions (CLOS methods, made
  4031. friends of all arguments) will provide the functional calling syntax, multiple-
  4032. polymorphism and access to parameters found in CLOS.  This can require some
  4033. complex switching, which is somewhat mitigated when multiple-polymorphism
  4034. is implemented with virtual functions.
  4035.  
  4036. Future FAQs should contain more detail.
  4037.  
  4038.  
  4039. 4.4)  Can I Use Dynamic Inheritance In C++?
  4040. -------------------------------------------
  4041.  
  4042. Yes, [Coplien 92] describes a scheme where a class can contain a pointer to
  4043. a base class that can switch between its derived classes, providing a limited
  4044. form.  Earlier chapters contain entries on bypassing C++'s message system and
  4045. even bypassing static linking.
  4046.  
  4047. Future FAQs should contain more detail.
  4048.  
  4049.  
  4050.  
  4051. ANNOTATED BIBLIOGRAPHY
  4052. ======================
  4053.  
  4054. [Agrawal 91]  R. Agrawal et al.  "Static Type Checking of Multi-Methods".
  4055.  OOPSLA 91.  Object-Oriented Programming Systems, Languages, and Applications.  
  4056.  ACM Press.  Addison Wesley.
  4057.  
  4058.   Compile-time checking and optimizations for multi-methods.
  4059.  
  4060. [Aho 86] Alfred V. Aho, Ravi Sethi, and Jeffrey D. Ullman.  Compilers:
  4061.  Principles, Techniques, and Tools. Reading, MA: Addison-Wesley, 1986.
  4062.  
  4063.   Authoritative, classic book on compilers and optimizations.  Type chapter
  4064.   contains section on type inferencing (using ML as an example).
  4065.  
  4066. [Berard 93]  Edward V. Berard.  Essays on Object-Oriented Software
  4067.   Engineering.  Prentice Hall.
  4068.  
  4069.   Many topics on OOSE, includes coverage of OO domain and requirements
  4070.   analysis.
  4071.  
  4072. [Black 86] A. Black et al.  Object-Structure in the Emerald System.  OOPSLA
  4073.  '86 Conference Proceedings, SIGPLAN Notices (Special Issue), Vol. 21, n0. 11,
  4074.  pp 78-86.    [I believe there is a more recent article, YTBI]
  4075.  
  4076.   The original article on Emerald.  OO language without inheritance but with
  4077.   abstract types and static subtype polymorphism.  Also designed for
  4078.   distributed programming and reuse.  See article for references: Jade on
  4079.   reuse [Raj 89]) and Distr. Prog.
  4080.  
  4081. [Black 87] A. Black, N. Hutchinson, E. Jul, H. Levyand L. Carter.  Distribution
  4082.  and Abstract Types in Emerald, IEEE Transactions on Software Engineering, Vol.
  4083.  SE13, no. 1 Jam., pp 65-76.
  4084.  
  4085.   Subtype polymorphism for distributed programming in Emerald [Black 86].
  4086.  
  4087. [Blair 89] "Genericity vs Inheritance vs Delegation vs Conformance vs ..."
  4088.  Gordon Blair, John Gallagher and Javad Malik, Journal of Object Oriented
  4089.  Programming, Sept/Oct 1989, pp11-17.
  4090.  
  4091.   Recommended by a reader, but the Author has yet to review this article.
  4092.  
  4093. [Boehm 86] B.W. Boehm. A Spiral Model of Software Development and Enhancement.
  4094.  Software Engineering Notes, Aug., vol. 11 (4), p 22.
  4095.  
  4096.  Presents an alternative evolutionary approach to the strict waterfall software
  4097.  engineering life-cycle.  Now a classic, most OO methodologies now emphasize
  4098.  the iterative or evolutionary approach to software development.
  4099.  
  4100. [Booch 87] Grady Booch.  Software Engineering with Ada.  2nd Ed.  Benjamin
  4101.  Cummings.
  4102.  
  4103.   Booch in his early years.  Mostly object-based programming with Ada.
  4104.  
  4105. [Booch 87b] Grady Booch.  Software Components With Ada, Structures, Tools,
  4106.  and Subsystems.  Benjamin Cummings.
  4107.  
  4108.   A taxonomy and collection of object-based components in Ada (includes code).
  4109.   Has many examples with generics.
  4110.  
  4111. [Booch 91] Booch, Grady. Object-Oriented Design With Applications.  Benjamin
  4112.   Cummings.
  4113.  
  4114.   The often referred to book on OOD.  Offers design notation and methodology.
  4115.   Brief coverage of OOA and elaborate OOD/P coverage in the applications.
  4116.   Good on basic principles and has case studies in Smalltalk, Object Pascal, 
  4117.   C++, CLOS and Ada.
  4118.  
  4119.   Also contains an *elaborate* classified bibliography on many areas of OO.
  4120.  
  4121. [Booch 94]  Grady Booch.  Object-Oriented Analysis And Design With
  4122.  Applications, 2nd Ed. Benjamin Cummings.  ISBN 0-8053-5340-2.
  4123.  
  4124.   The next FAQ should be updated to the second edition.  All examples are now
  4125.   in C++.  Booch incorporates several other major methodologies including
  4126.   Wirf-Brock's CRC (Class-Responsibility-Collaboration) and Jacobson's Use-
  4127.   Cases.
  4128.  
  4129. [Cardelli 85]  L. Cardelli and P. Wegner.  On Understanding Types, Data
  4130.  Abstraction, and Polymorphism.  ACM Computing Surveys vol. 17 (4).
  4131.  
  4132.  Long, classic article on Object-Oriented Types, Data Abstraction and
  4133.  Polymorphism.  Formal coverage with a type system analysis model as well.
  4134.  
  4135. [Chambers 92]  Craig Chambers.  The Design and Implementation of the SELF
  4136.  Compiler, an Optimizing Compiler for Object-Oriented Programming Languages.
  4137.  Dept of Computer Science, Stanford University, March 1992.
  4138.  
  4139.   Covers type optimizations for OO compilers.  See Appendix E, PAPERS.
  4140.  
  4141. [Chambers 93]  Craig Chambers.  Predicate Classes.  Proceedings ECOOP '93
  4142.   O. Nierstrasz, LNCS 707. Springer-Verlag, Kaiserslautern, Germany
  4143.   July 1993 pp 268-296
  4144.  
  4145.    "... an object is automatically an instance of a predicate class whenever
  4146.    it satisfies a predicate expression associated with the predicate class.
  4147.    The predicate expression can test the value or state of the object, thus
  4148.    supporting a form of implicit property-based classification that augments
  4149.    the explicit type-based classification provided by normal classes.  By
  4150.    associating methods with predicate classes, method lookup can depend not
  4151.    only on the dynamic class of an argument but also on its dynamic value or
  4152.    state. [...] A version of predicate classes has been designed and
  4153.    implemented in the context of the Cecil language.
  4154.  
  4155.   See Appendix E, PAPERS.
  4156.  
  4157. [de Champeaux 93] Dennis de Champeaux, Doug Lea, Penelope Faure.
  4158.  Object-Oriented System Development.  Addison-Wesley, ISBN 0-201-56355-X.
  4159.  
  4160.   Covers an integrated treatment of OOA and OOD.  Takes serious the
  4161.   computational model of one thread per object.  Gives more than usual
  4162.   attention to the OOA&D micro process.  Presents a unique OOD language.
  4163.  
  4164. [Coad 91]  Peter Coad and Edward Yourdon. Object-Oriented Analysis, 2nd ed.
  4165.  Englewood Cliffs, NJ. Prentice Hall.
  4166.  
  4167.   Coad and Yourdon's OO analysis method.
  4168.  
  4169. [Coad 91b]  Peter Coad and Edward Yourdon. Object-Oriented Design.  Englewood
  4170.  Cliffs, NJ. Prentice Hall.
  4171.  
  4172.   Coad and Yourdon's OO design method.
  4173.  
  4174. [Coleman 94] Derek Coleman, et. al.  Object-Oriented Development - The Fusion
  4175.  Method.  Prentice-Hall Object-Oriented Series. ISBN 0-13-338823-9
  4176.  
  4177.   Fusion is considered to be a second generation OOAD method in that it builds
  4178.   on successful components of a number of first generation methods (OMT, Booch,
  4179.   CRC, Objectory, etc).  However, this has been done with the requirements of
  4180.   industrial software developers in mind. And so issues of traceability,
  4181.   management etc. have been taken into consideration and the Method provides
  4182.   full coverage from requirements through to code.
  4183.  
  4184. [Cook 90] W.R. Cook, W.L.Hill, P.S. Canning. Inheritance Is Not Subtyping.
  4185.   Appeared in [Hudak 90] and Gunter 94].
  4186.  
  4187.     Theoretical article on the separation between type and class, or as the
  4188.     authors state between implementation inheritance and subtyping.
  4189.  
  4190. [Coplien 92] James O. Coplien.  Advanced C++ Programming Styles and Idioms.
  4191.   Addison Wesley.
  4192.  
  4193.   Covers advanced C++ programming and performing other more advanced and
  4194.   dynamic styles of OO in C++.
  4195.  
  4196. [Colbert 89]  E. Colbert.  The Object-Oriented Software Development Method: a
  4197.  practical approach to object-oriented development.  Tri-Ada Proc., New York.
  4198.  
  4199.   Presents the Object-Oriented Software development method.  Has emphasis on
  4200.   objects.
  4201.  
  4202. [Cox 86,91] Cox, Brad J.  Object-Oriented Programming, An Evolutionary
  4203.  Approach.  Addison Wesley.
  4204.  
  4205.   The original book on Objective-C.  Coverage on object-oriented design and
  4206.   programming.  Also covers Objective-C implementation, even into object code.
  4207.   
  4208.   Objective-C... '91 AW by Pinson and Wiener provide another good text.
  4209.  
  4210. [Embley 92]  D.W. Embley, B.D. Kurtz, S.N. Woodfield.  Object-Oriented Systems
  4211.  Analysis, A Model-Driven Approach. Yourdon Press/Prentice Hall, Englewood
  4212.  Cliffs, NJ.
  4213.  
  4214.   Presents the Embley and Kurtz OO methodology.
  4215.  
  4216. [Garfinkel 93]  Simson L. Garfinkel and Michael K. Mahoney.  NeXTSTEP
  4217.  PROGRAMMING  STEP ONE: Object-Oriented Applications.  Springer-Verlag.
  4218.  
  4219.   Introduction to the NextStep environment and applications development.
  4220.  
  4221. [Goldberg 83] Adele Goldberg and David Robson. Smalltalk-80 The Language and
  4222.  Its Implementation.  Addison Wesley.
  4223.  
  4224.   The original book on Smalltalk.  Covers implementation.  Also known as "the
  4225.   Blue Book".  Out of print.  Superceded by [Goldberg ??].
  4226.  
  4227. [Goldberg ??] Adele Goldberg and David Robson. Smalltalk-80: The Language.
  4228.  Addison-Wesley. 
  4229.  
  4230.   The "Purple Book".  Omits the obsolete abstract virtual machine description
  4231.   from the Blue Book.
  4232.  
  4233. [Gunter 94] Carl A. Gunter and John C. Mitchell. Theoretical Aspects of Object-
  4234.  Oriented Programming. MIT Press.  ISBN 0-262-07155-X.
  4235.  
  4236.   Highly mathematical, formal coverage of object-oriented programming;
  4237.   primarily on typing.
  4238.  
  4239. [Harmon 93] Paul Harmon.  Objects In Action: Commercial Applications Of Object-
  4240.  Oriented Technologies.  Jan, 1993.  A-W ISBN 0-201-63336-1.
  4241.  
  4242.   Sponsored by the OMG to summarize the use of OO technology in industry and
  4243.   business, contains a brief history and summary of OO and many case studies.
  4244.  
  4245. [HOOD 89] HOOD Working Group.  HOOD Reference Manual Issue 3.0.  WME/89-173/JB.
  4246.  Hood User Manual Issue 3.0. WME/89-353/JB.  European Space Agency.
  4247.  
  4248.   Presnets the HOOD (Hierarchical Object-Oriented Design) OOSE methodology.
  4249.   From the European Space Agency.  Based on Ada and object-based.
  4250.  
  4251. [Hudak 90] P. Hudak. Principles of Programming Languages.  ACM Press, pp 125
  4252.  -135.
  4253.  
  4254.   Contains several articles, including [Cook 90].
  4255.  
  4256. [Hudak 92] Paul Hudak and Simon Peyton Jones.  Haskell Report. SIGPLAN Notices.
  4257.  1992, vol 27, no 5.
  4258.  
  4259.   Haskell reference.
  4260.  
  4261. [Humphrey 89]  Watts Humphrey.  Managing the Software Process.  Addison Wesley.
  4262.   ISBN 0-201-18095-2
  4263.  
  4264.   Sponsored by the Software Engineering Institute (SEI), the presented project
  4265.   management model is inspired by the work of Boehm, Brooks, Deming and Juran
  4266.   and represents a strong step in the direction of achieving 6 sigma defect
  4267.   rate prevention and optimizing the software development process for quality,
  4268.   productivity, and reliability.  Presents the CMM, see section 1.21.
  4269.  
  4270. [Humphrey 95]  Watts S. Humphrey - "A Discipline for Software Engineering",
  4271.  816 pp., $47.50, 1995, Addison-Wesley (1-800-824-7799) ISBN 0-201-54610-8
  4272.  
  4273.   A scaled down version of [Humphrey 89] for individual software engineers.
  4274.   A new classic.  See section 1.21.
  4275.  
  4276. [IBM 90,91]  Various Documents from the IBM International Technical Centers:
  4277.  GG24-3647-00, GG24-3641-00, GG24-3566-00, GG24-3580-00.
  4278.  
  4279.   Present IBM's OOSE methodology.
  4280.  
  4281. [Jacobson 92]  Ivar Jacobson, et al.  Object-Oriented Software Engineering - A
  4282.  Use Case Driven Approach. ACM Press/Addison Wesley.
  4283.  
  4284.   Presents Jacobson's new OOSE methodology based on use cases.
  4285.  
  4286. [Jacobson 94]  Ivar Jacobson.  Toward Mature Object Technology. ROAD, Vol. 1,
  4287.  No. 1, May-June.  SIGS Publications.
  4288.  
  4289.   Overview of OOSE's object-oriented approach.  Includes specialized objects
  4290.   and layering for complexity management.
  4291.  
  4292. [Jones 92]  Rick Jones. Extended type checking in Eiffel. Journal of Object-
  4293.  Oriented Programming, May 1992 issue, pp.59-62.
  4294.  
  4295.   Presents subtype polymorphic extension to Eiffel (static typing only).
  4296.  
  4297. [Jurik 92] John A. Jurik, Roger S. Schemenaur, "Experiences in Object Oriented
  4298.  Development," ACM 0-89791-529-1/92/0011-0189.
  4299.  
  4300.   Presents the EVB OOSE methodology.  Also: Barbara McAllister, Business
  4301.   Development, EVB Software Engineering, Inc., (301)695-6960, barb@evb.com.
  4302.  
  4303. [Kiczales 92] Gregor Kiczales, Jim des Rivieres, Daniel G. Bobrow.  The Art
  4304.  of the Metaobject Protocol.  The MIT Press.
  4305.  
  4306.   Reflection and Metaobject Protocols (MOPs).  Uses a CLOS subset, Clossette,
  4307.   as a foundation.
  4308.  
  4309. [Kim 89]  Won Kim and Frederick Lochovsky Editors.  Object-Oriented Concepts,
  4310.  Applications, and Databases.
  4311.  
  4312.   Collection of articles on advanced OO and research systems.
  4313.  
  4314. [Krasner 88] G. E. Krasner and S. T. Pope. A Cookbook for Using the Model-View-
  4315.  Controller User Interface Paradigm in Smalltalk-80. JOOP, vol 1, no 3, August/
  4316.  September, 1988, pp 26-49,
  4317.  
  4318.   An early paper published on MVC.
  4319.  
  4320. [Lakoff 87] George Lakoff.  Women, Fire, and Dangerous Things: What Categories
  4321.   Reveal About The Mind.  UOC Press.
  4322.  
  4323.   An almost formal view of classification/categorization by the noted cognitive
  4324.   scientist, George Lakoff.  His view blasts objectivism and contends to
  4325.   replace it with a subjectivist view, based on a study of humans, natural
  4326.   language, and concept formation.
  4327.  
  4328. [LaLonde 90]  Wilf R. LaLonde and John R. Pugh.  Inside Smalltalk: Volume 1.
  4329.  Prentice Hall.
  4330.  
  4331.   Good introduction to Smalltalk.
  4332.  
  4333. [LaLonde 90b]  Wilf R. LaLonde and John R. Pugh.  Inside Smalltalk: Volume 2.
  4334.  Prentice Hall.
  4335.  
  4336.   Excellent coverage of MVC. However, it's based on ParcPlace Smalltalk-80,
  4337.   version 2.5, which is obsolete.
  4338.  
  4339. [Liskov 93] Barbara Liskov and Jeannette M. Wing.  Specifications and Their use
  4340.  in Defining Subtypes.  OOPSLA 93, pp 16-28.  ASM SIGPLAN Notices, V 28, No 10,
  4341.  Oct. 1993.  A-W ISBN 0-201-58895-1.
  4342.  
  4343.   Specifications on Subtype hierarchies.  Helps to insure the semantic
  4344.   integrity of a separate subtype system.  See section 2.7.
  4345.  
  4346. [Madsen 93] Ole Lehrmann  Madsen, Birger Moller-Pedersen, Kristen Nygaard:
  4347.  Object-oriented programming in the BETA programming language.  Addison-Wesley,
  4348.  June 1993. ISBN 0 201 62430 3
  4349.  
  4350.   The new and authoritative book on BETA, by the original designers.  They
  4351.   are some of the same designers of the Simula languages, originating OO.
  4352.   Also just announced:
  4353.     Object-Oriented Environments: The Mjolner Approach
  4354.     Editors: Jorgen Lindskov Knudsen, Mats Lofgren, Ole Lehrmann Madsen,
  4355.          Boris Magnusson
  4356.     Prentice Hall: The Object-Oriented Series
  4357.     ISBN: 0-13-009291-6 (hbk)
  4358.  
  4359. [Martin 92] James Martin and James J. Odell. Object-Oriented Analysis and
  4360.  Design, Prentice-Hall, Englewood Cliffs, NJ.  
  4361.  
  4362.   Its primary purpose is to indicate how information engineering (IE) can be 
  4363.   evolved to accommodate OO.  The analysis portion (starting at Chapter 15) 
  4364.   attempts to go back to 'first principles' and is based on a formal foundation.
  4365.   Therefore, the IE aspect is not required.  Emphasis is more on analysis than 
  4366.   design.
  4367.  
  4368. [Meyer 88] Bertrand Meyer. Object-Oriented Software Construction.  Prentice
  4369.  Hall.  [Is there a new edition out?]
  4370.  
  4371.   The original book on Eiffel.  Coverage on object-oriented design and
  4372.   programming.  Also:
  4373.  
  4374.  
  4375. [Meyer 92] Bertrand Meyer. Eiffel: The Language. Prentice Hall. Englewood
  4376.  Cliffs, NJ. 1992.
  4377.  
  4378.   The definitive book on Eiffel by its author.
  4379.  
  4380. [Meyer 94] Bertrand Meyer. Reusable Software: The Base Object-Oriented
  4381.  Components Libraries.
  4382.  
  4383.   The new Eiffel class Libraries.
  4384.  
  4385. [Mugridge 91] Warwick B. Mugridge et al.  Multi-Methods in a Statically-Typed
  4386.  Programming Language. Proc. ECOOP.
  4387.  
  4388.   Efficient implementation of Multi-Methods.
  4389.  
  4390. [Murray 93] Robert B. Murray.  C++ Strategies and Tactics.  Addison Wesley.
  4391.  
  4392.   C++, has template examples.
  4393.  
  4394. [Nerson 92] Jean-Marc Nerson.  Applying Object-Oriented Analysis and Design.
  4395.  CACM, 9/92.
  4396.  
  4397.   Demonstrates the basics of the BON method/notation.  Nerson: marc@eiffel.fr
  4398.  
  4399. [Paepcke 93] Andreas Paepcke.  Object-Oriented Programming: The CLOS
  4400.  Perspective.  MIT Press.  ISBN 0-262-16136-2.
  4401.  
  4402.   CLOS, readable introduction to its metaobject protocol, comparisons with
  4403.   other languages, uses and methodology, and implementation.  Develops a
  4404.   persistent object metaclass example.
  4405.  
  4406. [Raj 89] R.K. Raj and H.M. Levy.  A Compositional Model for Software Reuse.
  4407.  The Computer Journal, Vol 32, No. 4, 1989. 
  4408.  
  4409.   A novel approach aading reuse to Emerald [Black 86] without inheritance.
  4410.  
  4411. [Reenskaug 91] T. Reenskaug, et al.  OORASS: seamless support for the creation
  4412.  and maintenance of object-oriented systems. Journal of Object-Oriented
  4413.  Programming, 5(6).
  4414.  
  4415.   Presents the Object-Oriented Role Analysis, synthesis, and Structuring
  4416.   OOSE methodology.
  4417.  
  4418. [Royce 70] W. W. Royce. Managing the Development of Large Software Systems.
  4419.  Proceedings of IEEE WESCON, August 1970.
  4420.  
  4421.  Introduces the Waterfall Process Model.
  4422.  
  4423. [Rumbaugh 91] Rumbaugh James, et al.  Object-Oriented Modeling and Design.
  4424.  Prentice Hall.
  4425.  
  4426.   The often referred to book on OOA/OOD.  Introduces the Object Modeling
  4427.   Technique (OMT) OOA/D notation and methodology.  Has case studies.
  4428.  
  4429. [Sciore 89] Edward Sciore.  Object Specialization. ACM Transactions on
  4430.  Information Systems, Vol. 7, No. 2, April 1989, p 103.
  4431.  
  4432.   A hybrid approach between delegation and classical OO.
  4433.  
  4434. [Selic 94] Bran Selic, Garth Gullekson, and Paul T. Ward. Real-Time
  4435.  Object-Oriented Modeling. Published by John Wiley & Sons. 
  4436.  ISBN 0-471-59917-4
  4437.  
  4438.   OO method addresses complete lifecycle needs of real-time systems. Emphasizes
  4439.   executable models for early validation of requirements, architecture, and
  4440.   design combined with techniques for automatic generation of implementations.
  4441.   Specifically real-time with iterative and incremental development process.
  4442.   Single consistent graphical modeling concepts apply uniformly to OOA/D/I.
  4443.  
  4444. [Shlaer 88] Sally Shlaer and Stephen J. Mellor.  Object-Oriented Systems
  4445.  Analysis: Modeling the World in Data.
  4446.  
  4447.   Credited as the first book proposing an OOA method.
  4448.  
  4449. [Shlaer 92] Sally Shlaer and Stephen J. Mellor.  Object Lifecycles: Modeling
  4450.   the World in States.
  4451.  
  4452.   An addition to [Shlaer 88], provides dynamic modeling with a state-
  4453.   transition driven approach.
  4454.  
  4455. [Strachey 67]  C. Strachey.  Fundamental Concepts in programming languages.
  4456.  Lecture Notes for International Summer School in Computer Programming,
  4457.  Copenhagen, Aug.
  4458.  
  4459.   Contains original, classical definition of polymorphism.
  4460.  
  4461. [Stroustrup 90] Ellis, M.A., Stroustrup. The Annotated C++ Reference Manual.
  4462.  Addison Wesley.
  4463.  
  4464.   The ARM; the original and definitive book on C++.  Serves as the ANSI
  4465.   base document for C++.  Also covers C++ implementation.  It is meant as 
  4466.   a reference (including for compiler writers), not as a tutorial for
  4467.   beginners.  Perhaps a better ref is [Stroustrup 91].
  4468.  
  4469. [Stroustrup 91] Stroustrup, B.  The C++ Programming Language (2nd edition).
  4470.  
  4471.   Has the ARM, better reference for the use of C++ (recommended by bs).
  4472.   Contains sections on object-oriented software engineering.
  4473.  
  4474. [Tasker 93]  Dan Tasker.  The Problem Space, Practical Techniques for
  4475.   Gathering & Specifying Requirements. ISBN: 0-646-12524-9.  Avail only from
  4476.   author, dant@swdev.research.otc.com.au.
  4477.  
  4478.   Object-oriented requirements definition.  Hypertext.  Uses Rumbaugh's OMT as
  4479.   a base.  See also APPENDIX D.
  4480.  
  4481. [Ungar 87] D. Ungar and R.B. Smith.  The Self Papers. [Entry To Be Completed]
  4482.  
  4483.   The documents on Self; a delegation/prototyping language.  Also covers Self
  4484.   implementation and optimization.  See also APPENDIX E, PAPERS section.
  4485.  
  4486. [Wasserman 90] A.I. Wasserman et al. The Object-Oriented Software Design
  4487.  Notation for Software Design Representation. IEEE Computer, 23(3).
  4488.  
  4489.   Presents the Object-Oriented Structured Design (OOSD) OOSE methodology.
  4490.   Traditional structured techniques to OO, hybrid containing structured
  4491.   design and Booch.
  4492.  
  4493. [Wegner 87] Peter Wegner. "Dimensions of Object-Based Language Design",
  4494.   Proceedings of OOPSLA '87, October 4-8 1987, SIGPLAN Notices
  4495.   (Special Issue), V22, No 12, pp168-182, 1987.
  4496.  
  4497. [Wikstrom 87] Ake Wikstrom.  Functional Programming Using Standard ML.
  4498.  Prentice Hall, ISBN 0-13-331661-0, 1987.
  4499.  
  4500.   ML reference.
  4501.  
  4502. [Wilkie 93] George Wilkie. Object-Oriented Software Engineering - The
  4503.  Professional Developer's Guide. Addison Wesley.
  4504.  
  4505.   Covers OOSE, 11 popular analysis and design methodologies with examples,
  4506.   comparisons, and analysis, information systems (OODB), and case studies.
  4507.  
  4508. [Winter Partners]  Winter Partners 
  4509.  
  4510.   A proprietary toolset (OSMOSYS) for OOA and OOD.
  4511.   Winter Partners
  4512.     London Office:                 Zurich Office:
  4513.       West Wing, The Hop Exchange
  4514.       24a Southwark Street           Florastrasse 44
  4515.       London SE1 1TY                 CH-8008 Zurich
  4516.       England                        Switzerland
  4517.       Tel. +44-(0)71-357-7292        Tel. +41-(0)1-386-95 11
  4518.       Fax. +44-(0)71-357-6650        Fax. +41-(0)1-386-95 00
  4519.  
  4520. [Wirfs-Brock 90] Rebecca Wirfs-Brock, Brian Wilkerson, Lauren Wiener.
  4521.  Designing Object Oriented Software, Englewood Cliffs, NJ. Prentice Hall.
  4522.  
  4523.   Presents a "Responsibility Driven Design" (RDD) with "Class, Responsibility,
  4524.   Collaboration" (CRC) technique, a modern and new OOA/OOD methodology.
  4525.  
  4526. [Yaoqing 93]  Gao Yaoqing and Yuen Chung Kwong.  A Survey of Implementations
  4527.  of Parallel, Concurrent, and Distributed Smalltalk.  ACM SIGPLAN Notices.
  4528.  Vol 28, No. 9, Sept 93.
  4529.  
  4530.   Covers implementations of Parallel, Concurrent, and Distributed Smalltalk.
  4531.  
  4532. [Yourdon 92]  Edward Yourdon.  Decline and Fall of the American Programmer.
  4533.  YPCS.
  4534.  
  4535.   Excellent coverage of modern software engineering practice and world-class
  4536.   software development organizations.
  4537.  
  4538. ############################################################################
  4539.  
  4540.  
  4541. Path: senator-bedfellow.mit.edu!faqserv
  4542. From: Bob Hathaway <rjh@geodesic.com>
  4543. Newsgroups: comp.object,comp.answers,news.answers
  4544. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Part 5/13
  4545. Supersedes: <object-faq/part5_805979999@rtfm.mit.edu>
  4546. Followup-To: comp.object
  4547. Date: 31 Aug 1995 15:32:39 GMT
  4548. Organization: Geodesic Systems
  4549. Lines: 1239
  4550. Approved: news-answers-request@MIT.Edu
  4551. Distribution: world
  4552. Expires: 14 Oct 1995 15:31:54 GMT
  4553. Message-ID: <object-faq/part5_809883114@rtfm.mit.edu>
  4554. References: <object-faq/part4_809883114@rtfm.mit.edu>
  4555. NNTP-Posting-Host: bloom-picayune.mit.edu
  4556. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  4557. X-Last-Updated: 1995/06/01
  4558. Originator: faqserv@bloom-picayune.MIT.EDU
  4559. Xref: senator-bedfellow.mit.edu comp.object:37587 comp.answers:13975 news.answers:51856
  4560.  
  4561. Archive-name: object-faq/part5
  4562. Last-Modified: 05/31/94
  4563. Version: 1.0.8
  4564.  
  4565.  
  4566.  
  4567. APPENDICES
  4568. ==========
  4569.  
  4570.  
  4571. APPENDIX A  VIPS
  4572. ================
  4573.  
  4574. These are individuals whose names appear in comp.object most often. 
  4575. Please send recommendations for *major* VIPS often cited or referenced.
  4576.  
  4577. Booch, Grady <egb@rational.com>
  4578. -------------------------------
  4579.  
  4580. Grady Booch has been an object- based/oriented advocate for some time.  He's
  4581. written books such as Software Engineering with Ada [Booch 87], Software
  4582. Components with Ada [Booch 87b], and OOA/D with Applications [Booch 91, 94].
  4583. His latest notations are often referred to as simply the "Booch" method or
  4584. notation and he is Chief Scientist at Rational, a company providing training
  4585. and automated support for the method with a tool named "Rose" (See Appendix D).
  4586. The Booch method now incorporates many modern methods, including OMT, and Dr.
  4587. Rumbaugh has recently joined forces with Grady at Rational.
  4588.  
  4589.  
  4590. Cox, Brad
  4591. ---------
  4592.  
  4593. Founder of Objective-C, which grafts the Smalltalk facilities of an
  4594. Object id and a messaging mechanism onto C.  Author of [Cox 87].
  4595.  
  4596.  
  4597. Goldberg, Adele  (Alan Kay, Dan Ingalls)
  4598. ----------------------------------------
  4599.  
  4600. One of the founders of Smalltalk (with Alan Kay and Dan Ingalls).  Coauthor
  4601. of [Goldberg 83, ??], "Smalltalk-80 The Language and its Implementation".
  4602. Smalltalk was invented by a group at Xerox PARC; and a spinoff, ParcPlace, is
  4603. now marketing Smalltalk environments (see APPENDIX C).
  4604.  
  4605.  
  4606. Meyer, Bertrand <bertrand@eiffel.com>
  4607. -------------------------------------
  4608.  
  4609. Founder of Eiffel, author of [Meyer 88].  Often posts to comp.lang.eiffel
  4610. and comp.object [what a FAQ writer notices].  His company, Interactive
  4611. Software Engineering, has a case tool called EiffelCase (see APPENDIX D).
  4612.  
  4613.  
  4614. Nygaard, Krysten (and Dahl, Ole-Johan)
  4615. --------------------------------------
  4616.  
  4617. Inventor of Simula, the first object-oriented programming language.  Also
  4618. inventor of object oriented design, for which Simula-67 was considered an
  4619. implementation technique.  Now B.B. Kristensen, O.L. Madsen, B. Moller-
  4620. Pedersen, and K. Nygaard are working on BETA, their successor to Simula.
  4621.  
  4622.  
  4623. Rumbaugh, Dr. James
  4624. -------------------
  4625.  
  4626. Part of Rumbaugh, Blaha, Premerlani, Eddy and Lorenson, the authors of
  4627. [Rumbaugh 91].  They all work for GE Corporate Research and Development Center
  4628. in Schenectady New York (See below) and have an OOA/OOD notation/methodology
  4629. called the "Object Modeling Technique" (OMT).  It is a rather formal and
  4630. complete method often discussed in comp.object.  OMTool is the name of the
  4631. CASE system provided by Martin Marietta which supports OMT.  See APPENDIX D.
  4632.  
  4633. Recently, Dr. Rumbaugh has joined forces with Chief Scientist Grady Booch at
  4634. Rational: Rumbaugh@rational.com 
  4635.  
  4636.  
  4637. Shlaer, Sally (and Mellor, Stephen J.)
  4638. --------------------------------------
  4639.  
  4640. >Sally Shlaer            sally@projtech.com
  4641. >Project Technology      Training and Consulting using Shlaer-Mellor OOA/RD
  4642. >Berkeley, CA            (510) 845 1484
  4643. Also: steve@projtech.com
  4644.  
  4645. Cofounder of the Shlaer/Mellor OOA/RD method, president of Project Technology.
  4646. As shown above, occasionally posts to comp.object [what a FAQ writer notices].
  4647.  
  4648.  
  4649. Stroustrup, Bjarne (bs@alice.att.com)
  4650. -------------------------------------
  4651.  
  4652. Inventor of C++, a C superset, which has probably gained the most widespread
  4653. use of any object-oriented language today.  Often found in comp.lang.c++ and
  4654. comp.object.
  4655.  
  4656.  
  4657.  
  4658. APPENDIX B  OBJECT-ORIENTED DATABASES AND VENDORS
  4659. =================================================
  4660.  
  4661. This is a list of available Object-Oriented databases.  Thanks go to Stewart
  4662. Clamen, who's survey on schema evolution provided a good start.  Additional
  4663. short entries are encouraged; please send additions to the author of the FAQ
  4664. (and/or to Stewart).
  4665.  
  4666. The most recent copy of Stewart Clamen's summary on available databases
  4667. support for schema evolution will be available indefinitely via anonymous
  4668. FTP from BYRON.SP.CS.CMU.EDU:/usr/anon/OODBMS/evolution-summary.
  4669.  
  4670. [Kim 89] covers a few of the research systems below in depth.
  4671.  
  4672. Starred entries also have an entry in "APPENDIX E  ANONYMOUS FTP SITES".
  4673.  
  4674. See also section 3.5 for an Object Database Management Group (ODMG) reference.
  4675.  
  4676.  
  4677. TABLE OF CONTENTS
  4678.  
  4679. Extended Relational Database Model
  4680.  Research Systems
  4681.   POSTGRES*     [marketed by Montage]
  4682.   Starburst     [IBM almaden, entry NYI]
  4683.  Commercial Systems
  4684.   Montage       [Research System POSTGRES]
  4685.  
  4686. Object-Oriented Data Model
  4687.  Research Systems
  4688.   AVANCE
  4689.   CLOSQL
  4690.   ConceptBase*
  4691.   COOL/COCOON
  4692.   Encore*
  4693.   Exodus*
  4694.   Machiavelli
  4695.   MOOD4-PC*
  4696.   OBST/STONE*
  4697.   Ode*
  4698.   Oggetto
  4699.   Orion [marketed as ITASCA, see Entry]
  4700.   OTGen
  4701.   VODAK
  4702.  Commercial Systems
  4703.   ArtBASE
  4704.   EasyDB (Objective Systems, Sweden)
  4705.   GemStone/GeODE
  4706.   ITASCA
  4707.   Matisse
  4708.   NeoAccess
  4709.   O2
  4710.   Objectivity/DB
  4711.   ObjectStore
  4712.   Ontos [formerly VBase]
  4713.   Odapter/OpenODB program (HP)
  4714.   Poet
  4715.   Statice
  4716.   UniSQL
  4717.   Versant
  4718.  
  4719. Other Models
  4720.  Research Systems  
  4721.   GRAS*
  4722.   IRIS
  4723.  Commercial Systems  
  4724.   IDL
  4725.   Kala
  4726.   Pick
  4727.  
  4728. Interfaces
  4729.  Research Systems
  4730.   Penguin
  4731.  Commercial Systems
  4732.   AllegroStore (Franz)
  4733.   Object Gateway
  4734.   Persistence
  4735.   Subtleware
  4736.   Synchronicity (Smalltalk)
  4737.  
  4738.  
  4739. EXTENDED RELATIONAL DB MODEL
  4740. ----------------------------
  4741.  
  4742. Research Systems
  4743. ________________
  4744.  
  4745.  
  4746. > POSTGRES (Berkeley)
  4747.  
  4748. POSTGRES is an extended-relational database manager that supports
  4749. inheritance, user-defined types, functions, and operators, ad-hoc
  4750. queries, time travel, a rules system, tertiary storage devices,
  4751. and very large typed objects, among other things.  POSTGRES speaks
  4752. postquel, a derivative of the quel query language originally
  4753. designed at berkeley for the ingres database system.  User functions
  4754. may be written in C or in postquel.  C functions will be dynamically
  4755. loaded into the database server on demand, and either kind of function
  4756. may be executed from the query language.
  4757.  
  4758. POSTGRES and the papers that describe it are available free of charge
  4759. from toe.CS.Berkeley.EDU (128.32.149.117) in directory pub/postgres.
  4760. The code is stored in a directory named after the latest release; at
  4761. the time of this writing, that directory is postgres-v4r1.  The list
  4762. of officially-supported ports is short (decstations running ultrix 4.x
  4763. and sparcstations).  Unofficially, many more are supported -- people
  4764. elsewhere have done the ports and distribute their versions of the
  4765. code.  The list of unofficial ports is available in pub/postgres as
  4766. file UNOFFICIAL-PORT-LIST.
  4767.  
  4768. On Type Evolution:
  4769. You ask explicitly about type evolution.  We support schema
  4770. modification on all classes, including user classes.  This means that
  4771. you can add attributes (instance slots) and methods at any time.
  4772. Further, since postgres is a shared database system, such changes are
  4773. instantly visible to any other user of the class.
  4774.  
  4775. The language syntax supports attribute deletion, but the system won't
  4776. do it yet.  Since all data is persistent, removing attributes from a
  4777. class requires some work -- you need to either get rid of or ignore
  4778. all the values you've already stored.
  4779.  
  4780. Contact:
  4781. Paul Aoki <aoki@cs.berkeley.edu>
  4782.  
  4783. The postgres code from uc berkeley is being commercialized by
  4784. Miro Systems, Inc.        [This seems to have been updated to Montage]
  4785.  
  4786. Contact:
  4787.   paula hawthorn (paula@miro.com) 
  4788.   dave segleau (dave@miro.com)
  4789.  
  4790.  
  4791. Commercial Systems
  4792. ------------------
  4793.  
  4794. > Montage (ORDBMS) [Research System POSTGRES]
  4795.  
  4796. From: markh@montage.com (Mark Helfen)
  4797. Subject: Montage Database - brief product announcement
  4798. Followup-To: sales@montage.com 
  4799. Organization: Montage Software, Inc.
  4800. Date: Wed, 10 Nov 1993 23:05:03 GMT
  4801.  
  4802. The Montage object-relational database management system 
  4803. (ORDBMS) is now available from Montage Software, Inc. 
  4804.  
  4805. The Montage object-relational database management system 
  4806. includes the Montage Server(tm) database engine, the Montage 
  4807. Viewer(tm) -- a new visualization tool that simplifies queries of 
  4808. complex data -- and Montage DataBlades(tm), specialized modules 
  4809. that extend the capabilities of the database for specific applications.  
  4810. Montage represents the commercialization of the seven-year 
  4811. POSTGRES research project.   
  4812.  
  4813. The Montage Server extends the relational database model through 
  4814. its ability to handle complex information, and the inclusion of object-
  4815. oriented facilities and capabilities.  It uses the familiar relational row-
  4816. column metaphor for all data, so that text, numbers and complex data 
  4817. are all viewed, managed, manipulated and queried the same way.   
  4818. The relational metaphor is extended to allow data of any size and 
  4819. complexity to be stored and accessed in the way that is most 
  4820. effective.   SQL, used to access and manage data, is extended with 
  4821. SQL3-based capabilities to allow the definition of user data types and 
  4822. functions.
  4823.  
  4824. The Montage Viewer uses visualization technology to organize 
  4825. information in visual terms -- by location, shape, color and intensity, 
  4826. for example.  Similar to a "flight simulator," the Montage Viewer allows 
  4827. the user to visually navigate through data, refining each step by 
  4828. "panning" and "zooming" with a mouse.  
  4829.  
  4830. A DataBlade is a combination of data types and functions that are 
  4831. designed to support a specific application.   Text, Spatial, and Image 
  4832. are the first of many DataBlades that will comprise a full-range of 
  4833. industry-specific products created by Montage, third parties and 
  4834. users based upon their own expertise.    
  4835.  
  4836. o     The Text DataBlade expands the database's functionality by 
  4837. adding new data types and functions that manage text and document 
  4838. libraries, as well as a providing a new access method (Doc-Tree) 
  4839. which provides exceptional search performance for text.  
  4840.  
  4841. o     The Image DataBlade supports image conversion, storage, 
  4842. manipulation, enhancement and management of more than 50 image 
  4843. formats, and performs automatic conversion of formats at the user's 
  4844. discretion.  
  4845.  
  4846. o     Points, lines, polygons and their spatial relationships are now 
  4847. supported in the relational model with the Spatial DataBlade.  The 
  4848. DataBlade defines nine basic spatial types and makes over 200 SQL 
  4849. functions available for use on spatial data, as well as supports the 
  4850. R-Tree access method for high speed navigation of spatial data.    
  4851.  
  4852. Montage Software was co-founded by Gary Morgenthaler of 
  4853. Morgenthaler Ventures and Dr. Michael Stonebraker of the University 
  4854. of California, Berkeley, .  Morgenthaler is Montage Software's 
  4855. chairman of the board and Stonebraker serves as the company's 
  4856. chief technology officer.    Morgenthaler and Stonebraker co-
  4857. founded Ingres Corporation (then called Relational Technology, 
  4858. Inc.), in 1980.    
  4859.  
  4860. FOR ADDITIONAL INFORMATION:
  4861.  
  4862. Montage Software Inc. can be contacted at:
  4863.  
  4864. email:                        sales@montage.com
  4865. phone:                        (510) 652-8000
  4866. fax:                          (510) 652-9688
  4867.  
  4868. Mailing Address:
  4869.  
  4870. Montage Software, Inc.
  4871. 2000 Powell Street, Suite 1405
  4872. Emeryville, CA  94608
  4873.  
  4874. OO DATA MODEL
  4875. -------------
  4876.  
  4877. Research Systems
  4878. ________________
  4879.  
  4880. > AVANCE (SYSLAB)
  4881.  
  4882. An object-oriented, distributed database programming language.  Its
  4883. most interesting feature is the presence of system-level version
  4884. control, which is used to support schema evolution, system-level
  4885. versioning (as a way of improving concurrency), and objects with their
  4886. own notion of history.  System consists of programming language (PAL)
  4887. and distributed persistent object manager. 
  4888.  
  4889. REFERENCES: 
  4890.         Anders Bjornerstedt and Stefan Britts. "AVANCE: An
  4891.         Object Management System".  Proceedings of OOPSLA88.
  4892.  
  4893.  
  4894.  
  4895. > CLOSQL (University of Lancaster)
  4896.  
  4897. Status:-
  4898. CLOSQL is a research prototype OODB designed primarily for prototyping 
  4899. various schema evolution and view mechanisms based on class versioning.
  4900. The system is built using CommonLISP. It would really only be of interest
  4901. to other parties as a research tool.
  4902.  
  4903. Requirements:-
  4904. Common LISP including CLOS standard. The Graphical user interface requires
  4905. the Harlequin LispWorks Tool-kit. The system was built on a Sun4 and
  4906. has not been tested on any other platform.
  4907.  
  4908. Features:-
  4909. As a prototype, CLOSQL is not robust enough to sell. The system is single
  4910. user and does not properly support persistence - that is, the data has to
  4911. be loaded and saved explicitly. The query language is quite good 
  4912. making good use of the functional nature of the environment. 
  4913. Methods (LISP and query language only), class versioning and
  4914. multiple inheritance are all supported in the data model. Type checking
  4915. information is held in the database, but is NOT enforced at present. The
  4916. GUI is notable for its support for schema evolution, but otherwise rather
  4917. ordinary.
  4918.  
  4919. Availability:-
  4920. Probably freely available, but as the project was part funded by an
  4921. industrial partner, some consultation with them would be necessary before
  4922. the system could be released.
  4923.  
  4924. References:-
  4925. [1]  Monk, S. R. and I. Sommerville, "A Model for Versioning of Classes 
  4926. in Object-Oriented Databases", Proceedings of BNCOD 10, Aberdeen. 
  4927. pp.42-58. 1992.
  4928.  
  4929. [2]  Monk, S. "The CLOSQL Query Language". Technical report No. SE-91-15. 
  4930. Computing Dept, Lancaster University, Lancaster, LA1 4YR, UK. 1991.
  4931.  
  4932. [3]  Monk, S., "A Model For Schema Evolution In Object-Oriented Database 
  4933. Systems", PhD thesis, Dept of Computing, Lancaster University, Lancaster
  4934. LA1 4YR, UK. 1992.
  4935.  
  4936. On Schema evolution (from original survey):
  4937. CLOSQL implements a class versioning scheme (like ENCORE), but employs a
  4938. conversion adaptation strategy.  Instances are converted when there is a
  4939. version conflict, but unlike ORION and GemStone, CLOSQL can convert instances
  4940. to older versions of the class if necessary.
  4941.  
  4942.         Aberdeen, Scotland. July, 1992.
  4943.  
  4944. Contacts;
  4945. Simon Monk:      srm@computing.lancaster.ac.uk
  4946. Ian Sommerville: is@computing.lancaster.ac.uk 
  4947.  
  4948.  
  4949. > ConceptBase - A Deductive Object Manager for Meta Data Bases
  4950.  
  4951. ConceptBase is a multi-user deductive object manager mainly 
  4952. intended for conceptual modeling and the coordination of design 
  4953. environments. The system implements a dialect of Telos which 
  4954. amalgamates properties of deductive and object-oriented languages. 
  4955.  
  4956. Key features are 
  4957.  
  4958.    hybrid representation with frame-like objects, 
  4959.    semantic nets and logical specifications 
  4960.  
  4961.    unlimited extensibility by metaclass 
  4962.    hierarchies (useful for IRDS, schema evolution etc.) 
  4963.  
  4964.    deductive rules & integrity constraints 
  4965.  
  4966.    queries as classes with membership constraints 
  4967.  
  4968.    persistent object management with the ability to interrogate 
  4969.    past states of the database 
  4970.  
  4971. ConceptBase follows a client-server architecture. Client programs 
  4972. can connect to the ConceptBase server and exchange data via 
  4973. interprocess communication. The X11-based ConceptBase user 
  4974. interface offers a palette of graphical, tabular and textual tools 
  4975. for editing and browsing the object base. The ConceptBase 
  4976. programming interface allows the users to create their own 
  4977. client programs in C or Prolog. 
  4978.  
  4979. The system can be obtained for free from ftp.informatik.rwth-aachen.de in 
  4980.       /pub/CB/CB_3.2.4 (released 26-Apr-1994 for Sun/SPARC, SunOS 4.1.3) 
  4981.       /pub/CB/CB_3.3 (released 26-Apr-1994 for Sun/SPARC, Solaris 2.3) 
  4982. Both versions are functionally equivalent. They only differ in the 
  4983. operating system platform.Please read file /pub/CB/doc/InstallationGuide 
  4984. (resp. /pub/CB/doc/InstallationGuide_3.2.4) before downloading the software. 
  4985. For running the ftp version you must ask for a key by email.
  4986.  
  4987. Contact
  4988. ConceptBase-Team
  4989. RWTH Aachen - Informatik V
  4990. D-52056 Aachen - Germany
  4991.  
  4992. Tel./Fax: +49-241 80 21 501 / +49-241-8888321
  4993. email: CB@picasso.informatik.rwth-aachen.de 
  4994. href="http://www.informatik.rwth-aachen.de/I5/CBdoc/cbflyer.html"
  4995.  
  4996.  
  4997. > COOL/COCOON (Ulm Universitaet)
  4998.  
  4999. The COCOON project was intended to extend the concepts and the
  5000. architecture of relational database management systems (DBMSs) beyond
  5001. nested relational to object-oriented ones. Based upon the nested
  5002. relational DBMS kernel DASDBS, we have built a prototype implementation
  5003. of the COCOON model. Key characteristics of COCOON are: generic,
  5004. set-oriented query and update operators similar to relational algebra
  5005. and SQL updates, respectively; object-preserving semantics of query
  5006. operators, which allows for the definition of updatable views; a
  5007. separation of the two aspects of programming language "classes": type
  5008. vs. collection; predicative description of collections, similar to
  5009. "defined concepts" in KL-One--like knowledge representation
  5010. languages; automatic classification of objects and views (positioning
  5011. in the class hierarchy); physical clustering of subobjects via the use
  5012. of nested relations as the internal storage structures; support for the
  5013. optimization of both, the physical DB design and query transformation,
  5014. by corresponding optimizers.
  5015.  
  5016. Project goals are:
  5017.  
  5018. - to develop a general formal framework for investigations of all
  5019.   kinds of schema changes in object-oriented database systems
  5020.   (including schema design, schema modification, schema tailoring, and
  5021.   schema integration);
  5022. - to find implementation techniques for evolving database schemas,
  5023.   such that changes on the logical level propagate automatically to
  5024.   adaptations of the physical level (without the need to modify all
  5025.   instances, if possible).
  5026.  
  5027. In their current paper [see below], schema evolution is used as
  5028. example of a general framework for change in OODBs, supporting change
  5029. on three levels of database objects: data objects, schema objects, and
  5030. meta-schema objects.
  5031.  
  5032. Contact: Markus Tresch <tresch@informatik.uni-ulm.de>
  5033.  
  5034.  
  5035. REFERENCES:
  5036.         M. Tresch and M.H. Scholl. "Meta Object Management
  5037.         and its Application to Database Evolution."  In
  5038.         _Proceedings of the Eleventh International
  5039.         Conference on the Entity-Relationship Approach",
  5040.         Karlsruhe, Germany, Oct 1992.  Springer Verlag (to
  5041.         appear).
  5042.  
  5043.  
  5044.  
  5045. > Encore (Brown University)
  5046. email:bpe@browncs.brown.edu
  5047.  
  5048. Encore is an object-oriented database system targeted at large scale
  5049. software engineering applications which are involved in data modeling.
  5050. It was developed at Brown University in the late 1980s.  It is notable
  5051. for its special support for long-lived (ie. cooperative) transactions,
  5052. popular in design applications, and its support for class versioning.
  5053. Objects are never converted, rather, classes are versioned, and the
  5054. user can specify filters to make old-style instances appear as new
  5055. instances to new applications (and vice versa).
  5056.  
  5057.  
  5058. References/Additional Information:
  5059.  
  5060.  [] Mary F. Fernandez. OBSERVER: A storage system
  5061.     object-oriented applications. Technical Report CS-90-27,
  5062.     Brown University, Providence, RI, 1990.
  5063.  
  5064.  [] Mark F. Hornick and Stanley B. Zdonik. A shared, segmented
  5065.     memory system for an object-oriented database. ACM
  5066.     Transactions on Office Information Systems, 5(1):70--95,
  5067.     January 1987.
  5068.  
  5069.  [] Andrea H. Skarra and Stanley B. Zdonik. Type evolution in an
  5070.     object-oriented database. In Research Directions in
  5071.     Object-Oriented Programming, MIT Press Series in Computer
  5072.     Systems, pages 393--415. MIT Press, Cambridge, MA, 1987. An
  5073.     early version of this paper appears in the OOPSLA '86
  5074.     proceedings.
  5075.  
  5076.  [] Andrea H. Skarra and Stanley B. Zdonik. Concurrency control
  5077.     for cooperating transactions in an object-oriented database.
  5078.     In Won. Kim and Frederick H. Lochovsky, editors,
  5079.     Object-Oriented Concepts, Databases and Applications.
  5080.     Addison-Wesley, Reading, MA, 1989.
  5081.  
  5082. FTP: Complete source can be found in wilma.cs.brown.edu/pub/encore.tar.Z
  5083. See also APPENDIX E.
  5084.  
  5085.  
  5086. > Exodus (University of Wisconsin)
  5087.  
  5088. EXODUS is a DBMS from the University of Wisconsin.  An overview,
  5089. excerpted from the abstract of [CDG+90] reads:
  5090.  
  5091.     EXODUS,   an   extensible database    system  project that is
  5092.     addressing  data management problems  posed  by  a variety of
  5093.     challenging new applications.  The  goal of the project is to
  5094.     facilitate   the   fast    development of   high-performance,
  5095.     application-specific  database  systems.     EXODUS  provides
  5096.     certain  kernel facilities,   including  a versatile  storage
  5097.     manager.  In addition, it provides an architectural framework
  5098.     for building  application-specific database systems; powerful
  5099.     tools   to  help  automate the  generation   of such systems,
  5100.     including  a   rule-based query optimizer generator    and  a
  5101.     persistent  programming  language;  and libraries  of generic
  5102.     software components (e.g., access methods) that are likely to
  5103.     be useful for many application domains.
  5104.  
  5105. The programming language is called E, an extension of C++. [RC89]
  5106.  
  5107. REFERENCES:
  5108. (see "ftp.cs.wisc.edu:exodus/bibliography" for a complete list)
  5109.  
  5110. [CDG+90] Michael J. Carey, David J. DeWitt, Goetz Graefe,
  5111.          David M. Haight, Joel E. Richardson, Daniel T. Schuh,
  5112.          Eugene J. Skekita, and Scott L. Vandenberg. The EXODUS
  5113.          extensible DBMS project:  An overview. In Stanley B.
  5114.          Zdonik and David Maier, editors, Readings in
  5115.          Object-Oriented Database Systems, Data Management
  5116.          Series. Morgan Kaufmann, San Mateo, CA, 1990. Also
  5117.          available as WISC-CS-TR 808.
  5118.  
  5119. [CDRS89] Michael J. Carey, David J. DeWitt, Joel E. Richardson,
  5120.          and Eugene J. Skekita. Storage management for objects
  5121.          in EXODUS. In Won. Kim and Frederick H. Lochovsky,
  5122.          editors, Object-Oriented Concepts, Databases and
  5123.          Applications, chapter 14. Addison-Wesley, Reading, MA,
  5124.          1989. After Carey et al. Object and File Management in
  5125.          the EXODUS Database System, Proceedings of the Twelveth
  5126.          International Conference on Very Large Data Bases,
  5127.          1986.
  5128.  
  5129. [GD87]   G. Graefe and D. DeWitt. The EXODUS optimizer
  5130.          generator. In U. Dayal and I. Traiger, editors,
  5131.          Proceedings of the SIGMOD International Conference on
  5132.          Management of Data, San Francisco, CA, May 1987.
  5133.  
  5134. [RC89]   Joel E. Richardson and Michael J. Carey. Persistence in
  5135.          the E language:  Issues and implementation. Software --
  5136.          Practice and Experience, 19(12):1115--1150, December
  5137.          1989.
  5138.  
  5139.  
  5140. FTP: source code, documentation and a complete bibliography can be
  5141.      found at ftp.cs.wisc.edu:exodus/
  5142.  
  5143. See also APPENDIX E.
  5144.  
  5145.  
  5146. On Schema Evolution (from original survey):
  5147. No solution for the problem of schema evolution is provided.
  5148. Emulation is rejected by the authors, who claim that the addition of a
  5149. layer between the EXODUS Storage Manager and the E program would
  5150. seriously reduce efficiency.  Automatic conversion, whether lazy or
  5151. eager, is also rejected, as it does not mesh well with the C++ data
  5152. layout.  To implement immediate references to other classes and
  5153. structures, C++ embeds class and structure instances within its
  5154. referent.  The resulting change in the size of the object might
  5155. invalidate remote pointer references.
  5156.  
  5157.         Joel E.  Richardson and Michael J.  Carey.  "Persistence
  5158.         in the E language: Issues and Implementation."  Appeared
  5159.         in "Software -- Practice and Experience",
  5160.         19(12):1115-1150, December 1989.
  5161.  
  5162.  
  5163. > Machiavelli (University of Pennsylvania)
  5164.  
  5165. Machiavelli is a statically-typed programming language developed
  5166. at the University of Pennsylvania. Its most outstanding innovation 
  5167. is the use of conditional typing scheme in its type inference system. 
  5168. It does not address type evolution.
  5169.  
  5170. [communication with limsoon@saul.cis.upenn.edu]
  5171.  
  5172. [Note: Machiavelli is included in this summary because it
  5173.        previously incorporated persistence in its data model.]
  5174.  
  5175.  
  5176.  
  5177. > MOOD4-PC: Material's/Miniature Object-Oriented Database Prototype for
  5178.              NEC/IBM-PC
  5179.  
  5180. is an object-oriented database system(OODBS) program developed in the
  5181. course of our research project MOOD. The aim of the project MOOD is to
  5182. develop a material database system to handle raw material data which
  5183. are produced and accumulated in materials research and referred to by
  5184. material experts when they face scientific or engineering problems
  5185. where the expected behavior of particular materials in particular
  5186. environments are crucial importance. We all know that the conventional
  5187. database systems do not fulfill this requirement, though they serves
  5188. well for bibliographic databases or fact databases which deals with
  5189. the standard properties of standard materials.
  5190.  
  5191. MOOD4-PC is written in Arity/Prolog and available in source and
  5192. executable form via anonymous ftp from:
  5193.  
  5194.    ~/pub/mood/mood4
  5195.    at mood.mech.tohoku.ac.jp [130.34.88.61]
  5196.    
  5197.     ~/pub/database/mood
  5198.     at ftp.uu.net [192.48.96.9]
  5199.  
  5200.     ~/pub/computing/databases/mood
  5201.     at src.doc.ic.ac.uk [146.169.2.1]
  5202.  
  5203. Although it is true enough to say that MOOD4 is a general purpose
  5204. OODBS, it may be appropriate to point out that MOOD4 is significantly
  5205. different from what is generally meant by the term, the
  5206. Object-Oriented Database System.
  5207.  
  5208. That is, OODBSs, in general, consist of two parts:
  5209.  
  5210.    (1) Disk storage manager
  5211.    (2) Database language to define and manipulate data objects to
  5212.        be stored to and retrieved from the disk.
  5213.  
  5214. The database language of OODBS is akin to the object-oriented
  5215. programming language such as Smalltalk or C++. You can enjoy the full
  5216. versatility of these general purpose programming language in writing
  5217. application programs with the database language.
  5218.  
  5219. As apparent from these, OODBSs, in general, are for programmers who
  5220. write application programs which serve end users' needs. MOOD, on the
  5221. other hands, is not; it is for end users. It is provided with a user
  5222. interface named the object editor or OE in short. With OE, we can;
  5223.  
  5224.   (1) Edit class definition objects and save them. This replaces the
  5225.       data definition language.
  5226.  
  5227.   (2) Edit data objects and save them.
  5228.  
  5229.   (3) Create query objects, let the system select data objects which
  5230.       match the queries, and browse them.
  5231.  
  5232. In the other words, we can do everything necessary to manage and use
  5233. database with OE. MOOD, therefore, needs no programming language and,
  5234. in fact, has none. In this regard, MOOD may better be categorized to
  5235. the OODBS application.
  5236.  
  5237. The architecture of MOOD as such is the consequence of the nature of
  5238. information to be dealt with in material database. If we describe the
  5239. nature with a single word, "variety" will be the one most appropriate. 
  5240. No fixed data structure can handle a handful of material data because
  5241. their contents differ from one to another. The feature of OODBS
  5242. relevant here is not the intimacy with programming languages but the
  5243. flexibility of data structure which allows us to construct data
  5244. objects with a variety of structures which match the variety in the
  5245. information to be dealt with. Upon inputting and retrieving data
  5246. objects, end users are forced to face this variety in data structure
  5247. since significant information is born in the structures of individual
  5248. representations.
  5249.  
  5250. Yet, we say that MOOD is a general purpose OODBS. This is not in the
  5251. sense that we can develop application programs on it, but in the
  5252. sense that it generally supports the essential capabilities of OODBS;
  5253.  
  5254.   (1) The abstract data type.
  5255.  
  5256.   (2) The nesting of structured data objects.
  5257.  
  5258.   (3) The class hierarchy.
  5259.  
  5260.   (4) The inheritance of attributes along the hierarchy.
  5261.  
  5262.   (5) Matching between objects along their structures with the
  5263.       knowledge of the class hierarchy.
  5264.  
  5265. For additional features of MOOD4, please consult its manual available
  5266. with the program. Although they are biased to the processing of
  5267. material data (or, more generally, scientific and technical data),
  5268. MOOD with these capabilities can be used in any application domain at
  5269. least by the stage where you are to examine how well the pieces of
  5270. information of interest are represented in OODBS and how well specific
  5271. items of interest are discriminated out from the database as such.
  5272.  
  5273. Questions and suggestions on this software which are ever welcome
  5274. indeed may be addressed to;
  5275.  
  5276.      Noboru Ono                                             
  5277.      Dept. of Machine Intelligence and Systems Engineering, 
  5278.      Faculty of Engineering, Tohoku University.            
  5279.      Tel:++22-216-8111,
  5280.      Fax:++22-216-8156,
  5281.      E-mail:ono@mood.mech.tohoku.ac.jp
  5282.  
  5283.  
  5284.  
  5285. > OBST/STONE (Forschungszentrum Informatik [FZI], Karlsruhe, Germany)
  5286.  
  5287. OBST3-4 is now available at ftp.fzi.de under /pub/OBST/OBST3-4.
  5288. (Please do not confuse this new release with the older OBST3-3.4).
  5289.  
  5290. Experienced users will notice that we've changed the structure of
  5291. our ftp directory tree somewhat: compressed and gzip'ed files are
  5292. now cleanly separated. By sending
  5293.     echo 'info ftp_listing' | mail obst-listserv@fzi.de
  5294. you will get a directory listing from our ftp server.
  5295.  
  5296. OBST3-4 is a major release with a new meta schema interface
  5297. that enables schema modifications. A graphical schema browser
  5298. (USE) based on tclOBST is now also available. Please note that this
  5299. new tool has not yet been tested outside the FZI and that it
  5300. is currently not part of the OBST core cdistribution.
  5301.  
  5302. Beside bug fixes and performance improvements, we have added support
  5303. for IBM AIX and FreeBSD and improved the installation on LINUX PCs.
  5304.  
  5305. We would like to thank all OBST users who have helped us by testing a 
  5306. beta version of OBST, most notably:
  5307.   Naresh Sharma (N.Sharma@LR.TUDelft.NL)
  5308.   Michael Reifenberger (root@rz-wb.fh-sw.de)
  5309.   Hans-Ulrich Kobialka (kobi@borneo.gmd.de) 
  5310.   Jean Safar (jsafar@lehman.com)
  5311.   Gabor Karsai (gabor@vuse.vanderbilt.edu)
  5312.   Stefan Bohm (bohm@math.uni-muenster.de)
  5313.  
  5314. The installation of OBST requires a C++ compiler
  5315. (GNU g++ 2.3.3/2.4.5/2.5.8, or AT&T 2.1/3.01).
  5316.  
  5317. The OBST graphical tools run under the X-Windows
  5318. system (currently X11R4, X11R5 and X11R6). 
  5319. Installation has been tested for SunOS4.1.3 and LINUX only.
  5320.  
  5321. Best regards and happy OBST programming. 
  5322.  
  5323.    The OBST Team
  5324.  
  5325. ------------------------------------------------------------------------------
  5326. README of OBST3-4
  5327. -----------------
  5328.  
  5329. Version: OBST3-4
  5330. Date:    11/4/94
  5331.  
  5332. The OBject system of STONE --- OBST
  5333. -----------------------------------
  5334.  
  5335. The persistent object management system OBST was developed by
  5336. Forschungszentrum Informatik (FZI) as a contribution to the STONE
  5337. project (supported by grant no. ITS8902A7 from the BMFT, i.e. the
  5338. German Ministry for Research).
  5339.  
  5340. OBST was originally designed to serve as the common persistent
  5341. object store for the tools in software engineering environments.
  5342.  
  5343.  
  5344. Data Model
  5345. ---------
  5346.  
  5347. The OBST data model can be characterized by the following properties:
  5348.  
  5349.  * Schema definition language syntactically similar to C++
  5350.  * Support of multiple inheritance
  5351.  * Generic classes
  5352.  * Abstract classes and methods
  5353.  * Distinction between public, protected, and private methods
  5354.  * Redefinition of methods
  5355.  * Overloading of methods
  5356.  
  5357. Schemas and Containers
  5358. ----------------------
  5359.  
  5360. Schemas are compiled by the OBST schema compiler. The compilation
  5361. results are instances of classes of the meta schema. From these
  5362. instances in a next step interfaces to different programming languages
  5363. can be generated. At present the C++ language binding is implemented.
  5364.  
  5365. Objects are stored in so-called containers. The container an object
  5366. belongs to is determined at the time of object creation and fixed
  5367. throughout the object's lifetime. Containers are the units of 
  5368. clustering, synchronization, and recovery. Objects can be referenced
  5369. by other objects across container boundaries.
  5370.  
  5371. Incremental Loading
  5372. -------------------
  5373.  
  5374. OBST provides a mechanism to incrementally load methods. This enables
  5375. programs to deal with objects whose type is defined after the program 
  5376. itself has been developed. This is useful in systems that provide for 
  5377. inheritance and it supports schema evolution. We used it e.g. for
  5378. programs that interpret the object base and call methods of the
  5379. found objects (for example the below mentioned browser).
  5380.  
  5381. Prototype
  5382. ---------
  5383.  
  5384. Since end 1990 the first prototype of OBST is available and is shipped
  5385. to interested universities and research institutions. The current
  5386. version is publicly available via FTP (see below) since March '92.
  5387. There is a mailing list (see below) with >>100 subscribers.
  5388.  
  5389. The system comes with the schema compiler, a library of predefined
  5390. classes (like Set<Entity>, List<Entity>, String, ...), a graphical
  5391. object browser (more a shell than a browser), a graphical schema
  5392. designer (USE), the structurer and flattener (STF), tclOBST,
  5393. and all manuals.
  5394. For USE, STF and tclOBST see below.
  5395.  
  5396. Schema Evolution Support Environment (USE)
  5397. ------------------------------------------
  5398.  
  5399. This environment consists of a graphical schema designer built with
  5400. tclOBST (see below). It can be used to inspect existing class hierarchies
  5401. and to modify these hierarchies; it allows the addition of new classes
  5402. as well as the modification of existing ones.
  5403.  
  5404. Structurer and Flattener (STF)
  5405. ------------------------------
  5406.  
  5407. This is a tool to build objects from bytestrings and flatten objects
  5408. down to bytestrings. It is intended to be used when coupling UNIX
  5409. tools to the object management system. The user defines a grammar that
  5410. describes her objects. Afterwards, the structurer parses an ascii 
  5411. text according to the given grammar and creates an OBST object
  5412. structure that represents the corresponding parse tree.
  5413. The flattener does the inverse transformation, that means it generates
  5414. an ascii text from a given OBST object structure according to the given
  5415. grammar.
  5416.  
  5417. tclOBST
  5418. -------
  5419.  
  5420. tclOBST is a library which provides an embedding of OBST into the
  5421. interactive tool command language tcl, developed by John Ousterhout
  5422. at the University of Berkeley.
  5423. Based on the standard tcl shells, which are also comprised in the
  5424. tclOBST distribution, tclOBST offers interactive access to the complete
  5425. functionality modelled by OBST schemata.
  5426.  
  5427.  
  5428. System Requirements
  5429. -------------------
  5430.  
  5431. For the prototype's installation a C++ compiler
  5432. (GNU g++ 2.3.3/2.4.5/2.5.7 or AT&T 2.0/2.1/3.01) and the
  5433. X-Windows system (currently X11R4 or X11R5) for the graphical tools
  5434. are required.
  5435. Installation is well-tried on SUN Sparc stations and should be no
  5436. problem on other UNIX machines, too. You can find a more detailed
  5437. description of the supported platforms in the README.install.OBST*.
  5438.  
  5439. --------------------------------------------------------------------
  5440.  
  5441. For more information please mail to:
  5442.  
  5443.                 Forschungszentrum Informatik (FZI)
  5444.                        OBST Projekt
  5445.                  Haid-und-Neu-Strasse 10-14
  5446.                      D-76131 Karlsruhe
  5447.                           Germany
  5448.  
  5449. or email to:  obst@fzi.de
  5450.  
  5451. Phone:        ++49-721-9654-701
  5452. Fax:          ++49-721-9654-709
  5453. Teletex:      721 190 fziKA
  5454.  
  5455. The OBST system is available via anonymous FTP from
  5456. ftp.fzi.de [141.21.4.3] and some mirror servers.
  5457.  
  5458. The system as well as some overview papers, documentation
  5459. (User's Guide, Language Reference Manual, Tutorial, ...),
  5460. and lots of manual pages can be found in the directory /pub/OBST.
  5461.  
  5462. There are mailing lists for announcing OBST enhancements,
  5463. new versions, porting hints, etc. as well as for exchanging experiences
  5464. with other OBST users.
  5465.  
  5466. Send a mail with content 'LONGINDEX' to obst-listserv@fzi.de to learn about
  5467. the mailing lists which are currently installed:
  5468.     echo LONGINDEX | mail obst-listserv@fzi.de
  5469.  
  5470. The mailing lists are maintained by an automatic list processor.
  5471. Use 'HELP' to learn about the commands understood by this processor:
  5472.     echo HELP | mail obst-listserv@fzi.de
  5473.  
  5474. Bug reports should contain a small example program with which the
  5475. bug can be reproduced, or at least a detailed description of the
  5476. observed phenomenon. They should also mention:
  5477.      o OBST version 
  5478.      o configuration parameters for your OBST version
  5479.        (from file config.status)
  5480.      o kind and version of C++ compiler 
  5481.      o machine
  5482.      o operating system
  5483.  
  5484. Besides bug reports we are strongly interested in all experiences
  5485. our users make with OBST (e.g. sufficiency of data model, performance,
  5486. ...) and in our users' application areas and the applications as
  5487. well. So, please don't hesitate to send us a short note.
  5488.  
  5489. Best regards and happy OBST programming.
  5490.  
  5491.    The OBST Team,
  5492.  
  5493.     Boris Boesler, Dirk Eichberg, Frank Fock, Axel Freyberg,
  5494.     Michael Gravenhorst, Ingolf Mertens, Michael Pergande, Christian Popp,
  5495.     Bernhard Schiefer, Dietmar Theobald, Axel Uhl, Walter Zimmer
  5496.  
  5497. ---
  5498.  
  5499. BTW "Obst" is the German word for "fruit",
  5500.     so have a fruitful time with OBST!
  5501.  
  5502.  
  5503. > Ode
  5504.  
  5505.                                  Ode 2.0
  5506.                        An Object-Oriented Database
  5507.  
  5508.        C++ Compatible, Fast Queries, Complex Application Modeling,
  5509.        Multimedia Support, and more
  5510.  
  5511. See APPENDIX E, Databases, for description.
  5512. Note: Ode version 3.0 is now available.
  5513.  
  5514.  
  5515. > Oggetto, University of Lancaster, UK.
  5516.  
  5517. Developed at the University of Lancaster, UK.  Summary NYI.
  5518.  
  5519. "Oggetto: An Object Oriented Database Layered on a Triple Store",
  5520. J.A. Mariani, The Computer Journal, V35, No 2, pp108-118, April 1992.
  5521.  
  5522.  
  5523. > ORION (Now marketed as ITASCA)
  5524.  
  5525. ORION was a prototype OODBMS developed at MCC, an American consortium by Won
  5526. Kim and his group.  Won Kim has left MCC and formed a new company, UniSQL, in
  5527. Austin, with a new product of the same name.
  5528.  
  5529. See also entry under "ITASCA".
  5530.  
  5531. REFERENCES:
  5532.  
  5533. I have found nearly a dozen papers published by the ORION folks.
  5534. Overviews at various stages in its development and commercialization
  5535. can be found in:
  5536.  
  5537. [KBGW91] Won Kim, N. Ballou, J.F. Garza, and D.; Woelk. A
  5538.          distributed object-oriented database system supporting
  5539.          shared and private databases. ACM Transactions on
  5540.          Information Systems, 9(1):31--51, January 1991.
  5541.  
  5542. [KGBW90] W. Kim, J.F. Garza, N. Ballou, and D. Woelk.
  5543.          Architecture of the orion next-generation database
  5544.          system. IEEE Transactions on Knowledge and Data
  5545.          Engineering, 2(1):109--24, March 1990.
  5546.  
  5547. [KBCG89] Won Kim, Nat Ballou, Hong-Tai Chou, and Darrell Garza,
  5548.          Jorge F. Woelk. Features of the ORION object-oriented
  5549.          database system. In Won. Kim and Frederick H.
  5550.          Lochovsky, editors, Object-Oriented Concepts, Databases
  5551.          and Applications, chapter 11. Addison-Wesley, Reading,
  5552.          MA, 1989.
  5553.  
  5554. [KBC+88] Won Kim, N. Ballou, Hong-Tai Chou, J.F. Garza,
  5555.          D. Woelk, and J. Banerjee. Integrating an
  5556.          object-oriented programming system with a database
  5557.          system. In Proceedings of the ACM Conference on
  5558.          Objected-Oriented Programming:  Systems, Languages and
  5559.          Applications (OOPSLA), pages 142--152, San Diego, CA,
  5560.          September 1988. Published as ACM SIGPLAN Notices
  5561.          23(11).
  5562.          [Pointers to the previous papers documenting each of the
  5563.           advanced features listed above are cited therein.]
  5564.  
  5565.  
  5566. The paper most relevant to the issue of schema evolution is the
  5567. following:
  5568.  
  5569. [BKKK87] J. Banerjee, W. Kim, H-J. Kim, and H.F. Korth.
  5570.          Semantics and implementation of schema evolution in
  5571.          object-oriented databases. In U. Dayal and I. Traiger,
  5572.          editors, Proceedings of the SIGMOD International
  5573.          Conference on Management of Data, San Francisco, CA,
  5574.          May 1987.
  5575.  
  5576.  
  5577. You might also like to look at Kim's book, which provides a good
  5578. introduction to OODBMS, while focusing on the ORION work:
  5579.  
  5580. [Kim90]  Won Kim. Introduction to Object-Oriented Databases.
  5581.          Computer Systems. MIT Press, Cambridge, MA, 1990.
  5582.  
  5583.  
  5584. > OTGen (Carnegie Mellon University/UMass Amherst)
  5585.  
  5586. OTGen is a design for a system to support schema evolution in
  5587. object-oriented databases.  The chief contribution of OTGen is support
  5588. for programmer extensibility of transformation functions to allow a
  5589. system to support a wide range of schema changes, not just those that
  5590. can be easily automated.  While OTGen was never implemented, it is
  5591. based on the implementation of TransformGen, a system to support the
  5592. evolution of the specialized databases used by Gandalf programming
  5593. environments.  For more information on OTGen and TransformGen, please
  5594. see: 
  5595.  
  5596. Barbara Staudt Lerner and A. Nico Habermann, "Beyond Schema Evolution
  5597.     to Database Reorganization", in Proceedings of the Joint ACM 
  5598.     OOPSLA/ECOOP '90 Conference on Object-Oriented Programming:
  5599.     Systems, Languages, and Applications, Ottawa, Canada, October
  5600.     1990, 67-76. 
  5601.  
  5602. Barbara Staudt, Charles Krueger, and David Garlan, TransformGen:
  5603.     Automating the Maintenance of Structure-Oriented Environments, 
  5604.     Computer Science Department Carnegie-Mellon University, Technical 
  5605.     Report CMU-CS-88-186, November 1988.
  5606.  
  5607. David Garlan, Charles W. Krueger, and Barbara J. Staudt, "A Structural
  5608.     Approach to the Maintenance of Structure-Oriented Environments",
  5609.     in Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering
  5610.     Symposium on Practical Software Development Environments, Palo
  5611.     Alto, California, December 1986, 160-170.
  5612.  
  5613. Contact:
  5614. Barbara Lerner
  5615. blerner@cs.umass.edu
  5616.  
  5617.  
  5618. > VODAK
  5619.  
  5620. Research in the framework of VODAK focuses on an extensible data
  5621. model and database programming language, an advanced transaction
  5622. model, object-oriented query language, and support for multimedia data.
  5623.  
  5624. The VODAK Data Model Language VML
  5625.  
  5626. Usually database models lack mechanisms for extending them with
  5627. additional modeling primitives. This limitation does not allow the
  5628. adaptation of the models for specific application needs, e.g. database
  5629. integration, multimedia document handling, hypertext modeling, etc.
  5630.  
  5631. The VODAK Model Language VML  homogeneously integrates the concept of
  5632. metaclasses and the separation of types and classes with other
  5633. object-oriented concepts such as properties, methods, inheritance, and
  5634. object identity. Complex nested data structures can be defined using
  5635. the set, array, tuple, and dictionary type constructors. VML supports
  5636. its own programming language for implementing methods, specifying
  5637. transactions and an ad hoc query language.
  5638.  
  5639. In VML classes are used to organize a set of objects corresponding to
  5640. real world entities and relationships between them. Object types define
  5641. the structure of objects and the operations defined on these
  5642. structures.  They are associated with classes in order to determine the
  5643. structure and behavior of the class' instances. Metaclasses are first
  5644. class objects whose instances are classes. Metaclasses are associated
  5645. with three object types: an (optional) own-type extending their own
  5646. behavior, an instance-type specifying the behavior of their instances
  5647. (which are classes), and an  instance-instance-type specifying the
  5648. behavior of the instances of their instances.  Metaclasses can be
  5649. organized in an instantiation hierarchy of arbitrary depth.
  5650.  
  5651. This approach leads to an open, adaptable data model which provides for
  5652. the specification of additional modeling primitives at a meta layer of
  5653. the database schema. The concept of metaclasses and the separation of
  5654. classes and types allow to determine the structure and behavior of
  5655. objects and the individual inheritance behavior via semantic
  5656. relationships between arbitrary objects already at the meta layer
  5657. independently from the specifications given at the application layer
  5658. for the application specific classes.
  5659.  
  5660.  
  5661. The VODAK Transaction Model
  5662.  
  5663. In VODAK, we focus on two specific problems of transaction management.
  5664.  
  5665. 1. Operations to read and edit (hyper)documents are typically complex,
  5666. interactive and of long duration. A high degree of concurrency is
  5667. required to reduce the number and length of times a transaction is
  5668. blocked.
  5669.  
  5670. 2. A publication environment has to handle existing database systems
  5671. for using and modifying remote information and documents.  Transaction
  5672. managers of existing systems, i.e. concurrency control and recovery,
  5673. have to be integrated in a transparent way utilizing the functionality
  5674. of existing managers.
  5675.  
  5676. Our transaction model is based on open nested transactions. Compared to
  5677. conventional flat transactions, nested transactions allow more
  5678. concurrency and are more flexible for recovery.  A nested transaction
  5679. is a tree-like structure, dynamically built up by the call of
  5680. subtransactions until a bottom implementation level is encountered.
  5681.  
  5682. We extended the open nested model from a fixed calling hierarchy of
  5683. operations in a layered system (multi-level transactions) to an
  5684. arbitrary calling hierarchy of operations in an object-oriented system.
  5685. Commutativity of operations is applied to system defined VODAK methods,
  5686. and to methods of user defined object types.  For the second type of
  5687. operations, we developed a framework to specify commutativity and
  5688. inverse operations in VML.
  5689.  
  5690. Query Processing
  5691.  
  5692. Although nearly all object-oriented data models proposed so far include
  5693. behavioral aspects, most object-oriented query languages, algebras and
  5694. query optimization strategies simply adapt relational concepts since
  5695. they focus on the complex structures of objects and neglect the
  5696. behavior. We claim that this approach is not sufficient since it does
  5697. not reflect the much richer semantics methods can carry which have to
  5698. be taken into account for really efficient query processing. The quite
  5699. straightforward approach we consider is to integrate methods in an
  5700. algebraic framework for query processing and to make there partial
  5701. knowledge about methods available in the form of equivalences. We
  5702. integrate algebraic set operators with methods defined in database
  5703. schemas within an object-oriented data model. We investigate the impact
  5704. on the architecture of the query processor when the algebra becomes an
  5705. extendible component in query processing.
  5706.  
  5707. Multimedia Support
  5708.  
  5709. The V3 Video Server was built as a demonstration showing a multimedia
  5710. application developed on top of the VODAK database management system.
  5711. The V3 Video Server allows a user to interactively store, retrieve,
  5712. manipulate, and present analog and short digital video clips. A video
  5713. clip consists of a sequence of pictures and corresponding sound.
  5714. Several attributes like author, title, and a set of keywords are
  5715. annotated.
  5716.  
  5717. In the future, the VODAK DBMS will be enhanced with new built-in
  5718. functionality for multimedia datatypes. Therefore, existing components
  5719. of VODAK must be changed and new ones must be added to support time
  5720. dependencies, high data volumes, and user interaction.
  5721.  
  5722. Query Processing
  5723.  
  5724. Although nearly all object-oriented data models proposed so far include
  5725. behavioral aspects, most object-oriented query languages, algebras and
  5726. query optimization strategies simply adapt relational concepts since
  5727. they focus on the complex structures of objects and neglect the
  5728. behavior. We claim that this approach is not sufficient since it does
  5729. not reflect the much richer semantics methods can carry which have to
  5730. be taken into account for really efficient query processing. The quite
  5731. straightforward approach we consider is to integrate methods in an
  5732. algebraic framework for query processing and to make there partial
  5733. knowledge about methods available in the form of equivalences. We
  5734. integrate algebraic set operators with methods defined in database
  5735. schemas within an object-oriented data model. We investigate the impact
  5736. on the architecture of the query processor when the algebra becomes an
  5737. extendible component in query processing.
  5738.  
  5739. The VODAK Prototype
  5740.  
  5741. The system architecture consists of a central database environment and
  5742. several external database environments to which the user wants to have
  5743. integrated access. Each of these environments consists of an object
  5744. manager, a message handler, a transaction manager, and a communication
  5745. manager. In addition to these components an external database
  5746. environment includes a database interface module which realizes the
  5747. access to an external database system.
  5748.  
  5749. The DBMS components are currently built on top of DAMOKLES and will be
  5750. in the near future on top of ObjectStore.
  5751.  
  5752. A first version of a C++ based prototype of VODAK is available for Sun
  5753. Sparc Stations under certain conditions.  It implements all the
  5754. features specified in including e.g. metaclasses, transactions, and
  5755. remote message execution.
  5756.  
  5757. References
  5758.  
  5759. P. Muth, T. Rakow, W. Klas, E. Neuhold:  A Transaction Model for an
  5760. Open Publication Environment.  A. K. Elmagarmid (Ed.): Database
  5761. Transaction Models for Advanced Applications. Morgan Kaufmann
  5762. Publishers, San Mateo, Calif., 1992.
  5763.  
  5764. Wolfgang Klas, Karl Aberer, Erich Neuhold Object-Oriented Modeling for
  5765. Hypermedia Systems using the VODAK Modeling Language (VML) to appear
  5766. in: Object-Oriented Database Management  Systems, NATO ASI Series,
  5767. Springer Verlag Berlin Heidelberg, August 1993.
  5768.  
  5769. Karl Aberer, Gisela Fischer Object-Oriented Query Processing: The
  5770. Impact of Methods on Language, Architecture and Optimization
  5771. Arbeitspapiere der GMD No. 763, Sankt Augustin, July 1993.
  5772.  
  5773. T.C. Rakow, P. Muth The V3 Video Server: Managing Analog and Digital
  5774. Video Clips, Sigmod 93, Washington, DC.
  5775.  
  5776. For further information contact
  5777.  
  5778. {aberer,muth,rakow,klas}@darmstadt.gmd.de
  5779.  
  5780.   GMD-IPSI                                             
  5781.   Dolivostr. 15                                                           
  5782.   D-64293 Darmstadt
  5783.   GERMANY    
  5784.                                     
  5785.   FAX: +49-6151-869 966   
  5786.  
  5787.  
  5788. Commercial Systems
  5789. __________________
  5790.  
  5791. > ArtBASE  (Object-Oriented Data Model)
  5792.  
  5793. by:     ArtInAppleS Ltd.
  5794.         Kremelska 13
  5795.         845 03 Bratislava
  5796.         SLOVAKIA
  5797.         Phone: x42-7-362-889
  5798.         fax:   x42-7-777 779
  5799.         EMail: artbase.support@artinapples.cs
  5800.  
  5801. ############################################################################
  5802.  
  5803.  
  5804. Path: senator-bedfellow.mit.edu!faqserv
  5805. From: Bob Hathaway <rjh@geodesic.com>
  5806. Newsgroups: comp.object,comp.answers,news.answers
  5807. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Part 6/13
  5808. Supersedes: <object-faq/part6_805979999@rtfm.mit.edu>
  5809. Followup-To: comp.object
  5810. Date: 31 Aug 1995 15:32:41 GMT
  5811. Organization: Geodesic Systems
  5812. Lines: 1151
  5813. Approved: news-answers-request@MIT.Edu
  5814. Distribution: world
  5815. Expires: 14 Oct 1995 15:31:54 GMT
  5816. Message-ID: <object-faq/part6_809883114@rtfm.mit.edu>
  5817. References: <object-faq/part5_809883114@rtfm.mit.edu>
  5818. NNTP-Posting-Host: bloom-picayune.mit.edu
  5819. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  5820. X-Last-Updated: 1995/06/01
  5821. Originator: faqserv@bloom-picayune.MIT.EDU
  5822. Xref: senator-bedfellow.mit.edu comp.object:37588 comp.answers:13976 news.answers:51857
  5823.  
  5824. Archive-name: object-faq/part6
  5825. Last-Modified: 05/31/94
  5826. Version: 1.0.8
  5827.  
  5828. Distributor for Germany:
  5829.         ARS NOVA Software GmbH
  5830.         Stettener Strasse 32/3
  5831.         73732 Esslingen a.N.
  5832.         Germany
  5833.         Phone: x49-711 3704001
  5834.         Fax:   x49-711 3704001
  5835.         EMail: info@arsnova.stgt.sub.org
  5836.  
  5837. Languages: Objectworks\Smalltalk by ParcPlace Systems, Inc.
  5838.  
  5839. Platforms: Unix, PC Windows, Macintosh
  5840.  
  5841. Features:
  5842. - Fully implemented in Objectworks\Smalltalk
  5843.   (ArtBASE is delivered with source code)
  5844.  
  5845. - ArtBASE extents Smalltalk of persistency. Persistent objects are handled the
  5846.   same way as transient objects.
  5847.  
  5848. - Optimistic and pessimistic concurrency control.
  5849.  
  5850. - Transactions, including long lived transactions
  5851.  
  5852. - User concept with access restrictions
  5853.  
  5854. - storing of classes and methods in the database - entire applications 
  5855.   may be stored in an ArtBASE database, including the data AND the 
  5856.   application classes
  5857.  
  5858. - Currently, a single user version is available. The Distributed Multi User Server Version
  5859.   will be presented at the OOPSLA'93 at Washington D.C. in September 1993 for Unix
  5860.   environments and PCs.
  5861.  
  5862. - Existing applications can be turned to database applications very easily using ArtBASE
  5863.  
  5864.  
  5865. > EasyDB (Objective Systems, Sweden)
  5866.  
  5867. EasyDB features a (programming language independent) Data Definition
  5868. Language (DDL) for the definition of schemas.  It relies on the
  5869. Entity-Attribute-Relationship model.  Data Manipulation Languages
  5870. (DML) include a Navigational Query language (NQL) embedded in a host
  5871. language (C available now, Ada in January '93), and a generic C++
  5872. class library.
  5873.  
  5874. On Schema Evolution (from original survey):
  5875. The schema may be freely extended with new items (types, domains,
  5876. attributes, entities, relationships etc.). Deletion of items is not
  5877. allowed.
  5878.  
  5879. Data created with an older schema may co-exist with newer data. Old
  5880. applications need not be recompiled when the schema is updated.
  5881. Attempts by newer applications to access `older' data in an
  5882. inconsistent way are detected and reported via an exception handling
  5883. system.
  5884.  
  5885. [Tomas Lundstrom <tomas@os.se>]
  5886.  
  5887. Objective Systems SF AB (Ericsson)
  5888. Box 1128
  5889. S-164 22 Kista, Sweden
  5890. tel : +46-8-703-4591
  5891. fax : +46-8-750-8056
  5892. contact: Jaan Habma, jaan@os.se
  5893.  
  5894.  
  5895. > GemStone (Servio)
  5896.  
  5897. First introduced in 1987, Servio's GemStone is the oldest commercial ODBMS
  5898. available today. GemStone is particularly well suited for use in complex
  5899. multi-user, multi-platform client/server applications. It supports
  5900. concurrent access from multiple external languages, including Smalltalk-80,
  5901. Smalltalk/V, C++ and C. GemStone also provides a dialect of Smalltalk as an
  5902. internal DML, which can execute methods or entire applications in the
  5903. database.
  5904.  
  5905. Servio also offers GeODE (GemStone Object Development Environment), an
  5906. object database application development environment which allows developers
  5907. to build complete object applications visually, without writing code. With
  5908. GeODE's visual programming tools, programming an application is a matter of
  5909. wiring together graphical representations of encapsulated code blocks. A
  5910. simple extension mechanism promotes the re-use of code, thereby increasing
  5911. the speed of program development. Also, association of application user
  5912. interface elements with database objects is established through simple
  5913. graphical tools. GeODE applications are stored and run in the GemStone
  5914. database, and so are both self-porting and network-aware, and can be
  5915. accessed externally from any of the GemStone language interfaces. Because
  5916. of GemStone's network architecture, Geode applications can operate easily
  5917. in a client/server environment.
  5918.  
  5919.  
  5920.  ==============================================================================
  5921.  
  5922. GEMSTONE
  5923.  
  5924. GemStone is a highly scalable client-multiserver database for commercial
  5925. applications. GemStone's features include:
  5926.  
  5927. o  Active Database -- GemStone allows database application developers to
  5928.    write methods which are stored and executed directly in the database.
  5929.    These methods can be accessed either internally, or from external client
  5930.    applications. This can significantly reduce network traffic and allow
  5931.    applications to take advantage of the superior compute power of the
  5932.    server. This also eliminates the need to rebuild and re-deploy
  5933.    applications whenever application or business processing rules change.
  5934.    This in turn allows for centralized code development and management,
  5935.    architecture-independent code that ports itself to new platforms,
  5936.    reduced network usage, and true client/server applications that share
  5937.    compute load between client and server machines.
  5938.  
  5939. o  Concurrent Support for Multiple Languages -- GemStone provides
  5940.    concurrent support for applications developed in Smalltalk, C++, C or
  5941.    GeODE. All applications, regardless of language, can have simultaneous
  5942.    access to the same database objects.
  5943.  
  5944. o  Flexible multi-user transaction control -- Multiple users can
  5945.    operate in the database simultaneously, with a variety of transaction
  5946.    control modes available.
  5947.  
  5948. o  Object-level security -- Authorization control can be applied to any
  5949.    object in the database, allowing for fine tuning of object security.
  5950.  
  5951. o  Dynamic schema and object evolution -- GemStone supports schema
  5952.    modification through class versioning and allows full migration of
  5953.    objects between versions of their classes with a simple message send.
  5954.    Migration is fully customizable and is undoable.
  5955.  
  5956. o  Production Services -- GemStone delivers the full suite of features
  5957.    required in any production-ready networked database including online
  5958.    backup, rapid recovery, referential integrity, sophisticated concurrency
  5959.    control, and event signals and notifiers.
  5960.  
  5961. o  Scalability -- In a recent independent benchmark, GemStone scaled to
  5962.    support more than 1,000 simultaneous log-ins and 100 concurrent active
  5963.    users on a mid-sized SMP server.
  5964.  
  5965. o  Legacy Gateways -- GemStone incorporates gateways or data bridges
  5966.    that allow object applications to integrate legacy data, whether in SQL,
  5967.    IMS, VASM or other formats. The level of integration between GemStone
  5968.    and legacy data and applications can range from simple query access to
  5969.    extensive read-write interoperability.
  5970.  
  5971.  
  5972.  ==============================================================================
  5973.  
  5974. GEODE
  5975.  
  5976. GeODE is a comprehensive environment for rapidly designing, building and
  5977. deploying production-quality commercial object applications. Its design
  5978. promotes code reuse in a team programming environment for increased
  5979. productivity. GeODE consists of six main elements:
  5980.  
  5981. o  Visual Application Manager -- Provides centralized management
  5982.    of each application and its component parts, and a namespace for
  5983.    addressing known objects.
  5984.  
  5985. o  Visual Schema Designer -- Allows the development of database schema
  5986.    visually, making the process more interactive and intuitive than with
  5987.    object-oriented programming languages. It also provides analysis tools
  5988.    for examining an existing schema.
  5989.  
  5990. o  Visual Forms Designer -- The Forms Designer reads GemStone class
  5991.    definitions and an associated data dictionary to automatically create
  5992.    default forms suitable for simple data entry. These forms can be rapidly
  5993.    customized, using a wide selection of user interface components and
  5994.    field types, which include image and sound support, and a large set of
  5995.    form design aids. The list of field types can be extended interactively.
  5996.  
  5997. o  Visual Program Designer -- The Visual Program Designer allows developers
  5998.    to visually create and modify the behavior of an application without
  5999.    having to write code. Programs are created by connecting visual program
  6000.    blocks to field blocks drawn from the forms created in the Forms
  6001.    Designer. A large collection of predefined program blocks is provided
  6002.    with GeODE, and users can extend the catalog in any of a number of
  6003.    simple ways. Code-based programming can be integrated routinely.
  6004.  
  6005. o  Developer Class Library - GeODE comes standard with more than 480
  6006.    classes and thousands of methods, and is easily extended for handling
  6007.    specialized applications. In a team environment, some programmers can
  6008.    develop visual applications while others write new methods that are
  6009.    encapsulated into visual program blocks for easy reuse.
  6010.  
  6011. o  Developer Tools -- GeODE includes tools for debugging, browsing and
  6012.    inspecting applications. Included in this set of tools are several
  6013.    debuggers, browsers, inspectors, an object clipboard, an image editor,
  6014.    and a code profiler for performance analysis.
  6015.  
  6016.  
  6017.  ==============================================================================
  6018.  
  6019. PLATFORMS
  6020.  
  6021. GemStone release 3.2 and GeODE 2.0 and all language interfaces are
  6022. available for UNIX workstations and servers from SUN, HP, IBM, Sequent, and
  6023. DEC. Client-only support is available in a number of languages for Windows
  6024. 3.1, OS/2 and Macintosh. Servio is an active member in the Object
  6025. Management Group and the ANSI Smalltalk standardization committee. Servio
  6026. supports SUN ODMG, ANSI C++ and intends to comply fully with the emerging
  6027. standards.
  6028.  
  6029.  ==============================================================================
  6030.  
  6031. REFERENCES
  6032.  
  6033.   [Maier, et al. 84] D. Maier, J. Stein, A. Otis, A. Purdy, ``Development
  6034.   of an object-oriented DBMS'' Report CS/E-86-005, Oregon Graduate Center,
  6035.   April 86 - ACM 0-89791-204-7/86/0900-0472
  6036.  
  6037.   R.G.G. Cattell: Object Data Management - Object-Oriented and Extended
  6038.   Relational Database Systems; Addison-Wesley. ISBN 0-201-53092-9
  6039.  
  6040.   Robert Bretl, David Maier, Allen Otis, Jason Penney, Bruce Schuchardt,
  6041.   Jacob Stein, E. Harold Williams, Monty Williams. "The GemStone Data
  6042.   Management System." Chapter 12 of "Object-Oriented Concepts, Databases
  6043.   and Applications", by Kim and Lochovsky.
  6044.  
  6045.  
  6046.  ==============================================================================
  6047.  
  6048. CONTACTS
  6049.  
  6050.  === Headquarters - San Jose ====
  6051.  
  6052. Servio Corporation
  6053. 2085 Hamilton Avenue
  6054. Suite 200
  6055. San Jose  CA  95125
  6056.  
  6057. Tel: 800-243-9369
  6058. Tel: 408-879-6200
  6059. Fax: 408-369-0422
  6060.  
  6061.  === Chicago ====
  6062.  
  6063. Servio Corporation
  6064. 8410 Bryn Mawr
  6065. Suite 400
  6066. Chicago  IL  60631
  6067.  
  6068. Tel: 312-380-1310
  6069. Fax: 312-380-1308
  6070.  
  6071.  ===  New York ====
  6072.  
  6073. Servio Corporation
  6074. 1120 Avenue of the Americas
  6075. 4th Floor
  6076. New York  NY  10036
  6077.  
  6078. Tel: 212-626-6680
  6079. Fax: 212-626-6684
  6080.  
  6081.  === Dallas ====
  6082.  
  6083. Servio Corporation
  6084. 14875 Preston Road
  6085. Suite 550
  6086. Dallas  TX  75240
  6087.  
  6088. Tel: 214-980-7073
  6089. Fax: 214-980-2949
  6090.  
  6091.  === Europe/UK ====
  6092.  
  6093. Servio UK
  6094. Criterion House
  6095. Beauchamp Court, Victors Way
  6096. Barnet  EN5 5TZ  England
  6097.  
  6098. Tel: +44 81 447-0800
  6099. Fax: +44 81 447-0577
  6100.  
  6101.  === Japan ====
  6102.  
  6103. Servio Corporation
  6104. Daito-Eiwa Building, 7F
  6105. 5-11 Nihonbashi-Hakozakicho
  6106. Chuo-ku  Tokyo 103  Japan
  6107.  
  6108. Tel: +81 3 3660-1910
  6109. Fax: +81 3 3663-3287
  6110.  
  6111.  =====================
  6112.  === Distributors ====
  6113.  =====================
  6114.  
  6115.  === Germany, Austria, Switzerland ====
  6116.  
  6117. ObjectOriented System Technologies
  6118. Baroper Str. 337
  6119. Dortmund  50  W-4600
  6120. Germany
  6121.  
  6122. Tel: +49 231 975 990
  6123. Fax: +49 231 975 99-20
  6124.  
  6125.  === Japan ====
  6126.  
  6127. Japan Information Processing Service Co., Ltd.
  6128. 2-4-2 Toyo , Koto-ku
  6129. Tokyo, 135, JAPAN
  6130.  
  6131. Tel: +81 3 5690 3268
  6132. Fax: +81 3 5690 3390
  6133.  
  6134. --------------------
  6135.  
  6136. Nexus Technology K.K.
  6137. Suite 901
  6138. Botan 3-11-1
  6139. Koto-ku  Tokyo 135  Japan
  6140.  
  6141. Tel: +81 3 3660-1910
  6142. Fax: +81 3 3663-3287
  6143.  
  6144.  === Taiwan ====
  6145.  
  6146. Anco Technologies
  6147. 11-1F, 76 Tun Hwa S. Road, Sec. 2
  6148. Taipei
  6149. Taiwan, R.O.C.
  6150.  
  6151.  === Italy ====
  6152.  
  6153. Etnoteam S.P.A.
  6154. Via Adelaide Bono Cairoli 34
  6155. Milano  20127  Italy
  6156.  
  6157. Tel: +39 2 261 621
  6158. Fax: +39 2 261 10755
  6159.  
  6160.  === England ====
  6161.  
  6162. AI International Ltd.
  6163. 1 Parkview Road
  6164. Berkhamsted
  6165. Herts  HP4 2EY  England
  6166.  
  6167. Tel: +44 442 876 722
  6168. Fax: +44 442 877 997
  6169.  
  6170.  ==== Mexico ====
  6171.  
  6172. TEIX, Sistemas de Informacion
  6173. Estrategica S.A. de C.V.
  6174. Antonio M. Anza No. 43
  6175. Col Roma  Mexico D.F.  06700
  6176.  
  6177. Tel: +52 5 564-7146
  6178.  
  6179.  
  6180. > ITASCA
  6181.                        ITASCA ODBMS V2.2
  6182.  
  6183.                       Itasca Systems, Inc.
  6184.                        7850 Metro Parkway
  6185.                       Minneapolis, MN 55425
  6186.                         sales@itasca.com
  6187.                          (612) 851-3155
  6188.  
  6189.                           Sandy Miezwa
  6190.                          (612) 851-3169
  6191.  
  6192. Introduction
  6193.  
  6194. Itasca Systems develops, markets, and supports ITASCA, a distributed 
  6195. active object database management system and related tools. The initial 
  6196. research work for ITASCA occurred in the Object-Oriented and Distributed 
  6197. Systems Lab at the Microelectronics and Computer Technology 
  6198. Corporation (MCC) in Austin, Texas. The research was known as the 
  6199. ORION prototypes. 
  6200.  
  6201. The ITASCA Distributed ODBMS is a language neutral, full-featured, active 
  6202. object database that supports data access from various object
  6203. languages. ITASCA allows clients to transparently access data that is
  6204. distributed among multiple servers.  ITASCA supports full dynamic schema
  6205. modification that can be performed during any phase of the software
  6206. lifecycle.  Applications written in dissimilar and incompatible languages,
  6207. such as C++ and CLOS, share objects through ITASCA. ITASCA stores methods
  6208. inside the database, promoting reusability and maintainability.  The only
  6209. commercial ODBMS based upon the MCC Orion technology, ITASCA is considered
  6210. by many to be the most feature-rich ODBMS on the market today.
  6211.  
  6212. This overview describes release 2.2 of the ITASCA Distributed Object 
  6213. Database Management System. It describes how ITASCA functions, 
  6214. outlines its implementation features, and explains some of the system 
  6215. benefits. 
  6216.  
  6217.  
  6218. History of ITASCA
  6219.  
  6220. ITASCA is based on a series of object database research prototypes. Work 
  6221. on these prototypes began in 1985 at the Microelectronics and Computer 
  6222. Technology Corporation (MCC) Object-Oriented and Distributed Systems 
  6223. Laboratory. MCC released the first prototype, ORION-1, in May, 1987, as 
  6224. a single-user system. MCC extended ORION-1 to the ORION-1SX 
  6225. prototype system and released it to the shareholder companies in April, 
  6226. 1988. ORION-1SX was a multi-user system with a multi-client, single 
  6227. server architecture. The third prototype, ORION-2, introduced a distributed, 
  6228. object-oriented architecture for a multi-user environment. MCC released 
  6229. the third prototype to shareholder companies in July, 1989. ORION-2 has a 
  6230. multi-client, multi-server architecture. Having met its objectives, MCC 
  6231. stopped all work on ORION at that time. Over five million dollars was spent
  6232. for the three generations of prototypes.
  6233.  
  6234. The ITASCA product is an extension and commercialization of the ORION-2
  6235. prototype from MCC. Itasca Systems has added major enhancements and
  6236. features, improved the performance, and strengthened the code. It now runs
  6237. on UNIX systems from multiple vendors. ITASCA is an industrial-strength,
  6238. documented product, fully supported by Itasca Systems, Inc. Itasca Systems
  6239. continues to develop tools and other products to work with ITASCA.
  6240.  
  6241.  
  6242. Overview
  6243.  
  6244. ITASCA employs a distributed architecture with private and shared objects 
  6245. spread across UNIX-based computers on a local-area network. The 
  6246. ITASCA model follows the object-oriented view that uniformly models any 
  6247. real-world entity as an object. Each object has a unique identifier along with 
  6248. a state and behavior. Attributes represent the state of an object. Methods 
  6249. (code) define the behavior of an object. A class object collects objects that 
  6250. share the same set of attributes and methods. Subclasses derive from 
  6251. existing classes. The resulting schema, or database definition, is a class 
  6252. hierarchy. Each subclass inherits all the attributes and methods of its 
  6253. superclasses. ITASCA supports multiple inheritance. A subclass may derive 
  6254. from more than one superclass. 
  6255.  
  6256. One of the breakthroughs of object-oriented technology is the reusability of 
  6257. code. ITASCA allows for the active management of both reusable code and 
  6258. data in an integrated system. Developers may write applications in C++,
  6259. CLOS, C or Common Lisp. This means ITASCA is language neutral. Objects 
  6260. stored using one programming language can be accessed by other 
  6261. programming languages. It also means an application program need not be
  6262. written in an object-oriented language. 
  6263.  
  6264. The ITASCA database management system has features belonging to most any 
  6265. database system. This includes persistent storage for data and schema, 
  6266. concurrency control and locking, transaction management, multiple 
  6267. security levels, and logging and recovery for both CPU and disk media 
  6268. failure. Additional features of ITASCA include dynamic schema 
  6269. modification, long-duration transactions, shared and private databases, 
  6270. distributed version control, distributed transaction management, distributed 
  6271. query management, distributed change notification, object migration, and 
  6272. an extensible architecture.
  6273.  
  6274. Shared and private databases exist in a distributed environment in ITASCA. 
  6275. The shared database is distributed across workstations (sites) in a network. 
  6276. An ITASCA server controls the partition of the shared database at each site. 
  6277. ITASCA clients provide transparent access to the various partitions of the 
  6278. shared database. The architecture allows any number of private databases at 
  6279. each distributed database site. Data can move between private and shared 
  6280. databases. Private databases allow private data that is not shared with other 
  6281. users of the database.
  6282.  
  6283. ITASCA stores the schema redundantly at each site to improve 
  6284. performance. The schema storage also includes code in the form of 
  6285. methods. Management of schema updates is automatic for all sites. This 
  6286. includes sites that were off-line during any changes. Automatic distribution 
  6287. of schema changes, including method code changes, simplifies database 
  6288. administration.
  6289.  
  6290. ITASCA stores each instance of data in one site. The system or a user may 
  6291. move the data from one site to another to improve data locality. Access to 
  6292. moved data remains transparent. There is no need for a user or application 
  6293. to know the specificlocation of data in the ITASCA distributed database. 
  6294. ITASCA will automatically find the location of the data. This simplifies 
  6295. distributed application development. The developer can rely on ITASCA 
  6296. finding data in the distributed database.
  6297.  
  6298. No single site acts as a master site, thus ITASCA's architecture has no 
  6299. single point of failure. ITASCA has neither a central data server nor a 
  6300. central name server. This is important for maintaining a database system 
  6301. with high availability in a networked workstation environment.
  6302.  
  6303. ITASCA supports dynamic schema modification to create a flexible 
  6304. environment for changing or customizing a database system. Authorized 
  6305. users can add and remove attributes or change the subclass/superclass 
  6306. relationship at any time. Authorized users can also add or remove partitions 
  6307. of the shared database at any time. All this can be done interactively without 
  6308. affecting other parts of the ITASCA database at the time changes occur to 
  6309. the schema. There is no need to "bring the system down" or off-load/reload 
  6310. data to restructure the database. Dynamic schema modification can 
  6311. significantly reduce maintenance costs. It also is useful in environments 
  6312. where change to data definitions are normal or relatively frequent.
  6313.  
  6314. ITASCA has a sophisticated security authorization technique tied to the 
  6315. class hierarchy. It supports both positive and negative authorizations at any 
  6316. level in the class hierarchy. For example, granting access to all objects but 
  6317. one requires only two authorizations: a global grant followed by a specific 
  6318. denial. Authorization extends to classes, instances of classes, attributes, 
  6319. and methods. Also, inheritance of authorization reduces the work of database 
  6320. administration. 
  6321.  
  6322. Long-duration transactions allow users to check objects out of the shared, 
  6323. distributed database into their private databases. Users can then change the 
  6324. objects in the private databases without affecting the shared database or 
  6325. other users. These changes can be committed to the private database. Then, 
  6326. at any later time, the user can check the updated object or objects back into 
  6327. the shared database.
  6328.  
  6329. ITASCA supports version control of objects. A new version of an object 
  6330. promotes the original or parent object to restrict further changes to the 
  6331. parent. ITASCA also supports alternate versions such that multiple versions 
  6332. can have the same parent. Promoting an object version to a released status 
  6333. restricts any deletion of the object. ITASCA uses generic versions to 
  6334. dynamically reference the most recent or default version of an object 
  6335. without any intervention by a user or application.
  6336.  
  6337. Change notification in ITASCA is either flag-based or message-based. 
  6338. Flag-based notification will identify an updated object upon querying the 
  6339. object for such information. It is a passive notification scheme. Message-
  6340. based notification, on the other hand, is an active notification scheme. It 
  6341. will execute a method (or code) upon an update or other change to an object. 
  6342. Such methods can send mail messages or invoke other methods or 
  6343. programs. 
  6344.  
  6345. Memory management in ITASCA uses both page and object buffers. 
  6346. ITASCA has a traditional database page buffer scheme that contains pages 
  6347. with multiple objects. Desired objects move from the page buffer to an 
  6348. object buffer. The object buffer then provides ITASCA with enhanced in-
  6349. memory performance because it contains only frequently-referenced 
  6350. objects. 
  6351.  
  6352.  
  6353. > MATISSE
  6354.  
  6355. OODBMS FEATURES LIST:
  6356.  
  6357. An Industrial Strength Open Semantic Object Database
  6358.  
  6359. Performance
  6360. -       Symmetric, Fine Grain, Multi-Threaded Architecture
  6361. -       Parallel and Asynchronous Disk I/O
  6362. -       Automatic Disk Optimization through Dynamic Clustering
  6363. -       High Speed OLTP Environment
  6364. Reliability
  6365. -       24 Hour - Mission Critical Operation
  6366. -       Media Fault Tolerant (Object Replication)
  6367. -       Transparent On-line Recovery
  6368. Database Administration
  6369. -       Full On-line Administration (No Down Time)
  6370. -       On-line Incremental or Full Back-Up
  6371. -       Dynamically Increase Database Size -   On-line
  6372. -       Full On-line Monitoring
  6373. Data Management and Consistency
  6374. -       Dynamic Schema Evolution
  6375. -       Consistent Database Reads without Locking
  6376. -       Historical Versioning, both Schema and Data Objects
  6377. -       Built-in Enforced Referential Integrity
  6378. -       Object Level Implicit or Explicit Locking
  6379. Scalability
  6380. -       Hundreds of Concurrent On-line Users
  6381. -       Hundreds of Gigabytes Per Database
  6382. -       From Few Bytes to Four Gigabytes for Each Object
  6383. -       Up to Four Giga-objects Per Database
  6384. Object Model
  6385. -       Full Object Oriented Model
  6386. -       User Extensible Object Meta-Schema
  6387. -       Support for Complex, Highly Dynamic, Variable Sized Objects
  6388. -       Multiple Inheritance
  6389. Intelligent Objects
  6390. -       Triggers at Object, Attribute, or at Relationship Level
  6391. -       Consistency Rules at Object, Attribute, or at Relationship Level
  6392. -       Customizable Intelligent Object Indexing
  6393. -       Automatic Inverse Relationships
  6394. Open Systems
  6395. -       Open C, C++ API
  6396. -       Supports Any Commercial Development Tool and Language
  6397. -       No Proprietary Tool Required
  6398. -       Heterogeneous Cross Platform Client/Server Architecture
  6399.  
  6400.  
  6401. For additional information on MATISSE, contact
  6402. ----------------------------------------------
  6403.  
  6404. In the UNITED STATES:
  6405. ADB, Inc.  (Advanced Database)
  6406. 238 Broadway
  6407. Cambridge, MA  02139 - USA
  6408.  
  6409. Phone:  1 (617) 354-4220
  6410. Fax:    1 (617) 547-5420
  6411. Email:  info@adb.com
  6412.  
  6413. In EUROPE:
  6414. ADB/Intellitic SA. 
  6415. 12/14, rue du Fort de Saint Cyr
  6416. Montigny le Bretonneux
  6417. 78182 Saint Quentin en Yvelines Cedex - FRANCE
  6418.  
  6419. Phone:  33 (1) 30 14 54 35
  6420. Fax:    33 (1) 30 14 54 40
  6421. Email:  info@adb.fr
  6422.  
  6423.  
  6424. In JAPAN:
  6425. ADB/Intellitic SA.
  6426. c/o SGN Co., LTD
  6427. Urban Toranomon Building - 1-16-4 Toranomon
  6428. Minato-Ku Tokyo 105 - JAPAN
  6429.  
  6430. Phone:  81 (3) 3593.34.31
  6431. Fax:    81 (3) 3593.34.32
  6432.  
  6433.  
  6434.         MATISSE TECHNOLOGY BRIEF
  6435.  
  6436. MATISSE was designed to have an OPEN API, and not be 
  6437. tightly bound to a single language (such as C++ or Smalltalk).  
  6438. MATISSE can be used effectively with C++, C, and any other language.
  6439. This allows for MATISSE to be easily integrated into almost any 
  6440. user application.
  6441.  
  6442. MATISSE is based upon the following principles and ideals:
  6443.  
  6444. MATISSE is first and foremost a database, whose purpose is to 
  6445. always provide information in a consistent and correct format, 
  6446. insuring referential integrity amidst the most complex database 
  6447. modifications.  And, to provide a set of DBA tools which meet 
  6448. the challenge of managing large, complex database applications.
  6449.  
  6450. Production quality applications require production quality databases.  
  6451. This means high reliability, high scalability, no database down 
  6452. time for archival/backup/restore and 24hr/7days  per week operation.  
  6453. MATISSE supports these requirements.
  6454.  
  6455. A flexible, intelligent meta-model architecture based upon the 
  6456. principles of semantic links and object technology allows for the 
  6457. most effective bases for representing and managing complex, highly 
  6458. interrelated data.  The MATISSE meta-model provides built in 
  6459. constraint checking, user definable constraints for triggers and 
  6460. daemons, and full dynamic schema and meta-schema evolution.  
  6461.  
  6462. Providing an architecture which is open allows for the integration 
  6463. of MATISSE with any language or environment.  MATISSE is not bound 
  6464. to any language.  Its 'C' API allows for its use with many 
  6465. languages and environments.
  6466.  
  6467. The following list describes the features of MATISSE which we 
  6468. believe provide the competitive advantage:
  6469. -    Mission-critical operation - 24 hour operation and fault tolerance
  6470. -    Independence from any programming language
  6471. -    Dynamic schema management and evolution
  6472. -    Flexibility of the MATISSE  meta-model
  6473. -    Historical versioning
  6474. -    Consistent reads without locking - concurrency and locking
  6475. -    Support for high level consistency and referential integrity
  6476. -    Multi-threading architecture provides for a high degree of scalability
  6477.  
  6478. Each of these items are described in more detail below:
  6479.  
  6480. Mission Critical Operation.
  6481. MATISSE is designed to support 24 hour a day / 7 day a week operation, 
  6482. on multi-client / multi-server architectures.  Administration tools 
  6483. offer high end features which are mandatory for legacy DB administrators.  
  6484.  
  6485.  
  6486. Independence from any Programming Language.
  6487. The MATISSE client is implemented as a library of C procedures.  As a
  6488. result, any standard language can be used to develop applications on 
  6489. top of MATISSE, provided that the corresponding compiler is capable 
  6490. of calling external C-functions. To date, production applications have 
  6491. been built on top of MATISSE using C, ADA and C++.
  6492.  
  6493.  
  6494. Dynamic Schema Management.
  6495. Schema objects can be accessed using the same API available for data 
  6496. objects. The Data Definition Language is identical to the Data 
  6497. Manipulation language.  Versioning is implemented for both schema 
  6498. and data objects.  Thus, any running application can modify the database
  6499. schema, provided that existing instances do not become inconsistent with
  6500. that schema.  Consistency rules are checked by MATISSE.
  6501.  
  6502.  
  6503. Flexibility of the Model.
  6504. MATISSE is compliant with the IRDS standard.  Its architecture is 
  6505. highly extendible at both the Schema and the Meta-Schema level.  The 
  6506. MATISSE Semantic Meta-Model is not hard-coded.  It can be updated to 
  6507. conform with any OMG, ANSI, ISO, ... standard that might be issued 
  6508. in the future.  MATISSE can easily adapt to changing and evolving 
  6509. standards, without significant effort or re engineering.
  6510.  
  6511.  
  6512. Versioning.
  6513. Using the on-line versioning mechanism, MATISSE allows any connected 
  6514. client application to dynamically access any past database version which
  6515. was marked as a version to be saved.  Access can be performed without
  6516. any particular administrative operation, and concurrently with other 
  6517. on-line accesses to current or other historical  versions.
  6518.  
  6519. Since a database version includes both data and schema objects, a 
  6520. past version is always consistent, even after schema modification.  As 
  6521. a past version is accessed, so to is it's schema, and even the 
  6522. appropriate meta-schema associated with the accessed version.
  6523.  
  6524.  
  6525. Consistent Reads without Locking.
  6526. Using its versioning mechanism, MATISSE offers three kinds of 
  6527. database access:  
  6528.  
  6529. Typical transaction-based access: : as the 
  6530. database migrates forwards, and updates are made, database access 
  6531. occurs against the latest consistent database version.  A successful 
  6532. transaction commit results in a new consistent version.  If explicitly 
  6533. named, this version becomes a historical database version, which can 
  6534. be accessed by its logical name in the future . 
  6535.  
  6536. Historical version access: the application specifies the logical 
  6537. name of the historical version to be accessed. Access is read-only, 
  6538. and does not require any locking mechanism.
  6539.  
  6540. Current Time access: : this is a very powerful and unique feature 
  6541. of MATISSE.  Any application can request the latest available consistent
  6542. database version, using a reference to current time, with no 
  6543. locking overhead.  The "current time" database version is based 
  6544. upon the last transaction commit, and is automatically maintained by 
  6545. the database.  A "current time" database version acquires no database 
  6546. locks when accessed in read-only mode, thereby significantly 
  6547. reducing overhead.
  6548.  
  6549. Through these three access modes,  MATISSE supports on-line 
  6550. transaction processing and decision support requirements concurrently 
  6551. within a single application, through the use of current and historical
  6552. versions.
  6553.  
  6554. Support for High Level Consistency.
  6555. With MATISSE, referential integrity cannot be corrupted.  MATISSE's 
  6556. Semantic Links are specialized - i.e. they are specifically 
  6557. established between classes, they are directional, and, inverse links 
  6558. are automatically and dynamically set by MATISSE.  As a result, a 
  6559. MATISSE database understands its relationships, and fully manages 
  6560. all internal consistency features, insuring that no corruption occurs.  
  6561.  
  6562. Developers can describe very complex consistency methods and rules 
  6563. using daemons and triggers.  These methods can be attached to 
  6564. particular events such as, before or after creation, as well as class, 
  6565. instance, attribute modification.  Daemons and triggers provide for 
  6566. message propagation within your database. This results in a very 
  6567. intelligent database, which can be event driven.
  6568.  
  6569.  
  6570. MATISSE Server runs on
  6571. -  Sun Sparcstation - SunOS 4.1.3
  6572. -  Sun Sparcstation - Solaris
  6573. -  VAX - VMS
  6574. -  HP9000 - HP-UX
  6575.  
  6576. MATISSE Client runs on
  6577. -  Sun Sparcstation - SunOS 4.1.3
  6578. -  Sun Sparcstation - Solaris
  6579. -  HP9000 - HP-UX
  6580. -  Windows NT
  6581. -  Macintosh
  6582.  
  6583.  
  6584. > NeoAccess
  6585.  
  6586. A cross-platform object-oriented database engine based on C++. It allows
  6587. developers to embed the power of a fully-functional object-oriented database
  6588. system into their applications. All of the data contained in the database,
  6589. including indices, can be in a single file, so users can treat a database
  6590. file as they would a standard document file. The programming model is
  6591. designed to keep visible complexity to a minimum while providing a
  6592. feature-rich foundation on which to build and enhance applications.
  6593.  
  6594. NeoAccess has taken a different approach toward the issues surrounding object
  6595. persistence than have other solutions that have been offered. We believe that
  6596. objects should be viewed as having a set of properties with a pliable state.
  6597. With NeoAccess persistent objects are provided with persistence and sharing
  6598. properties. These properties allow objects to maintain an association with a
  6599. file. This association, which can be built and broken freely, allowing
  6600. objects to migrate freely between disk and memory. The API to these
  6601. properties address issues such as adding or deleting the object from a file,
  6602. sorting and indexing, locating and later freeing the object in memory, object
  6603. sharing, and maintaining relationships between objects.
  6604.  
  6605. NeoAcces
  6606. s with has been fully integrated into standard application frameworks such as
  6607. Borland's ObjectWindows and MacApp 3.0 and the THINK Class Library on the
  6608. Macintosh. A single source tree can be used to build the engine in all
  6609. development environments. Database files are binary-compatible across
  6610. platforms so users on different types of machines can share data without
  6611. conversion.
  6612.  
  6613. Contact:
  6614. Bob Krause
  6615. NeoLogic Systems
  6616. 1373 Third Avenue
  6617. San Francisco, CA 94122
  6618. (415) 566-9207
  6619.  
  6620.  
  6621. > O2 (INRIA/O2 Technology)
  6622.  
  6623. This is an entry on schema evolution.  General papers on O2 are included.
  6624.  
  6625. We have implemented in O2 schema updates in our first release but
  6626. without NO IMPACT on the database (we have a design to implement
  6627. deferred update, but it is a paper design). However, users manage to
  6628. convert their instances by hand, using their O2 programs written
  6629. themselves, and with the aid of the following tools:
  6630.  
  6631. 1- There is a set of predefined classes whose instances contain
  6632.    objects representing a schema (i.e., a Meta-schema). These classes
  6633.    may be used in a conversion program, they may even be extended by
  6634.    the programmer.
  6635.  
  6636. 2- There is a save-restore program that allows to take an O2 database,
  6637.    save it on a file or a tape in a logical way (i.e., independent of
  6638.    the physical format of objects on disk), and restore it again on a
  6639.    (perhaps new release) of the system, in an empty database.
  6640.    Currently, when saving a database its schema is also saved. The
  6641.    next extension to this save/restore program will be to save the
  6642.    database without saving its schema, and then restore the database
  6643.    on a new version of that schema. The restore program will be able
  6644.    to perform automatically some conversions like "add attribute" or
  6645.    "delete attribute".
  6646.  
  6647.  
  6648. Schema updates with impact on the database will be implemented in future 
  6649. releases.
  6650.  
  6651. [Fernando Velez <fernando@o2tech.fr>]
  6652.  
  6653.  
  6654. For more information on O2, consult the following REFERENCES:
  6655.  
  6656.         Francois Bancilhon, Claude Delobel, Paris
  6657.         Kanellakis.  "Building an Object-Oriented Database
  6658.         System: The Story of O2".  Morgan Kaufmann Series
  6659.         in Data Management Systems, San Mateo, Calif., 1992.
  6660.         
  6661.         F. Bancilhon, G. Barbette, V. Benzaken, C. Delobel,
  6662.         S. Gamerman, C. Lecluse, P. Pfeffer, P. Richard,
  6663.         and F. Velez.  "The Design and Implementation of
  6664.         O2, and Object-Oriented Database System".
  6665.         Advances in Object-Oriented Database Systems,
  6666.         Springer Verlag. (Lecture Notes in Computer Science
  6667.         series, Number 334.)
  6668.  
  6669.         C. Lecluse, P. Richard, and F. Velez. "O2, an
  6670.         Object-Oriented Data Model".  Proceedings of
  6671.         SIGMOD88.  Also appears in Zdonik and Maier,
  6672.         "Readings in Object-Oriented Database Systems",
  6673.         Morgan Kaufmann, 1990.
  6674.  
  6675.  ==== Corporate headquarters:
  6676. O2 Technology
  6677. 7 Rue du Parc de clagny
  6678. 78035 Versailles Cedex
  6679. France
  6680. tel : 33 1 30 84 77 77
  6681. fax : 33 1 30 84 77 90
  6682.  
  6683. [They have many other contacts worldwide]
  6684.  
  6685.  
  6686. > Objectivity/DB (Objectivity)
  6687.  
  6688. Introduction:
  6689.  
  6690. Objectivity/DB has a fully distributed client/server architecture that
  6691. transparently manages objects distributed across heterogeneous environments and
  6692. multiple databases.  It provides an application interface that uses transparent
  6693. indirection to ensure integrity and provides a single logical view of all
  6694. information, with all operations working transparently on any database on the
  6695. network, with scalable performance as users and objects increase.  A
  6696. higher-level Object Definition Language (ODL) is available as well as a C
  6697. functional interface, integrated C++ interface, and SQL++.
  6698.  
  6699.  
  6700. Objectivity/DB
  6701.  
  6702. Objectivity/DB [Reference:  Technical Overview, Objectivity, 1993], a product
  6703. of Objectivity, Inc. of Menlo Park, CA, provides an integrated C++ programming
  6704. interface with an emphasis on the DBMS engine for robustness and scalability
  6705. from workgroups to enterprise-wide production applications.  In production use
  6706. today with more than 50,000 end users licensed, it supports a fully
  6707. distributed, rather than central-server, architecture, with all operations
  6708. working transparently over a mixture of multiple databases, schemas, users, and
  6709. computers, and over heterogeneous hardware, operating systems, and networks. 
  6710. The language interface includes a C++ class library interface, soon to be ODMG;
  6711. a C function library; and SQL++, supporting query predicates with either SQL or
  6712. C++ syntax, interactively or programmatically.  Over forty administrative and
  6713. GUI tools provide both an interactive and programmatic interface, and a
  6714. messaging backplane allows third party tools integration at four different
  6715. levels, with a list of partners at all levels.
  6716.  
  6717. One of the key architectural concepts of Objectivity/DB is an object reference
  6718. mechanism that ensures data integrity.  Unlike traditional ODBMSs that use
  6719. direct pointers, which become invalid after commit and hence lead to crashes
  6720. and corrupt databases, Objectivity/DB uses an indirection to guarantee safe
  6721. reference.  Transparent to the user, this indirection requires an extra test
  6722. and pointer dereference, or a couple of cycles, which is not measurable in most
  6723. applications.  However, it ensures integrity of all references, even across
  6724. transaction boundaries, resulting in production quality robustness.  Also, it
  6725. provides object level granularity for the object manager, allowing it to move,
  6726. cluster, and swap objects as necessary, one of the keys required for
  6727. scalability in objects and users.  Finally, it allows object-level granularity
  6728. for current features, such as heterogeneity and versioning, and future
  6729. extensions, such as object-level security.
  6730.  
  6731. A higher-level Object Definition Language (ODL) is provided that allows
  6732. declaration of modeling concepts such as bi-directional associations, behavior
  6733. of associations between objects as they version (move, copy drop), and
  6734. propagation of methods across associations.  These then result in automatically
  6735. generated methods and declarations for both C++ and C.  The standard C++ API
  6736. allows application programmers to work with any standard compilers and
  6737. debuggers, with no extra pre-processors, providing ODBMS capabilities via
  6738. overloading C++ operators (new, ->, etc.), and declarations via provided
  6739. classes (for references, etc.).
  6740.  
  6741. Workgroup through enterprise-wide and cross-enterprise computing is supported
  6742. via a distributed client/server architecture that provides a single logical
  6743. view over multiple databases on heterogeneous machines.  The user sees a
  6744. logical view of objects connected to objects and need not worry that one object
  6745. is in a database on a Sun workstation, while another may be in a database under
  6746. Windows or VMS.  All operations work transparently across this environment,
  6747. including atomic transactions with two-phase commit, propagating methods, and
  6748. versioning.  Objects may be moved between databases and platforms without
  6749. affecting working applications or requiring changes to the applications. 
  6750. Multiple schemas may be created, without affecting other users or databases,
  6751. and may be used simultaneously with shared schemas, allowing local groups to
  6752. define their own models but still connect to other groups.  Databases may be
  6753. detached from this shared environment (federated database) and used on portable
  6754. devices, reconnected or moved to different (compatible) environment, or
  6755. distributed as parts or image libraries.  Gateways to RDBMSs are provided via
  6756. third-party integration with Persistence Software, and more generally to any
  6757. foreign data store, as long as the user installs the appropriate access
  6758. methods, extending the single-logical-view to include read/write access to
  6759. arbitrary foreign data stores.  Together, these allow delegation of
  6760. responsibilities to the appropriate users, integration with existing systems,
  6761. and gradual migration toward full enterprise-wide sharing.
  6762.  
  6763. The on-demand object manager directly and automatically manages object access
  6764. and buffering, rather than relying on system facilities such as virtual memory
  6765. or user manual get/put calls.  Mechanisms used include multiple buffer pools
  6766. locally and remotely, b-trees, hashing, scoped names, keys, and iterators, with
  6767. distributed catalogues for schemas and databases.  A direct connection is
  6768. established between the user and the objects used, so that users do not
  6769. conflict unless and until they are competing for the same objects, thus
  6770. avoiding the traditional central-server bottleneck.  Short transactions are
  6771. based on traditional (transient) locks, owned by the process, and group
  6772. together an arbitrary set of operations.  Long transactions are based on
  6773. persistent locks, owned by the user, and provide the same arbitrary grouping. 
  6774. Default concurrency is two-phase locking and serialization, but extensions
  6775. available include MROW, or multiple-readers concurrent with one-writer, and
  6776. allow users to lock with or without wait or with timed waits, to implement more
  6777. sophisticated mechanisms.
  6778.  
  6779. Objects may be modeled using C++ structures augmented by classes provided such
  6780. as strings, dictionaries, and relationship management, as well as some
  6781. particular domain libraries.  A simple object is a C++ class (or C structure)
  6782. with associated access methods.  A complex object may include multiple varrays,
  6783. each being a dynamically varying sized array of arbitrary structure.  A
  6784. composite object is any network of related objects that acts as a single
  6785. object, both structurally and behaviorally, via propagation of behaviors to
  6786. component objects.  Any number of composite objects may be contained in
  6787. composite objects, and a single object may participate in any number of
  6788. composites.  The relationship mechanism supports uni- and bi-directional
  6789. relationships, one-to-one, one-to-many, and many-to-many.  Versioning is
  6790. supported at object granularity, may be turned on or off at any time for each
  6791. object, may be restricted to linear or allow branching with multiple writers. 
  6792. References to versioned objects may be to a specific version or to the default
  6793. version, which may be separately specified by a method and may allow multiple
  6794. defaults.  Schema and object evolution are supported via versioning of the
  6795. type-defining objects.  Each time a type definition is changed, its defining
  6796. object is versioned, allowing arbitrary changes.  Objects may then be instances
  6797. of the old or new type version.  Object evolution or upgrading to the new type
  6798. version is supported  by the user writing conversion methods which are
  6799. installed and invoked by the system.
  6800.  
  6801. ANSI SQL query is supported in the SQL++ product.  Predicate syntax may be
  6802. either C++ or SQL.  The ODBC and SQL Access Group (SAG) protocols are
  6803. supported.  Queries may be invoked programatically or interactively, with ad
  6804. hoc support.  Access to object features is available via methods and traversal
  6805. of relationships.
  6806.  
  6807. Over forty administrative and developer tools are provided, each with both an
  6808. interactive and programmatic interface.  These include GUI object and type
  6809. browsers, query browsers, report generator, tools to examine and force short
  6810. and long locks, to move objects and databases, etc.  On-line incremental backup
  6811. provides a consistent network-wide snapshot, including referential integrity
  6812. across all databases, and runs incremental and full database backups with no
  6813. need to acquiesce the databases and no interference with active applications. 
  6814. All tools are built around a messaging backplane, which supports four levels of
  6815. integration with user and third-party tools.  Integrated products include HP
  6816. SoftBench (full operational level), CenterLine's ObjectCenter (tool level), 
  6817. Persistence RDBMS gateway, PTech and ProtoSoft Design and Analysis (language
  6818. level), and XVT and UIM/X (compatibility level).
  6819.  
  6820. Objectivity/DB is resold by Digital Equipment Corporation as DEC Object/DB,
  6821. providing a multi-billion-dollar second source vendor.  Over 50,000 end users
  6822. are licensed in production use, with applications including real-time
  6823. telecommunications, aerospace, defense, case, CAD/CAM, CIM, manufacturing, oil
  6824. & gas, process control, transportation, multi-media, case, document management,
  6825. financial analysis, and corporate information management.  Platform support
  6826. includes all Sun, all DEC (including VMS, alpha, OSF-1), HP/9000 series (both
  6827. 68xxx and PA-RISC), IBM RS/6000, NCR 3300, SGI, Windows 3.1, and Windows NT.
  6828.  
  6829. On Schema Evolution (from original survey):
  6830. In the just-released Version 2.0 (shipping Oct 92), schema evolution
  6831. is supported via dynamic versioning of type-defining objects [ie.
  6832. class versions -- SMC], and via a step-by-step approach that allows
  6833. conversion of instance data via user-provided conversion methods.
  6834. Also, a full dynamic type manager interface is available for doing
  6835. fancier things.
  6836.  
  6837. Contact:
  6838.  
  6839. Drew Wade
  6840. Objectivity, Inc.
  6841. 800 El Camino Real
  6842. Menlo Park, CA  94025 USA
  6843. drew@objy.com
  6844. 1(415)688-8000 voice
  6845. 1(415)325-0939 fax
  6846. admin ass't:  Vickie Clements (vickie@objy.com)
  6847. information:  info@objy.com
  6848.  
  6849.  
  6850. > ObjectStore Object Database System From Object Design, Inc.
  6851.  
  6852.  
  6853. Product Description    
  6854.  
  6855. ObjectStore[TM] is a high performance ODBMS designed for ease of use in
  6856. development of sophisticated applications using object-oriented
  6857. development techniques.  It offers a tightly-integrated language
  6858. interface to a complete set of traditional DBMS features including
  6859. persistence, transaction management (concurrency control and
  6860. recovery), distributed access, associative queries over large amounts
  6861. of data, and database administration utilities.  ObjectStore's data
  6862. management facilities combined with popular development tools create a
  6863. high productivity development environment for implementing
  6864. object-oriented applications.
  6865.  
  6866. Key Features:
  6867.  
  6868.    - Transparent interface designed for popular C and C++ programming
  6869.      environments. 
  6870.  
  6871.    - Concurrent access to large amounts of persistent data. 
  6872.  
  6873.    - Distribution of objects over networks using a variety of popular
  6874.      network protocols.
  6875.  
  6876.    - Access to persistent data at the same speed as transient data.
  6877.  
  6878.    - Extensible data modeling capabilities for applications requiring
  6879.      complex data structures.
  6880.  
  6881.    - Easy migration path for existing C and C++ applications.
  6882.  
  6883.    - Class libraries for version and configuration management.
  6884.  
  6885.    - Class libraries for managing collections of objects.
  6886.  
  6887.    - A fully distributed (multi-server/multi-database) ad hoc query
  6888.      capability.
  6889.  
  6890.    - An interactive Browser to inspect objects and object
  6891.      descriptions.
  6892.  
  6893.    - Interoperable with ObjectStore servers running on other operating
  6894.      systems and hardware environments.
  6895.  
  6896.    - Complete schema evolution for an application's metadata and
  6897.      existing object instances.
  6898.  
  6899.    - Full online backup for continuous processing environments.
  6900.  
  6901.    - Meta object protocol with programmatic access to schema
  6902.      information. 
  6903.  
  6904.    - Dynamic Type creation for extending existing class definitions
  6905.      during program execution.
  6906.  
  6907.  
  6908. System View
  6909.  
  6910. ObjectStore supports cooperative access through its flexible
  6911. client/server software architecture, which allows users to make the
  6912. take advantage of the computational power that exists on the desktop.
  6913. ObjectStore's client/server implementation allows one server to
  6914. support many client workstations, each workstation to simultaneously
  6915. access multiple databases on many servers, and a server to be resident
  6916. on the same machine as a client.  ObjectStore's distributed
  6917. architecture supports several network environments for
  6918. interoperability among popular workstations and PC's and includes
  6919. support for TCP/IP, Novell IPX/SPX, other popular network protocols.
  6920.  
  6921.  
  6922. Application Interface
  6923.  
  6924. Access to ObjectStore is provided through a library based application
  6925. interface compatible with popular C and C++ compilers and programming
  6926. environments.  The ObjectStore application interface provides support
  6927. for C++ compilers -- such as those from workstation suppliers -- and
  6928. development environments from independent software vendors such as
  6929. Visual C++ from Microsoft, ObjectCenter from CenterLine Software, Inc.
  6930. and Energize from Lucid, Inc.  The application interface provides
  6931. powerful high-level function calls which enable the programmer to
  6932. create multi-user application which share large amounts of data.
  6933. These functions include:
  6934.  
  6935.    - Relationship Management
  6936.    - Version Management
  6937.    - Collection Management
  6938.    - Storage Management
  6939.    - Associative Queries
  6940.    - Object Iteration
  6941.    - Transaction Management 
  6942.    - Index Management
  6943.    - Clustering
  6944.  
  6945. Applications developed using ObjectStore library calls are
  6946. source-level compatible with ObjectStore applications developed for
  6947. other operating systems on other hardware platforms.
  6948.  
  6949. Platforms
  6950.  
  6951. ObjectStore is available on the following major platforms:
  6952.     
  6953. Unix Workstation Platforms
  6954.  
  6955.    - DEC MIPS Ultrix 
  6956.    - HP 700 Series HP-UX
  6957.    - HP 800 Series HP-UX 
  6958.    - IBM RS/6000 AIX
  6959.    - NCR 3000 
  6960.    - Olivetti LSX-50xx SVR4
  6961.    - Silicon Graphics IRIX 5.x
  6962.    - SunSoft Intel Solaris 2
  6963.    - SunSoft SPARC Solaris 1 SunOS 4
  6964.    - SunSoft SPARC Solaris 2 SunOS 5
  6965.    - Univel UnixWare
  6966.  
  6967. PC Platforms
  6968.  
  6969.    - Windows 3.1 (Win32s)
  6970.    - Windows NT (Intel)
  6971.    - OS/2 Release 2.0 and 2.1
  6972.    - Novell Netware Release 3.1 and 4.0 (server only)
  6973.  
  6974. The Company
  6975.  
  6976. ############################################################################
  6977.  
  6978.  
  6979. Path: senator-bedfellow.mit.edu!faqserv
  6980. From: Bob Hathaway <rjh@geodesic.com>
  6981. Newsgroups: comp.object,comp.answers,news.answers
  6982. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Part 7/13
  6983. Supersedes: <object-faq/part7_805979999@rtfm.mit.edu>
  6984. Followup-To: comp.object
  6985. Date: 31 Aug 1995 15:32:44 GMT
  6986. Organization: Geodesic Systems
  6987. Lines: 1415
  6988. Approved: news-answers-request@MIT.Edu
  6989. Distribution: world
  6990. Expires: 14 Oct 1995 15:31:54 GMT
  6991. Message-ID: <object-faq/part7_809883114@rtfm.mit.edu>
  6992. References: <object-faq/part6_809883114@rtfm.mit.edu>
  6993. NNTP-Posting-Host: bloom-picayune.mit.edu
  6994. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  6995. X-Last-Updated: 1995/06/01
  6996. Originator: faqserv@bloom-picayune.MIT.EDU
  6997. Xref: senator-bedfellow.mit.edu comp.object:37589 comp.answers:13977 news.answers:51858
  6998.  
  6999. Archive-name: object-faq/part7
  7000. Last-Modified: 05/31/94
  7001. Version: 1.0.8
  7002.  
  7003. ObjectStore[TM], Object Design's object-oriented database management
  7004. system, is currently used by more than 500 companies.  The company
  7005. targets end-user customers in major corporations and governments
  7006. through its direct sales force, and also focuses on independent
  7007. software developers, systems integrators and international
  7008. distributors to license its products.  In the systems software market,
  7009. Object Design has already licensed object storage technology to
  7010. SunSoft that will be embedded in the Solaris(r) (Project DOE)
  7011. environment.  Through this relationship Hewlett Packard also has rights
  7012. to the technology for use in HP/UX(r) (DOMF).
  7013.  
  7014. In April 1993, IBM Corporation became one of the company's leading
  7015. investors as part of a far-reaching strategic relationship involving
  7016. an equity investment, internal use and joint development agreements.
  7017.  
  7018. Object Design's Support Services group provides extensive support
  7019. services tailored to meet each customer's specific needs.  A regularly
  7020. scheduled series of training courses are offered, either at Object
  7021. Design facilities across North America, select international locations
  7022. or at customer sites, that reduce the learning curve for
  7023. object-oriented development.  The training courses include
  7024. "Introduction to Object-Oriented Programming and C++," "Designing
  7025. Object-Oriented Database Applications" and "Building High Performance
  7026. Applications with ObjectStore."  To further assist its customers,
  7027. Object Design makes its team of experts available to provide a wide
  7028. range of training, support and consulting services.
  7029.  
  7030. The company distributes its products through a direct sales and
  7031. telesales force in the North America, wholly-owned subsidiaries in
  7032. Australia (61-2-212-2766), Germany (49-611-39707-0), Japan
  7033. (81-3-3251-2882), and the United Kingdom (44-793-486111) as well as
  7034. through distributors in 15 countries.
  7035.  
  7036. The US headquarters are located in Burlington, Mass., the company
  7037. maintains regional or district offices in Atlanta; Chicago; Los
  7038. Angeles; New York; Portland; San Mateo, Calif.; and Washington, DC.
  7039.  
  7040. You may obtain information about ObjectStore or Object Design by any
  7041. of the following methods:
  7042.  
  7043. Address:
  7044.  
  7045.     Object Design, Inc.
  7046.     25 Burlington Mall Road
  7047.     Burlington, MA 01803
  7048.  
  7049. Telephone:
  7050.  
  7051.     Call toll-free 1-800-962-9620 in the USA or 617-674-5000 and
  7052.     ask for telemarketing.
  7053.  
  7054. Internet:
  7055.  
  7056.     Send email requests to info@odi.com.
  7057.  
  7058.     You can also download public information from our ftp server,
  7059.     ftp.odi.com (198.3.16.17).  Login as "anonymous", and use your
  7060.     mail address (username@site) as your password.  Major files of
  7061.     interest include:
  7062.  
  7063.     /pub/docs/techsum-net.ps    Technical Summary (postscript)
  7064.     /pub/docs/techsum.net        Technical Summary (FrameMaker)
  7065.     /pub/oo7/results.ps        OO7 Benchmark Results (postscript)
  7066.  
  7067. CompuServe:
  7068.  
  7069.     GO ODIFORUM, section 1.
  7070.  
  7071. International distributors contact information follows:
  7072.  
  7073. GERMANY
  7074.  
  7075. Patzschke + Rasp 
  7076. Software und Systeme
  7077. Bierstadter StraBe 7
  7078. D-65189 Wiesbaden Germany
  7079. 011-49-611-17-310
  7080. 011-49-611-17-3131 FAX
  7081.  
  7082. SPAIN, PORTUGAL
  7083.  
  7084. DyM
  7085. Diseno y Metodologia, SA
  7086. Francisco Gervas, 17, 5.0 G
  7087. Madrid, Spain 28020011-34-1-571-3123 or 571-3880
  7088. 011-34-1-571-3942 FAX
  7089.  
  7090.  
  7091. SWEDEN, NORWAY, DENMARK, FINLAND
  7092.  
  7093. ENEA Data
  7094. Box 4150
  7095. S-203 12 Malmo
  7096. Sweden
  7097. 011-46-40-70930
  7098. 011-46-40-230240 FAX
  7099.  
  7100. SWITZERLAND
  7101.  
  7102. UNISYS (Schweiz) AG
  7103. Zucherstrasse 59-61
  7104. A-8800 Thalwill
  7105. Switzerland
  7106. 011-411-723-3366
  7107. 011-411-720-3737 FAX
  7108.  
  7109. ITALY
  7110.  
  7111. AIS S.p.a.
  7112. Via Rombon, 11-20134
  7113. Milano, Italy
  7114. 011-39-226-40197
  7115. 011-39-2 2641-0744 FAX
  7116.  
  7117. ISRAEL
  7118.  
  7119. TACTLINE, Ltd.
  7120. Beit-Oved 76800
  7121. Israel
  7122. 011-972-840-4898
  7123. 011-972-840-6927 FAX
  7124.  
  7125. JAPAN
  7126.  
  7127. Mitsui Engineering & Shipbuilding Co., Ltd.(MES)
  7128. 6-4 ,Tsukiji 5-chome
  7129. Chuo-ku,Tokyo, 104 
  7130. 011-81-3-3544-3355
  7131. 011-81-3-3544-3036FAX
  7132.  
  7133. Stan Systems Corporation
  7134. Sumitomo Higashi Shinbashi Bldg.
  7135. 1-1-11 Hamamatsucho
  7136. Minato-Ku, Tokyo 105 Japan
  7137. 011-81-3-5472-5515
  7138. 011-81-3-5472-5544 FAX
  7139.  
  7140.  
  7141. System Network Corporation:
  7142. Tohto Bldg. 6F
  7143. 5-1-4 Toranomon, Minato-ku, 
  7144. Tokyo  105 Japan
  7145. Phone#:   +81-3-3437-4081
  7146. Fax#:       +81-3-3437-4060
  7147.  
  7148. Toyo Information Systems Co.,Ltd.
  7149. Nihonbashi Toyo Bldg. 4F
  7150. 2-7-24 Nihonbashi
  7151. Chuo-Ku, Tokyo 103 Japan
  7152. 011-81-3-3271-7681
  7153. 011-81-3-3271-7685 FAX
  7154.  
  7155. TAIWAN, R.O.C.
  7156.  
  7157. Exartech International Corp 
  7158. 10F, 82, Chung-Cheng S. RD.
  7159. Sanchung, Taipei, Taiwan, ROC
  7160. 011-886-2-977-6828
  7161. 011-886-2-977-6829 FAX
  7162.  
  7163. SOUTH AFRICA
  7164.  
  7165. Realtime Computer Services (Pty) Ltd.
  7166. 4th Floor, 35 Wale Street
  7167. Cape Town 8001
  7168. South Africa
  7169. 011 27 21 24 4350
  7170. 011 27 21 221507 FAX
  7171.  
  7172.         
  7173. > Ontos [formerly VBase] (Ontologic)
  7174.  
  7175. Entry on schema evolution only:
  7176.  
  7177. *Ontos provides schema evolution. It allows any class to be modified.
  7178. *The major drawback is that data does not migrate ie., instances are
  7179. *not modified to adopt to the new class definition. So schema changes
  7180. *can be done only on classes that do not contain instances and do not
  7181. *have sub classes that contain instances.
  7182. *[h.subramanian@trl.OZ.AU]
  7183.  
  7184. *As a system for experiments, we are currently using ONTOS from
  7185. *Ontologic Inc.  Unfortunately, there is no transparent concept of
  7186. *schema evolution for populated database. Thus, we still investigate
  7187. *how it works.
  7188.  
  7189. ONTOS has a version of ONTOS for OS/2.  Approximately $11K. Others I don't know
  7190.  
  7191.  
  7192. > Odapter/OpenODB (Hewlett-Packard)
  7193.  
  7194. Odapter is HP's new object/relational adapter which
  7195. enables object-oriented developers to share a common
  7196. object model stored in the ORACLE7 relational database
  7197. management system (RDBMS).  Odapter is also available with
  7198. HP's ALLBASE/SQL RDBMS.  The combination of Odapter
  7199. and ALLBASE/SQL is called OpenODB.
  7200.  
  7201. Odapter 
  7202. Technical Data 
  7203. Object/Relational Adapter 
  7204.   
  7205. A Productivity Tool for Scalable Object-Oriented 
  7206. Applications 
  7207.   
  7208. Odapter is a tool for developers writing scalable 
  7209. object-oriented applications requiring the 
  7210. integration of new objects and legacy information. 
  7211. Odapter is valuable because it: 
  7212. * accelerates application development 
  7213. * reduces the cost of keeping applications current 
  7214. * enables applications to scale 
  7215.   
  7216. Odapter delivers the productivity of object 
  7217. technology while adhering to your data management 
  7218. standards. 
  7219.   
  7220. Consider Odapter if you need to be able to do one 
  7221. or more of the following: 
  7222. * develop object-oriented applications and 
  7223. store objects in a relational database 
  7224. * easily access legacy data and existing 
  7225. applications from your new system 
  7226. * support a large number of end-users who will 
  7227. be simultaneously accessing information 
  7228. * store large amounts of  complex information 
  7229.   
  7230. The following are examples of applications well- 
  7231. suited for Odapter: 
  7232. * a customer billing application written in 
  7233. Smalltalk combining data stored in DB2 with new 
  7234. objects. (Telecommunications) 
  7235. * a network management application written in C 
  7236. using Odapter as the object manager, able to scale 
  7237. to millions of objects (Manufacturing) 
  7238. * a complex Oil and Gas industry standard model 
  7239. automatically generated from an Express analysis 
  7240. and design tool. 
  7241. (Oil & Gas) 
  7242. * a medical application using Odapter to 
  7243. combine heterogeneous components of patient 
  7244. records. (Healthcare) 
  7245.   
  7246. Odapter provides authorized access to sharable 
  7247. objects, including existing data and business 
  7248. processes. By bringing object-oriented capabilities 
  7249. to heterogeneous systems environments, Odapter 
  7250. delivers increased functionality while leveraging 
  7251. the stability of existing RDBMSs and legacy 
  7252. information. 
  7253.   
  7254. Odapter Object Model 
  7255.   
  7256. The Odapter object model is based on three key 
  7257. concepts - objects, types and functions. 
  7258. * Objects are a combination of data and 
  7259. behavior (functions). Figure 2 is an example of an 
  7260. object. 
  7261. * Types are dynamic templates allowing you to 
  7262. group together similar components or objects. 
  7263. * Functions define the attributes, 
  7264. relationships and behavior of objects. Odapter 
  7265. supports four types of user-defined functions: 
  7266.   
  7267. Stored functions define attributes and 
  7268. relationships that are stored in the database. In 
  7269. Figure 2, flightno is a stored function. The 
  7270. functions aircraft and crew are also stored 
  7271. functions with user-defined results. 
  7272.   
  7273. SQL-based functions allow you to access existing 
  7274. relational tables with Odapter's object-oriented 
  7275. model. In Figure 2, citypair is an SQL-based 
  7276. function accessing values from an existing 
  7277. relational table. 
  7278.   
  7279. OSQL-based functions define attributes and 
  7280. relationships that are derived or calculated with 
  7281. OSQL statements. In Figure 2, delay and depart are 
  7282. OSQL-based functions. Delay calculates changes in 
  7283. arrival and departure times based upon events that 
  7284. disrupt the schedule; depart handles the update of 
  7285. functions related to departure and transitions the 
  7286. flight from OnGround to InAir. 
  7287.   
  7288. External functions are a reference to code or data 
  7289. stored outside of Odapter. In Figure 2, cancel is 
  7290. an external function that executes code outside of 
  7291. Odapter to free up resources no longer assigned to 
  7292. the flight. 
  7293.   
  7294. Odapter Language 
  7295.   
  7296. The Odapter language can be combined with functions 
  7297. implemented in C++, Smalltalk or C. You create and 
  7298. manipulate objects, types and functions using 
  7299. Odapter's object-oriented structured query language 
  7300. (OSQL). OSQL is a functional language that is a 
  7301. semantic superset of SQL, the structured query 
  7302. language for relational databases. OSQL is a 
  7303. computationally complete language with statements 
  7304. allowing you to define and manipulate information 
  7305. in your Odapter enhanced relational database, 
  7306. specify authorization for individuals or groups, 
  7307. define transactions, embed program logic within 
  7308. functions, and administer the database. 
  7309.   
  7310. OSQL includes programming flow statements, such as 
  7311. IF/THEN/ELSE, FOR and WHILE. This procedural 
  7312. language allows Odapter functions to model complex 
  7313. behavior, simplifying your application code. By 
  7314. decoupling behavior from the applications, multiple 
  7315. applications can share information with benefits 
  7316. such as consistency, security and integrity. See 
  7317. Table 5 for a list of all OSQL statements. 
  7318.   
  7319. Odapter Object Storage 
  7320.   
  7321. Odapter objects are stored in the developer's 
  7322. choice of relational databases. Odapter interfaces 
  7323. to the underlying RDBMS through an SQL command 
  7324. interface. Currently, developers can choose to 
  7325. store their objects in ORACLE7 or HP ALLBASE/SQL. 
  7326.   
  7327. The choice of RDBMS is made when a particular 
  7328. database is created. The users are only limited by 
  7329. the number of Odapter concurrent user licenses 
  7330. purchased. This flexibility allows database 
  7331. administrators to continue using their existing 
  7332. administration procedures and keeps the group from 
  7333. having to choose yet another database management 
  7334. system. 
  7335.   
  7336. During the initial development of an application, 
  7337. developers can make rapid progress without 
  7338. knowledge of the underlying relational database. 
  7339. Optimization of the objects and how they are stored 
  7340. in the underlying relational database is best 
  7341. done during the deployment phase. 
  7342.   
  7343. Odapter Development Environments 
  7344.   
  7345. Odapter developers have a choice of development 
  7346. environments. Whether Smalltalk, C++ or more 
  7347. traditional C and C-linkable languages are used, 
  7348. Odapter enables object storage in a scalable and 
  7349. robust relational database. In fact, objects can be 
  7350. shared between different applications, allowing 
  7351. different projects to employ the best tools for the 
  7352. job! 
  7353.   
  7354. Odapter and Smalltalk 
  7355.   
  7356. Odapter provides Smalltalk developers with 
  7357. transparent access to information stored in the 
  7358. underlying relational database. 
  7359.   
  7360. Odapter's Smalltalk Class Builder utility 
  7361. automatically generates ParcPlace Smalltalk 
  7362. compatible classes and methods based upon an 
  7363. Odapter object model. The developer can select 
  7364. specific Odapter types and functions, resulting in 
  7365. a corresponding set of Smalltalk classes and 
  7366. methods. Once the Smalltalk schema is generated, 
  7367. the Smalltalk developer can transparently access 
  7368. the underlying relational database, as shown in 
  7369. Figure 3. 
  7370.   
  7371. printFlight 
  7372.    |allFlightObjects| 
  7373.    allFlightObject:=Flight allObjects. 
  7374.    AllFlightObjects do: [:aFlight| 
  7375.       Transcript show :aFlight flightno value; cr]. 
  7376. Figure 3 
  7377.   
  7378.   
  7379. Figure 3 shows how to access the flight objects 
  7380. shown in Figure 2 through Smalltalk. This example 
  7381. retrieves all flight object identifiers and prints 
  7382. the flight# for each one of the flight objects. 
  7383.   
  7384. All Smalltalk classes and methods which result in 
  7385. the access of Odapter structures are italicized. 
  7386. Flight is a Smalltalk class that corresponds to the 
  7387. Odapter type Flight. The Smalltalk methods 
  7388. allObjects and flightno map to Odapter calls that 
  7389. access data from the relational database storage 
  7390. manager. 
  7391.   
  7392. Odapter and C++ 
  7393.   
  7394. For C++ developers, once the corresponding C++ 
  7395. model is created, Odapter provides the abilility to 
  7396. manage C++ objects stored in the underlying 
  7397. relational database, as shown in Figure 4. 
  7398.   
  7399. void printFlight() 
  7400.    int i; 
  7401.    ODBType Flight ("Flight"); 
  7402.    ODBBag allFlights=Flight.allObjects(); 
  7403.    ODBFunc flightno("flighno"); 
  7404.   
  7405.    for(i=0;i<allFlights.size();i++){ 
  7406.       cout<<flightno(allFlights[i]); 
  7407.    } 
  7408. Figure 4 
  7409.   
  7410. Figure 4 shows a C++ version of the Smalltalk 
  7411. example in Figure 3. That is, Figure 4 shows how to 
  7412. access all the flight objects shown in Figure 2 and 
  7413. prints the flight number associated with each 
  7414. flight object. 
  7415.   
  7416. The Odapter C++ library includes a set of classes 
  7417. (e.g. ODBType, ODBClass, ODBFunc, ODBBag) and 
  7418. corresponding member functions (e.g. allObjects). 
  7419. User-defined classes (Flight) and member functions 
  7420. (flightno) are also shown. In Figure 4, all Odapter 
  7421. calls are in italics. 
  7422.   
  7423. Odapter and C-linkable Languages 
  7424.   
  7425. For traditional developers using C, or any 
  7426. languages linkable with C, the object-oriented 
  7427. features are provided by Odapter. Odapter objects 
  7428. are manipulated by embedding OSQL statements in the 
  7429. C program, similar to the db.execosql call shown in 
  7430. Figure 4. In addition, the C interface requires the 
  7431. conversion of data types from Odapter to C. 
  7432.   
  7433. By embedding Odapter calls in a C program, the C 
  7434. language becomes object-oriented. 
  7435.   
  7436. Features and Benefits 
  7437.   
  7438. Accelerates Application Development 
  7439.   
  7440. Odapter accelerates application development by 
  7441. integrating with familiar development environments 
  7442. and by providing a robust object-oriented model. 
  7443.   
  7444. Odapter's choice of development environments 
  7445. includes those which support the Smalltalk, C++ and 
  7446. C languages. 
  7447.   
  7448. Odapter's robust object model enables the 
  7449. integration of legacy data and business processes 
  7450. in the context of one sharable business object 
  7451. model, shielding the developer from the data 
  7452. storage complexity. 
  7453.   
  7454. The following Odapter features accelerate 
  7455. application development: 
  7456.   
  7457. Automatic mapping of objects to relational 
  7458. databases 
  7459. The application developer is shielded from the task 
  7460. of converting complex object models to two 
  7461. dimensional relational tables. 
  7462.   
  7463. Smalltalk Class Builder 
  7464. Once an OSQL schema is created, whether using 
  7465. available analysis and design tools or manually, 
  7466. Odapter's Smalltalk Class Builder can generate 
  7467. corresponding Smalltalk classes and methods. The 
  7468. developer can select the relevent part of the 
  7469. Odapter schema to generate. As the Odapter object 
  7470. model changes, developers can also incrementally 
  7471. update the Smalltalk classes. 
  7472.   
  7473. Object Identity 
  7474. Each object manipulated by Odapter has a unique, 
  7475. system-provided handle called an object identifier 
  7476. (OID). OIDs eliminate the need for creating unique 
  7477. keys to identify stored information. Additionally, 
  7478. OIDs reduce duplication of information when several 
  7479. attributes would be needed to uniquely identify 
  7480. information in the database. OIDs are also a 
  7481. powerful way to tune data access and performance. 
  7482.   
  7483. Inheritance 
  7484. Odapter objects can use functions defined on parent 
  7485. types in the type hierarchy. For example, as shown 
  7486. in Figure 5, a subtype of Employee called Pilot 
  7487. could inherit functions from Employee like hire and 
  7488. name, while defining unique functions like 
  7489. hoursflown and status. 
  7490.   
  7491.   
  7492. Multiple Inheritance 
  7493. Functions defined on a type can be inherited by one 
  7494. or more subtypes. In Figure 5, functions accessible 
  7495. by the type ManagingPilot are inherited from its 
  7496. parents, namely all functions defined on Employee, 
  7497. Pilot and Manager. By inheriting rather than 
  7498. redefining functions, you can easily add 
  7499. functionality to your application. 
  7500.   
  7501. OSQL 
  7502. If you already know SQL, you can quickly be 
  7503. productive using Odapter's OSQL. Both query 
  7504. languages are set-based, that is they retrieve sets 
  7505. of information based upon queries. Thus, OSQL does 
  7506. not require users to navigate through the database 
  7507. chasing pointers or object references. 
  7508.   
  7509. Encapsulation 
  7510. Odapter protects end-user applications from changes 
  7511. to the internal definition of objects. Since 
  7512. Odapter only allows access to data through 
  7513. functions with well defined arguments and results, 
  7514. your applications are protected from changes to the 
  7515. function body and you have control over how 
  7516. information is used. 
  7517.   
  7518. Aggregate Types 
  7519. Aggregates are used to represent collections, such 
  7520. as crew members (maybe several pilots, flight 
  7521. attendants and a mechanic) for a particular flight, 
  7522. or the employees reporting to a particular manager. 
  7523. Aggregates are not required to have a predetermined 
  7524. size. Odapter manages the memory associated with 
  7525. aggregates, relieving your application of this 
  7526. work. 
  7527.   
  7528. User-defined Data Types 
  7529. You can construct user-defined data types in 
  7530. Odapter, such as a type called Flight, Employee or 
  7531. Aircraft, as shown in Figure 6. Functions defined 
  7532. on these types can manipulate data stored within 
  7533. the current object, within other related objects or 
  7534. outside of Odapter. User-defined types maximize 
  7535. flexibility and lead to more manageable, clearer 
  7536. code. 
  7537.   
  7538. Complex Objects 
  7539. With Odapter you can construct complex objects from 
  7540. simpler objects. For example, Figure 6 shows the 
  7541. relationships between the types Flight, Aircraft 
  7542. and Employee.  Complex objects relieve applications 
  7543. from managing such relationships. 
  7544.   
  7545.   
  7546. Reduces the Cost of Keeping Applications Current 
  7547.   
  7548. Odapter supports a server-centric business model 
  7549. which means the business logic and associated data 
  7550. is sharable by multiple applications. By separating 
  7551. out business objects (data and processes), from the 
  7552. application development environment, your company's 
  7553. business can be modified without impacting the 
  7554. applications. These changes can be immediately 
  7555. leveraged by the calling applications without 
  7556. recompilation 
  7557.   
  7558. The following features make applications easier to 
  7559. keep current: 
  7560.   
  7561. External Functions 
  7562. Using external functions, you can access 
  7563. distributed data and code stored outside of the 
  7564. relational database used by Odapter for storage, 
  7565. regardless of location or data format. Examples of 
  7566. external data sources include IMS, DB2 as well as 
  7567. custom databases and flat files. Odapter acts as an 
  7568. integrator so your application can manipulate 
  7569. information as recognizable business objects. This 
  7570. not only allows transparent migration of data over 
  7571. time, it accelerates developer productivity by 
  7572. hiding the complexity of a diverse data storage 
  7573. environment. 
  7574.   
  7575. Overloaded Functions 
  7576. Multiple functions can have the same name with 
  7577. different implementations. An application calls a 
  7578. function (e.g. salary) and Odapter determines at 
  7579. run-time which code (salary for Manager or salary 
  7580. for Pilot) to execute, based upon the type of the 
  7581. object against which the function is invoked. The 
  7582. application is simplified since the conditional 
  7583. logic for determining which function to execute is 
  7584. now in Odapter. 
  7585.   
  7586. Dynamic Schema Modification 
  7587. Odapter object models can be modified while the 
  7588. database is running. Developers can add new 
  7589. functions and types, as well as change the 
  7590. implementation of functions. This capability is 
  7591. particularly valuable to applications with high 
  7592. availability requirements. 
  7593.   
  7594. Dynamic Typing 
  7595. You can change the type of an object without 
  7596. destroying and recreating the object. An object can 
  7597. also belong to more than one type. As shown in 
  7598. Figure 7, once a Flight leaves the ground, it would 
  7599. change state from being an OnGround to an InAir 
  7600. Flight. OnGround functions such as maintenancecrew 
  7601. and availableseats would no longer be needed. An 
  7602. InAir object would need certain functions like 
  7603. bestroute and delay to calculate the most time 
  7604. efficient route and to calculate a projected delay 
  7605. based current weather conditions. Dynamic Typing 
  7606. allows you to represent an object in Odapter which 
  7607. transforms itself over time and, therefore, changes 
  7608. capabilities and attributes. 
  7609.   
  7610. Late Binding 
  7611. Odapter supports functions that are resolved at 
  7612. runtime. Late binding allows you more flexibility 
  7613. in application development and gives you the full 
  7614. power of overloaded functions as described earlier. 
  7615. On the other hand, Odapter will precompile or do 
  7616. early binding to improve performance. However, when 
  7617. types and functions changes at runtime, impacting a 
  7618. particular function, late binding occurs and the 
  7619. application automatically takes advantage of the 
  7620. new implementation of the function when it is 
  7621. called. 
  7622.   
  7623. Referential Integrity 
  7624. Since Odapter manages the relationships between 
  7625. objects, it can manage referential integrity on 
  7626. your behalf. That is, if an object referenced by 
  7627. other objects is deleted, the system removes all 
  7628. dependencies.  Your application code is simplified 
  7629. since Odapter is able to keep the logical business 
  7630. model intact automatically. 
  7631.   
  7632. Multimedia 
  7633. Odapter allows you to manage large, unformatted 
  7634. data in binary format and treat that data as an 
  7635. attribute of an object. For example, you may want 
  7636. to create a function called diagram to show the 
  7637. sections and seating for an Aircraft object. 
  7638. Multimedia information can include graphics, images 
  7639. and voice. You can also define functions in Odapter 
  7640. to manipulate this multimedia information. For 
  7641. example, you can create a function called showexits 
  7642. that adds information to the diagram. Thus, various 
  7643. applications can share these complex functions. 
  7644.   
  7645. Import Facility 
  7646. The Odapter Import facility allows developers to 
  7647. update existing Odapter functions with data from 
  7648. external files such as spreadsheets or other 
  7649. databases. This is an object-oriented version of 
  7650. the relational "bulk load" functionality. 
  7651.   
  7652. Enables Applications to Scale 
  7653.   
  7654. Odapter makes applications more scalable by storing 
  7655. objects in a choice of RDBMSs, like ORACLE7. As a 
  7656. result, applications can access large volumes of 
  7657. data, be used by a large numbers of users, and 
  7658. perform on-line backup. In addition, Odapter 
  7659. protects against unauthorized access from users in 
  7660. a distributed environment. 
  7661.   
  7662. Odapter, with the help of the underlying relational 
  7663. storage manager, ensures the integrity and security 
  7664. of your data while maximizing the availability of 
  7665. that data for end users. 
  7666.   
  7667. The following features enable applications to 
  7668. scale: 
  7669.   
  7670. Indexing 
  7671. Indexes are automatically generated when you create 
  7672. types and functions in Odapter. You can also define 
  7673. your own indexes using B-tree and hashing 
  7674. algorithms. Indexes make end user access to 
  7675. information faster. 
  7676.   
  7677. Clustering 
  7678. Related functions and objects which have the same 
  7679. value for a function can be stored close to each 
  7680. other. This ability to influence how objects are 
  7681. stored allows you to tune the performance of the 
  7682. database based on how the information will be 
  7683. accessed by applications. 
  7684.   
  7685. Transaction Management 
  7686. Odapter ensures the logical and physical integrity 
  7687. of your database by giving you complete control 
  7688. over the unit of work to be performed within a 
  7689. single transaction. With this control, you can save 
  7690. or rollback a transaction (throw away temporary 
  7691. work) at your discretion. Savepoints are also 
  7692. supported so that you can rollback parts of a 
  7693. transaction. 
  7694.   
  7695. Multi-user Concurrency Control 
  7696. Odapter is designed to support hundreds of users 
  7697. accessing the same information while guaranteeing 
  7698. the integrity of that information. 
  7699.   
  7700. Authorization 
  7701. You can control access to an Odapter enhanced 
  7702. database at the database and function levels based 
  7703. on individuals or groups of users. For example, 
  7704. authorization statements can provide read access to 
  7705. a large group of users while limiting write or 
  7706. delete access. 
  7707.   
  7708. High Availability 
  7709. Because Odapter actually stores objects in an 
  7710. RDBMS, Odapter can leverage RDBMS features to 
  7711. maximize the availability of your information by 
  7712. providing: 
  7713. * on-line backup of the database, to backup the 
  7714. database while it is being accessed 
  7715. * dual logging, to ensure the integrity of your 
  7716. log file 
  7717. * switch log, to automatically switch to a 
  7718. second log file if the original log file becomes 
  7719. full 
  7720. * dynamic file expansion, to expand the size of 
  7721. your database as it becomes full 
  7722.   
  7723. Odapter will also take advantage of other available 
  7724. features of the underlying relational database 
  7725. management system such as replication or "warm 
  7726. standby". 
  7727.   
  7728. Recovery 
  7729. Odapter uses the robust logging and recovery 
  7730. facilities of the RDBMS. In case of a failure, you 
  7731. can rollback work or perform rollforward recovery 
  7732. to a particular time, using the log file to 
  7733. recreate saved work. 
  7734.   
  7735. Odapter  Software Components 
  7736.   
  7737. Odapter uses a client/server architecture, enabling 
  7738. you to efficiently utilize your computing power. 
  7739. Clients use the object application call interface 
  7740. (OACI) to communicate with the server over the 
  7741. network. The clients and server components can also 
  7742. reside on the same machine. 
  7743.   
  7744. Odapter is bundled with the following client and 
  7745. server components, as shown in Figure 8: 
  7746.   
  7747. Client Components 
  7748.   
  7749. * Interactive Object-Oriented SQL (IOSQL) 
  7750. This interface allows you to interactively enter 
  7751. all Object-oriented SQL (OSQL) statements, 
  7752. facilitating rapid prototyping and testing. IOSQL 
  7753. provides query, administration and editing 
  7754. capabilities. 
  7755.   
  7756. * Graphical Browser (GOSQL) 
  7757. The Graphical Browser is a tool that allows you to 
  7758. graphically explore your database schema and 
  7759. contents, and execute any OSQL statement. This tool 
  7760. is designed to assist application developers by 
  7761. making it easier to view and manipulate your object 
  7762. model stored in Odapter. 
  7763.   
  7764. * Windows OSQL (WINOSQL) 
  7765. This PC-based interactive interface to OSQL allows 
  7766. you to interactively enter all OSQL statements. 
  7767.   
  7768. * Object Application Call Interfaces (OACI) 
  7769. Odapter provides client interface libraries for the 
  7770. Smalltalk and C++ object-oriented programming 
  7771. languages, allowing these languages to be tightly 
  7772. coupled with Odapter. 
  7773.   
  7774. You can also write Odapter applications using any 
  7775. programming language that can be linked with C 
  7776. (such as Ada, COBOL, FORTRAN and Pascal). The 
  7777. programmatic interface is similar to a "Dynamic 
  7778. SQL" interface, and passes strings representing 
  7779. OSQL statements to the Odapter server. No 
  7780. preprocessors are required. 
  7781.   
  7782. Server Components 
  7783.   
  7784. * Odapter Object Manager 
  7785. The Object Manager executes OSQL calls made by the 
  7786. Odapter clients. The Object Manager processes 
  7787. requests, and accesses data and code stored in the 
  7788. Odapter enhanced relational data storage manager or 
  7789. passes the request to a subsystem outside of 
  7790. Odapter using Odapter External Functions. 
  7791.   
  7792. * External Functions 
  7793. External functions allow you to access data and 
  7794. code stored outside of Odapter, regardless of data 
  7795. format or location. External functions can 
  7796. automatically link to specific data sources using 
  7797. the Odapter EDA-Objects class library and the 
  7798. EDA/SQL product from Information Builder's, Inc. 
  7799. (IBI). External functions can also be implemented 
  7800. by you as subroutines written in general-purpose 
  7801. programming languages and compiled outside of 
  7802. Odapter. External functions can be called by any 
  7803. OSQL statement, allowing you to manipulate this 
  7804. remote data and application code like any other 
  7805. Odapter object. For example, Figure 9 shows how 
  7806. Odapter integrates diverse heterogeneous 
  7807. information in an Oil and Gas environment. 
  7808.   
  7809. * EDA-Objects 
  7810. HP and IBI have jointly developed an external 
  7811. function library called EDA-Objects. Coupled with 
  7812. IBI's EDA/SQL product, EDA-Objects provides 
  7813. connections to over 50 commonly used databases on 
  7814. 35 different platforms. The external function 
  7815. library to connect to EDA/SQL is shipped with 
  7816. Odapter; however, you must purchase other EDA/SQL 
  7817. components from IBI directly to use the product. 
  7818. EDA-Objects is one way to integrate external data 
  7819. from multiple servers into a single business model 
  7820. managed by Odapter. This is done without physically 
  7821. moving the data or changing the applications which 
  7822. are dependent on the data in its current form. 
  7823.   
  7824. Additional Products 
  7825.   
  7826. * Development Environments and Tools 
  7827. Odapter allows you to use your favorite development 
  7828. environments for application development. Some 
  7829. tools are more tightly coupled with Odapter than 
  7830. others. HP has recruited tools partners to address 
  7831. all aspects of application development including 
  7832. application design and analysis, data model 
  7833. manipulation, fourth generation language 
  7834. application development, report writing and legacy 
  7835. data access. 
  7836.   
  7837. * Relational Database 
  7838. Odapter uses a relational database as its storage 
  7839. manager for the storage of Odapter objects. The 
  7840. relational database performs physical file 
  7841. management and database functions such as multi- 
  7842. user concurrency, transaction management, and 
  7843. recovery. The relational database allows you to 
  7844. perform on-line backup and recovery, manage 
  7845. physical distribution of files, maximize 
  7846. availability and change database parameters. 
  7847.   
  7848. * COMPASS 
  7849. COMPASS is a consulting product which includes the 
  7850. Hewlett-Packard implementation of the 
  7851. Petrotechnical Open Software Corporation (POSC) 
  7852. Software Integration Platform (SIP) specification. 
  7853. The SIP specification defines a data model and an 
  7854. interface which allow users and applications to 
  7855. access exploration and production data, independent 
  7856. of the database engine technology. 
  7857.   
  7858. The COMPASS package is an add-on to Odapter and 
  7859. includes: 
  7860. * COMPASS specific consulting/training (1 day) 
  7861. * POSC-based DAE interface library and documentation 
  7862. * Interactive user interface called ixpres 
  7863. * Archived copy of a pre-loaded Odapter 
  7864. enhanced database with sample reference data 
  7865. * Scripts for building a POSC-based Odapter 
  7866. enhanced database 
  7867. * Contributed software library (data loaders, 
  7868. demonstration programs) 
  7869.   
  7870. COMPASS gives developers a 'jump start' on building 
  7871. applications focused on petroleum exploration and 
  7872. production. Other industries will find COMPASS an 
  7873. inexpensive and useful approach for building 
  7874. geographic information systems (GIS) and other 
  7875. applications which can re-use of the cartography 
  7876. (mapmaking) and geometric objects defined in the 
  7877. model. 
  7878.   
  7879. POSC is a not-for profit organization created to 
  7880. lower the costs associated with accessing and 
  7881. integrating exploration and production data for the 
  7882. oil and gas industry. 
  7883.   
  7884. System Environment 
  7885.   
  7886. Hardware       Operating    Memory      Disk Space 
  7887. platform       System       (minimum)   (minimum)* 
  7888.   
  7889. HP 9000 S700   HP-UX 8.07   32MB        10MB + 
  7890. S800           or later                 necessary 
  7891.                                         swap space 
  7892.   
  7893. Sun            Solaris 1.0  32MB        10MB + 
  7894.                (SunOS 4.3);             necessary 
  7895.                Solaris 2.0              swap space 
  7896.                (SunOS 5.2) 
  7897.   
  7898. IBM RS/6000    AIX 3.2.5    32MB        10MB + 
  7899.                                         necessary 
  7900.                                         swap space 
  7901.   
  7902. X Terminal                  6MB         none 
  7903.   
  7904. IBM PC         DOS 5.0,     4MB         1MB 
  7905. compatible     MS-Windows 
  7906.                3.1 or later 
  7907. Table 1:  Odapter Client Environments 
  7908.   
  7909. * Swap space needed will depend on the complexity 
  7910. of the application and the number of concurrent 
  7911. users. Swap space will significantly increase the 
  7912. necessary disc space. 
  7913.   
  7914. Hardware       Operating    Memory      Disk Space 
  7915. platform       System       (minimum)   (minimum)* 
  7916.   
  7917. HP 9000 S700   HP-UX 9.0    64MB        15MB + 
  7918. S800           or later                 necessary 
  7919.                                         swap space 
  7920. Table 2:  Odapter Server Environment 
  7921.   
  7922. * Additional memory may be required. Swap space 
  7923. will significantly increase the necessary disc 
  7924. space. The amount of memory and swap space depends 
  7925. on the complexity of the application and the number 
  7926. of concurrent users. 
  7927.   
  7928. Odapter Software Requirements 
  7929.   
  7930. To use Odapter, you will need one of the RDBMSs 
  7931. listed below, TCP/IP transport and ARPA Berkeley 
  7932. Services (for Unix systems), HP LAN Manager or 
  7933. Microsoft LAN Manager (for the PC client) software. 
  7934. To use the Odapter Graphical Browser, you will need 
  7935. X11 X-Window support. 
  7936.   
  7937. Table 3: Relational Databases 
  7938.   
  7939.             Version          Memory      Disk Space 
  7940.                              (minimum)   (minimum) 
  7941.   
  7942. ORACLE7     7.0.13 or later  refer to    refer to 
  7943.             with "procedural Oracle      Oracle 
  7944.             option" (PL/     manuals     manuals 
  7945.             SQL), Pro*C, 
  7946.             SQL*Plus & Oracle 
  7947.             common libraries and 
  7948.             utilities 
  7949.   
  7950. ALLBASE/SQL shipped with     64MB A/SQL  10MB 
  7951.             OpenODB          and Odapter 
  7952.   
  7953. * ALLBASE/SQL is included with the Odapter 
  7954. software. The combination of Odapter and 
  7955. ALLBASE/SQL is known as OpenODB. 
  7956.   
  7957.   
  7958. Ordering Information 
  7959.   
  7960. Software, training, consulting and support can be 
  7961. purchased separately, as well as in bundles. 
  7962. Pricing for the stand-alone software is based on 
  7963. the number of user processes accessing a single 
  7964. database server at the same time. Any number of 
  7965. user licenses can be ordered. You must also order 
  7966. the Odapter Media & Manuals product when ordering 
  7967. the Developer's Bundle or the Concurrent User 
  7968. License. HP standard support options are available 
  7969. for all Odapter license and media products. 
  7970. The OpenODB and Odapter products are sold together. 
  7971. OpenODB is the combination of Odapter and 
  7972. ALLBASE/SQL. You are only limited by the number of 
  7973. concurrent licenses purchased for Odapter. 
  7974.   
  7975. Product Number and Product Description 
  7976.   
  7977. B3767BB  Odapter/OpenODB Concurrent User License 
  7978. Software license only. Must order B3768BA to 
  7979. receive software and manuals. Must specify number 
  7980. of users. 
  7981.   
  7982. B3768BA  Odapter/OpenODB Media and Manuals  Must 
  7983. choose media option. Includes software and one set 
  7984. of manuals. Requires prior or concurrent purchase 
  7985. of software license. 
  7986.   
  7987. B2470BA  Odapter/OpenODB Developer's Bundle 
  7988. Includes 8 user software license, 5 days of on- 
  7989. your-site consulting, one year of on-line support 
  7990. and 2 passes to the Odapter/OpenODB Training Class. 
  7991. Must order B3768BA to receive software and manuals. 
  7992.   
  7993. B3179A  Odapter/OpenODB Evaluator's Bundle 
  7994. Includes a 40 user software license for 3 months, 
  7995. media, documentation, 3 months of on-line support, 
  7996. and 1 pass to the Odapter/OpenODB Training Class. 
  7997.   
  7998. B3184S  Odapter/OpenODB Training Class (5 days) 
  7999.   
  8000. B3185A  Odapter/OpenODB Reference Manuals  Includes 
  8001. the Odapter/OpenODB Reference Manual and the 
  8002. Odapter/OpenODB System Functions Manual. 
  8003.   
  8004. B3186A  Odapter/OpenODB Consulting  Customized 
  8005. consulting in any of the following areas: COMPASS, 
  8006. object-oriented analysis and design, schema design 
  8007. and review, authorization/security design and 
  8008. review, performance tuning, advanced usage, 
  8009. Odapter/OpenODB application development planning 
  8010. and review and implementation of access to legacy 
  8011. data sources. 
  8012.   
  8013. To order these products, please contact your local 
  8014. HP sales representative or one of the offices on 
  8015. the back page of this document. 
  8016.   
  8017. Table 5. Odapter Features 
  8018.   
  8019. OBJECT-ORIENTED FEATURES 
  8020. Aggregates (BAG, LIST, SET, TUPLE) 
  8021. Complex Objects 
  8022. Dynamic Schema Modification 
  8023. Dynamic Typing 
  8024. Encapsulation 
  8025. External Functions 
  8026. Functions (Stored Code or Methods) 
  8027. Late Binding 
  8028. Multiple Inheritance 
  8029. Object Identity (OID) 
  8030. Overloaded Functions 
  8031. Type (Class) Hierarchy 
  8032. User-defined Data Types 
  8033. Versioning Primitives 
  8034.   
  8035. CLASS LIBRARIES 
  8036. C++ 
  8037. EDA-Objects 
  8038. Smalltalk 
  8039. Softbench 
  8040.   
  8041. CLIENT INTERFACES 
  8042. Graphical Browser (GOSQL) 
  8043. Import 
  8044. Interactive OSQL 
  8045. Object Application Call Interfaces (OACI): 
  8046.   C++ 
  8047.   SmallTalk 
  8048.   C-linkable languages  (Ada, COBOL, FORTRAN, 
  8049. Pascal) 
  8050. Smalltalk Class Builder 
  8051. Windows OSQL 
  8052.   
  8053. OSQL STATEMENTS 
  8054. Add/Remove Type To/From Object 
  8055. Add/Remove User 
  8056. Begin/Commit/Rollback Work 
  8057. Call Function 
  8058. Change Owner 
  8059. Change Password 
  8060. Connect/Disconnect 
  8061. Create/Delete Function 
  8062. Create/Delete Index 
  8063. Create/Delete Object 
  8064. Create/Delete Type 
  8065. Create/Delete User/Group 
  8066. Declare/Delete variables 
  8067. Grant/Revoke 
  8068. If/Then/Else, While, For 
  8069. Implement/Modify Function 
  8070. Open/Fetch/Close Cursor 
  8071. Raise Error 
  8072. Security On/Off 
  8073. Savepoint 
  8074. Select 
  8075. Store 
  8076. Update 
  8077.   
  8078. PRIMITIVE DATA TYPES 
  8079. Binary 
  8080. Boolean 
  8081. Character 
  8082. Date 
  8083. Datetime 
  8084. Decimal 
  8085. Floating Point 
  8086. Integer 
  8087. Interval 
  8088. Small Integer 
  8089. Time 
  8090.   
  8091. Sales Offices 
  8092. For more information, call you local sales office 
  8093. listed in your telephone directory or an HP 
  8094. regional office listed below for the location of 
  8095. your nearest sales office. 
  8096.   
  8097. United States: 
  8098. 1-800-637-7740, extension 8521 
  8099.   
  8100. Canada: 
  8101. Hewlett-Packard Ltd. 
  8102. 6877 Goreway Drive 
  8103. Mississauga, Ontario L4V 1M8 
  8104. (416) 678-9430 
  8105.   
  8106. Japan: 
  8107. Yokogawa-Hewlett-Packard Ltd. 
  8108. 15-7, Nishi Shinjuku 4 Chome 
  8109. Shinjuku-ku 
  8110. Tokyo 160, Japan 
  8111. (03) 5371-1351 
  8112.   
  8113. Latin America: 
  8114. Hewlett-Packard 
  8115. Latin American Region 
  8116. Headquarters 
  8117. 5200 Blue Lagoon 
  8118. Suite 950 
  8119. Miami, FL 33126 
  8120. (305) 267-4220 
  8121.   
  8122. Australia New Zealand: 
  8123. Hewlett-Packard Australia Ltd. 
  8124. 31-41 Joseph Street 
  8125. Blackburn, Victoria 3130 
  8126. Australia (A.C.N. 004 394 763) 
  8127. (03) 895 2805 
  8128.   
  8129. Asia Pacific: 
  8130. Hewlett-Packard Asia Ltd. 
  8131. 22/F Bond Centre, West Tower 
  8132. 89 Queensway 
  8133. Central, Hong Kong 
  8134. (852) 848-7777 
  8135.   
  8136. Europe/Africa/Middle East: 
  8137. Hewlett-Packard S.A. 
  8138. 150, Route du Nant-d'Avril 
  8139. CH-1217 Meyrin 2 
  8140. Geneva, Switzerland 
  8141. (22) 780 81 11 
  8142.   
  8143. Technical information in this document is subject 
  8144. to change without notice. 
  8145. All brand and product names appearing herewith are 
  8146. registered trademarks or trademarks of their 
  8147. respective holders. 
  8148.   
  8149. ` Copyright Hewlett-Packard Company 1994.  All 
  8150. rights reserved.  Reproduction , adaptation, or 
  8151. translation without prior written permission is 
  8152. prohibited except as allowed under the copyright 
  8153. law. 
  8154. Printed in USA 7/94 
  8155. 5963-2045E
  8156.  
  8157.  
  8158. For more information, please send a message to 
  8159. odapter@cup.hp.com with the subject of "index" or
  8160. "help".  If you would like to speak with someone
  8161. in person, please leave a voice mail message at
  8162. the Odapter Support, Training and Consulting number,
  8163. (408) 447-5051 and someone will get back to you
  8164. as soon as possible.
  8165.  
  8166.  
  8167. > POET <Persistent Objects and Extended Database Technology>  (BKS Software)
  8168.  
  8169. C++ Language Support
  8170.  
  8171. o    tight semantic integration with C++
  8172. o    any C++ object or structure can be made persistent by adding the 
  8173.      persistent keyword
  8174. o    storing and reading a C++ object does not change its state or behavior
  8175. o    full support for C++ encapsulation, object identity,  inheritance, and 
  8176.      polymorphy
  8177. o    C++ pointers and references are automatically converted to database 
  8178.      references when storing objects
  8179. o    database references are automatically converted to C++ pointers and 
  8180.      references when reading objects
  8181. o    all database definition is done through a small extension to C++ 
  8182.      declaration syntax
  8183.  
  8184. Database Functionality
  8185. navigation, queries, sorting, indexes, single-user operation, multi-user
  8186. operation using client/server architecture, flexible locking for objects
  8187. and sets, nested transactions, watch & notify for objects and sets,
  8188. event handling, database size limited only by hard disk size
  8189.  
  8190. C++ Language Extensions
  8191. persistence, indexes, transient data elements in persistent classes, sets,
  8192. dependent objects
  8193.  
  8194. PTXX-Precompiler
  8195. automatically converts extended C++ class declarations into ANSI 2.0 code,
  8196. registers classes in the class dictionary, provides class versioning
  8197.  
  8198. Predefined C++ Classes
  8199. date, time, strings, and BLOBS (binary large objects)
  8200.  
  8201. Portability
  8202. all platforms are source-code compatible, any POET database may be read by
  8203. any computer full support for heterogeneous networks
  8204.  
  8205. Platforms
  8206. Available for MS-DOS / MS-Windows (Borland C++, Microsoft), 
  8207. OS/2 (Borland C++), Novell, Macintosh MPW, and various Unix 
  8208. systems, including NeXT (NeXTStep) and Sun OS (Sun C++).
  8209.  
  8210. How to Contact Us:
  8211. BKS has offices in Santa Clara, Hamburg, and Berlin.  Silicon 
  8212. River, Limited, is responsible for POET in the United Kingdom.  
  8213.  
  8214. Santa Clara:    (North America, Australia, Asia)
  8215.  
  8216. BKS Software
  8217. 4633 Old Ironsides Drive  Suite 110
  8218. Santa Clara, CA 95054
  8219. Phone:  415/286-4640
  8220.  
  8221. Contact Person: jrobie@netmbx.netmbx.de (Jonathan Robie)
  8222.  
  8223.  
  8224. > Statice (Symbolics)
  8225.  
  8226. From: fischerm@darmstadt.gmd.de (Markus Fischer)
  8227. Newsgroups: comp.databases.object,comp.lang.lisp
  8228. Subject: Statice now runs on Unix
  8229. Date: 15 Jun 93 14:55:48 GMT
  8230.  
  8231. Hi there,
  8232.  
  8233. since I've never seen 'Symbolics' or 'Statice' in
  8234. comp.database.object, this might be interesting:
  8235.  
  8236. A few days ago, Symbolics announced the availability of a beta-
  8237. release of their ODBMS 'Statice' on Unix platforms. It is quite
  8238. powerful and tightly integrated within Common Lisp.
  8239. Currently, Symbolics and LUCID are supported.
  8240. People (like me) used to Symbolics' Genera development environment 
  8241. can continue to use Statice there (where it has been already
  8242. successfully employed in 'real world' applications)
  8243. and now also use it on Unix Workstations.  (Those are the cheaper
  8244. boxes, I guess). Both kinds of platforms can be freely intermixed
  8245. in a network.
  8246.  
  8247. Statice is based on standards of Lisp: CLOS and CLIM 
  8248. (Common Lisp Object System, resp. Common Lisp Interface Manager)
  8249.  
  8250. Here's the address of Symbolics in Germany; they're mostly 
  8251. responsible for Statice on Unix:
  8252.  
  8253. Symbolics Systemhaus GmbH
  8254. Mergenthalerallee 77
  8255. 6236 Eschborn (til June 31)
  8256. 65760 Eschborn (from July 1)
  8257. Tel. (49) 6196-47220, Fax (49) 6196-481116
  8258.  
  8259. Contact person is Dr. Thomas Neumann (TN@symbolics.de).
  8260.  
  8261. Also:
  8262.  
  8263. "Update Database Schema" brings an existing database into conformance
  8264. with a modified schema.  Changes are classified as either compatible
  8265. (lossless, i.e., completely information-preserving) or incompatible
  8266. (i.e., potentially information-losing in the current implementation).
  8267. Basically, any change is compatible except for the following:
  8268.  
  8269.     -- If an attribute's type changes, all such attributes extant
  8270.     are re-initialized (nulled out).  Note that Statice permits
  8271.     an attribute to be of type T, the universal type.  Such an
  8272.     attribute can then take on any value without schema
  8273.     modification or information loss.
  8274.  
  8275.     -- If a type's inheritance (list of parents) changes, the
  8276.     type must be deleted and re-created, losing all extant
  8277.     instances of that type. This is Statice's most serious
  8278.     current limitation.  The simplest workaround is to employ a
  8279.     database dumper/loader (either the one supplied by Symbolics
  8280.     or a customized one) to save the information elements and
  8281.     then reload them into the modified schema.
  8282.  
  8283. [Lawrence G Mayka <lgm@IExist.ATT.COM>]
  8284.  
  8285.  
  8286. > UniSQL
  8287.  
  8288. UniSQL offers a state-of-the-art suite of integrated object-oriented database
  8289. systems and application development products which can be used separately or
  8290. together to support complex development projects which use object-oriented
  8291. development techniques, integrate sophisticated multimedia data, and require
  8292. true multidatabase access to relational and object-oriented databases. The
  8293. UniSQL product suite includes:
  8294.  
  8295.         UniSQL/X Database Management System;
  8296.         UniSQL/M Multidatabase System; and
  8297.         UniSQL/4GE Application Development Environment
  8298.         User interfaces include: C++, C, Object SQL, SmallTalk, and ODBC
  8299.         Database interfaces include: Ingres, Oracle, Sybase, UniSQL/X, and EDA/SQL
  8300.  
  8301. UniSQL offers:
  8302.  
  8303. - A wide selection of user interfaces including C++, SmallTalk, C, Microsoft's
  8304.   ODBC, both embedded (static and dynamic) and interactive Object SQL, and UniSQL
  8305.   and 3rd-party development tools.
  8306.  
  8307. - Mission-critical database features such as a high-level query language
  8308.   (SQL/X), cost-based query optimization, automatic transaction management,
  8309.   automatic concurrency control, dynamic schema evolution, dynamic authorization,
  8310.   physical disk structuring options, and installation tuning parameters.
  8311.  
  8312. - The UniSQL Multimedia Framework which provides natural and uniform database
  8313.   system support for all types of large unstructured data objects. The Multimedia
  8314.   Framework also provides for seamless integration of multimedia devices such as
  8315.   fax machines, CD jukeboxes, satellite feeds, image compression boards, etc.
  8316.  
  8317. - The UniSQL/M Multidatabase System enables developers to manage a collection
  8318.   of multi-vendor databases -- Ingres, Oracle, Sybase, DB2, UniSQL/X, and others
  8319.   -- as a single federated database system with full object-oriented
  8320.   capabilities.
  8321.  
  8322. UniSQL has well over 150 customers around the world, the majority of which are
  8323. using UniSQL database products for mission-critical applications which require
  8324. object-oriented, multimedia, post-relational, and heterogeneous database
  8325. capabilities.
  8326.  
  8327. A typical UniSQL customer is a Fortune 500 company, a commercial software
  8328. developer, or government organization that is using UniSQL database products
  8329. to:
  8330.  
  8331. - support mission-critical application development projects which are being
  8332.   developed using object-oriented programming languages and development
  8333.   techniques,
  8334.  
  8335. - support applications which must integrate many different types of corporate
  8336.   data -- text and documents, tabular data, images and audio, engineering
  8337.   drawings, GIS data, procedural data (programs), etc. -- into a single
  8338.   application context.
  8339.  
  8340. - support the full object-oriented development paradigm using existing
  8341.   relational database systems such as Ingres, Oracle, Sybase, and DB2.
  8342.  
  8343. - logically integrate one or more relational and object-oriented databases to
  8344.   form a single, homogenized database server which supports both relational and
  8345.   object-oriented facilities.
  8346.  
  8347. In September 1992, UniSQL was selected by the Petrotechnical Open Software
  8348. Corporation (POSC) -- over more than 25 other industry vendors -- to provide
  8349. database technology which is being used by POSC in their development of a new
  8350. data management specification for the oil & gas industry. Also during 1992,
  8351. because of its powerful multimedia capabilities, UniSQL was selected by the MIT
  8352. AthenaMuse Consortium on multimedia as the consortium's multimedia database
  8353. system.
  8354.  
  8355. During the DB/EXPO '93 Conference and Exhibition, UniSQL was chosen in
  8356. competition with major industry database vendors as a finalist in the
  8357. ``RealWare Awards''.  The ``RealWare Awards'' honor companies that have
  8358. had a major impact in the user community.
  8359.  
  8360. UniSQL was founded in May 1990 by Dr. Won Kim, President and CEO, delivering
  8361. the UniSQL/X DBMS in March of 1992. With its world-class database research and
  8362. architectural team, UniSQL has perfected what the database industry has sought
  8363. since the mid-1980s: a fully object-oriented data model that is a natural
  8364. conceptual outgrowth of the popular relational model. Both the UniSQL/X DBMS
  8365. and the UniSQL/M Multidatabase System represent the first of a powerful new
  8366. generation of client-server database systems that support the full
  8367. object-oriented paradigm yet retain all of the strengths and capabilities of
  8368. relational database systems including support for ANSI-standard SQL.
  8369.  
  8370. UniSQL currently has 45 employees and is privately owned and managed by Dr.
  8371. Kim. The company has secured long-term funding from NTT Data Communications
  8372. Systems Corp. (NTT Data), a $2 billion company, which is Japan's foremost
  8373. systems integrator and UniSQL's exclusive distributor in Japan.
  8374.  
  8375. For more information, contact:
  8376.  
  8377.         UniSQL, Inc.
  8378.         9390 Research Blvd., II-200
  8379.         Austin, Texas 78759-6544
  8380.         Tel.: 512/343-7297
  8381.         Tollfree: 800/451-DBMS
  8382.         Fax.: 512/343-7383
  8383.  
  8384. And:
  8385. From: jonh@unisql.UUCP (Jon Higby)
  8386. Newsgroups: comp.databases,comp.databases.theory,comp.databases.object,comp.object
  8387. Subject: Re: SQL3, Itasca, & UniSQL/X
  8388. Message-ID: <6143@unisql.UUCP>
  8389. Date: 10 Sep 93 14:26:04 GMT
  8390. References: <CD1Ln5.9G3@dcs.glasgow.ac.uk>
  8391. Organization: UniSQL, Inc., Austin, Texas, USA
  8392.  
  8393. >>...
  8394. For UniSQL/X, feel free to contact me (email, snail-mail or phone).
  8395.  
  8396. UniSQL/X is a SQL compliant database with Object Oriented extensions
  8397. (classes, inheritance, methods, etc).  We have an information packet
  8398. available which includes a white-paper on our OORDMS approach.
  8399.  
  8400. Jon Higby
  8401. Technical Services Consultant
  8402.  
  8403. UniSQL, Inc.
  8404. 9390 Research II, Suite 200
  8405. Austin, Texas  78759-6544
  8406. (512) 343-7297
  8407.  
  8408. *****************************************************************************
  8409. Standard disclaimer ... All opinions expressed are my own and not of my 
  8410.                         employer.......................................
  8411. *****************************************************************************
  8412.  
  8413. ############################################################################
  8414.  
  8415.  
  8416. Path: senator-bedfellow.mit.edu!faqserv
  8417. From: Bob Hathaway <rjh@geodesic.com>
  8418. Newsgroups: comp.object,comp.answers,news.answers
  8419. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Part 8/13
  8420. Supersedes: <object-faq/part8_805979999@rtfm.mit.edu>
  8421. Followup-To: comp.object
  8422. Date: 31 Aug 1995 15:32:46 GMT
  8423. Organization: Geodesic Systems
  8424. Lines: 1314
  8425. Approved: news-answers-request@MIT.Edu
  8426. Distribution: world
  8427. Expires: 14 Oct 1995 15:31:54 GMT
  8428. Message-ID: <object-faq/part8_809883114@rtfm.mit.edu>
  8429. References: <object-faq/part7_809883114@rtfm.mit.edu>
  8430. NNTP-Posting-Host: bloom-picayune.mit.edu
  8431. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  8432. X-Last-Updated: 1995/06/01
  8433. Originator: faqserv@bloom-picayune.MIT.EDU
  8434. Xref: senator-bedfellow.mit.edu comp.object:37590 comp.answers:13978 news.answers:51859
  8435.  
  8436. Archive-name: object-faq/part8
  8437. Last-Modified: 05/31/94
  8438. Version: 1.0.8
  8439.  
  8440.  
  8441.  
  8442. > Versant (Versant Object Technology)
  8443.  
  8444.   See also: http://www.versant.com
  8445.  
  8446. Versant is a client/server object database management system (ODBMS) targeted at
  8447. distributed, multi-user applications.  Versant runs on UNIX and PC platforms, 
  8448. including Sun, IBM, HP, DEC, SGI, Sequent, OS/2, with support for Windows NT is 
  8449. planned during 1993.
  8450.  
  8451. Versant provides transparent language interfaces from object-oriented 
  8452. programming languages such as C++ and Smalltalk.  Versant also supports a C API.
  8453.  
  8454. Versant is built with an object-level architecture, which means that operations 
  8455. are generally performed on the object (or group thereof) level.  Key Versant 
  8456. features include:
  8457.  
  8458.  Performance
  8459.  -----------
  8460.  
  8461. *  Object-level locking for fine granularity concurrency control
  8462. *  Server-based query processing to reduce network I/O
  8463. *  Dual caching to speed warm traversals
  8464. *  Dynamic space reclamation and reuse
  8465.  
  8466.  Distribution
  8467.  ------------
  8468.  
  8469. *  Immutable, logical object identifiers for data integrity
  8470. *  Object migration (transparent relocation across nodes)
  8471. *  Transparent cross-node references (distributed db)
  8472. *  Automatic two-phase commit
  8473.  
  8474.  Other
  8475.  -----
  8476.  
  8477. *  Schema evolution (online via lazy updates)
  8478. *  Standard workgroup features (e.g., versioning, checkin/out)
  8479. *  Detachable, personal databases
  8480. *  DBA utilities
  8481.  
  8482.  
  8483. Additional information available from
  8484.  
  8485. info@versant.com  (General information)
  8486. davek@versant.com (Dave Kellogg)
  8487.  
  8488. Versant Object Technology 
  8489. 1380 Willow Road
  8490. Menlo Park, California  94025
  8491.  
  8492. 415-329-7500 phone.
  8493. 415-325-2380 fax.
  8494.  
  8495.  
  8496. On Schema Evolution (from original survey):
  8497. We support run-time schema evolution.  It uses a lazy scheme, so
  8498. schema operations are very fast.  Objects on disk may have an older
  8499. `storage class' and they will be updated to the new schema when they
  8500. are used.
  8501.  
  8502. In older releases schema evolution was allowed only on leaf classes
  8503. (those with no subclasses).  In our new release 2 (going to beta test
  8504. soon) you can do schema evolution on any class.
  8505.  
  8506. In the future we're working on more general view mechanisms so you can
  8507. see a subset of the attributes in memory, or some more complicated
  8508. transformation.  This goes together with support for multiple
  8509. compilers and multiple languages.
  8510.  
  8511. [Joe Keane <osc!jgk@amd.com>]
  8512.  
  8513. Also: 1-800-Versant
  8514.  
  8515.  
  8516.  
  8517.  
  8518. Other Models
  8519. ------------
  8520.  
  8521. Research Systems
  8522. ________________
  8523.  
  8524. > GRAS
  8525.  
  8526. --------------------------------------------------------------
  8527. GRAS - A Graph-Oriented Database System for SE Applications
  8528. Copyright (C) 1987-1993  Lehrstuhl Informatik III, RWTH Aachen
  8529. --------------------------------------------------------------
  8530.  
  8531. See the GNU Library General Public License for copyright details.
  8532.  
  8533. Contact Adresses:
  8534.  
  8535.     Dr. Andy Schuerr 
  8536.     Lehrstuhl fuer Informatik III,
  8537.     University of Technology Aachen (RWTH Aachen),
  8538.     Ahornstr. 55,
  8539.     D-5100 Aachen
  8540.  
  8541. Email to
  8542.  
  8543.     andy@i3.informatik.rwth-aachen.de
  8544.  
  8545. GRAS is a database system which has been designed according
  8546. to the requirements resulting from software engineering
  8547. applications. Software development environments are composed
  8548. of tools which operate on complex, highly structured data.
  8549. In order to model such data in a natural way, we have selected
  8550. attributed graphs as GRAS' underlying data model.
  8551.  
  8552. A first prototype of the GRAS (GRAph Storage) system - described
  8553. in /BL 85/ - was already realized in 1985. Since this time
  8554. gradually improving versions of the system have been used at
  8555. different sites within the software engineering projects
  8556. IPSEN /Na 90/, Rigi /MK 88/, MERLIN /DG 90/, and CADDY /EHH 89/.
  8557. Based on these experiences, almost all parts of the original
  8558. prototype have been redesigned and reimplemented.
  8559.  
  8560. Thus, nowadays a stable and efficiently working single-process
  8561. version of the system GRAS with interfaces for the programming
  8562. languages Modula-2 and C is available as free software for Sun
  8563. workstations (the GRAS system itself is implemented in Modula-2
  8564. and consists of many layers which might be reusable for the
  8565. implementation of other systems):
  8566.  
  8567.   Via anonymous ftp from ftp.informatik.rwth-aachen.de
  8568.   in directory /pub/unix/GRAS in file gras.<version-no>.tar.Z.
  8569.  
  8570.   There are several files containing documentation, sources, binaries,
  8571.   application examples, and libraries. All binaries are for Sun/4
  8572.   machines. Sun/3 binaries are shipped only if explicitly requested.
  8573.  
  8574.   You have to use the following sequence of operations for installing
  8575.   the GRAS system at your site:
  8576.  
  8577.   1) 'ftp ftp.informatik.rwth-aachen.de' (with login name "anonymous"
  8578.      and password equal to your mail address).
  8579.   2) 'cd pub/unix/GRAS' (for changing the current directory).
  8580.   3) 'binary' (command for changing ftp mode).
  8581.   4) 'get gras.<version-no.>' (use 'ls' for finding the currently used
  8582.       GRAS version nr.).
  8583.   5) 'bye' (for exiting ftp).
  8584.   6) 'uncompress gras.<version-no>.tar'.
  8585.   7) 'tar xvf gras.<version-no>.tar' (creates a subdirectory GRAS_2 for
  8586.      the Modula-2 implementation of GRAS including its C-interface).
  8587.   8) Follow the instructions in file GRAS_2/README.
  8588.  
  8589.  
  8590. The current version has programming interfaces for Modula-2 and C
  8591. and supports:
  8592.  
  8593.   - the manipulation of persistent attributed, directed node- and
  8594.     edge-labeled graphs (including the creation of very long
  8595.     attributes and of attribute indexes).
  8596.  
  8597.   - the manipulation of temporary/volatile generic sets/relations/lists,
  8598.  
  8599.   - the coordination of graph accesses by different GRAS applications
  8600.     (multiple-read/single-write access with graphs as lock units),
  8601.  
  8602.   - error recovery based on shadow pages and forward logs,
  8603.  
  8604.   - nested transactions and linear undo/redo of arbitrarily long
  8605.     sequences of already committed graph modifying operations based
  8606.     on forward and backward logs,
  8607.  
  8608.   - event-handling (with certain kinds of graph-modifications
  8609.     as events and graph-modifying transactions as event-handlers),
  8610.  
  8611.   - primitives for version control comprising the capability
  8612.     for efficiently storing graphs as forward/backward deltas to
  8613.     other graphs,
  8614.  
  8615.   - and primitives for declaring graph schemes and for incremental
  8616.     evaluation of derived attributes.
  8617.  
  8618. Furthermore, tools for (un-)compressing graphs and a X11R5-based
  8619. graph browser are part of this release.
  8620.  
  8621. A multi-process version of the system GRAS supporting the inter-
  8622. action of multiple client and multiple server processes within
  8623. one local area network is nearby completion (version 6.0/0).
  8624.  
  8625. Thus, the GRAS system may be considered to be the core of a graph
  8626. oriented DBMS environment. The development of such an environment
  8627. based on a very high-level specifications language named PROGRES
  8628. is under way (the underlying calculus of this specification language
  8629. are so-called PROgrammed GRaph REwriting Systems).
  8630.  
  8631. This environment will comprise the following tools (a prerelease
  8632. of this environment might be made available upon request):
  8633.  
  8634.   - a syntax-directed editor for graph schemes, graph rewrite rules,
  8635.     and sequences of graph rewrite rules,
  8636.  
  8637.   - an incrementally working consistency checker,
  8638.  
  8639.   - an incrementally working compiler&interpreter translating
  8640.     PROGRES specifications into sequences of GRAS procedure
  8641.     calls (for C as well as for Modula-2),
  8642.  
  8643.   - and an "enhanced" graph (scheme) browser.
  8644.  
  8645.  
  8646. References
  8647. ----------
  8648.  
  8649. Refer to the following publications for further info about GRAS, PROGRES,
  8650. and related topics:
  8651.  
  8652. /BL85/          Brandes, Lewerentz: A Non-Standard Data Base System within
  8653.                 a Software Development Environment. In Proc. of the Workshop
  8654.                 on Software Engineering Environments for Programming-in-the-
  8655.                 Large, pp 113-121, Cape Cod, June 1985
  8656.  
  8657. /DHKPRS90/      Dewal, Hormann, Kelter, Platz, Roschewski, Schoepe: Evaluation
  8658.                 of Object Management Systems. Memorandum 44, University
  8659.                 Dortmund, March 1990
  8660.  
  8661. /Feye92/    Feye A.: Compilation of Path Expressions (in German), Diploma
  8662.         Thesis, RWTH Aachen (1992)
  8663.  
  8664. /Hoefer92/    Hoefer F.: Incremental Attribute Evaluation for Graphs (in
  8665.         German), Diploma Thesis, RWTH Aachen (1992)
  8666.  
  8667. /HPRS90/        Hormann, Platz, Roschweski, Schoepe: The Hypermodel Benchmark,
  8668.                 Description, Execution and Results. Memorandum 53, University
  8669.                 Dortmund, September 1990
  8670.  
  8671. /KSW92/ *       Kiesel, Schuerr, Westfechtel: GRAS, A Graph-Oriented Database
  8672.                 System for (Software) Engineering Applications. Proc. CASE 93,
  8673.         Lee, Reid, Jarzabek (eds.): Proc. CASE '93, 6th Int. Conf. on
  8674.         Computer-Aided Software Engineering, IEEE Computer Society
  8675.         Press (1993), pp 272-286
  8676.         Also:  Technical Report AIB 92-44, 
  8677.  
  8678. /Klein92/    Klein P.: The PROGRES Graph Code Machine (in German), Diploma
  8679.         Thesis, RWTH Aachen (1992)
  8680.  
  8681. /Kossing92/    Kossing P.: Modelling of Abstract Syntax Graphs for normalized
  8682.         EBNFs (in German), Diploma Thesis, RWTH Aachen (1992)
  8683.  
  8684. /LS88/          Lewerentz, Schuerr: GRAS, a Management System for Graph-
  8685.                 Like Documents. In Proceedings of the Third International
  8686.                 Conference on Data and Knowledge Bases, Morgan Kaufmann
  8687.                 Publ. Inc. (1988), pp 19-31
  8688.  
  8689. /Nagl89/        Nagl (ed.): Proc. WG'89 Workshop on Graphtheoretic Concepts
  8690.                 in Computer Science, LNCS 411, Springer-Verlag (1989)
  8691.  
  8692. /NS91/          Nagl, Schuerr: A Specification Environment for Graph Grammars,
  8693.                 in Proc. 4th Int. Workshop on Graph-Grammars and Their
  8694.                 Application to Computer Science, LNCS 532, Springer-
  8695.                 Verlag 1991, pp 599-609
  8696.  
  8697. /Schuerr89/     Schuerr: Introduction to PROGRES, an Attribute Graph Grammar
  8698.                 Based Specification Language, in: /Nagl89/, pp 151-165
  8699.  
  8700. /Schuerr91a/ *  Schuerr: PROGRES: A VHL-Language Based on Graph Grammars,
  8701.                 in Proc. 4th Int. Workshop on Graph-Grammars and Their
  8702.                 Application to Computer Science, LNCS 532, Springer-
  8703.                 Verlag 1991, pp 641-659
  8704.         Also:  Technical Report AIB 90-16
  8705.  
  8706. /Schuerr91b/    Schuerr: Operational Specifications with Programmed Graph
  8707.         Rewriting Systems: Theory, Tools, and Applications, 
  8708.         Dissertation, Deutscher Universitaetsverlag (1991) (in German)
  8709.  
  8710. /SZ91/ *        Schuerr, Zuendorf: Nondeterministic Control Structures for
  8711.                 Graph Rewriting Systems, in Proc. WG'91 Workshop in Graph-
  8712.                 theoretic Concepts in Computer Science, LNCS 570, Springer-
  8713.                 Verlag 1992, pp 48-62
  8714.         Also: Technical Report AIB 91-17
  8715.  
  8716. /Westfe89/      Westfechtel: Extension of a Graph Storage for Software
  8717.                 Documents with Primitives for Undo/Redo and Revision Control.
  8718.                 Technical Report AIB Nr. 89-8, Aachen University of Technology,
  8719.                 1989
  8720.  
  8721. /Westfe91/      Westfechtel: Revisionskontrolle in einer integrierten Soft-
  8722.                 wareentwicklungsumgebung, Dissertation, RWTH Aachen, 1991
  8723.  
  8724. /Zuendorf89/    Zuendorf: Kontrollstrukturen fuer die Spezifikationssprache
  8725.                 PROGRES, Diplomarbeit, RWTH Aachen, 1989
  8726.  
  8727. /Zuendorf92/ *  Zuendorf A.: Implementation of the Imperative/Rule Based
  8728.                 Language PROGRES, Technical Report AIB 92-38, RWTH Aachen,
  8729.                 Germany (1992)
  8730.  
  8731. /Zuendorf93/ *  Zuendorf A.: A Heuristic Solution for the (Sub-) Graph
  8732.                 Isomorphism Problem in Executing PROGRES, Technical
  8733.                 Report AIB 93-5, RWTH Aachen, Germany (1993)
  8734.  
  8735. * : All reports marked with an asterisk are available via anonymous ftp from
  8736.     ftp.informatik.rwth-aachen.de in directory /pub/reports/... .
  8737.  
  8738. See also PROGRES documentation.
  8739.  
  8740. [See also APPENDIX E]
  8741.  
  8742.  
  8743. > IRIS (HP Labs)
  8744.  
  8745. [Iris is a system out of HP Labs that began as a prototype and eventually
  8746. became a commercial product.  I believe it was eventually incorporated into
  8747. the new HP product, OpenODB. - clamen]
  8748.  
  8749. Long and short system summaries can be found in:
  8750.  
  8751. [FISH89] D.H. Fishman et. al. Overview of the Iris DBMS. In Won.
  8752.          Kim and Frederick H. Lochovsky, editors,
  8753.          Object-Oriented Concepts, Databases and Applications,
  8754.          chapter 10, pages 219--250. Addison-Wesley, Reading,
  8755.          MA, 1989.
  8756.  
  8757. [FBC+87] D.H. Fishman, D. Beech, H.P. Cate, E.C. Chow,
  8758.          T. Connors, J.W. Davis, N. Derrett, C.G. Hock, W. Kent,
  8759.          P. Lyngbaek, B. Mahbod, M.A. Neimat, T.A. Tyan, and
  8760.          M.C. Shan. Iris:  An object-oriented database
  8761.          management system. ACM Transactions on Office
  8762.          Information Systems, 5(1):48--69, January 1987.
  8763.  
  8764. The abstract of the latter (written early in the project) follows:
  8765.  
  8766.    The Iris database management system is a research prototype of
  8767.    a next-generation database management system intended  to meet
  8768.    the needs of new and emerging database applications, including
  8769.    office    automation and knowledge-based systems,  engineering
  8770.    test and measurement, and hardware  and software design.  Iris
  8771.    is exploring a rich set of  new database capabilities required
  8772.    by    these   applications,   including  rich    data-modeling
  8773.    constructs, direct  database support for inference,  novel and
  8774.    extensible data types, for example to  support graphic images,
  8775.    voice,    text,   vectors,  and  matrices,    support for long
  8776.    transactions   spanning  minutes  to  many  days, and multiple
  8777.    versions of data.  These capabilities are, in addition  to the
  8778.    usual support for  permanence   of data, controlled   sharing,
  8779.    backup and recovery.
  8780.  
  8781.    The   Iris   DBMS consists   of  (1) a  query   processor that
  8782.    implements  the   Iris object-oriented  data    model, (2)   a
  8783.    Relational Storage Subsystem (RSS) -like  storage manager that
  8784.    provides  access paths and  concurrency  control, backup   and
  8785.    recovery, and (3) a collection of programmatic and interactive
  8786.    interfaces.  The data   model supports  high-level  structural
  8787.    abstractions,  such  as  classification, generalization,   and
  8788.    aggregation, as  well  as behavioral    abstractions.      The
  8789.    interfaces to  Iris  include an  object-oriented extension  to
  8790.    SQL.
  8791.  
  8792.  
  8793. On Schema Evolution (from original survey):
  8794. Objects in the Iris system may acquire or lose types dynamically.
  8795. Thus, if an object no longer matches a changed definition, the user
  8796. can choose to remove the type from the object instead of modifying the
  8797. object to match the type.  In general, Iris tends to restrict class
  8798. modifications so that object modifications are not necessary.  For
  8799. example, a class cannot be removed unless it has no instances and new
  8800. supertype-subtype relationships cannot be established.
  8801.  
  8802.  
  8803. Commercial Systems
  8804. __________________
  8805.  
  8806.  
  8807. > IDL (Persistent Data Systems)
  8808.  
  8809. IDL is a schema definition language. Schema modifications are defined
  8810. in IDL, requiring ad-hoc offline transformations of the database, in
  8811. general.  A simple class of transformations can be handled by
  8812. IDL->ASCII and ASCII->IDL translators (i.e., integer format changes,
  8813. list->array, attribute addition).
  8814.  
  8815. [conversation with Ellen Borison of Persistent Data Systems]
  8816.  
  8817.  
  8818. ADDITIONAL REFERENCES:
  8819.         John R. Nestor. "IDL: The Language and Its
  8820.         Implementation". Prentice Hall. Englewood Cliffs,
  8821.         NJ., 1989.
  8822.  
  8823.  
  8824.  
  8825. > Kala
  8826.                          Kala Technical Brief
  8827.  
  8828. Summary
  8829.  
  8830. Kala(tm) is a Persistent Data Server managing distributed, shared,
  8831. arbitrarily complex and evolving persistent data. Kala is highly
  8832. efficient and secure. Kala manages the visibility of persistent data
  8833. elements to its clients, thus supporting any types of transactions,
  8834. versions, access control, security, configurations. Kala does not
  8835. restrict you to any particular model. Kala provides the mechanism, but
  8836. imposes no policy. Usable as either a link library communicating to a
  8837. server or as a standalone, Kala is compact and simple.
  8838.  
  8839. Kala is used for applications such as: kernel of DBMS products,
  8840. substrate for extended file systems, implementation of language
  8841. persistence, data manager for groupware applications as well as
  8842. applications which deal with large, complex, and changing volumes of
  8843. data (text databases, financial distributed transaction systems). Our
  8844. current customers use Kala in applications ranging from CASE
  8845. repositories to CAD systems, from document management for financial
  8846. institutions to OODBMS platforms, from real-time applications to
  8847. database research.  Kala is a component of broad reuse.
  8848.  
  8849.  
  8850. Motivation
  8851.  
  8852. The simplest persistent data storage available to you is the file
  8853. system on your disk drive. File systems have some attractive
  8854. characteristics; their performance is good, they can hold any data,
  8855. they're easy to use, and, of course, the price is right. Conversely,
  8856. files are unreliable.  They provide no mechanism for in maintaining
  8857. data consistency and only primitive data sharing facilities. Few file
  8858. systems offer version control and all require that you transform data
  8859. between "internal" and "external" forms all the time.
  8860.  
  8861. Unlike a file system, a true database management system provides
  8862. mechanisms for sharing data and for ensuring the integrity of the
  8863. data.  It supports transactions and version control, although the
  8864. specifics of these functions may not be exactly what your application
  8865. needs. Finally, a database system is scalable, and much more robust
  8866. than a file when your hardware or software fails.
  8867.  
  8868. The downside to a database system is that, compared to a file system,
  8869. it is slower by an order of magnitude or more. Also, a database system
  8870. generally confines you to dealing only with the kind of data that it
  8871. can handle. In addition, a database is usually very complicated,
  8872. difficult to learn and use, and expensive, both in terms of your cost
  8873. of operation and in the amount of system resources they consume.
  8874.  
  8875. Whether you choose a file system or a database manager, then, you
  8876. have to sacrifice either economy or performance. Is there a happy
  8877. medium?  Something with the speed and flexibility of files, the
  8878. reliability, shareability and robustness of databases, and at a cost
  8879. that won't break your wallet or the available hardware? Sure there is!
  8880. Kala is a first in a new breed of products, persistent data servers,
  8881. aimed squarely at the yawning gap between DBMSs and file systems.
  8882.  
  8883.  
  8884. Overview
  8885.  
  8886. Kala is *not* a DBMS. Instead, you use Kala whenever the few canned
  8887. combinations of DBMS features do not meet the needs of your
  8888. application. A DBMS product constrains you to accept *its* choice of
  8889. an end-user graphical interface, a query language binding, a specific
  8890. high level data or object model, a particular transaction model, a
  8891. single versioning scheme, etc. This either compromises your
  8892. application's functionality, or forces your to spend substantial
  8893. development effort and money to bridge the impedance mismatch to the
  8894. application.  Instead, Kala allows *you* to develop no more and no
  8895. less than the functionality you need. You build your domain specific
  8896. functionality our of a small set of primitives with very little code.
  8897. Your gains in productivity, efficiency, and flexibility are
  8898. substantial.
  8899.  
  8900. To sustain this level of flexibility and reuse, Kala manages any data
  8901. that you can represent in machine memory out of bits and references.
  8902. Examples include records, dynamically linked graphs and lists,
  8903. executable code, and object encapsulations.
  8904.  
  8905. Kala can handle data as small as one bit, and as large as the virtual
  8906. memory and more, while being totally unaware of the data's semantics.
  8907. Its stores and retrieves data efficiently, and compactly over a
  8908. distributed and dynamically reconfigurable set of Stores. Upon
  8909. retrieval, Kala dynamically relocates embedded references to retain
  8910. the original topological structure of the data, thus preserving
  8911. referential integrity. Kala also supports active data, physical store
  8912. management, and automatic archiving.
  8913.  
  8914. Kala repackages the fundamentals and universals of data management in
  8915. one reusable data server, separating them from the application domain
  8916. specific models and policies. Kala defines a low level interoperabi-
  8917. lity point for the data storage domain, just as X does for the display
  8918. domain and Postscript does for the printing domain.
  8919.  
  8920. Kala has matured through four successive versions to its present
  8921. industrial strength implementation and stable API. Kala is lean,
  8922. compact, and portable. Kala is a high performance, low overhead
  8923. system. We call it a Reduced Instruction Set Engine (RISE). Unlike
  8924. large, complex, and typically bulky DBMS products, Kala is small,
  8925. simple, and suitable for managing anywhere from a single diskette to
  8926. terabytes of distributed data.
  8927.  
  8928.  
  8929. Benefits
  8930.  
  8931. * For those who need functionality traditionally associated with
  8932.   databases, but cannot tolerate the overhead and complications DBMS
  8933.   products introduce, Kala offers a flexible, compact, performant,
  8934.   elegant, and simple alternative.
  8935.  
  8936. * For those whose application domain requires data models where the
  8937.   mapping to those offered by today's DBMS products is cumbersome,
  8938.   introduces development and execution overhead, and is not portable
  8939.   across multiple linguistic and environmental platforms, Kala offers
  8940.   a data model independent interface against any data model
  8941.   expressible in terms of bits and pointers can be easily built.
  8942.  
  8943. * For those who need DBMS functionality or qualities that no single
  8944.   DBMS product now has, Kala offers the opportunity to build that
  8945.   functionality now with little effort out of a simple set of
  8946.   primitives, and not wait for one vendor or another to deliver
  8947.   it later.
  8948.  
  8949. * For those who have determined that the only viable option for their
  8950.   application's persistent data needs is the file system, and have
  8951.   resined to the idea that they will have to build everything else
  8952.   they need from scratch, Kala offers an off-the-shelf implementation
  8953.   without loss of any of files' advantages.
  8954.  
  8955. * For those who need performance, size, portability, storage
  8956.   compactness, and industrial strength that no single DBMS product can
  8957.   now satisfy, Kala offers all of the above now.
  8958.  
  8959. * For those who realize that while object-level interoperability is a
  8960.   strong desideratum, the likelihood of a single, universal such model
  8961.   in the foreseeable future is quite low, Kala offers a solid, long
  8962.   term alternative. Data store interoperability that brings us beyond
  8963.   file systems is the best practical bet. Kala is the basis for data
  8964.   store interoperability now.
  8965.  
  8966. * Finally, for all of you who are concerned about the economics of
  8967.   software, and take the view that there are many elements that
  8968.   could contribute negatively to the soundness of your business, such
  8969.   as operational costs, software maintenance costs, software licensing
  8970.   costs, software development and learning costs, etc., you will find
  8971.   Kala an economically sound, sensible, and practical product.
  8972.  
  8973.  
  8974. Features
  8975.  
  8976. - The execution architecture is that of multiple (communicating)
  8977.   servers and multiple clients. Kala can also be configured in a
  8978.   standalone (single process) mode. Kala's IPC is built for maximum
  8979.   performance, portable to any given datagram protocol.
  8980.  
  8981. - The managed data elements are made out of uninterpreted bits and
  8982.   references. Data elements (named `monads') are universally uniquely
  8983.   identified. Bits are stored with no overhead. References,
  8984.   represented in memory as native machine pointers, are stored
  8985.   very compactly, introducing an average of 2.5 bytes overhead.
  8986.  
  8987. - Kala is a fully recoverable system, short of media damage. Recovery
  8988.   from hardware failures can be supported by the layer beneath Kala.
  8989.  
  8990. - The Kala primitives support arbitrary transaction models, including
  8991.   classic short transactions, long (persistent) transactions, nested
  8992.   transactions, shared transactions, pessimistic and optimistic
  8993.   policies, etc. Concurrency control is achieved through two locking
  8994.   mechanisms (short-term and long-term (persistent, shared) locking),
  8995.   with full support for atomicity of operations and two-phase commit.
  8996.  
  8997. - The Kala primitives support arbitrary versioning models, allowing
  8998.   versions to co-exist in split/rejoined networks, various version
  8999.   organization strategies (single-thread, tree, DAG, etc.). Kala
  9000.   primitives provide mechanisms for arbitrary access and update
  9001.   triggers, such as notifications, security checks upon access/update,
  9002.   etc. __ with no limitations on what the trigger code does. Kala
  9003.   provides protection measures against virus and other intruding
  9004.   executions.
  9005.  
  9006. - The Kala primitives support a wide range of access control, security
  9007.   and protection models, including revocable access rights, access
  9008.   control without the overhead of ACL management, arbitrary access
  9009.   validation routines, etc. Kala does not introduce any more security
  9010.   holes than the operating environment already has.
  9011.  
  9012. - Kala has primitives for physical store allocation and de-allocation
  9013.   management, for a wide spectrum of store administrative tasks, as
  9014.   well as licensing administration. The latter includes application-
  9015.   sensitive time-limited client-connect-based licensing, as well as
  9016.   metered (connect/load/store) usage. Kala can be set up to do
  9017.   automatic archiving and backup of its physical store.
  9018.  
  9019. - Kala provides a wide spectrum of licensing schemes, usable by
  9020.   platforms and applications built upon Kala to their customer base.
  9021.   Kala provides renewable licenses, perpetual licenses, full
  9022.   protection against duplication without hardware (hostid) support,
  9023.   metered (pay-by-use) usage, etc.
  9024.  
  9025. - And more ... not fitting on this page-long Technical Brief.
  9026.  
  9027.  
  9028. Availability
  9029.  
  9030. o Kala is available now on Sun platforms (SunOS / 68K & SPARC), as
  9031.   well as on 80x86/MS-DOS (both Microsoft and Borland compilers &
  9032.   runtimes supported) platforms. If you are interested in a port to
  9033.   your favorite platform, call us to discuss our Development and
  9034.   Porting Partnership Programme.
  9035.  
  9036. o Kala's interface is ANSI C, also callable from C++. If you are
  9037.   interested in an interface or a binding to your favorite programming
  9038.   language, please call us to discuss out Development Partnership
  9039.   Programme.
  9040.  
  9041. o For pricing and other information, please contact us by phone, fax
  9042.   or via e-mail at Info@Kala.com
  9043.  
  9044.  
  9045.  _     _     ____   _         ____ tm ____________________________________
  9046.  \\   /     |    \   \       |    \       \\\\ 
  9047.   \\ /__     \ __ \   \       \ __ \       \\\\ 
  9048.    \\    \    \    \   \       \    \       \\\\  
  9049.     \\    \    \    \   \       \    \       \\\\  No more than you need !!!
  9050.      \\'   \'   \'   \'  '____'  \'   \'      \\\\  No less than you want !!!
  9051.       ........................................................................
  9052.       Penobscot Development Corporation                 email: Info@Kala.com
  9053.        One Kendall Square Building 200 Suite 2200 Cambridge MA 02139-1564 USA
  9054.         voice +1-617-267-KALA fax +1-617-859-9597 tech support +1-201-539-7739
  9055.          ...............(5252) fax +1-617-577-1209.............................
  9056.  
  9057.  
  9058.  
  9059.      +---------------------------------------------------------------+
  9060.      |   Copyright (c) 1992-93, Penobscot Development Corporation.   |
  9061.      |   Kala is a Trademark of Penobscot Development Corporation.   |
  9062.      +---------------------------------------------------------------+
  9063.  
  9064. On Schema Evolution (from original survey):
  9065.  
  9066. Kala manages an untyped persistent store, implementing the semantics
  9067. of robust, distributed, secure, changing, and shareable persistent
  9068. data.  Layers built upon the Kala platform can implement the semantics
  9069. of objects with the same properties.
  9070.  
  9071. As it operates below the schema layer, Kala does not address schema
  9072. evolution directly. However, It supports the building of schema'ed
  9073. layers above it and below the application, and those layers can
  9074. provide for schema evolution conveniently using Kala primitives.
  9075. This parts-box approach requires extra work on the part of the developer
  9076. compared to out-of-the-box solutions, but provides power and
  9077. flexibility sufficient for relatively low cost solutions in
  9078. difficult environments (e.g. graph-structured data, dynamic classing) 
  9079. where no out-of-the-box solution is available.
  9080.  
  9081.  
  9082. Contacts:
  9083. Sergiu Simmel           sss@kala.com
  9084. Ivan Godard             ig@kala.com
  9085. general information     info@kala.com
  9086. subscription to moderated newsletter    forum-request@kala.com
  9087.  
  9088.  
  9089. REFERENCES:
  9090.         Segui S. Simmel and Ivan Godard. "The Kala Basket: A
  9091.         Semantic Primitive Unifying Object Transactions,
  9092.         Access Control, Versions, annd Configurations
  9093.  
  9094.  
  9095. > Pick
  9096.  
  9097. With Pick and its variants you only have problems if you want to
  9098. redefine an existing field.  Because of the way the data are stored
  9099. and the separation of the data and the dictionary you can define
  9100. additional fields in the dictionary without having to do anything to
  9101. the data - a facility which we have found very useful in a number of
  9102. systems.
  9103.  
  9104. There is no general facility to redefine an existing field - you just
  9105. make whatever changes are required in the dictionary then write an
  9106. Info Basic program to change the data.  We have seldom needed to do
  9107. this, but it has not been complicated to do.
  9108.  
  9109. If a field in the database is no longer used, it is often easiest
  9110. simply to delete the reference to that field in the dictionary, and
  9111. accept the storage overhead of the unused data.  In such cases, while
  9112. the data cannot be accessed through the query language, (Pick)Basic
  9113. programs can still access them.
  9114.  
  9115. [Geoff Miller <ghm@ccadfa.cc.adfa.oz.au>]
  9116.  
  9117.  
  9118.  
  9119. Interfaces
  9120. ----------
  9121.  
  9122.  
  9123. Research Systems
  9124. ________________
  9125.  
  9126.  
  9127. > Penguin (Stanford)
  9128.  
  9129. Penguin is an object-oriented interface to relational databases.
  9130. Penguin has its own simple language-independent object model with
  9131. inheritance for composite objects defined as views (called
  9132. view-objects) of a relational database.  These view-objects represent
  9133. data according to application requirements in such a way that multiple
  9134. applications can share overlapping, but different, sets of data.
  9135. Multiple applications may share data by having overlapping schemata
  9136. with differing composite objects and differing inheritance mappings.
  9137. We have a C++ binding, which supports multiple inheritance.  The
  9138. result is a framework for collaboration among multiple users, each
  9139. with differing perspectives about the system and its data.
  9140.  
  9141. For additional information, please contact ark@db.stanford.edu
  9142.  
  9143. References:
  9144.  
  9145. ``A C++ Binding for Penguin: a System for Data Sharing among
  9146. Heterogeneous Object Models,'' Arthur M. Keller, Catherine Hamon,
  9147. Foundations on Data Organization (FODO) 93, October 1993, Chicago.
  9148.  
  9149. ``Querying Heterogeneous Object Views of a Relational Database,''
  9150. Tetsuya Takahashi and Arthur M. Keller, Int. Symp. on Next Generation
  9151. Database Systems and their applications, Fukuoka, Japan, September
  9152. 1993, to appear.
  9153.  
  9154. ``Updating Relational Databases through Object-Based Views,'' by
  9155. Thierry Barsalou, Niki Siambela, Arthur M. Keller, and Gio Wiederhold,
  9156. ACM SIGMOD, Denver, CO, May 1991.
  9157.  
  9158. ``Unifying Database and Programming Language Concepts Using the Object
  9159. Model'' (extended abstract), Arthur M. Keller, Int. Workshop on
  9160. Object-Oriented Database Systems, IEEE Computer Society, Pacific
  9161. Grove, CA, September 1986.
  9162.  
  9163.  
  9164. Commercial Systems
  9165. __________________
  9166.   
  9167. >AllegroStore
  9168.  
  9169. See Databases & Development Sept. 5, 1994, p1. 
  9170.  
  9171. "Lisp, Smalltalk Languages Given Database Systems"
  9172.  
  9173. Quote:
  9174. Franz, based in Berkeley, Calif., is now shipping AllegroStore, which the
  9175. company calls the first object database system designed for object-oriented
  9176. Lisp.
  9177.  
  9178. [...] The database is based on the ObjectStore engine from Object Design, also
  9179. in Burlington.  It supports multiple clients and servers, [...]
  9180.  
  9181. Franz is at 800-333-7260 or 510-548-3600.
  9182.  
  9183.  
  9184. >OBJECT GATEWAY
  9185.  
  9186. Object Gateway is a modeling, mapping and code generation tool that lets
  9187. you look at existing relational data in Oracle, Sybase and other servers
  9188. as if they are object oriented.  It is a 100% client-resident and runs on
  9189. Microsoft Windows platforms.
  9190.  
  9191. Schema Genie, the design time component of Object Gateway, lets you design an
  9192. ODMG-style object model for your SQL database. Once the model is designed,
  9193. you can generate a variety of language interfaces for it (C++, C, OLE
  9194. Automation and Visual Basic are currently supported).
  9195.  
  9196. Object Engine is the run-time component of the system and it implements the
  9197. object data model by supporting features such as activation and deactivation of
  9198. objects, complex object assembly, inheritance, relationships and cache
  9199. management.  Object Browser is a component of the system that lets you browse
  9200. through and manipulate data based on the object model that you defined.
  9201.  
  9202. The central tenet of Object Gateway is that inside every complex relational
  9203. database, there is an object model waiting to get out. Such a model reduces
  9204. the abstraction level mismatch between modern, object oriented client tools
  9205. and SQL servers. Automatic generation of an object oriented data access layer
  9206. eliminates the need for programmers to hand-craft code to do the same.
  9207.  
  9208. For more information, please contact Sierra Atlantic at the address
  9209. below:
  9210.  
  9211.     Sierra Atlantic Inc
  9212.     830 Hillview Court, Suite 270,
  9213.     Milpitas, CA 95035
  9214.     Phone: (408) 956 3006
  9215.     Fax:   (408) 956 3001
  9216.     Email:  objgtwy@shell.portal.com
  9217.  
  9218.  
  9219. > Persistence
  9220.  
  9221.                 PERSISTENCE(TM): BRIDGING THE GAP BETWEEN OBJECT 
  9222.                     ORIENTED DEVELOPMENT AND RELATIONAL DATA
  9223.  
  9224. Persistence is an application development tool which provides object
  9225. oriented access to existing relational data.  Persistence uses an
  9226. automatic code generator to convert object models into C++ classes
  9227. which know how to read and write themselves to a relational database.
  9228.  
  9229. Leverage existing data
  9230.  
  9231. Persistence enables object oriented access to existing relational
  9232. databases. Applications built with Persistence can work side by side
  9233. with legacy systems.
  9234.  
  9235. Automate database access
  9236.  
  9237. By generating the methods to convert relational data into objects,
  9238. Persistence saves the developer from having to write literally hundreds
  9239. of lines of code per class.
  9240.  
  9241. Speed application development
  9242.  
  9243. With Persistence, major changes to the application object model can be
  9244. completed in minutes, not weeks.
  9245.  
  9246. Quality
  9247.  
  9248. Persistence generates tested, bug-free code. Using Persistence helps
  9249. ensure the reliability and reusability of your applications.
  9250.  
  9251. Performance
  9252.  
  9253. At Runtime, Persistence manages an object cache to enhance performance
  9254. while ensuring data integrity. The Persistence object cache can provide
  9255. a factor of ten performance improvement for data intensive
  9256. applications.
  9257.  
  9258. Portability
  9259.  
  9260. Code generated by Persistence is database independent. You can choose
  9261. which database to work with at link step, increasing application
  9262. portability.
  9263.  
  9264.                         TECHNICAL SPECIFICATIONS
  9265.  
  9266. The Persistence Database Interface Generator converts object schemas
  9267. into C++ classes.
  9268.  
  9269.                                                 Custom
  9270.                                                 Code
  9271.                                                    |
  9272.                                                    v
  9273.  
  9274. Object schema    --->   Persistence    ---->    Generated
  9275.                         Generator               Classes
  9276.                                                    ^
  9277.                                                    |
  9278.                                                    v
  9279.                                                 Persistence
  9280.                                                 Object Cache
  9281.                                                    ^
  9282.                                                    |
  9283.                                                    v
  9284.                                                 Legacy Data
  9285.  
  9286.  
  9287. Encapsulation
  9288.  
  9289. Each class generated by Persistence maps to a table or view in the database.
  9290. - Query using ANSI SQL or attribute values
  9291. - Add custom code to generated classes
  9292. - Preserve custom code when model changes
  9293.  
  9294. Inheritance
  9295.  
  9296. Persistence supports inheritance of attributes, methods and relationships.
  9297. - Propagate superclass queries to subclasses
  9298. - Use virtual methods for polymorphism
  9299.  
  9300. Associations
  9301.  
  9302. Persistence maps associations to foreign keys in the database. Each class has methods to access related classes.
  9303. - Ensure referential integrity between classes
  9304. - Specify delete constraints for associations
  9305.  
  9306. Object Caching
  9307.  
  9308. The Persistence Runtime Object Management System caches objects during
  9309. transactions and ensures data integrity. In the object cache,
  9310. Persistence "swizzles" foreign key attributes into in-memory pointers,
  9311. speeding object traversal.
  9312.  
  9313. Transactions
  9314.  
  9315. When a transaction is committed, Persistence walks through the object
  9316. cache and writes out changes to the database.
  9317.  
  9318. Environment
  9319.  
  9320. Platforms/Operating systems
  9321. Persistence will support all major Unix and Intel platforms
  9322. - Sun/SunOS 4.x, Solaris 2.x
  9323. - HP/HP-UX 8.0, 9.0
  9324. - IBM/AIX (planned 11/93)
  9325. - Intel/NT (planned 3/94)
  9326.  
  9327. Development Tools
  9328.  
  9329. Persistence supports all major C++ compilers and integrates with GE's
  9330. OMTool, allowing developers to go straight from an object model to a
  9331. running C++ application.
  9332. - Cfront 2.1: ObjectCenter 1.0, SPARCompiler, ObjectWorks
  9333. - Cfront 3.0: ObjectCenter 2.0, SPARCompiler, Softbench C++
  9334. - GE's OMTool
  9335.  
  9336. Databases
  9337.  
  9338. Persistence provides database independence. With our Objectivity
  9339. integration, we also provide a clear migration path to object
  9340. databases.
  9341. - Oracle V6, V7
  9342. - Sybase 4.x
  9343. - Ingres 6.x
  9344. - Objectivity ODBMS
  9345. - Informix (planned 9/93)
  9346. - ODBC (planned 3/94)
  9347.  
  9348.                             CUSTOMER QUOTES
  9349.  
  9350. "We wanted to use object technology while continuing to support our
  9351. legacy systems. Persistence made this feasible by automating over 30
  9352. percent of our development cycle." Steve Hunter, Sterling Software
  9353.  
  9354. "Persistence cut our development time by approximately 40%, because we
  9355. would have had to do all the mapping functions ourselves." Jim
  9356. Adamczyk, Partner, Andersen Consulting
  9357.  
  9358. "I'm convinced we'll save weeks or months of time because of
  9359. Persistence." Mike Kubicar, SunSoft Defect Tracking Team
  9360.  
  9361. "The good thing is that you can change your object model and just
  9362. re-generate the database interface classes at the press of a button."
  9363. Richard Browett, Product manager, K2 Software Developments, Ltd.
  9364.  
  9365. "The Persistence package saved at least 25 to 50 percent of the
  9366. development time, and seemed extremely robust. Support has been nothing
  9367. short of phenomenal." Stew Schiffman, DuPont Research and Development
  9368.  
  9369.                         FOR MORE INFORMATION
  9370.  
  9371. For more information on Persistence, please contact Carl White, VP Sales:
  9372. - By phone: (415) 341-1280
  9373. - By fax: (415) 341-8432 
  9374. - By email: information@persistence.com
  9375.  
  9376. Persistent Data Systems
  9377. PO Box 38415
  9378. Pittsburgh, PA  15238-9925
  9379.  
  9380.  
  9381. > Subtleware
  9382.                  SUBTLEWARE(TM) FOR C++
  9383.  
  9384.           Connecting C++ with Relational Databases
  9385.  
  9386.  
  9387. Subtleware for C++ (Subtleware) is a software development toolset which 
  9388. openly automates C++ connectivity to relational databases by providing:
  9389.  
  9390. *  A C++ pre-processor that automatically generates the code necessary 
  9391.    to read and write C++ objects to a relational database.
  9392.  
  9393. *  A schema mapper that defines C++ classes from relational database 
  9394.    schema, and
  9395.  
  9396. *  A class library that simplifies C++ application access to existing 
  9397.    relational data,
  9398.  
  9399.  
  9400. SUBTLEWARE INCREASES PROGRAMMER PRODUCTIVITY
  9401.  
  9402. Subtleware vastly simplifies the coding necessary for C++ to work with 
  9403. relational databases: 
  9404.  
  9405. *  It jump starts application development by generating C++ class 
  9406.    definitions from relational database schema.
  9407.  
  9408. *  It speeds application development by eliminating the need to 
  9409.    write hundreds of lines of database mapping code per class. 
  9410.  
  9411. *  It dramatically reduces application maintenance time by eliminating
  9412.    the need to modify the database mapping code with each C++ class 
  9413.    definition change. 
  9414.  
  9415. As a result, C++ application developers can focus on what brings value to 
  9416. their organization, application development; and, C++ application 
  9417. development projects can reduce their development costs as well as speed 
  9418. their time-to-market.
  9419.  
  9420.  
  9421. SUBTLEWARE IS DESIGNED TO BE OPEN
  9422.  
  9423. *  Subtleware adds value to your C++ development environment!  
  9424.    Subtleware fits into your existing C++ development environment by 
  9425.    working with your preferred C++ design tools, compilers, and class 
  9426.    libraries. No Subtleware-specific design tools are necessary.
  9427.  
  9428. *  Subtleware works directly with your existing C++ class definitions!
  9429.  
  9430. *  Subtleware adds value to your relational database systems!  
  9431.    Your C++ applications can work concurrently and share data with 
  9432.    your other relational database applications. Subtleware makes your
  9433.    existing relational database into a powerful OODBMS.
  9434.  
  9435. *  Subtleware library source code and generated code is freely 
  9436.    available!  No run-time fees are imposed.
  9437.  
  9438.  
  9439. SUBTLEWARE IS WIDELY AVAILABLE
  9440.  
  9441. Subtleware runs on a wide range of computing platforms:
  9442. *  PC's running Windows 3.x, Windows NT, OS/2, and DOS.
  9443. *  Unix workstations, including Sun and HP.
  9444.  
  9445. Subtleware supports a variety of database interfaces:
  9446.   *  ANSI SQL                *  ODBC
  9447.   *  Oracle                  *  Sybase 
  9448.   *  Watcom                  *  Informix (planned 8/95)
  9449.   *  Ingres (planned 10/95) 
  9450.   *  ODMG (planned 12/95)
  9451.  
  9452. Subtleware supports virtually all C++ 2.x and 3.x compilers, including:
  9453. *  Borland C++
  9454. *  Microsoft Visual C++
  9455. *  HP C++
  9456. *  SunPro C++
  9457.  
  9458.  
  9459. SUBTLEWARE IMPROVES SOFTWARE QUALITY
  9460.  
  9461. Subtleware generates well-documented, bug-free code. Furthermore, 
  9462. Subtleware code generation can be customized for your application 
  9463. requirements. Using Subtleware greatly increases the reliability and 
  9464. reusability of your applications.
  9465.  
  9466.  
  9467. SUBTLEWARE OPTIMIZES APPLICATION PERFORMANCE
  9468.  
  9469. Subtleware generates static SQL code that can be linked directly into your 
  9470. application or packaged as a DLL or shared library. Subtleware does not 
  9471. require the use of high-overhead, run-time modules for managing your 
  9472. persistent objects.
  9473.  
  9474.  
  9475. SUBTLEWARE PROVIDES RUN-TIME FLEXIBILITY
  9476.  
  9477. Subtleware offers dynamic SQL capabilities for performing run-time 
  9478. specified data access.
  9479.  
  9480.  
  9481. SUBTLEWARE MAXIMIZES APPLICATION PORTABILITY
  9482.  
  9483. Subtleware is database independent. Your applications use the same 
  9484. Subtleware API no matter which underlying database is being used. 
  9485. Changing your database simply entails linking in another Subtleware 
  9486. database support module to your application.
  9487.  
  9488.  
  9489. TECHNICAL DETAILS
  9490.  
  9491. The Subtleware pre-processor converts C++ classes to relational database 
  9492. schema:
  9493.  
  9494.   C++ Class ------> Subtleware Pre-Processor -----> Relational Database Schema
  9495.  
  9496.  
  9497. The Subtleware SQLExec facility simplifies C++ access to existing 
  9498. relation data:
  9499.  
  9500.   C++ Code <-------------> Subtleware SQLExec ----------> Legacy Data
  9501.  
  9502.  
  9503. The Subtleware schema mapper converts relational database schema to 
  9504. C++ classes:
  9505.  
  9506.   Relational Schema -----> Subtleware Schema Mapper ------> C++ Class
  9507.  
  9508.  
  9509. OBJECT MODEL SUPPORT
  9510.  
  9511. Subtleware supports encapsulation, inheritance, containment, and polymorphism. 
  9512. A C++ class is mapped to a table in a relational database. Each member 
  9513. data variable (local, inherited, or contained) is mapped to a column in 
  9514. the database table.
  9515.  
  9516.  
  9517. ASSOCIATION SUPPORT
  9518.  
  9519. Subtleware provides a set of Subtle Pointer classes for persisting one-to-
  9520. one relationships between objects. Each Subtle Pointer class offers a 
  9521. unique set of behavior regarding pointer chasing and referential 
  9522. integrity constraints. Subtle Pointers "swizzle" associations into in-
  9523. memory pointers, speeding object traversal.
  9524.  
  9525.  
  9526. COLLECTION SUPPORT
  9527.  
  9528. Subtleware provides a set of Subtle Collection classes for persisting N-
  9529. to-many relationships between objects. Each Subtle Collection class 
  9530. offers a unique data structure abstraction. 
  9531.  
  9532.  
  9533. CONCURRENCY CONTROL SUPPORT
  9534.  
  9535. Subtleware utilizes the data locking mechanisms of the underlying 
  9536. relational database. Concurrency is specified by the database isolation 
  9537. level or locking protocol in-use.
  9538.  
  9539.  
  9540. TRANSACTION SUPPORT
  9541.  
  9542. Subtleware supports transaction commit and rollback support. When a 
  9543. transaction is committed, all Subtleware database operations are 
  9544. performed. When a transaction is rolled back, all Subtleware database 
  9545. operations are ignored.
  9546.  
  9547.  
  9548. DEVELOPMENT TOOL SUPPORT
  9549.  
  9550. Subtleware supports all major C++ compilers and development 
  9551. environments. Subtleware works with any C++ development tool that 
  9552. generates or uses C++ header files (class definitions) and offers 
  9553. customized integration with Cadre's OT for Rumbaugh, allowing 
  9554. developers to go straight from an object model to a running C++ 
  9555. application.
  9556.  
  9557.  
  9558. FOR MORE INFORMATION
  9559.  
  9560. For more information on Subtleware, please contact Frank Yacano:
  9561.  
  9562. By phone: (617) 558-4100
  9563. By fax: (617) 558-4103 
  9564. By email: subtle@world.std.com
  9565.  
  9566.  
  9567. > Synchronicity
  9568.  
  9569. See Databases & Development Sept. 5, 1994, p1. 
  9570.  
  9571. "Lisp, Smalltalk Languages Given Database Systems"
  9572.  
  9573. Easel's Synchronicity 2.0 is a new release of the company's business object
  9574. modeling system, fromerly known as Synchrony.  The new version, which will
  9575. run under Windows and OS/2, lets developers using Easel's Enfin development
  9576. system map Smalltalk objects to relational databases.
  9577.  
  9578. Easil is at 617-221-2100.
  9579.  
  9580.  
  9581. APPENDIX C  OBJECT-ORIENTED LANGUAGES AND VENDORS
  9582. =================================================
  9583.  
  9584. See also APPENDIX D.
  9585.  
  9586. FORMAT:
  9587.     tool name, 
  9588.     description and methods
  9589.     operating systems
  9590.     Vendor name, 
  9591.     city/state, phone (if known)
  9592.  
  9593. ACTOR ($495)
  9594. ------------
  9595. *Prototyping & Code generation (ACTOR, access to C, Pascal)
  9596. *IBM PS/2, PC AT/XT
  9597. The Whitewater Group Inc.
  9598. 600 Davis, Evanston, IL 60201
  9599.  
  9600. Allegro CL
  9601. ----------
  9602. *Advanced Object Oriented Development System based on CLOS.  Incremental
  9603.  compiler; automatic memory management; integrated editor, debugger class
  9604.  browsers, and profilers; multiple inheritance, method combination, multiple
  9605.  argument discrimination, meta-object protocol.
  9606. *Unix workstations (Sun/Sparc, IBM RS/6000, HP, Silicon Graphics)
  9607.  PCs with Microsoft Windows
  9608. Franz Inc.
  9609. 1995 University Avenue
  9610. Berkeley, CA 94704
  9611. (510) 548-3600, FAX (510) 548-8253
  9612. Email info@franz.com
  9613.  
  9614. Bootcon
  9615. -------
  9616. *DOS
  9617. Modular Software System
  9618.  
  9619. CaseVision
  9620. ----------
  9621. *Browser, Static Analysis, no compiler (yet), Editor Debugger, Profiler, ... 
  9622. Silicon Graphics
  9623.  
  9624. Classic-Ada
  9625. -----------
  9626. *Object-Oriented Ada Environment (to Ada translator)
  9627. Software Productivity Solutions
  9628. (407) 984-3370.
  9629.  
  9630. Comeau C++ 3.0.1 With Templates
  9631. -------------------------------
  9632. * compiler
  9633. * many OS's (MS-DOS, AmigaDOS, UNIX (SVR4, SPARC, UNIX 386, etc), etc)
  9634. Comeau Computing
  9635. 91-34 120th Street
  9636. Richmond Hill, NY 11418-3214
  9637. 718-945-0009, comeau@csanta.attmail.com
  9638.  
  9639. Distributed Smalltalk (HP)
  9640. --------------------------
  9641. *ParcPlace's VisualWorks Extension, world's first complete implementation of
  9642. *the OMG CORBA 1.1.
  9643. European Knowledge Systems Centre (HP's European software tools specialists)
  9644. ph:    44 272 228794
  9645. email: wjb@hplb.hpl.hp.com
  9646.  
  9647. Dylan (Dynamic Language)
  9648. ------------------------
  9649. *Apple's language with dynamic power but with efficiency of static languages.
  9650. *Not proprietary, many impls.
  9651. *ftp site includes experimental implementations, the FAQ, literature, etc.
  9652. *See also Appendix E.
  9653. *Apple. Under way: Windows, Unix.
  9654. http://www.cambridge.apple.com.
  9655. ftp://cambridge.apple.com/pub/dylan
  9656. try: straz@apple.com, Steve Strassmann, PhD
  9657.  
  9658. Energize (5 $16250, single $4250, lcc 1500)
  9659. -------------------------------------------
  9660. *Debugger, Class Language Calltree Error Project Browsers
  9661. *SunOS 4.1
  9662. Lucid
  9663. 707 Laurel St.
  9664. Menlo Park, CA 95025
  9665. (415) 329-8400
  9666.  
  9667. Frameworks 3.1 ($495.)
  9668. ----------------------
  9669. *IDE, Browser, Debugger, Compiler, ...
  9670. *DOS, Windows
  9671. Borland International
  9672. 1800 Greenhills Road
  9673. Scotts Valley, CA  95067
  9674. 800-331-0877
  9675.  
  9676. FUSE ($1560 C++, $1944 FUSE)
  9677. ----------------------------
  9678. *Distr Builds, Editor, Debugger, Profiler, Call Graphs, Call Tree Animation,
  9679.  Browser, ...
  9680. *Ultrix RISC, OSF/1 AXP  (planned to alpha NT)
  9681. DEC
  9682. 14475 Northeast 24th St.
  9683. Bellvue, WA 98007
  9684.  
  9685. GNU GCC (g++)
  9686. -------------
  9687. *C++ compiler, (non-graphical) debugger.
  9688. *Unix
  9689. prep.ai.mit.edu:/pub/gnu/gcc-2.4.5.tar.gz
  9690.  
  9691. GNU GCC (g++)
  9692. -------------
  9693. *C++ compiler, (non-graphical) debugger.
  9694. MS-DOS
  9695. grape.ecs.clarkson.edu:/pub/msdos/djgpp/djgpp.zip 
  9696.  
  9697. Hamilton C-Shell
  9698. ----------------
  9699. *A shell
  9700. *OS/2, Windows
  9701. Hamilton Labs
  9702.  
  9703. HighC/C++ (basic $795, w/Phar Lap $995)
  9704. ---------------------------------------
  9705. *Editor, Debugger, Windows ADK, Unix Utilities, Speedkit
  9706. *Unix
  9707. MetaWare Inc.
  9708. 2161 Deleware Ave.
  9709. Santa Cruz, CA  95060
  9710. (408) 429-6382
  9711.  
  9712. Iconix Power Tools
  9713. ------------------
  9714. *Multiuser, OO development toolset
  9715. *Macintosh
  9716. Iconix Software Engineering
  9717. Santa Monica, Ca.
  9718.  
  9719. MetaC
  9720. -----
  9721. *testing tool, code coverage, lint-style chking, C, C++, tests mem alloc errors
  9722.  QASE (Quality Assured Software Engineering)
  9723. 938 Willowleaf Dr.
  9724. Suite 2806
  9725. San Jose, CA 95128
  9726. (408) 298-3824 ext. 5
  9727.  
  9728. MKS Toolkit
  9729. -----------
  9730. *Make, ...
  9731. *PC (Unix-Like)
  9732. MKS
  9733.  
  9734. NEXPERT
  9735. -------
  9736. *GUI-type builder, rule based, objects, classes, subclasses, rule inheritance,
  9737.  embedded, but you can call external routines. 
  9738. Neuron Data Elements 
  9739. From: jrp@accint.com (Jason R. Pascucci)  (abstract from a post)
  9740.  
  9741. NextStep
  9742. --------
  9743. *Application, DB, Windows, Indexing, 3D Graphics Kits, Project and Interface
  9744.  Builder, Viewers, Modelers, Compilers/Debuggers, Performance, PostScript, ...
  9745. *Next, 486, ???
  9746. Next Computer, Inc.
  9747. 900 Chesapeake Drive
  9748. Redwood City, CA 94063
  9749. 800-TRY-NEXT
  9750.  
  9751. ############################################################################
  9752.  
  9753.  
  9754. Path: senator-bedfellow.mit.edu!faqserv
  9755. From: Bob Hathaway <rjh@geodesic.com>
  9756. Newsgroups: comp.object,comp.answers,news.answers
  9757. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Part 9/13
  9758. Supersedes: <object-faq/part9_805979999@rtfm.mit.edu>
  9759. Followup-To: comp.object
  9760. Date: 31 Aug 1995 15:32:53 GMT
  9761. Organization: Geodesic Systems
  9762. Lines: 1427
  9763. Approved: news-answers-request@MIT.Edu
  9764. Distribution: world
  9765. Expires: 14 Oct 1995 15:31:54 GMT
  9766. Message-ID: <object-faq/part9_809883114@rtfm.mit.edu>
  9767. References: <object-faq/part8_809883114@rtfm.mit.edu>
  9768. NNTP-Posting-Host: bloom-picayune.mit.edu
  9769. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  9770. X-Last-Updated: 1995/06/01
  9771. Originator: faqserv@bloom-picayune.MIT.EDU
  9772. Xref: senator-bedfellow.mit.edu comp.object:37591 comp.answers:13979 news.answers:51860
  9773.  
  9774. Archive-name: object-faq/part9
  9775. Last-Modified: 05/31/94
  9776. Version: 1.0.8
  9777.  
  9778. ObjectCenter
  9779. ------------
  9780. *C++ programming environment, high quality graphics, browser, debugger,
  9781.  interpreter.
  9782. *Sun, ???
  9783. CenterLine
  9784. (kendall@)centerline.com
  9785.  
  9786. ObjectIQ
  9787. --------
  9788. *OO devel environ. Objects, rules, debugger, browser, GUI builder, more.
  9789. *RAD and intelligent decision support applications.
  9790. European Knowledge Systems Centre (HP's European software tools specialists)
  9791. ph:    44 272 228794
  9792. email: wjb@hplb.hpl.hp.com
  9793.  
  9794. ObjectWorks, VisualWorks
  9795. ------------------------
  9796. *Smalltalk programming environment from the Smalltalk people.
  9797. ParcPlace Systems, Inc.
  9798. 999 E. Arques Avenue
  9799. Sunnyvale, CA 94086
  9800. email:    info@parcplace.com
  9801. fax:    1-408-481-9095
  9802. voice:    1-800-759-PARC
  9803.  
  9804. OpenTalk
  9805. --------
  9806. *Smalltalk to C++ and C Translator.
  9807. TNI Industries (Techniques Nouvelles d'Informatique)
  9808. ZI du Vernis
  9809. 29200 Brest
  9810. France
  9811. tel 98 05 24 85, fax 98 49 45 33
  9812.  
  9813. OST/Look
  9814. --------
  9815. *C++ program animator.
  9816. *Suns, PCs, others coming.
  9817. Admiral Software
  9818. 193-199 London Road
  9819. Camberley
  9820. Surrey
  9821. UK
  9822. Tel: (44) (276) 692269
  9823. Fax: (44) (276) 677533
  9824.  
  9825. Prograph
  9826. --------
  9827. *OO visual programming environment
  9828. *Macintosh
  9829. TGS Systems
  9830. Halifax, Nova Scotia
  9831. 902-455-4446
  9832.  
  9833. SDE WorkBench/6000 ($918 - $7350)
  9834. ---------------------------------
  9835. *Editor (syntax Highlighting), Browser, Flow Grapher, Make, Test Coverage
  9836.  Analysis, Debugger, Profiler, ...
  9837. *HP Apollo 9000, Sparcstations
  9838. IBM, Canada
  9839. PRGS Toronto Laboratory
  9840. 895 Don Mills Road
  9841. North, York
  9842. Ontario, Canada, M3C 1W3
  9843. 800-IBM-CALL
  9844.  
  9845. SNAP
  9846. ----
  9847. *Template based devel. environment for building distributed OO applications
  9848. Template Software Inc.
  9849. 13100 Worldgate Drive, Suite 340
  9850. Herndon, VA  22070-4382
  9851. (703) 318-1000
  9852.  
  9853. SNiFF+
  9854. ------
  9855. *C/C++ development environment with fuzzy parser, Emacs integration and code
  9856.  browsers, free to universities.  See APPENDIX E, TOOLS AND CASE
  9857. *SunOS 4.x, Solaris 2.x, AIX 3.2, HP/UX 8.0/9.0
  9858. takeFive Software
  9859. Jakob-Haringer-Strasse 8
  9860. 5020 Salzburg, AUSTRIA
  9861. phone: +43 662 457 915
  9862. fax:   +43 662 457 915 6
  9863. email: sniff@takefive.co.at
  9864.  
  9865. SoftBench ($1785 C++, $4500 Softbench)
  9866. --------------------------------------
  9867. *C++ class constructor, CASE (graphically modify C++), Browser, Analyzer,
  9868.  Editor, Builder, Debugger, ...
  9869. HP
  9870. 3404 E. Harmony Rd. MS 81
  9871. Fort Collins, CO 80525
  9872. 800-845-0070
  9873. or
  9874. Cupertino, Ca.
  9875. 800-752-0900 ext. 2707
  9876. or 303-229-2255
  9877.  
  9878. SparkWorks ($1995, $995 C++)
  9879. ----------------------------
  9880. *Debugger, Profiler, Source Browser, File Merge, MakeTool
  9881. *Suns
  9882. SunPro
  9883. 2550 Garcia Ave.
  9884. Mountain View, CA 94043
  9885. (800) 926-6620
  9886.  
  9887. TowerEiffel
  9888. -----------
  9889. *Advanced software engineering and development system for Eiffel.  Includes
  9890.  a high performance Eiffel 3 compiler, programming environment and tools,
  9891.  GUI Builder, ODBMS Interface, and reusable software libraries for data
  9892.  structures, graphics, and simulation.
  9893. *Available for SunOS, Solaris, NEXTSTEP, Linux, OS/2, and Windows.  Plans for
  9894.  OSF, AIX, and SGI Iris.
  9895. Tower Technology Corporation
  9896. 1501 West Koenig Lane
  9897. Austin, Texas 78756   USA
  9898. TEL: 800 285 5124 or 512 452 9455
  9899. FAX: 512 452 1721
  9900. email: tower@twr.com
  9901. www: http://www.cm.cf.ac.uk/Tower/
  9902.  
  9903. Zortech C++ v. 3.1 ($499)
  9904. -------------------------
  9905. *Debugger, Workbench, Resource Workshop
  9906. *PCs?
  9907. Symantec Corp
  9908. 10201 Torre Ave.
  9909. Cupertino, CA 95014
  9910. (408) 253-9600
  9911.  
  9912.  
  9913. APPENDIX D  OBJECT-ORIENTED CASE (OOA/D/P TOOLS) AND VENDORS
  9914. ============================================================
  9915.  
  9916. See also APPENDIX C.
  9917.  
  9918. Below is a list of available OO CASE environments.  Many thanks to James Odell
  9919. <71051.1733@compuserve.com> for his extensive list and to Ron Schultz
  9920. <ron@bse.com> for a list posted to comp.object on 9/13/92.  Many additional
  9921. entries have been added and additional entries are encouraged; please send
  9922. additions and updates to the author of the FAQ (and/or to James and Ron).
  9923.  
  9924. Second is a collection of articles, products, and papers on CASE systems.
  9925. These appeared as posts to comp.object.
  9926.  
  9927. I. graphic-only OO-CASE
  9928. •    EasyCASE
  9929. •    HOOD Toolset
  9930. •    Model 5w
  9931. •    Stood
  9932. •    TurboCASE
  9933.  
  9934. II. OO-CASE with some code generation (1 to 60%)
  9935. •    AdaVantage
  9936. •    Bachman/Analyst
  9937. •    BOCS
  9938. •    EiffelCase
  9939. •    HOMSuite
  9940. •    IE\O (canceled)
  9941. •    ILOG KADS Tool
  9942. \067    Intelligent OOA (?)
  9943. •    MacAnalyst/Designer
  9944. •    ObjectCraft
  9945. \067    Object Domain
  9946. •    Objecteering
  9947. •    ObjectModeler
  9948. •    ObjecTool
  9949. •    Object Oriented Designer
  9950. •    ObjectOry
  9951. •    ObjectTeam
  9952. •    OEW
  9953. •    OMTool
  9954. •    OOSD
  9955. •    OOTher
  9956. •    Prosa/om
  9957. •    Rational Rose
  9958. •    S-CASE
  9959. •    Select/OMT
  9960. •    SES/Objectbench
  9961. •    System Architect
  9962. •    VIEWS-SF
  9963. •    Westmount I-CASE OMT
  9964. •    001
  9965.  
  9966. III. Meta OO-CASE (CASE that builds CASE)
  9967. •    Envision
  9968. •    Excelerator II
  9969. •    GraphTalk
  9970. •    MetaEdit
  9971. •    Object Maker
  9972. •    Paradigm Plus
  9973. •    Toolbuilder
  9974.  
  9975. IV.  Full execution OO-CASE
  9976. •    BridgePoint
  9977. \067    ObjectGEODE
  9978. •    ObjecTime
  9979. •    Ptech
  9980. •    OMW
  9981.  
  9982. Available CASE Systems
  9983.  
  9984. FORMAT:
  9985.     tool name, 
  9986.     description and methods
  9987.     operating systems(price, if known)
  9988.     vendor name, 
  9989.     vendor contact information
  9990.  
  9991. 001
  9992. ---
  9993. *Object-oriented, full life cycle CASE
  9994. *VAX/VMS, Unix ($24,000)
  9995. Hamilton Technologies Inc
  9996. 17 Inman St., Cambridge MA  01239
  9997. (617) 492-0058
  9998.  
  9999. AdaVantage ($1095--$1780)
  10000. -------------------------
  10001. *analysis, design (Ada) Generators: production code, Ada compiler and tool set
  10002.  reusable components library
  10003. *PC AT/XT, Mac, Unix Workstations
  10004. Meridian Software Systems, Inc.
  10005. 23141 Verdugo Dr., Ste 105, Laguna Hills CA 92653
  10006.  
  10007. Bachman Data Analyst
  10008. --------------------
  10009. *Data Modeling and analysis with OO support
  10010. *PC-DOS, OS/2, Unix
  10011. Bachman Information Systems
  10012. 8 New England Executive Park, Burlington, MA  01803
  10013. (617) 273-9003
  10014.  
  10015. BOCS
  10016. ----
  10017. *Semantic Nets, Object-Message Diagrams, State Transition Diagrams, Petri-Nets
  10018. *Generates C++
  10019. *PC-DOS, OS/2, Windows Macintosh ($595)
  10020. Berard Software Engineering 
  10021. 902 Wind River Lane, Suite 203
  10022. Gaithersburg, MD  20878
  10023. 301-417-9884
  10024.  
  10025. BridgePoint
  10026. -----------
  10027. *Shlaer/Mellor notation
  10028. *general purpose code generator from"Action Language" psuedo code
  10029. *based on user-defined templates
  10030. *simulation tool
  10031. *Unix ($6,000)
  10032. Objective Spectrum
  10033. 901 Kildaire Rd
  10034. Cary, NC  27511
  10035. (919) 460-1500
  10036. (919) 380-6463 (fax)
  10037.  
  10038. EasyCASE
  10039. --------
  10040. *Parts of Shlaer/Mellor method plus lots of other non-OO notations
  10041. *Windows, DOS ($495 to $1,295)
  10042. Evergreen CASE Tools, Inc
  10043. 8522 154th Ave NE
  10044. Redmond, WA  98052
  10045. (206) 881-5149
  10046. (206) 883-7676 (fax)
  10047.  
  10048. EiffelCase
  10049. ----------
  10050. *ISE's BON (Better Object Notation)
  10051. *Generates Eiffel class templates
  10052. *Unix, Windows NT ($1,995)
  10053. Interactive Software Engineering, Inc
  10054. 270 Storke Road, Suite 7
  10055. Goleta, CA  93117
  10056. (805) 685-1006
  10057. (805) 685-6869 (fax)
  10058.  
  10059. Envision
  10060. --------
  10061. *Methodology independent, user defined.  Meta-CASE.  Template code
  10062.  generation.  Examples include BPR, Yourdon/ER, OMT.
  10063. *Windows,NT,OS/2,(Chicago),Network Servers (8,000 Single, Multiple discounts).
  10064. Future Tech Systems (Leon Stucki)
  10065. 824 E. Main
  10066. Auburn, Washington 98002
  10067. (206) 939-7552
  10068. (206) 735 6763 (fax)
  10069.  
  10070. Excelerator II
  10071. --------------
  10072. *Odell/Martin, Rumbaugh, Jacobson, and Wirfs-Brock notation
  10073. *Can customize and mix parts of on approach with another in a user-friendly manner
  10074. *LAN, meta-CASE with customizable graphics and rules
  10075. *OS/2, Windows NT ($9,500)
  10076. Intersolv, Inc
  10077. 3200 Tower Oaks Blvd
  10078. Rockville, MD  20852
  10079. (301) 230-3200
  10080. (301) 231-7813(fax)
  10081.  
  10082. GraphTalk
  10083. ---------
  10084. *many notations (IE, NIAM, HOOD, Merise, SADT)
  10085. *configurable meta-CASE tool
  10086. *executable code generation of C (via enhanced pseudo code) and GQL
  10087. *Sun, DEC, RS6000, UNIX, Motif, PS/2, PC 386, OS/2
  10088. Rank Xerox
  10089. AI & CASE Division
  10090. 7, rue Touzet Gaillard
  10091. 93586 Saint-Ouen Cedex
  10092. France
  10093. +33 (1) 494 85085
  10094.  
  10095. HOMSuite
  10096. --------
  10097. *responsibility-driven design
  10098. *Generates C++ and Smalltalk/V
  10099. *Windows ($595)
  10100. Hatteras Software Inc
  10101. 208 Lochside Dr
  10102. Cary, NC  27511
  10103. (919) 851-0993
  10104.  
  10105. HOOD Toolset (design only)
  10106. --------------------------
  10107. *HOOD notation
  10108. *Unix, DOS
  10109. CASET Corporation
  10110. 33751 Connemara Dr
  10111. San Juan Cap., CA  92693
  10112. (714) 496-8670
  10113.  
  10114. IE\O IEF (IE\O canceled)
  10115. ------------------------
  10116. *OO version of IEF.  IEF now handles some OO CASE?
  10117. *OS/2 
  10118. Texas Instruments
  10119. 1-800-336-5236
  10120.  
  10121. ILOG KADS Tool
  10122. --------------
  10123. *knowledge-based system (KBS) approach named KADS, part is OO to
  10124. *capture knowledge, part involves rules that capture decision-making logic,
  10125. *generates C++
  10126. *Unix, DEC VMS
  10127. ILOG
  10128. 2, ave Gallieni, BP 85
  10129. 94523 Gentilly Cedex
  10130. France
  10131. +33 1 4663-6666
  10132. +33 1 4663-1582 (fax)
  10133.  
  10134. Intelligent OOA
  10135. ---------------
  10136. *Shlaer/Mellor notation
  10137. *general purpose code generator from"Action Language" psuedo code
  10138. *based on user-defined templates
  10139. *simulation tool
  10140. *Unix
  10141. Kennedy-Carter (in the U.K.)
  10142. Contact Tracy Morgan on
  10143.     44-181-947-0553
  10144. or fax
  10145.     44-181-944-6536
  10146. or mail tracy@kc.com
  10147.  
  10148. LOV/Object Editor
  10149. -----------------
  10150. *Rumbaugh notation
  10151. *generates C++
  10152. *interfaces with Verilog product suite
  10153. *Unix, OSF/Motif
  10154. Logiscope, Inc.
  10155. 3010 LBJ Freeway, Suite 900
  10156. Dallas, TX  75234
  10157. (214) 241-6595
  10158. (214) 241-6594
  10159.  
  10160. MacAnalyst and MacDesigner
  10161. --------------------------
  10162. *various notations
  10163. *screen prototyping
  10164. *Macintosh ($995-2,590)
  10165. Excel Software
  10166. PO Box 1414
  10167. Marshalltown, IA
  10168. (515) 752-5359
  10169. (515) 752-2435 (fax)
  10170.  
  10171. MetaEdit
  10172. --------
  10173. *Analysis and design tool that supports most available structured
  10174.  and OO analysis and design methods, and can be easily customized. 
  10175.  OO methods supported: Booch, Coad/Yourdon, Demeter, Rumbaugh, OSA and MOSESA.  
  10176. *MetaEdit is available for MS-Windows 3.1 (499$ - 1500$).
  10177. MetaCase Consulting OY
  10178. P.O. Box 449
  10179. Ylistünmîentie
  10180. FIN-40101 Jyvîskylî
  10181. Finland
  10182. tel. & fax. +358-41-650 400
  10183. http://www.jsp.fi/metacase
  10184.  
  10185. [The shareware version can be found from Simtel, Cica, and their mirrors. The
  10186.  version 1.0 is shareware but the latest version 1.1 is fully commercial.]
  10187.  
  10188. [MetaEdit 1.1 - MetaCase Consulting Oy - metacase@jsp.fi
  10189.                 shareware version "metaed10.zip" can be ftp'd from ftp.funet.fi
  10190.                 (other sites also have the file, check archie)]
  10191.  
  10192. Model 5w 
  10193. --------
  10194. *prototype, free with purchase of OOA text "The Problem Space".
  10195.  GUI front end for integrated repository supporting OO requirements
  10196.  analysis, including events, rules, participants, and locations.
  10197. *Windows 3.X under DOS or OS/2
  10198. Dan Tasker Consulting
  10199. Sydney, Australia
  10200. Phone/Fax +61 2 909-8961
  10201. dant@swdev.research.otc.com.au
  10202.  
  10203. ObjectCraft
  10204. -----------
  10205. *OOT's own graphic notation
  10206. *Generates C++ 
  10207. *DOS ($99)
  10208. Object-Oriented Technologies
  10209. 2124 Kittredge St,  Suite 118
  10210. Berkeley,  CA  94704
  10211. (415) 759-6270 (voice/fax)
  10212.  
  10213. Object Domain
  10214. -------------
  10215. *Booch notation (All diagrams:class,object,state,process,module and
  10216.  interaction diagrams)
  10217. *generates C++ headers and stubs
  10218. *MS-Windows 3.1
  10219. *Shareware US $99.00 
  10220. *See Appendix E
  10221. Dirk Vermeersch
  10222. 1397 Ridgewood Drive
  10223. San Jose, CA 95118
  10224. dirkv@netcom.com
  10225.  
  10226. Objecteering
  10227. ------------
  10228. *Softeam's "Class Relation" approach notation
  10229. *Generates C++ ("up to 60%"), open with multiple, concurrent user
  10230. *Sun, DEC, HP, RS6000, Unix, X Windows/Motif ($9,500)
  10231. Softeam
  10232. One Kendall Square, #2200
  10233. Cambridge, MA  02139
  10234. (617) 621-7091
  10235. (617) 577-1209 (fax)
  10236.  
  10237. ObjectGEODE
  10238. ------------------
  10239. *OMT, ITU's SDL and MSC methodology notations
  10240. *Object and Use Cases Analysis, Architectural, Data and Behavioral 
  10241. Design
  10242. *Rapid prototyping, Verification and Validation through Simulation,
  10243. *Full C/C++ code generation for most popular embedded RT systems
  10244. *ObjectGEODE runs on: SparcStation/SunOS & Solaris, HP/HPUX, 
  10245. RS6000/AIX, DecAlpha/OSF1 (From $10,000)
  10246. Logiscope, Inc.
  10247. 3010 LBJ Freeway, Suite 900
  10248. Dallas, TX 75234
  10249. (214) 241 6595
  10250. 800 424 3095
  10251. (214) 241 6594 (fax)
  10252. support@logtech.com
  10253.  
  10254. ObjecTime  
  10255. ---------
  10256. *ROOM methodology (Real-Time Object-Oriented Modelling) notation
  10257. *OO state charts with methods specified in own Smalltalk-like language or C++
  10258. *generates Smalltalk, C, C++ and interfaces with C++ environment
  10259. *internally used product by Bell-Northern for several years
  10260. *full code generation for embedded RT systems
  10261. *Unix  ($20,000 includes training and support)
  10262. ObjecTime Limited
  10263. 340 March Road, Suite 200
  10264. Kanata, Ontario,
  10265. Canada K2K 2E4
  10266. (613) 591-3400
  10267.  
  10268. ObjectMaker
  10269. -----------
  10270. *supports many diagramming notations
  10271. *customize methods, checking, and semantics with external rules
  10272. *configurable meta-CASE tool
  10273. *Cobol, Ada, C, and C++ generation (shell) and reverse engineering
  10274. *Macintosh, VAX, Windows 3, X Windows/Motif ($8,000 to $25,000)
  10275. Mark V Systems Ltd
  10276. 16400 Ventura Blvd
  10277. Encino, Ca.
  10278. (818) 995-7671
  10279.  
  10280. ObjectModeler
  10281. -------------
  10282. *Rumbaugh, Coad/Yourdon, Jacobson and Booch notation
  10283. *multiple, concurrent user
  10284. *generates SQL, C++, Smalltalk templates
  10285. *Macintosh, Unix ($1,495›5,995)
  10286. Iconix Software Engineering
  10287. 2800 28th St.,  Suite 320
  10288. Santa Monica, CA  90405
  10289. (310) 458-0092
  10290.  
  10291. ObjecTool (was OOA/OODTool), Together/C++(new)
  10292. -----------------------------------------------
  10293. *Coad/Yourdon, Object-oriented analysis.  ObjectTool (Startup tool)
  10294. *Windows, OS/2, HP/Sun Unix.
  10295. *Together/C++ (Windows only) Code/Design integration.
  10296. Object International, Inc.
  10297. 8140 N. MoPac Expwy
  10298. Austin, Tx  78759-6535
  10299. 800-926-9306
  10300. (512) 795-0202
  10301. (512) 795-0332 (fax) 
  10302.  
  10303. Object Oriented Designer (Freeware: See Appendix E:66)
  10304. ------------------------------------------------------
  10305. *Only object model (with some extension) of Rumbaugh notation
  10306. *generates C++
  10307. *primitive graphics editor
  10308. *Unix machine(SunSparc, HP, Solaris, Linux, RS6000)
  10309. *written by C++ with OSF/Motif 1.2
  10310. *freeware 
  10311. *obtainable from any ftp.x.org site (/contrib/devel_tools/OOD)
  10312.     and from ASSET project
  10313. *a little unreliable
  10314. Prof. Taegyun Kim (ktg@taejo.pufs.ac.kr)
  10315. Pusan Univ. of Foreign Studies
  10316. 55-1 Uam-Dong Pusan 608-738 Korea
  10317. 82 (051) 640-3178
  10318.  
  10319. Objectory 
  10320. ---------
  10321. *Jacobson notation.
  10322. *Generates C++, CMM support.
  10323. *Windows, OS/2, Unix, 4 configurations, $5000.00 - $10000.00 (USD)
  10324. Objectory AB
  10325. Torshamnsgatan 39, 
  10326. Mail Box 1128, S-164 ss
  10327. Kista
  10328. Sweden
  10329. support@os.se
  10330.  
  10331. ObjectTeam (also Teamwork)
  10332. --------------------------
  10333. *Shlaer/Mellor, Rumbaugh (a "special edition" of Paradigm Plus)
  10334. *SQL, ADA, Smalltalk, C, and C++ generation
  10335. *VAX/VMS, Unix, OS/2, PC-DOS  Rumbaugh: PC($4000)/Unix($8000),
  10336. *SM: Unix (1 at a time) 
  10337. *Demo Tutorial, Eval copies.  ATM example + others.
  10338. Cadre Technologies, Inc
  10339. 222 Richmond St.,
  10340. Providence, RI
  10341. (401) 351-5950
  10342. (401) 455-6800 (fax)
  10343.  
  10344. OEW (Object Engineering Workbench)  
  10345. ----------------------------------
  10346. *Martin/Odell object diagrams
  10347. *generates C++ (templates unless supplemented with C coded methods)
  10348. *reverse engineers C++
  10349. *Sun OS, PC Windows 3.x ($99-$2190)
  10350. Innovative Software GmbH
  10351. Niddastr. 66-68
  10352. 6000 Frankfurt/M 1
  10353. Germany
  10354. +49 60 236 929
  10355. +49 69 236930 (fax)
  10356.  
  10357. OOTher
  10358. ------
  10359. *Coad/Yourdon OOA, FSM(subset of SDL), Jacobson's Use Case and Object
  10360. * Interaction diagrams.  Consistency, C++ header gen. from OOA.
  10361. *MS-Windows 3.1
  10362. *Freeware for students/schools/home users. Corp 1-5 Shareware (USD $170).
  10363. *See Appendix E, entry 67
  10364. Roman M. Zielinski <conrozi@kk90.ericsson.se>
  10365. Tre Kaellors Vaeg 7
  10366. S-145 65 Norsborg
  10367. Sweden
  10368.  
  10369. OMW (Object Management Workbench)
  10370. ---------------------------------
  10371. *draws and executes from Martin/Odell diagrams
  10372. *produces fully executable ANSI C environment
  10373. *UI construction facilities, "object engine" for managing objects
  10374. *AI "rule engine" for managing rules 
  10375. *interfaces with multiple databases
  10376. *Unix; generated code runs on any ANSI C environment ($5,000-25,000) 
  10377. IntelliCorp
  10378. 1975 El Camino Real West 
  10379. Mountain View, CA  94025 
  10380. (415) 965-5500
  10381. (415) 965-5647 (fax)
  10382.  
  10383. OMTool (see also StP/OMT)
  10384. --------------------------
  10385. *OMTool(tm) version 2.0 (Object Modeling Tool, Rumbaugh) PC-based graphical
  10386.  tool for OO analysis and design. graphical prep and editing of object models
  10387.  for systems, programs, databases using the OMT.
  10388. *8MB mem/math coproc(16MB without), Windows 3.1, Mouse, Hard Disk with 4 MB of
  10389.  available disk space, 386 CPU, Video Graphics Adapter.
  10390. *Price: $995.00 US.
  10391. Martin Marietta Advanced Concepts Center
  10392. 640 Freedom Business Center
  10393. King of Prussia, PA 19406
  10394.   +1 (610) 992-6200, 
  10395.   +1  800  438-7246, 
  10396.   +1 (610) 992-6299  (FAX) 
  10397.   
  10398. OSMOSYS
  10399. -------
  10400. *OOA and OOD for OSMOSYS
  10401. Winter Partners
  10402. London Office:                 Zurich Office:
  10403.   West Wing, The Hop Exchange
  10404.   24a Southwark Street           Florastrasse 44
  10405.   London SE1 1TY                 CH-8008 Zurich
  10406.   England                        Switzerland
  10407.   Tel. +44-(0)71-357-7292        Tel. +41-(0)1-386-95 11
  10408.   Fax. +44-(0)71-357-6650        Fax. +41-(0)1-386-95 00
  10409.  
  10410. Paradigm Plus
  10411. -------------
  10412. *CASE toolset supporting Booch(new), Coad/Yourdon, EVB, and others.
  10413. *configurable meta-CASE tool
  10414. *Rev eng code.  Gen code templates.  Incr code gen next release, year end.
  10415. *Windows: Fixed/1 machine, $3995, maint $599. Floating/net $4995, maint $750.
  10416. *Unix: $7770, $1155 maint.    Multiple discounts.
  10417. *Eval, Demo, 30 day eval copy.
  10418. Protosoft
  10419. 17629 El Camino Real 202
  10420. Houston TX 77058
  10421. 713 480 3233
  10422. Fax 713 480 6606
  10423.  
  10424. Prosa/om
  10425. --------
  10426. *Coad/Yourdon notation
  10427. *Generates C++, SQL
  10428. *Windows, OS/2,  Motif 
  10429. Prosa Software
  10430. Kirkkokato 5 B
  10431. SF-90100 Oulu, FInland
  10432. +358 (81) 376-128
  10433. +358 (81) 371-754
  10434.  
  10435. Ptech
  10436. -----
  10437. *Martin/Odell notation
  10438. *modifiable meta-model
  10439. *supports Martin/Odell notation, "data model is the database", C++ and Ontos
  10440.  or Objectivity code generation (fully executable code), formal foundation
  10441. *Unix, ($5,000-25,000)
  10442. Ptech, Inc.
  10443. 200 Friberg Parkway
  10444. Westborough, MA 01581  USA
  10445. (508) 366-9166
  10446.  
  10447. Rational Rose
  10448. -------------
  10449. *Booch notation OOA/D
  10450. *generates C++
  10451. *Unix, AIX ($749-5,249)
  10452. *(PC version formerly sold by Palladio Software)
  10453. Rational
  10454. 3320 Scott Blvd.
  10455. Santa Clara, Ca.  95054
  10456. (408) 496-3700
  10457. Also:
  10458. *C++ Booch Components 1-800-767-3237 ext. 23
  10459.  
  10460. S-CASE
  10461. ------
  10462. *Booch-93 notation
  10463. *generates C++ headers and stubs
  10464. *project management aids, multi-user
  10465. *Windows, OSF/Motif, Open Look, Macintosh ($249-995)
  10466. MultiQuest Corp
  10467. 1699 E. Woodfield Rd Suite A-1
  10468. Schaumburg, IL  60173
  10469. (708) 240-5555, (708) 240-5556 (fax)
  10470.  
  10471. Select OMT
  10472. ----------
  10473. *Rumbaugh notation
  10474. *generates C++
  10475. *Windows ($695)
  10476. Select Software Tools, Ltd
  10477. 1526 Brookhollow Dr.
  10478. Santa Ana, CA  92705
  10479. (714) 957-6633; (714) 957-6219
  10480.  
  10481. SES/Objectbench
  10482. ---------------
  10483. *Shlaer/Mellor notation, supports GUI and database links editors, browsers,
  10484.  test utilities, and statistical analysis for simulation development.
  10485.  Emphasizes importance of model animation to functionally verify the analysis.
  10486. *generates C++
  10487. *Macintosh, MS-DOS, UNIX ($4,900 to $24,300)
  10488. Software & Engineering Software (SES)
  10489. 4301 Westbank Dr., Bldg A, Austin, TX 78746
  10490. (512) 328-5544, (512) 327-6646 (fax)
  10491.  
  10492. Stood
  10493. -----
  10494. *HOOD (version 3.1) notation, supports Ada, C, C++
  10495. *Unix, RISC, X windows
  10496. Techniques Nouvells d'Informatique
  10497. Technopole Brest-Iroise
  10498. ZI du Vernis, Case postale 1
  10499. 29608 Brest Cedex, France
  10500. +33 9 8052744, +33 9 849-4533 (fax)
  10501.  
  10502. StP/OMT - Software through Pictures
  10503. -----------------------------------
  10504. *Member of StP family of integrated multi-user software development tools.
  10505.  Developed jointly by MM ACC and IDE. Open architecture, object- and system-
  10506.  level designs, reuses existing class structures to build applications.
  10507.  Stand-alone or part of OMT Success Packages which combines training,
  10508.  consulting, mentoring, and maintenance in addition to software.  Shared
  10509.  repository, version control and locking, code and document generation.
  10510. *StP/OMT runs on; AIX, DECstation, RS/6000, Sun OS, SPARCstation, HP 700/800,
  10511.  and Sun Solaris.
  10512. *Price: $12,000.00 US
  10513. Interactive Development Environments.
  10514. 595 Market Street, 10th Floor
  10515. San Francisco, CA 94105
  10516. +1 (415) 543-0900, 
  10517. +1  800  888-4331
  10518.  
  10519. System Architect
  10520. ----------------
  10521. *Booch, Coad/Yourdon, Shlaer-Mellor.
  10522. *design portion specific to Smalltalk, Ada, Object Pascal, and C++
  10523. *dialogues and menu management (Windows, C, C++),  DB views (SQL, C++),
  10524.  other (C++)
  10525. *Windows ($1395, single User), OS/2($1795, base).
  10526. Popkin Software
  10527. 11 Park Place
  10528. New York, NY  10007
  10529. (212) 571-3434
  10530. (212) 571-2426 (fax)
  10531.  
  10532. Toolbuilder
  10533. -----------
  10534. *many notation (IE, HOOD, SSADM, Shlaer-Mellor)
  10535. *configurable meta-CASE tool
  10536. *executable code generation of C, C++, Cobol, ADA (via enhanced design-level
  10537.  action diagrams) and Motif and Open Look
  10538. *interfaces  to Sybase, Oracle, Informix
  10539. *Sun Sparc, Apollo, HP 9000, DECstation, RS6000 ($17,000)
  10540. IPSYS Software
  10541. 28 Green St.
  10542. Newbury, MA 01951
  10543. (508) 463-0006
  10544. IPSYS Software plc
  10545. Marlborough Court
  10546. Pickford Street
  10547. Macclefield, Cheshire 
  10548. SK11 6JD  U. K.
  10549. +44 (625) 616722
  10550.  
  10551. TurboCASE
  10552. ---------
  10553. *ER diagrams and state charts
  10554. *design portion supports class hierarchy, collaboration
  10555. *Macintosh ($995)
  10556. StructSoft
  10557. 5416 156th Ave SE
  10558. Bellevue, WA  98006
  10559. 206-644-9834
  10560.  
  10561. VIEWS-SF
  10562. --------
  10563. *supports VSF's extensive approach (including rules) some of which are based on other popular notations
  10564. *C++ template generation, reverse engineerings 
  10565. *OS/2, Unix ($8,000›$23,500)
  10566. Virtual Software Factory, Inc
  10567. 13873 Park Center Rd, #218
  10568. Herndon, VA  22071
  10569. (703) 318-1180
  10570.  
  10571. Westmount I-CASE OMT
  10572. --------------------
  10573. *Rumbaugh notation
  10574. *generates SQL and C++
  10575. *multi-developer
  10576. *WIndows
  10577. *Open repository (Informix, Ingres, Sybase)
  10578. *Documentation and report generation
  10579. Westmount Technology B.V.
  10580. Olof Palmestraat 24
  10581. P.O.Box 5063
  10582. 2600 GB  DELFT
  10583. The Netherlands
  10584. Tel. (+31) (0)15 - 141212
  10585. Fax. (+31) (0)15 - 120267
  10586. Westmount USA Inc.
  10587. 1555 Wilson Blvd.,
  10588. Suite 300,
  10589. Arlington, VA 22209,
  10590. U.S.A.
  10591. Tel. (+1) 703 875 8799
  10592. Fax. (+1) 703 527 5709
  10593.  
  10594.  
  10595. ARTICLES, PRODUCTS, AND PAPERS ON CASE SYSTEMS
  10596. ----------------------------------------------
  10597.  
  10598. > "CASE Products 1990: A survey of CASE Products from US Vendors",
  10599.   Arbeitspapiere der GMD 518, March, 1991.  Heinz W. Schmidt,
  10600.  
  10601. Ovum Ltd
  10602. 1 Mortimer Street
  10603. London W1N 7RH
  10604. England
  10605. Tel: +44 71 255 2670
  10606. Fax: +44 71 255 1995
  10607.  
  10608. From: oil@idt.unit.no (Odd Ivar Lindland)
  10609. Subject: Re: CASE Survey
  10610. Organization: Norwegian Institute of Technology, University of Trondheim
  10611. Date: Fri, 9 Jul 93 06:57:25 GMT
  10612. >...
  10613. A comprehensive survey of 35 commercial CASE tools is given in 
  10614. "Ovum evaluates: CASE products". It is from 1993 and is continuously updated. 
  10615. It has all the information you asked for. The bad thing is that it is very
  10616. expensive ($1995 !!!). You should get a 40 % academic discount, however.
  10617. Moreover, recently they had a "quick-answer discount" making the full price
  10618. (before academic discount) $1295. Anyway, I believe it is good investment if you
  10619. quickly want to have comprehensive information about the current CASE market.
  10620. Particularly valuable is the comparative evaluation of the 35 products.
  10621.  
  10622.  
  10623. > Proceedings of the Workshop on the Next Generation of CASE Tools (NGCT)
  10624.  
  10625. From: sjbr@cs.utwente.nl (Sjaak Brinkkemper)
  10626. Subject: 
  10627. Organization: University of Twente, Dept. of Computer Science
  10628. Date: Fri, 9 Jul 1993 11:05:51 GMT
  10629.  
  10630. The proceedings of the Fourth Workshop on the Next Generation of
  10631. CASE Tools (NGCT'93) are available as a technical report from the
  10632. Center for Telematics and Information Technology, University of
  10633. Twente.
  10634.  
  10635. Price: Nfl 45, US$ 25 (including shipping and money transfer)
  10636.  
  10637. Order by sending a message including a POSTAL ADDRESS to:
  10638. Sjaak Brinkkemper
  10639. CTIT
  10640. E-mail: sjbr@cs.utwente.nl
  10641.  
  10642. *******************************************************
  10643. *      Proceedings of the Fourth Workshop on the      *
  10644. *           Next Generation of CASE Tools             *
  10645. *     Universite Paris 1 Sorbonne - 7/8 June 1993     *
  10646. *******************************************************
  10647.  
  10648. Editors: S. Brinkkemper and F. Harmsen
  10649. Center for Telematics and Information Technology
  10650. University of Twente
  10651. the Netherlands
  10652. 174 pages
  10653.  
  10654. Abstract
  10655.  
  10656. The Workshop on the Next Generation of CASE Tools (NGCT) is an
  10657. annual event, bringing together leading researchers on Computer
  10658. Aided Software Engineering (CASE). NGCT workshop is a pre-conference
  10659. workshop of the annual Conference on Advanced Information Systems
  10660. Engineering (CAiSE). The goal of this year's workshop, held in
  10661. Paris, is to conduct an in-depth discussion of research approaches
  10662. in the area of Computer Aided Software Engineering. Three main
  10663. themes have been identified: 
  10664. *       CASE architectures
  10665. *       Development process support
  10666. *       Advanced requirements engineering
  10667. The workshop committee accepted fourteen papers, which are grouped
  10668. in the proceedings according to these three themes. Among the topics
  10669. of the papers are: multiparadigm specification for interoperable
  10670. information systems, capturing design decisions, automated user
  10671. interface derivation, deductive repositories, human error analysis,
  10672. and business modeling.
  10673.  
  10674.  
  10675.  
  10676. APPENDIX E  ANONYMOUS FTP SITES
  10677. ===============================
  10678.  
  10679. These are anonymous ftp sites of interest to the OO community.  Thanks go to
  10680. Mike DeVaney (dm_devaney@pnl.gov gen ftp site list) and to Bill Kinnersley
  10681. (billk@hawk.cs.ukans.edu, anon ftp programming languages list), whose initial
  10682. lists helped to get things going.  Additional short entries are encouraged;
  10683. please send additions to the author of the FAQ (and/or to Mike and Bill).
  10684.  
  10685. Entries will be standardized and summarized in future FAQs and are not
  10686. limited to one category.
  10687.  
  10688. Starred entries have a summary below and can be found as ">#" followed by the
  10689. description.  These entries will eventually be cleaned up.
  10690.  
  10691. PROGRAMMING LANGUAGES
  10692. ---------------------
  10693.  
  10694. ajpo.sei.cmu.edu:/public/ada95                  Ada95 info, ARM
  10695. cs.nyu.edu:pub/gnat/...                        *Ada95 (compiler, GNU,50)
  10696. ftp.inria.fr:lang/alcool                       *Alcool-90 (dyn ML,1)
  10697. arjuna.ncl.ac.uk:/pub/Arjuna                   *Arjuna (Distr Prog System,2)
  10698. munnari.oz.au:pub/bebop.tar.Z                  *BeBOP(seq,par,LP,OO,meta,46) 
  10699. sales@mjolner.dk                                BETA (Mjolner Informatics Demo)
  10700. monch.edrc.cmu.edu:/usr0/snl/archive/bos-1.2   *BOS (prototyping,3)
  10701. grape.ecs.clarkson.edu:/pub/msdos/djgpp/djgpp.zip C++ (for MS-DOS)
  10702. prep.ai.mit.edu:/pub/gnu/gcc-2.4.5.tar.gz       C++ (for Unix, & Objective-C)
  10703. cambridge.apple.com/pub/dylan                  *Dylan (Dynamic Language,75)
  10704. omnigate.clarkson.edu:/pub/msdos/djgpp         *G++ for DOS (Many sites,4)
  10705. tsbgw.isl.rdc.toshiba.co.jp:
  10706.   pub/toshiba/cooc-beta.1.1.tar.Z              *cooC (Concurrent, OO C ext.,5)
  10707. parcftp.xerox.com:pcl                           CLOS
  10708. pion.lcs.mit.edu                                CLU (Sun, VAX)
  10709. ftp.cs.cornell.edu:/pub/CML-0.9.tar.Z           CML
  10710. arisia.xerox.com                                Pcl (Portable CommonLoops)
  10711. xcf.berkeley.edu:src/local/fmpl                *FMPL (prototyping,6)
  10712. nebula.cs.yale.edu                              Glasgow Haskell
  10713. piggy.cs.chalmers.se                            Chalmers Haskell (hbc)
  10714. software.watson.ibm.com                         Hermes (Unix)
  10715. cs.arizona.edu                                  Icon
  10716. sun.soe.clarkson.edu                            ISETL (DOS, Mac, Unix, VMS,src)
  10717. http://java.sun.com/index.html                *Java (Distr Prog, 81)
  10718. cs.orst.edu                                     Little Smalltalk (C src)
  10719. ftp.ircam.fr:/pub/IRCAM/programs               *MAX (visual OO,7)
  10720. 128.59.24.6 (MeldC@cs.columbia.edu)             MeldC (Rflctv, prllel, OO lang)
  10721. gatekeeper.dec.com                              Modula-3 (SRC)
  10722. cs.uni-sb.de:/pub/osmall/machine               *O'small (OO lang for teaching,8)
  10723. neptune.inf.ethz.ch                             Oberon (MacII, SPARC, DECstn)
  10724. wuarchive.wustl.edu:/mirrors/msdos/pgmutl/oberon11.zip Oberon (MS-DOS)
  10725. ux1.cso.uiuc.edu:pub/amiga/fish/ff380           Oberon (Amiga)
  10726. obj3dist@csl.sri.com (license or request)      *OBJ3 (OO lang,9)
  10727. prep.ai.mit.edu:/pub/gnu/gcc-2.4.5.tar.gz       Objective-C (for Unix, & C++)
  10728. gate.fzi.de:/pub/OBST                          *OBST (lang, perst, OODB,10)
  10729. watserv1.waterloo.edu                           occam (VAX sim, Tahoe)
  10730. 128.100.1.192:/pub/ootDistrib                  *OOT (OO Turing demo,11)
  10731. wuarchive.wustl.edu:/mirrors/unix-c/languages/ops5 OPS5 (interpreter)
  10732. etlport.etl.go.jp:/pub/OZ++/OZ++-R2.tar.gz     *OZ++ (Distr Env,83)
  10733. http://www.cs.tcd.ie/acourtny/phantom/phantom.html *Phantom (Dist Prog,80)
  10734. wuarchive.wustl.edu:/mirrors/msdos/pli/runpli1a.arc PL/I (interpreter)
  10735. watserv1.waterloo.edu                           Russell
  10736. parcftp.xerox.com:pub/russell                   Russell
  10737. ftp.icsi.berkeley.edu:pub/sather               *Sather (was simple Eiffel,12)
  10738. altdorf.ai.mit.edu: scm                         Scheme (small, portable)
  10739. gatekeeper.dec.com: elk                         Scheme (for Suns)
  10740. acorn.cs.brandeis.edu: gambit                   Scheme (for 68K's)
  10741. otis.stanford.edu                              *Self (13)
  10742. self.stanford.edu                               Self
  10743. cs.nyu.edu                                      SETL2 (DOS, OS/2, Mac, Unix)
  10744. rascal.ics.utexas.edu                           SIMULA 67 (Mac)
  10745. prep.ai.mit.edu:pub/gnu                         Smalltalk-80 (GNU v1.1)
  10746. st.cs.uiuc.edu                                 *Smalltalk V (35)
  10747. cs.yale.edu:pub/ml                              SML/NJ
  10748. research.att.com:dist/ml                        SML (Version 0.75)
  10749. sbcs.sunysb.edu                                 SML (lazy)
  10750. ucbvax.berkeley.edu                             tcl
  10751. tk.telematik.informatik.uni-karlsruhe.de:/pub/tnt/tnt-0.1.tar.gz *Trellis,69
  10752. ftp.cs.umu.se:/pub/umlexe01.zoo                 uML
  10753.  
  10754. csd4.csd.uwm.edu:/pub/compilers/list            Free Compilers/Interp's list
  10755. primost.cs.wisc.edu: pub/comp.compilers/LanguageList*  Bill Kinnersley's list
  10756. idiom.berkeley.ca.us: pub/compilers-list/LanguageList*
  10757. http://cui_www.unige.ch/langlist                Bill on Prog Langs & contacts
  10758. ftp://ftp.wustl.edu/doc/misc/lang-list.txt      (billk@hawk.cs.ukans.edu)
  10759.  
  10760. See also Knowledge Media cd-rom collection on Languages, entry 47.
  10761.  
  10762.  
  10763. COMPILER TOOLS
  10764. --------------
  10765.  
  10766. prep.ai.mit.edu:pub/gnu/bison-1.14.tar.Z        Yacc
  10767. ftp.th-darmstadt.de:/pub/programming/languages/C++ *C++ gram, etc.,14
  10768.   [See also Free Compilers and Kinnersley's List above!]
  10769.  
  10770.  
  10771. DATABASES (See also APPENDIX B)
  10772. -------------------------------
  10773.  
  10774. ftp.informatik.rwth-aachen.de:pub/CB            *ConceptBase (OODB, reqkey,15)
  10775. pippin.cs.monash.edu.au:pub/export/diamond-0.1.2.tar.Z  *C++ OODB (16)
  10776. wilma.cs.brown.edu/pub/encore.tar.Z              Encore of Brown Univ
  10777. ftp.cs.wisc.edu:exodus                          *Exodus (Storage Man, perst,17)
  10778. ftp.informatik.rwth-aachen.de:/pub/unix/GRAS522_3 *GRAS (18)
  10779. mood.mech.tohoku.ac.jp                          *MOOD   (OODB, lim arch,19)
  10780. src.doc.ic.ac.uk:/computing/databases            MOOD/Postgres/OBST copies
  10781. gate.fzi.de:/pub/obst                           *OBST/STONE(schema,prst obj,10)
  10782. research.att.com                                *Ode    (C++ OODB,20)
  10783. postgres.berkeley.edu:pub                       *POSTGRES (Ext. Rel. DBMS,21)
  10784. toe.CS.Berkeley.EDU:pub/postgres                *POSTGRES,21
  10785. cs.utexas.edu:pub/garbage/{swizz,texaspstore}.ps *Texas Persistent Store,41
  10786.  
  10787. See also idiom.berkeley.ca.us:pub/free-databases or
  10788. ftp.idiom.com:/pub/free-databases, object-oriented databases.
  10789.  
  10790.  
  10791. TOOLS AND CASE
  10792. --------------
  10793.  
  10794. ftp.cs.purdue.edu:/pub/gb/*                     *C++ Signatures (subtyping),40
  10795. ftp.centerline.com:/pub/tags-1.0.tar.Z          *C++ tags, 23
  10796. ftp.th-darmstadt.de:/pub/programming/languages/C++ *Cls bwsr,tmplates,GC,etc,14
  10797. ftp.informatik.uni-stuttgart.de:/pub/eiffel     *Eiffel archive, 24
  10798. interviews.stanford.edu:/pub/3.1.tar.Z           InterViews 3.1 (C/C++ browser)
  10799. oak.oakland.edu:/SimTel/win3/pgmtools/domain.zip*Object Domain (SW Case,76)
  10800. export.lcs.mit.edu:/contrib/devel_tools/OOD     *OO Designer CASE Tool,66
  10801. OAK.Oakland.Edu:pub/msdos/windows3/oot-106f.zip *OOTher OO CASE Tool,67
  10802. wsmr-simtel20.army.mil(192.88.110.20)            OOTool (win31 directory?)
  10803. labrea.stanford.edu:/pub/pomoco                 *ORBELINE: CORBA,65
  10804. ftp.informatik.uni-stuttgart.de:/pub/eiffel/eiffel-3/sig *short tool, 24
  10805. siam.unibe.ch:C++/Sniff1.6/                     *Sniff (C++ devel environ,22)
  10806. self.stanford.edu:/pub/sniff                    *Sniff,22
  10807.  
  10808.  
  10809. LIBRARIES AND INTERFACES
  10810. ------------------------
  10811.  
  10812. butler.hpl.hp.com:stl                        *C++ STL, Std. Temp. Lib.,79
  10813. arjuna.ncl.ac.uk                             *C++SIM (Simula-like Sim Pkg,38)
  10814. csc.ti.com:pub/COOL.tar.Z                    *COOL(C++, orig from TI,25)
  10815. cs.utexas.edu:pub/COOL/GE_COOL2.1.tar.Z      *COOL(C++, Cfront 2.1, from GE,25)
  10816. ftp.fu-berlin.de:/pub/unix/languages/cool/cool-2.1.tar.Z *CooL Soft Prod Env,70
  10817. omg.org:pub/NEC_DII/93-1-2...                 CORBA (DII)
  10818. claude.ifi.unizh.ch:under pub/standards/spec  CORBA Spec
  10819. omg.org:pub/OMG_IDL_CFE_1.2/bin              *idl.SunOS4.x, idl.Solaris2.x,26
  10820. ftp.cica.indiana.edu:/pub/pc/win3/programr   *MindFrame for Windows,54
  10821. ftp.th-darmstadt.de:pub/programming/languages/C++ *NIHCL COOL OATH ET++,etc,14
  10822. ftp.th-darmstadt.de:pub/programming/languages/C++/class-libraries/OSE
  10823.                          *OSE:C++ Prog tools & Class Lib,42
  10824. watmsg.UWaterloo.ca:pub/uSystem              *u++:C++ Trans. and Concry RTS,48
  10825.  
  10826.  
  10827.  
  10828.  
  10829. DOCUMENTATION AND INFO SERVERS
  10830. ------------------------------
  10831.  
  10832. ftp.ncsa.uiuc.edu:Web/xmosaic or info.cern.ch:pub/www  *Browser for OO info,27
  10833. ftp.th-darmstadt.de:/pub/programming/languages/C++ *C++ docs, code, net sums,14
  10834. ftp.cm.cf.ac.uk:pub/Eiffel                     Eiffel FAQ
  10835. zaphod.uchicago.edu:/pub/faq.8-25[.Z]          OO FAQ (this document)
  10836. http://cui_www.unige.ch/OSG/FAQ/OO-FAQ/       *OO FAQ(hypertext version),WWW,27
  10837. http://cui_www.unige.ch/OSG/OOinfo/           *OO Information sources on WWW,27
  10838. byron.sp.cs.cmu.edu:/usr/anon/OODBMS/evolution-summary OODB Schema Evol Summary
  10839. byron.sp.cs.cmu.edu:/usr/anon/OODBMS/Manifesto.{PS,txt}.Z OODB Manifesto
  10840. http://osiris.sunderland.ac.uk/rif/metacase/metacase.home.html
  10841.                                               *Meta-Case Info,78
  10842.  
  10843. PAPERS
  10844. ------
  10845.  
  10846. ftp.cs.tcd.ie:/pub/tcd/tech-reports                 *Amadeus,persistence,62
  10847. scslwide.sony.co.jp:pub/CSL-Papers                  *Apertos (MO Distr OS,28)
  10848. sail.stanford.edu:pub/MT/93actors.ps.Z              *Actors Paper (UIUC,29)
  10849. biobio.cs.uiuc.edu:directory pub/papers             *Actors Papers,29
  10850. euagate.eua.ericsson.se:ftp/pub/eua/c++/rules.ps.Z  *C++ coding standard,44
  10851. http://www.cs.washington.edu/research/projects/cecil/www/cecil-home.html
  10852.                                                     *Cecil,77
  10853. choices.cs.uiuc.edu                                  Choices OO OS
  10854. ftp.chorus.fr:pub/chorus-reports                    *Chorus,Dist,RT,MicroK,63
  10855. http://cui_www.unige.ch/Chloe/Oscar/home.html        Concurrency Papers,WWW,27
  10856. ftp.ens.fr:/pub/reports/liens/liens-94-18.A4.dvi.Z  *Contra-/Co- Variance,71
  10857. ftp.gte.com:pub/dom                                 *Distrib Reports GTE,52
  10858. ftp.ifi.unizh.ch: pub/techreports/electra.ps.Z       Electra ORB, sec 3.8.6
  10859. cs.utexas.edu:pub/garbage/gcsurvey.ps                Garbage Collection,sec 3.9
  10860. wilma.cs.brown.edu:/pub/gdbiblio.{tex,ps}.Z         *graph drawing,31
  10861. world.std.com:/pub/kala/TechDocs/Overview_Sun.ps,*  *Kala Archive,45
  10862. ftp.ccs.neu.edu:pub/demeter/documents               *Law of Demeter,32
  10863. ftp.cs.ualberta.ca:pub/oolog/state.ps.Z              MUTABLE STATE OOPL SURVEY
  10864. mushroom.cs.man.ac.uk:/pub/mushroom/papers          *OO Dyn Grping, memory,33
  10865. st.cs.uiuc.edu:/pub/papers                           OO Frameworks, R. Johnson
  10866. http://pclsys64.dcrl.nd.edu/papers                   OS Papers (OO?),68
  10867. http://www.gh.cs.su.oz.au/Grasshopper/index.html     Perst. Operating Systems
  10868. cs.washington.edu:/pub/chambers/predicate-classes.ps.Z *Pred Classes (Cecil,34)
  10869. ftp.cs.umd.edu:pub/sel/papers                        *Quality,72
  10870. ftp.informatik.uni-stuttgart.de/pub/doc/techreports/Metrics.ps.gz *Quality,73
  10871. ginger.cs.berkeley.edu/pub/raidPapers                RAID Papers  (Berkeley) 
  10872. sprite.(cs.)berkeley.edu:~ftp/pub/RAID-II            RAID configs (Berkeley) 
  10873. ius4.ius.cs.cmu.edu:/usr/chimera/public/CMU_RI_TR_93_11.ps.Z *Real Time,49
  10874. ftp://ftp.gte.com/pub/dom/reports/MANO93d.ps        *Reflection Paper,82
  10875. self.stanford.edu:pub/papers/chambers-thesis        *Self Opt,ChambersThesis,30
  10876. self.stanford.edu:/pub/papers/hoelzle-thesis.ps.Z   *Self Opt,HoelzleThesis,64
  10877. self.stanford.edu:pub/papers/                        Self Papers
  10878. vega.dur.ac.uk:/pub/papers/foot.dvi                  Testing OO (sect 3.11)
  10879. townsend@mprgate.mpr.ca                              Testing OO (sect 3.11)
  10880. ftp.parc.xerox.com:/pub/mops/traces.ps              *Traces,kiczales,MOP,DI,43
  10881. neptune.inf.ethz.ch: pub/issac93.ps.Z                Types, Comp alg (Santas)
  10882. cui.unige.ch:OO-articles                             U. Geneva OO Group papers
  10883. research.microsoft.com:/pub/papers/vdg.ps           *Value Dependence Graphs,57
  10884. ftp.cs.utwente.nl:/pub/doc/TRESE                    *Various on OO,58
  10885.  
  10886.  
  10887.  
  10888. The Postgres, OBST and Exodus sites also contain a good selection of papers. 
  10889. See below for a huge collection of CS bibliographies (about 290,000) including
  10890. references on OO.  Contact: Alf-Christian Achilles <achilles@ira.uka.de>
  10891.   FTP: ftp.ira.uka.de[129.13.10.90]:pub/bibliography
  10892.   WWW: http://www.ira.uka.de/ftp/ira/bibliography/index.html
  10893.  
  10894.  
  10895. GENERAL
  10896. -------
  10897.  
  10898. ics.uci.edu:gnu/C++_wrappers.tar.Z    *ACE Lib, C++ Networking,55
  10899. scslwide.sony.co.jp:pub/CSL-Papers    *Apertos(Meta-Obj Distr OS, research,28)
  10900. euagate.eua.ericsson.se:ftp/pub/      *Archive site,C++,Coplien,papers,etc,44
  10901. research.att.com:dist/drawdag/*.Z     *Graph service,37
  10902. parcftp.parc.xerox.com:/pub/ilu/ilu.html *ILU OMG CORBA,59
  10903. netcom.com:/pub/softia/keobj.zip      *KEOBJ, OO DSP micro-kernel,53
  10904. ftp.th-darmstadt.de:/pub/programming/languages/C++ *lots for C++,14
  10905. st.cs.uiuc.edu                        *Manchester Archive and some,35
  10906. gatekeeper.dec.com:/pub/usenet/com.sources.unix/volume20/metrics *Metrics,61
  10907. ftp.odi.com:/pub/oo7/results.ps       *Object Design's OO7 Results,36
  10908. ftp.gmd.de:gmd/peace                   Peace, OO parallel OS
  10909. http://www.taligent.com                Taligent
  10910. cs.orst.edu:pub/budd/oopintro/slides/* *Teaching Intro to OO Slides, T. Budd,56
  10911. wuarchive.wustl.edu:languages/ada/crsware *Teaching OO Course Slides,51
  10912. fcoallie@qc.bell.ca                    *TRILLIUM (CMM,74)
  10913.  
  10914.  
  10915. OTHER
  10916. -----
  10917.  
  10918. Knowledge Media                       *Big col. on cd-roms, lots of freeware,47
  10919. Computer Select Database              *commercial on cd-rom,39
  10920. Walnut Creek                          *Internet Info CDROM, including FAQs,60
  10921. godot.uvic.ca:/pub/oopsla-93           OOPSLA-93 Info
  10922.  
  10923.  
  10924. DESCRIPTIONS
  10925. ------------
  10926.  
  10927. >1  Alcool-90 (dyn ML)
  10928.  
  10929. What: Alcool-90 Release 0.40.3
  10930. From: rouaix@inria.fr (Francois Rouaix)
  10931. Date: 18 May 92 09:36:22 GMT
  10932.  
  10933. Alcool-90 is an experimental extension of ML with run-time overloading and
  10934. a type-based notion of modules, functors and inheritance.
  10935.  
  10936. New constructs have been added:
  10937.         * Overloaded symbols (overload).
  10938.         * Local definition of abstract values (overload in).
  10939.         * Implementations and parametric functors (pack to). 
  10940.         * Extension functors (overload with).
  10941.         * Class-based Dynamics (dynamic).
  10942.  
  10943. This version of Alcool is based on the CAML Light implementation (release
  10944. 0.4) of the ML language, but this release is autonomous.
  10945.  
  10946. Alcool-90 is available by anonymous FTP from ftp.inria.fr:
  10947.  
  10948.     host:      ftp.inria.fr  (128.93.1.26)
  10949.     directory: lang/alcool
  10950.     files:
  10951.      README                 Copyright information.
  10952.      alcool270492.tar.Z     Sources for Un*x machines (Apr 27 1992 Release).
  10953.      alcooldoc.dvi.tar.Z    DVI for the Alcool-90 report draft.
  10954.  
  10955. For questions, comments, bug reports, please e-mail to Francois.Rouaix@inria.fr
  10956.  
  10957.  
  10958. >2  Arjuna (Distr Prog System)
  10959.  
  10960. What: Release 2 of Arjuna Distributed Programming System
  10961. From: arjuna@newcastle.ac.uk (Arjuna Project)
  10962. Date: Mon, 17 May 1993 12:37:34 GMT
  10963.  
  10964.         We are pleased to announce the  availability  of a new  version 
  10965. of Arjuna:  a programming system for  reliable  distributed  computing, 
  10966. and the Arjuna mailing list.
  10967.  
  10968.         The software  and the manual  for  the  Arjuna  system  can  be 
  10969. obtained by anonymous ftp: arjuna.ncl.ac.uk (128.240.150.1)
  10970.  
  10971. Arjuna System
  10972.  
  10973.         This beta release of  ArjunaPR2.0  fixes all known bugs present 
  10974. in ArjunaPR1.2B that have  been  reported to us or  that we have found, 
  10975. and contains only minimal information about how to use the new features 
  10976. provided.   This  release  should  be  compilable  with  the  following 
  10977. compilers:
  10978.  
  10979.         AT&T Cfront Release 2.1, on SunOS 4.1.x,
  10980.             (using Sun supplied lex and yacc).
  10981.         AT&T Cfront Release 3.0.1, on SunOS 4.1.x and Solaris 2.1,
  10982.             (using Sun supplied lex and yacc).
  10983.         GCC versions 2.1, 2.2.2, on SunOS 4.1.x,
  10984.             (using flex(v2.3.x) and bison).
  10985.         Patched GCC version 2.3.3 on SunOS 4.1.x and Solaris 2.1,
  10986.             (using flex(v2.3.x) and bison).
  10987.         Sun C++ 2.1, on SunOs 4.1.x,
  10988.             (using Sun's lex++ and yacc++).
  10989.         HP  C++ (B2402 A.02.34), HP-UX 8.07,
  10990.             (using HP supplied lex and yacc or lex++ and yacc++).
  10991.  
  10992. The major new features are:
  10993.  
  10994.         - Faster object store.
  10995.         - Support for replicated objects.
  10996.         - Memory resident object store.
  10997.         - Support for ANSAware (not available via ftp)
  10998.  
  10999.         Arjuna supports nested atomic actions (atomic transactions) for 
  11000. controlling operations on objects (instances of C++ classes), which can 
  11001. potentially be persistent. Arjuna has been implemented in C++ to run on 
  11002. stock  platforms  (Unix  on  SUNs,  HPs  etc).  The  software available 
  11003. includes  a C++  stub generator  which hides  much  of the  details  of 
  11004. client-server  based  programming,  plus  a system  programmer's manual 
  11005. containing  details of  how  to  install  Arjuna and  use it  to  build 
  11006. fault-tolerant  distributed  applications.  The software and the manual 
  11007. can be obtained by anonymous ftp: arjuna.ncl.ac.uk (128.240.150.1)
  11008.  
  11009.         Several  enhancements   and   ports  on   various   distributed 
  11010. computing platforms are in progress.  We would be pleased  to hear from 
  11011. researchers and teachers  interested in using Arjuna.  The programmer's 
  11012. manual  contains the  e-mail  addresses for sending  your  comments and 
  11013. problem reports.
  11014.  
  11015. ANSAware version of Arjuna
  11016.  
  11017. The ANSAware version of Arjuna is available from:
  11018.  
  11019. Architecture Projects Management Limited
  11020. Poseidon House
  11021. Castle Park                                  Phone    +44 223 323010
  11022. Cambridge                                    Fax      +44 223 359779
  11023. CB3 0RD                                      Internet apm@ansa.co.uk
  11024. United Kingdom                               UUCP     ...uknet!ansa!apm
  11025.  
  11026. Arjuna Mailing List
  11027.  
  11028. To enable us to  help people using Arjuna,  an electronic mail list has 
  11029. been setup. You can join  the Arjuna mailing list  by sending an e-mail 
  11030. message to "mailbase@mailbase.ac.uk" containing:
  11031.  
  11032. join arjuna <Your Name>
  11033.  
  11034. For example : join arjuna John Smith
  11035.  
  11036. Mail  messages  can  then   be  sent  to  "arjuna@mailbase.ac.uk",  for 
  11037. distribution.
  11038.  
  11039.  
  11040. Arjuna Project Team
  11041. The Department of Computing Science,
  11042. The University,
  11043. Newcastle upon Tyne.
  11044. NE1 7RU, UK.
  11045.  
  11046. Fax:           +44 91 222 8232
  11047. e-mail:        arjuna@newcastle.ac.uk
  11048. anonymous ftp: arjuna.ncl.ac.uk (128.240.150.1)
  11049.  
  11050. EMAIL = arjuna@newcastle.ac.uk
  11051. POST  = Computing Laboratory, The University, Newcastle upon Tyne, UK NE1 7RU
  11052. VOICE = +44 91 222 8067         FAX = +44-91-222-8232
  11053.  
  11054. Subject: Arjuna papers announcement
  11055. Date: Tue, 8 Jun 1993 16:47:02 GMT
  11056.  
  11057. This is to announce the availability of most Arjuna related papers and
  11058. theses via anonymous ftp from arjuna.ncl.ac.uk. These papers are
  11059. available in both US Letter and European A4 standards in postscript and
  11060. should now print on systems. Any problems in printing should be directed to
  11061. arjuna@newcastle.ac.uk.
  11062.  
  11063. Since there are too many papers to describe in one posting there is an index
  11064. available in /pub/Arjuna/Index which contains the abstracts from all of
  11065. the papers/theses and their locations within the ftp hierarchy.
  11066.  
  11067.  
  11068. >3  BOS (prototyping)
  11069.  
  11070. What: BOS
  11071. From: Sean.Levy@cs.cmu.edu
  11072. Date: 23 Apr 92 18:07:32 GMT
  11073.  
  11074. [For readers of comp.object and self-interest, BOS is a prototype-based
  11075. object system that I have, er, prototyped in Tcl. It is available via anon
  11076. FTP to monch.edrc.cmu.edu under /usr0/snl/archive/bos-1.2.tar.Z (you have to
  11077. cd to /usr0/snl/archive first and then get the file, due to CMU security hacks
  11078. in ftpd). I thought that this would be of interest to comp.object and
  11079. self-interest, so I'm cross-posting/mailing --S]
  11080.  
  11081. Note: I play very fast and loose with the terminology of OOP to get my
  11082. point across. I apologize if I offend any sensibilities, and will clarify what
  11083. I say if it is obfuscated by my use of terms.
  11084.  
  11085.  
  11086. >4  G++ for DOS (Many sites)
  11087.  
  11088. :From: DJ Delorie <dj@ctron.com>
  11089. :Newsgroups: gnu.announce,gnu.misc.discuss
  11090.  
  11091. :               DJGPP 1.10 is now available!
  11092.                          :
  11093.                          :
  11094. :               --- DJGPP - G++ for MSDOS/386 ---
  11095.  
  11096. :djgpp is normally uploaded to:
  11097. :  omnigate.clarkson.edu                 128.153.4.2     pub/msdos/djgpp
  11098. :  math.utexas.edu                       128.83.133.215  pub/msdos/djgpp(*)
  11099. :  ftp.uni-koeln.de                      134.95.128.208
  11100. :                                                       msdos/gnuprogs/djgpp (*)
  11101. :  ftp.eb.ele.tue.nl                     131.155.40.15
  11102. :                                                       pub/pc/gnu/gcc-pl* & gcc-newst
  11103. :  wowbagger.pc-labor.uni-bremen.de      134.102.228.9   pub/msdos/djgpp
  11104. :  src.doc.ic.ac.uk                      146.169.2.1     ibmpc/djgpp
  11105. :  ftp.mcc.ac.uk                         130.88.200.7    pub/djgpp
  11106. :  UK.AC.MCC.FTPJ (JANET)                user<guest>     <PUB>djgpp
  11107.  
  11108. :(*) Please do not access during working hours (7am - 6pm their local time)
  11109.  
  11110.  
  11111. >5  cooC (Concurrent, OO C ext.)
  11112.  
  11113. From: maeda@isl.rdc.toshiba.co.jp (Ken-ichi Maeda)
  11114. Subject: cooC FTP release (2nd posting)
  11115. Date: 2 Jul 93 15:13:11
  11116. Organization: TOSHIBA R & D Center, Kawasaki, JAPAN.
  11117.  
  11118.         We are pleased to announce the release of new object oriented
  11119. language based on C.  The language has support for concurrent object
  11120. execution with synchronous or asynchronous message pssaing and wait when
  11121. necessary reply handling.  The language known as cooC (concurrent object
  11122. oriented C) is available by anonymous FTP for research purposes.
  11123.  
  11124.         FTP Site:  tsbgw.isl.rdc.toshiba.co.jp (133.196.1.11)
  11125.         File: pub/toshiba/cooc-beta.1.1.tar.Z
  11126.  
  11127.         The released version of cooC employs SunOS(TM) LWP (light weight
  11128. process), to obtain concurrent execution.  The release consists of the
  11129. language translator (cooC->C), a runtime library (SunOS(TM)), a
  11130. concurrent object based debbuger, an example groupware application
  11131. (SharedDraw) and some technical papers.
  11132.  
  11133. BECAUSE THE SYSTEM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR
  11134. ANY PART OF THE SYSTEM.
  11135.  
  11136.         TOSHIBA Corporation while making cooC free for research, retains
  11137. copyright.
  11138.  
  11139.         For further detail, please refer to COPYRIGHT notice in the
  11140. package.
  11141.  
  11142.         Any questions and/or comments are welcome at the following
  11143. e-mail address.
  11144.  
  11145.         cooc@isl.rdc.toshiba.co.jp
  11146.  
  11147. --
  11148. --------------------------------------------------------------------
  11149. Ken-ichi Maeda <maeda@isl.rdc.toshiba.co.jp>
  11150. Communication and Information Systems Research Lab. II
  11151. TOSHIBA Research & Development Center
  11152. 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210, JAPAN
  11153. TEL. (+81- or 0)44-549-2237  FAX. (+81- or 0)44-520-1841
  11154. --------------------------------------------------------------------
  11155.  
  11156.  
  11157. >6  FMPL (prototyping)
  11158.  
  11159. What: Interpreter for FMPL of Accardi, Release 1
  11160. From: blojo@xcf.berkeley.edu (Jon Blow)
  11161. Date: 2 Jun 92 08:42:26 GMT
  11162.  
  11163. An interpreter for FMPL of Accardi, Release 1 is now available for ftp at 
  11164. xcf.berkeley.edu:src/local/fmpl/.
  11165.  
  11166. *FMPL is a prototype-based object-oriented programming language.
  11167. *FMPL possesses lambda-calculus based constructs.
  11168. *FMPL is an event-driven language; the events it responds to are mainly
  11169. based on the behavior of input/output streams, not only within the unix domain
  11170. but across the internet as well.
  11171. *FMPL supports "pretty"-printing of internally-represented code back into
  11172. readable form.
  11173. *FMPL is an experimental language developed at the Experimental Computing 
  11174. Facility of the University of California, Berkeley.  This release is something
  11175. of a beta test since the language has not been widely used outside Berkeley.
  11176. It is hoped that this release will draw useful comments and suggestions from
  11177. the world at large that will help in improving future versions of FMPL.
  11178.  
  11179.  
  11180. >7  MAX (visual OO)
  11181.  
  11182. From: fingerhu@ircam.fr (Michel Fingerhut)
  11183. Subject: IRCAM DSP software for DEC/ALPHA and DEC/MIPS
  11184. Organization: Inst. de Recherche et Coordination Acoustique/Musique, Paris
  11185. Date: Fri, 13 Aug 93 11:25:23 GMT
  11186.  
  11187. ftp.ircam.fr:/pub/IRCAM/programs contains some of the IRCAM-developed
  11188. software packages (in demo version; see further down for availability
  11189. of the fully functional versions), including runnable binaries for
  11190. both the DEC/ALPHA (osf1) and DEC/MIPS (ultrix) architectures, and soon
  11191. available on other platforms (SGI and Macintosh).
  11192.  
  11193. MAX
  11194.  
  11195. MAX is a visual, object-oriented, programming language, initially
  11196. designed for interactive musical performance, but which is suitable for
  11197. digital signal processing as well as real-time control.  It allows
  11198. interconnecting of oscillators and filters, building custom controller
  11199. modules and simulation units all from a core collection of signal
  11200. processing objects.
  11201.  
  11202. ############################################################################
  11203.  
  11204.  
  11205. Path: senator-bedfellow.mit.edu!faqserv
  11206. From: Bob Hathaway <rjh@geodesic.com>
  11207. Newsgroups: comp.object,comp.answers,news.answers
  11208. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Part 10/13
  11209. Supersedes: <object-faq/part10_805979999@rtfm.mit.edu>
  11210. Followup-To: comp.object
  11211. Date: 31 Aug 1995 15:33:12 GMT
  11212. Organization: Geodesic Systems
  11213. Lines: 1193
  11214. Approved: news-answers-request@MIT.Edu
  11215. Distribution: world
  11216. Expires: 14 Oct 1995 15:31:54 GMT
  11217. Message-ID: <object-faq/part10_809883114@rtfm.mit.edu>
  11218. References: <object-faq/part9_809883114@rtfm.mit.edu>
  11219. NNTP-Posting-Host: bloom-picayune.mit.edu
  11220. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  11221. X-Last-Updated: 1995/06/01
  11222. Originator: faqserv@bloom-picayune.MIT.EDU
  11223. Xref: senator-bedfellow.mit.edu comp.object:37592 comp.answers:13981 news.answers:51864
  11224.  
  11225. Archive-name: object-faq/part10
  11226. Last-Modified: 05/31/94
  11227. Version: 1.0.8
  11228.  
  11229. First developed by Miller Puckette at IRCAM in late 1986 to control
  11230. the IRCAM 4X, it was later implemented on the Apple Macintosh as a
  11231. graphical programming environment for MIDI applications.  This version
  11232. has been extended by the Opcode company in Palo Alto, CA (USA), and is
  11233. available through them.
  11234.  
  11235. The Alpha version (and its demo-only subset) is based on the NeXT
  11236. version, where it is used to control the IRCAM-designed ISPW board.
  11237. This card, based on two Intel i860 microprocessors, handles
  11238. numerically-intensive real-time operations.
  11239.  
  11240. To date, it has been extensively used in live performance of
  11241. full-length musical compositions (see some references in the MAX/doc
  11242. directory), as well as in scientific and experimental applications
  11243. requiring real-time control.
  11244.  
  11245. SVP
  11246.  
  11247. SVP (``Super Vocodeur de Phase'') is a signal processing tool which was
  11248. designed and developed at IRCAM by Gilles Poirot and Philippe
  11249. Depalle.  It is a full system for the analysis and synthesis of sound,
  11250. whose core is a phase vocoder, and which comprises several modules for
  11251. analysis (FFT, LPC..), filtering (band modes, surface modes...), time-
  11252. scaling, mixing, spectral combination, cross-synthesis and
  11253. amplification, which can be combined in multiple ways.
  11254.  
  11255. UDI
  11256.  
  11257. UDI is a library of C routines which provides a coherent software
  11258. approach for developing and maintaining digital signal processing
  11259. algorithms on stand-alone workstations or on host/array processor
  11260. configuration.  Initially designed for sound signal analysis and
  11261. synthesis, it can be used by any application which does vector math
  11262. calculation.
  11263.  
  11264. It provides functions ranging from elementary vector and matrix
  11265. operations to more specific DSP operations, such as, but not limited
  11266. to, FFT, least-square, linear prediction coding, discrete cepstrum and
  11267. pitch detection.
  11268.  
  11269. UDI was actually used in implementing SVP.
  11270.  
  11271. HOW TO RETRIEVE
  11272.  
  11273. ftp.ens.fr:/pub/reports/liens/liens-94-18.A4.dvi.Z
  11274.  
  11275. AVAILABILITY
  11276.  
  11277. For information on availability of these and other IRCAM tools with
  11278. full functionality and documentation, and/or licensing of source code,
  11279. as well as IRCAM publications (technical/scientific reports) please contact
  11280. (in french or english, preferably):
  11281.  
  11282.         Mr. Vincent Puig
  11283.         Directeur de la Valorisation
  11284.         IRCAM
  11285.         31, rue Saint-Merri
  11286.         F-75004 Paris, France
  11287.  
  11288.         email:  puig@ircam.fr
  11289.         FAX:    +33 1 42 77 29 47
  11290.  
  11291. Additional info can be found in the README file in the above directory.
  11292.  
  11293. REPORTING PROBLEMS AND GETTING HELP
  11294.  
  11295. ... in retrieving the software and/or in running it: please send email to
  11296.  
  11297.         manager@ircam.fr
  11298.  
  11299.  
  11300.  
  11301. >8  O'small (OO lang for teaching)
  11302.  
  11303. From: hense@sol.cs.uni-sb.de (Andreas Hense)
  11304. Subject: *** NEW O'small compiler available by ftp !!! ***
  11305. Date: 25 Jun 1993 13:54:35 GMT
  11306. Organization: Universitaet des Saarlandes,Rechenzentrum
  11307.  
  11308.              O'small - THE object-oriented language for teaching
  11309.              ---------------------------------------------------
  11310.                        (Announcement of a new compiler)
  11311.  
  11312. *** An object-oriented language for teaching?
  11313.  
  11314. Depending on which aspects of object-orientation you want to convey you
  11315. may choose your teaching language. If you want to teach the aspect of
  11316. software reuse and nice graphical user interfaces, you should choose
  11317. Smalltalk. If you want to show students how to program in a best
  11318. selling language you should choose C++.
  11319.  
  11320.  
  11321. *** In which case should I choose O'small?
  11322.  
  11323. You should consider O'small if you believe that computer languages
  11324. should have a GOOD FORMAL SEMANTICS. Everyone will agree that a
  11325. language needs a formal semantics. Otherwise, your program will yield
  11326. different results on different implementations. A good formal
  11327. semantics does not only serve the purpose of precisely defining what
  11328. the results of your programs are, it also gives insights about the
  11329. nature of the language. 
  11330.  
  11331. You should consider O'small if you do not want to waste time on
  11332. unnecessary details. O'small is CONCISE. Its syntax and semantics
  11333. takes no more than one page (if you choose the right font). Its syntax
  11334. is similar to more traditional languages. O'small has been used in a
  11335. lecture showing the differences between wrapper semantics
  11336. (denotational) and method lookup semantics (operational). 
  11337.  
  11338. O'small is FREE! Up to now, there has only been an O'small interpreter
  11339. written in Miranda [Hen91b]. This interpreter is directly based on the
  11340. denotational semantics of O'small [Hen91d]. The interpreter itself is
  11341. available by ftp. However, you need Miranda in order to run it. Now,
  11342. there is a NEW IMPLEMENTATION of O'small based entirely on EASILY
  11343. AVAILABLE SOFTWARE. This software is not free but it does not cost
  11344. anything. The new implementation is based on an abstract machine [Boe93].
  11345.  
  11346. You can MODIFY the language and have your students make experiments
  11347. with it. The source code of the abstract machine and the
  11348. specifications for the parser and scanner generators are available.
  11349. Using these generators you can make experiments for your own research
  11350. in statical analysis of object-oriented languages.
  11351.  
  11352.  
  11353. *** I would like to TRY O'small
  11354.  
  11355. You get the implementation by anonymous internet ftp.
  11356. The following table gives the ftp connection information.
  11357.  
  11358. Host:                   Net Address:      Directory:
  11359. -------------------------------------------------------------
  11360. cs.uni-sb.de            134.96.7.254      /pub/osmall/machine
  11361.  
  11362. The directory /pub/osmall/machine contains the files
  11363.         README 
  11364.         ANNOUNCE                this file
  11365.         HowToGetML 
  11366.         oma.1.00.tar.Z          compressed tar-file
  11367.  
  11368.  
  11369. ***************************************************************************
  11370. NOTE: Ftp should be put into binary mode before transferring the compressed
  11371. tar file.
  11372. ***************************************************************************
  11373.  
  11374. Here is a sample dialog:
  11375.  
  11376.    ftp
  11377.    ftp> open cs.uni-sb.de
  11378.    Name: anonymous
  11379.    Password: <your name>
  11380.    ftp> binary
  11381.    ftp> cd /pub/osmall/machine
  11382.    ftp> get README
  11383.    ftp> get ANNOUNCE
  11384. (  ftp> get HowToGetML  )
  11385.    ftp> get oma.1.00.tar.Z
  11386.    ftp> close
  11387.    ftp> quit
  11388.  
  11389. If you have a Sun 4 or a SPARC you can use the existing executable files.
  11390. Otherwise, you need 'sml-yacc', 'sml-lex' and 'sml-noshare'. Read
  11391. 'HowToGetML' to obtain them.
  11392.  
  11393. Instructions on using the machine are contained in the file README.
  11394.  
  11395. References
  11396.  
  11397. [Boe93]  Christoph Boeschen.  Christmas - An abstract machine for
  11398.          O'small.  Master's thesis, Universit"at des Saarlandes, 
  11399.          Fachbereich 14, June 1993.
  11400.  
  11401. [Hen91b] Andreas V. Hense.  An O'small interpreter based on denotational
  11402.          semantics.  Technical Report A 07/91, Universit"at des Saarlandes,
  11403.          Fachbereich 14, November 1991.
  11404.  
  11405. [Hen91c] Andreas V. Hense. Type inference for O'small. Technical Report A
  11406.          06/91, Universit"at des Saarlandes, Fachbereich 14, October 1991.
  11407.  
  11408. [Hen91d] Andreas V. Hense.  Wrapper semantics of an object-oriented pro-
  11409.          gramming language with state. In T. Ito and A. R. Meyer, editors,
  11410.          Theoretical Aspects of Computer Software, volume 526 of Lecture No-
  11411.          tes in Computer Science, pages 548-568. Springer-Verlag, September
  11412.          1991.
  11413.  
  11414. [Hen93]  Andreas V. Hense.  Denotational semantics of an object-oriented
  11415.          programming language with explicit wrappers.  Formal Aspects of
  11416.          Computing, 5(3), 1993. to appear.
  11417.  
  11418. [HS92]   Andreas V. Hense and Gert Smolka.  A verification of extensible
  11419.          record types.  In Zhongzhi Shi, editor, Proceedings of the IFIP
  11420.          TC12/WG12.3 International Workshop on Automated Reasoning,
  11421.          pages 137-164, Beijing, P.R. China, 13-16 July 1992. Internatio-
  11422.          nal Federation for Information Processing, Elsevier, North-Holland,
  11423.          Excerpta Medica.
  11424.  
  11425. [HS93]   Andreas V. Hense and Gert Smolka.  Principal types for object-
  11426.          oriented languages. Technical Report A 02/93, Universit"at des Saar-
  11427.          landes, Fachbereich 14, June 1993.
  11428.  
  11429.  
  11430. >9  OBJ3 (OO lang)
  11431.  
  11432. What: Release 2.0 of OBJ3 (needed for FOOPS and OOZE, concurrent OOP)
  11433. Date: Thu, 4 Jun 92 15:07:26 BST
  11434. From: Paulo.Borba@prg.oxford.ac.uk
  11435.  
  11436. OBJ is available from SRI, see the message below; prototypes implementations of
  11437. FOOPS (without the concurrent extension) and OOZE are due to the end of the
  11438. year, but for both you also need OBJ. 
  11439.  
  11440. Unfortunately, I don't have any document about the FOOPS extension now, but
  11441. probably by the end of the year. I will send it to you as soon as possible.
  11442.  
  11443.  
  11444. What: Release 2.0 of OBJ3 is now available
  11445. From: winkler@csl.sri.com (Timothy Winkler)
  11446. Date: 6 Apr 92 08:35:40 GMT
  11447.  
  11448. Release 2.0 of OBJ3 is now available!
  11449.  
  11450. Improvements in this version include some language extensions and additional 
  11451. theorem proving features.  In addition, an effort has been made to speed up
  11452. the implementation; rewriting is often twice as fast as in the original
  11453. implementation.  We are including the AKCL patches from the University of
  11454. Texas at Austin in the distribution, which are necessary for maintaining the
  11455. portability of OBJ3 and also improve its efficiency.  In addition, we are
  11456. distributing a SPARC version of OBJ3.
  11457.  
  11458. OBJ3 has pattern matching modulo associativity, commutativity, and identity.
  11459. New: the system automatically computes conditions for rules involving matching
  11460. modulo identity that are used to prevent obvious non-termination problems.
  11461.  
  11462. Also new to this version of OBJ3 is a facility for controlled rewriting. This
  11463. provides substantially increased support for the use of the system for
  11464. equational theorem proving.
  11465.  
  11466. To receive the OBJ3 distribution tape or an OBJ3 license, send a request
  11467. to:
  11468.  
  11469.            Judith Burgess (OBJ3)
  11470.            Computer Science Laboratory
  11471.            SRI International
  11472.            333 Ravenswood Ave.
  11473.            Menlo Park, CA 94025-3493, USA
  11474.  
  11475.         Telephone: (415) 859-5924
  11476.         Fax: (415) 859-2844
  11477.             email: obj3dist@csl.sri.com
  11478.  
  11479. Be sure to give us your postal mailing address.  Then we will send you the
  11480. OBJ3 Information Form, and License Agreement, with instructions on how to
  11481. fill them out.  (A KCL license form will also be included.)  When you return
  11482. them to us, appropriately filled out and signed, we will send you the tape,
  11483. somedocumentation, and, in case you are requesting a tape, an invoice for
  11484. $150.00 plus any required taxes.
  11485.  
  11486. If you already have an OBJ3 license, then you don't need to get a new license,
  11487. but, if you are requesting a tape from SRI, you are asked to pay the above
  11488. distribution fee.
  11489.  
  11490. It is also possible to get a license for OBJ3 at no charge from SRI and then
  11491. get the OBJ3 distribution itself from some third party also having a license.
  11492.  
  11493. Jose Meseguer, Timothy Winkler, and Patrick Lincoln
  11494. Computer Science Laboratory
  11495. SRI International
  11496. 333 Ravenswood Avenue
  11497. Menlo Park, California 94025, USA
  11498.  
  11499. Joseph Goguen
  11500. Programming Research Group
  11501. Computing Laboratory
  11502. Oxford University
  11503. 11 Keble Road
  11504. Oxford OX1 3QD, United Kingdom
  11505.  
  11506.  
  11507. >10  OBST (lang, perst, OODB)
  11508.  
  11509. See entry under Appendix B.
  11510.  
  11511.  
  11512. >11  OOT (OO Turing demo)
  11513.  
  11514. What: OOT
  11515. From: holt@turing.toronto.edu (Ric Holt)
  11516. Date: 26 Apr 93 20:14:43 GMT
  11517.  
  11518. OBJECT ORIENTED TURING: DEMO AVAILABLE VIA FTP
  11519.  
  11520. OOT (Object Oriented Turing) is a programming language that has been 
  11521. developed at the University of Toronto.  An OOT demo, which includes the 
  11522. fully implemented language, is available for Sun/4's running X windows.  
  11523. See below for instructions to copy the demo to your site.
  11524.  
  11525. OOT supports the standard OOPL features of information hiding, classes,
  11526. polymorphism and generics, as well as the usual features in C and Pascal 
  11527. style languages.  It also supports concurrency, exception handling 
  11528. and system programming (pointer arithmetic, bit manipulation, etc).  
  11529.  
  11530. The OOT environment is designed for teaching Computer Science.
  11531. It is being used in introductory programming courses, courses
  11532. on OO concepts, compiler courses, OS courses, etc.
  11533.  
  11534. The OOT environment is fully integrated, with multi-window editing, turbo 
  11535. speed compiler, integrated color graphics, GUI user interface, implicit MAKE, 
  11536. on-line manual, integrated demos, etc.  The system includes an experimental
  11537. CASE tool with an interface browser and a visual system browser.
  11538.  
  11539.  
  11540. >12  Sather (simple Eiffel)
  11541.  
  11542. What: SATHER
  11543.  
  11544. Sather is under development at the International Computer Science Institute.
  11545. Sather has clean and simple syntax, parameterized classes, object-oriented
  11546. dispatch, multiple inheritance, strong typing, and garbage collection. The
  11547. compiler generates efficient and portable C code which is easily integrated
  11548. with existing code.
  11549.  
  11550. The initial beta test release of the language was in May, 1991. The compiler,
  11551. debugger, Emacs development environment, documentation, and library classes
  11552. are available by anonymous ftp from "icsi-ftp.berkeley.edu".
  11553. "sather@icsi.berkeley.edu" is a mailing list for discussing aspects of Sather
  11554. and "sather-admin@icsi.berkeley.edu" should be used for bug reports and
  11555. requests to be added or deleted from the mailing list.
  11556.  
  11557. Sather is based on Eiffel but is more concerned with efficiency and less with
  11558. some of the formal and theoretical issues addressed by Eiffel. The language is
  11559. much smaller than the current Eiffel, it eliminates over 40 keywords and
  11560. simplifies the syntax and inheritance rules. 
  11561.  
  11562. Like Eiffel, Sather code is compiled into portable C and efficiently links
  11563. with existing C code. The Sather compiler is written in Sather and has been
  11564. operational for almost a year, though it is still being improved. Preliminary
  11565. benchmarks show a performance improvement over Eiffel of between a factor of 4
  11566. and 50 on basic dispatching and function calls. On the benchmarks used at
  11567. Stanford to test Self (including 8 queens, towers of hanoi, bubblesort, etc),
  11568. Sather is even slightly faster than C++.
  11569.  
  11570. The Sather compiler and libraries are publicly available under a very
  11571. unrestrictive license aimed at encouraging contribution to the public library
  11572. without precluding the use of Sather for proprietary projects.  The goal is to
  11573. establish a repository for efficient, reusable, well written, publicly
  11574. available, classes for most of the important algorithms in computer science.
  11575. There are currently about 120 classes in the library. The libraries are
  11576. growing quickly and will collect together classes from many authors under the
  11577. same unrestrictive license. 
  11578.  
  11579. A GNU emacs development environment for Sather is available. A debugger based
  11580. on gdb from the Free Software Foundation is also available. A parallel version
  11581. of Sather for shared memory machines called "Psather" is also under
  11582. development.
  11583.  
  11584. From the Sather FAQ, August 16, 1993 (See Section 1.24):
  11585.  
  11586. Q 1: What is Sather?
  11587.      ~~~~~~~~~~~~~~ 
  11588. Sather is an object oriented language which aims to be simple,
  11589. efficient, interactive, safe, and non-proprietary. It aims to meet the
  11590. needs of modern research groups and to foster the development of a
  11591. large, freely available, high-quality library of efficient
  11592. well-written classes for a wide variety of computational tasks. It was
  11593. originally based on Eiffel but now incorporates ideas and approaches
  11594. from several languages. One way of placing it in the "space of
  11595. languages" is to say that it attempts to be as efficient as C, C++, or
  11596. Fortran, as elegant and safe as Eiffel or CLU, and to support
  11597. interactive programming and higher-order functions as well as Common
  11598. Lisp, Scheme, or Smalltalk.
  11599.  
  11600. Sather has garbage collection, statically-checked strong typing,
  11601. multiple inheritance, separate implementation and type inheritance,
  11602. parameterized classes, dynamic dispatch, iteration abstraction,
  11603. higher-order routines and iters, exception handling, assertions,
  11604. preconditions, postconditions, and class invariants. The development
  11605. environment integrates an interpreter, a debugger, and a
  11606. compiler. Sather code can be compiled into C code and can efficiently
  11607. link with C object files.
  11608.  
  11609.  
  11610. >13  Self
  11611.  
  11612. From: hoelzle@Xenon.Stanford.EDU (Urs Hoelzle)
  11613. Subject: Announcing Self 3.0
  11614. Date: 28 Dec 93 22:19:34 GMT
  11615.  
  11616.                ANNOUNCING Self 3.0 
  11617.  
  11618. The Self Group at Sun Microsystems Laboratories, Inc., and Stanford
  11619. University is pleased to announce Release 3.0 of the experimental
  11620. object-oriented programming language Self.
  11621.  
  11622. This release provides simple installation, and starts up with an
  11623. interactive, animated tutorial.
  11624.  
  11625. Designed for expressive power and malleability, Self combines a pure,
  11626. prototype-based object model with uniform access to state and
  11627. behavior. Unlike other languages, Self allows objects to inherit state
  11628. and to change their patterns of inheritance dynamically. Self's
  11629. customizing compiler can generate very efficient code compared to
  11630. other dynamically-typed object-oriented languages.
  11631.  
  11632. The latest release is more mature than the earlier releases: more
  11633. Self code has been written, debugging is easier, multiprocessing is more
  11634. robust, and more has been added to the experimental graphical user interface
  11635. which can now be used to develop code. There is now a mechanism
  11636. (still under development) for saving objects in modules, and a
  11637. source-level profiler.
  11638.  
  11639. The Self system is the result of an ongoing research project and
  11640. therefore is an experimental system. We believe, however, that the
  11641. system is stable enough to be used by a larger community, giving
  11642. people outside of the project a chance to explore Self.
  11643.  
  11644. 2 This Release
  11645.  
  11646. This release is available free of charge and can be obtained via
  11647. anonymous ftp from Self.stanford.edu. Also available for ftp are a
  11648. number of published papers about Self.
  11649.  
  11650. There is a mail group for those interested in random ramblings about Self,
  11651. Self-interest@Self.stanford.edu. Send mail to self-request@self.stanford.edu
  11652. to be added to it (please do not send such requests to the mailing list
  11653. itself!).
  11654.  
  11655. 2.1 Implementation Status
  11656.  
  11657. Self currently runs on SPARC-based Sun workstations running SunOS 4.1.x
  11658. or Solaris 2.3. The Sun-3 implementation is no longer provided.
  11659.  
  11660. 2.2 Major Changes
  11661.  
  11662. Below is a list of changes and enhancements that have been made since
  11663. the last release (2.0.1).  Only the major changes are included. 
  11664.  
  11665. o The graphical browser has been extended to include editing
  11666.   capabilities. All programming tasks may now be performed through the
  11667.   graphical user interface (the "ui"). Type-ins allow for expression
  11668.   evaluation, menus support slot editing, and methods can be entered and
  11669.   edited. If you are familiar with a previous version of the Self
  11670.   system, Section 14.1 of the manual entitled "How to Use Self 3.0"
  11671.   contains a quick introduction to the graphical user interface. The
  11672.   impatient might want to read that first.
  11673.  
  11674. o A mechanism - the transporter - has been added to allow arbitrary
  11675.   object graphs to be saved into files as Self source. The system has
  11676.   been completely modularized to use the transporter; every item of
  11677.   source now resides in a transporter-generated
  11678.   module. Transport-generated files have the suffix .sm to distinguish
  11679.   them from "handwritten" files (.Self), though this may change as we
  11680.   move away from handwritten source.  The transporter is usable but rough,
  11681.   we are still working on it.
  11682.  
  11683. o Every slot or object may now have an annotation describing the
  11684.   purpose of the slot. In the current system, annotations are strings
  11685.   used to categorize slots. We no longer categorize slots using
  11686.   explicit category parent objects. Extra syntax is provided to annotate
  11687.   objects and slots.
  11688.  
  11689. o A new profiler has been added, which can properly account for the
  11690.   time spent in different processes and the run-time system, and which
  11691.   presents a source-level profile including type information (i.e.,
  11692.   methods inherited by different objects are not amalgamated in the
  11693.   profile, nor are calls to the same method from different sites). It
  11694.   also presents a consistent source-level view, abstracting from the
  11695.   various compiler optimizations (such as inlining) which may confuse
  11696.   the programmer.
  11697.  
  11698. o Privacy is not enforced, although the privacy syntax is still
  11699.   accepted. The previous scheme was at once too restrictive (in that
  11700.   there was no notion of "friend" objects) and too lax (too many object
  11701.   had access to a private slot). We hope to include a better scheme in
  11702.   the next release.
  11703.  
  11704. o The "new" compiler has been supplanted by the SIC ("simple inlining
  11705.   compiler"), and the standard configuration of the system is to
  11706.   compile first with a fast non-optimizing compiler and to 
  11707.   recompile later with the SIC. Pauses due to compilation or
  11708.   recompilation are much smaller, and applications usually run faster.
  11709.  
  11710. o Characters are now single-byte strings. There is no separate
  11711.   character traits.
  11712.  
  11713. o Prioritized inheritance has been removed; the programmer must now
  11714.   manually resolve conflicts. We found the priority mechanism of
  11715.   limited use, and had the potential for obscure errors.
  11716.  
  11717. 2.4 Bug Reports
  11718.  
  11719. Bug reports can be sent to self-bugs@self.stanford.edu. Please include
  11720. an exact description of the problem and a short Self program
  11721. reproducing the bug.
  11722.  
  11723. 2.5 Documentation
  11724.  
  11725. This release comes with two manuals:
  11726.    How to Use Self 3.0 (SelfUserMan.ps)
  11727.    The Self Programmer's Reference Manual (progRef.ps)
  11728.  
  11729. Happy Holidays!
  11730.  
  11731. -- The Self Group
  11732.  
  11733.  
  11734. >14  C++ gram, etc.
  11735.  
  11736. What: ftp site for C++ material
  11737. From: schrod@iti.informatik.th-darmstadt.de (Joachim Schrod)
  11738. Date: 27 May 92 22:32:35 GMT
  11739.  
  11740. There were a lot of questions about C++ material in the last time and some 
  11741. announcements which involved our ftp server.
  11742.         ftp.th-darmstadt.de [130.83.55.75]
  11743.         /pub/programming/languages/C++
  11744. At the moment we have:
  11745.  -- documentation and assorted stuff
  11746.         C++ products list as announced by Saumen K Dutta (in a subdirectory!)
  11747.         C++ YACC grammar, ET++ tutorial, summaries from the Net,
  11748.         sources from James Coplien's book (idioms...), etc.
  11749.  -- class libraries
  11750.         NIHCL (original, persistent for ObjectStore, with g++ 1.4x changes)
  11751.         COOL, OATH, RogueWave vector, ET++,
  11752.         RPC package, a package for sockets, awe (thread package)
  11753.  -- tools
  11754.         class browser (for GNU Emacs), indent++, yacc+, template
  11755.         processor of Brad Cox[sp?], DEC garbage collector
  11756.  
  11757. More stuff is always welcome.  (Btw, Interviews and Motif C++ wrapper
  11758. classes are to be found in the /pub/X11 subtree.)
  11759.  
  11760.  
  11761. >15  ConceptBase (OODB, reqkey)
  11762.  
  11763. What: ConceptBase
  11764.  
  11765. See APPENDIX B.
  11766.  
  11767. A four week test-version of ConceptBase V3.1 is available 
  11768. on the FTP server ftp.informatik.rwth-aachen.de in the 
  11769. directory pub/CB.  For running the ftp version you must ask for a 
  11770. key by email.
  11771.  
  11772.  
  11773. >16  C++ OODB
  11774.  
  11775. From: darrenp@dibbler.cs.monash.edu.au (Daz)
  11776. Subject: Re: Class libraries for accessing RDBs ?
  11777. Organization: Monash University, Melb., Australia.
  11778. Date: Thu, 17 Jun 1993 23:53:22 GMT
  11779.  
  11780. shekar@gizmo.CS.MsState.Edu (Chandrashekar Ramanathan) writes:
  11781.  
  11782. >Hello,
  11783. >       Are there any shareware/ftp'able C++ class libraries that
  11784. >provide Relational Database access? I would also appreciate any
  11785. >pointers (ideas/articles/journals) to the various issues that one has
  11786. >to consider in designing such library. 
  11787. Ok, I'm not sure if it's exactly what you want, but it's a database, it's
  11788. fully written in c++ with classes etc, and it's out for beta testing.
  11789.  
  11790. Check out pippin.cs.monash.edu.au:pub/export/diamond-0.1.2.tar.Z
  11791. and please mail darrenp@dibbler.cs.monash.edu.au if you decide to play with
  11792. it.
  11793.  
  11794. Daz.
  11795. --
  11796. Darren Platt, Department of Computer Science
  11797. darrenp@dibbler.cs.monash.edu.au
  11798. Monash University, Clayton Melbourne, Victoria, Australia
  11799.  
  11800.  
  11801. >17  Exodus (Storage Man, perst)
  11802.  
  11803. What: Exodus project software (Storage Manager & GNU E)
  11804. From: zwilling@caseus.cs.wisc.edu (Mike Zwilling)
  11805. Date: 16 Jul 92 04:53:19 GMT
  11806.  
  11807. In the past there have been discussions in comp.object and comp.databases
  11808. about persistent storage for object-oriented databases and programming
  11809. languages.  As you may know, the EXODUS Database Toolkit project at the
  11810. University of Wisconsin has researched these issues and others for a number of
  11811. years.  The purpose of this note is to inform you that the software from the
  11812. EXODUS project is freely available via anonymous ftp.  The EXODUS software
  11813. includes the EXODUS Storage Manager and the compiler for the E persistent
  11814. programming language.  Also included is documentation, and a suite of test
  11815. programs for both components.  This note briefly describes the software and
  11816. explains how to obtain it.  We currently support DECstation 3100s/5000s and
  11817. SPARC based workstations.  Others have ported the code to HP700s and IBM
  11818. RS6000s.
  11819.  
  11820. The EXODUS Storage Manager is a client-server object storage system which
  11821. provides "storage objects" for storing data, versions of objects, "files"
  11822. for grouping related storage objects, and indexes for supporting efficient
  11823. object access.  A storage object is an uninterpreted container of bytes which
  11824. can range in size from a few bytes to hundreds of megabytes.  The Storage
  11825. Manager provides routines to read, overwrite, and efficiently grow and shrink
  11826. objects.  In addition, the Storage Manager provides transactions, lock-based
  11827. concurrency control, and log-based recovery.
  11828.  
  11829. GNU E is a persistent, object-oriented programming language developed as part
  11830. of the Exodus project.  GNU E extends C++ with the notion of persistent data,
  11831. program level data objects that can be transparently used across multiple
  11832. executions of a program, or multiple programs, without explicit input and
  11833. output operations.
  11834.  
  11835. GNU E's form of persistence is based on extensions to the C++ type system to 
  11836. distinguish potentially persistent data objects from objects that are always
  11837. memory resident.  An object is made persistent either by its declaration (via
  11838. a new "persistent" storage class qualifier) or by its method of allocation
  11839. (via persistent dynamic allocation using a special overloading of the new
  11840. operator).  The underlying object storage system is the Exodus storage manager,
  11841. which provides concurrency control and recovery in addition to storage for
  11842. persistent data.
  11843.  
  11844. The current release of GNU E is based on gcc/g++ version 2.2.2, and is upward 
  11845. compatible with C++ as implemented by that compiler.
  11846.  
  11847. A bibliography of EXODUS related papers can be obtained from the ftp site
  11848. described below.
  11849.  
  11850. To obtain the software, simply ftp to ftp.cs.wisc.edu (128.105.8.18), login
  11851. as anonymous with your email address as a password, "cd" to the "exodus"
  11852. directory, and follow the directions (directions will be given as you "cd").
  11853. See the README for the latest information about the software and an indication
  11854. of our future plans.  If you decide to use the software, please contact us at
  11855. exodus@cs.wisc.edu so that we can notify you of changes.
  11856.  
  11857.  
  11858. >18  GRAS
  11859.  
  11860. GRAS - A Graph-Oriented Database System for SE Applications
  11861. Copyright (C) 1987-1992  Lehrstuhl Informatik III, RWTH Aachen
  11862. This library is free software under the terms of the GNU Library 
  11863. General Public License.
  11864.  
  11865. Lehrstuhl f"ur Informatik III --> GRAS
  11866. University of Technology Aachen (RWTH Aachen),
  11867. Ahornstr. 55,
  11868. D-5100 Aachen
  11869. Contact : Dr. Andy Sch"urr (or Richard Breuer),
  11870. andy@rwthi3.informatik.rwth-aachen.de
  11871. ricki@rwthi3.informatik.rwth-aachen.de (for technical support)
  11872.  
  11873. The system GRAS with interfaces for the programming languages Modula-2
  11874. and C is available as public domain software for Sun3/Sun4 workstations
  11875. (the GRAS system itself is implemented in Modula-2 and consists of many
  11876. layers which might be reusable for the implementation of other systems): 
  11877.  
  11878.   Via anonymous ftp from tupac-amaru.informatik.rwth-aachen.de
  11879.   (137.226.112.31) in the directory /pub/unix/GRAS522_3
  11880.  
  11881.   There are several files contain documentation, sources, binaries,
  11882.   and libraries. All binaries are for Sun/4 machines. Sun/3 binaries
  11883.   are shipped only if explicitly requested.
  11884.  
  11885. [See APPENDIX B]
  11886.  
  11887.  
  11888. >19  MOOD   (OODB, lim arch)
  11889.  
  11890. What: MOOD/P3 Ver.2.00 OODBS {Miniature,Materials}OODBS.
  11891. From: ono@mood.mech.tohoku.ac.jp (Noboru Ono)
  11892. Date: 18 May 92 10:28:42 GMT
  11893.  
  11894. The following program/sample database package is available through anonymous
  11895. FTP at mood.mech.tohoku.ac.jp (130.34.88.61). Sorry it is not the sources and
  11896. operates only in NEC-PC9801/MS-DOS environment.  Sorry again documents are all
  11897. in Japanese. We will tell you later when English documents has become ready.
  11898.  
  11899.       MOOD/P3 Ver.2.00
  11900.       Material's Object-Oriented Database, Prototype 3
  11901.  
  11902. This program, as you may guess,
  11903.  
  11904.       1) is an Object-Oriented database system program,
  11905.       2) operates on PC-9801 series personal computer, and
  11906.       3) is accompanied by sample material database schema.
  11907.  
  11908. Although this program has been developed and being used in the experiments
  11909. on material data processing in which we are now involved, it is a general
  11910. purpose OODBS. 
  11911.  
  11912. Noboru Ono
  11913. Dept. of Machine Intelligence and Systems Engineering,
  11914. Faculty of Engineering, Tohoku University.
  11915. Tel:++22-222-1800
  11916. Fax:++22-268-3688
  11917. E-mail:ono@mood.mech.tohoku.ac.jp
  11918.  
  11919.  
  11920. >20  Ode    (C++ OODB)
  11921.  
  11922. Note: Ode version 3.0 is now available.
  11923.  
  11924. What: Ode Release 1.1
  11925. From: nhg@research.att.com
  11926.  
  11927. Ode is an object-oriented database based on the C++ database model. The
  11928. primary interface to Ode is the database programming language O++ which is
  11929. based on C++.
  11930.  
  11931. Ode 1.1 is now available to Universities.  This is a beta release.  The
  11932. current version of Ode runs on Sun (Sparc) workstations and users must have
  11933. C++ release 2.0 or a later release.  If you are interested in using Ode and
  11934. giving us feedback on your experience with Ode, please send me mail with the
  11935. appropriate information.
  11936.  
  11937. Narain Gehani
  11938. AT&T Bell Labs 3D-414
  11939. 600 Mountain Ave
  11940. Murray Hill, NJ 07974
  11941.  
  11942.  
  11943. From: thssamj@iitmax.iit.edu (Aditya M. Jani)
  11944. Subject: *Announcement* UserGroup for ODE (OODBMS from AT&T)
  11945. Organization: Illinois Institute of Technology, Chicago
  11946. Date: Fri, 25 Jun 93 17:27:53 GMT
  11947.  
  11948.                     Ode Object database v2.0
  11949.                     ------------------------
  11950. Ode 2.0 is available via ftp from research.att.com.
  11951. Here is a sample session showing how to retrieve Ode 2.0
  11952. which is kept in the directory
  11953.  
  11954.     dist/ode2.0
  11955.  
  11956. as a compressed tar file named
  11957.  
  11958. 2.0.oppbin.tar.Z
  11959.  
  11960. First create the directory on the local machine
  11961. where ode is to be installed, e.g.,
  11962.  
  11963. mkdir ode
  11964. cd ode
  11965.  
  11966. Retrieve the compressed tar Ode file using ftp into
  11967. as illustrated below.
  11968. Then uncompress it
  11969.  
  11970. uncompress 2.0.oppbin.tar.Z
  11971.  
  11972. and unbundle it
  11973.  
  11974. tar xvf 2.0.oppbin.tar
  11975.  
  11976. Next see file README, fix install file, and run install
  11977.  
  11978. ./install
  11979.  
  11980.  
  11981.  
  11982.  
  11983. Sample ftp session
  11984. --------------
  11985. $ ftp research.att.com
  11986. Connected to tcp!192.20.225.2!1390.
  11987. 220 inet FTP server (Version 4.271 Fri Apr 9 10:11:04 EDT 1993) ready.
  11988. Name (research.att.com:smith): anonymous
  11989. 331 Guest login ok, send ident as password.
  11990. Password: smith@hostname
  11991. 230 Guest login ok, access restrictions apply.
  11992. Remote system type is UNIX.
  11993. Using binary mode to transfer files.
  11994. ftp> cd dist
  11995. 250 CWD command successful.
  11996. ftp> cd ode2.0
  11997. 250 CWD command successful.
  11998. ftp> get 2.0.oppbin.tar.Z
  11999. 200 PORT command successful.
  12000. 150 Opening BINARY mode data connection for 2.0.oppbin.tar.Z (2762525
  12001. bytes).
  12002. 226 Transfer complete.
  12003. 2762525 bytes received in 1.6e+02 seconds (16 Kbytes/s)
  12004. ftp> quit 
  12005. 221 Goodbye.
  12006.  
  12007. -------------------------------------------------------------------------------
  12008.  
  12009.                               Available Now!
  12010.  
  12011.  
  12012.  
  12013.  
  12014.                                  Ode 2.0
  12015.                        An Object-Oriented Database
  12016.  
  12017.        C++ Compatible, Fast Queries, Complex Application Modeling,
  12018.        Multimedia Support, and more
  12019.  
  12020.  
  12021.  
  12022.  
  12023.        Ode 2.0 is now available to Universities.  Users who currently
  12024.        have Ode 1.1 will be automatically sent a tape with Ode 2.0.
  12025.        There is no charge for Ode.  However, AT&T requires the signing
  12026.        of a non-disclosure agreement.
  12027.  
  12028.  
  12029.  
  12030.        Details
  12031.        -------
  12032.  
  12033.        ODE OBJECT-ORIENTED DATABASE
  12034.  
  12035.        The Ode object database is based on the C++ object paradigm.
  12036.        Ode  uses  one  integrated data model (C++ classes) for both
  12037.        database and general purpose manipulation.  The Ode database
  12038.        is   defined,   queried  and  manipulated  in  the  database
  12039.        programming language O++, which provides simple and  elegant
  12040.        facilities for manipulating the database.
  12041.  
  12042.        O++  is  an  upward-compatible  extension  of  C++.   A  few
  12043.        facilities have been added to C++ to make it into a database
  12044.        programming language.  C++ programmers can learn  O++  in  a
  12045.        very short time.
  12046.  
  12047.        O++ programs can be compiled with C++ programs thus allowing
  12048.        the use of existing C++ code.
  12049.  
  12050.        THE ODE MODEL OF PERSISTENCE
  12051.  
  12052.        Ode offers a simple and elegant notion of persistence  which
  12053.        is   modeled  on  the  ``heap''.   Specifically,  memory  is
  12054.        partitioned into volatile and persistent.  Volatile  objects
  12055.        are   allocated   in   volatile   memory  (stack  or  heap).
  12056.        Persistent objects are allocated  in  persistent  store  and
  12057.        they  continue  to exist after the program that created them
  12058.        has terminated.
  12059.  
  12060.        An Ode database is a collection of persistent objects.  Each
  12061.        object  is  identified  by  a  unique  object  id  (i.e.,  a
  12062.        persistent pointer,  or  to  be  precise,  a  pointer  to  a
  12063.        persistent object).
  12064.  
  12065.        The database programming language  O++  provides  facilities
  12066.        for   creating  and  manipulating  the  Ode  database.   For
  12067.        example,   O++   provides    facilities    for    specifying
  12068.        transactions,  creating and manipulating persistent objects,
  12069.        querying the database, creating and manipulating versions.
  12070.  
  12071.        WHAT IS AN OBJECT-ORIENTED DATABASE
  12072.  
  12073.        Some  important  characteristics   of   an   object-oriented
  12074.        database are:
  12075.  
  12076.           + data is stored as objects,
  12077.  
  12078.           + data  can  be  interpreted  (using  methods)  only   as
  12079.             specified by the class designer,
  12080.  
  12081.           + relationship  between  similar  objects  is   preserved
  12082.             (inheritance), and
  12083.  
  12084.           + references between objects are preserved.
  12085.  
  12086.        ADVANTAGES OF OBJECT-ORIENTED DATABASES
  12087.  
  12088.           + Speed: Queries can  be  faster  because  joins  (as  in
  12089.             relational  databases)  are  often not needed.  This is
  12090.             because an object can be retrieved directly  without  a
  12091.             search, by following object ids.
  12092.  
  12093.           + No impedance mismatch: The same data model is  used  by
  12094.             both   the   database   programming  language  and  the
  12095.             database;  it  is  not  necessary  to  do  any   format
  12096.             conversions  when  reading  the data from disk and when
  12097.             storing the data on disk.
  12098.  
  12099.           + Programmers  need  to  learn   only   one   programming
  12100.             language:  The  same  programming  language is used for
  12101.             both data definition and data manipulation.
  12102.  
  12103.           + Complex applications: The full power  of  the  database
  12104.             programming language's type system can be used to model
  12105.             the data structures of a complex  application  and  the
  12106.             relationship between the different data items.
  12107.  
  12108.           + Multimedia  applications:  The   semantic   information
  12109.             stored  in  the  database  (class  methods) facilitates
  12110.             correct  interpretation  of  the  data.   This  reduces
  12111.             application complexity since applications do no have to
  12112.             be responsible for the correct interpretation of data.
  12113.  
  12114.           + Versions: Object-oriented databases  typically  provide
  12115.             better support for versioning.  An object can viewed as
  12116.             the set of all its versions.  Also, object versions can
  12117.             be treated as full fledged objects.
  12118.  
  12119.           + Triggers  and  constraints:  Object-oriented  databases
  12120.             provide systematic support for triggers and constraints
  12121.             which are the basis of active databases.
  12122.  
  12123.        Finally, most, if not all, object-oriented applications that
  12124.        have  database  needs  will  benefit  from  using an object-
  12125.        oriented database.  Specifically, C++ applications that have
  12126.        database needs will benefit from using Ode.
  12127.  
  12128.        FEATURES OF ODE
  12129.  
  12130.          1.  Ode is C++ based and compatible with C++.
  12131.  
  12132.          2.  The  Ode  object   database   provides   four   object
  12133.              compatible  mechanisms  for  manipulating and querying
  12134.              the database: O++, OdeView, OdeFS, and CQL++:
  12135.  
  12136.                 + O++ is a database programming language  based  on
  12137.                   C++.   O++  is  upward compatible with C++ and it
  12138.                   makes minimal  changes  to  C++.   O++  offers  a
  12139.                   simple and elegant notion of persistence which is
  12140.                   modeled on the ``heap''.  O++ provides facilities
  12141.                   for querying the database, and a variant of other
  12142.                   facilities.
  12143.  
  12144.                 + OdeView is a graphical X-based interface  to  the
  12145.                   Ode database.
  12146.  
  12147.                 + OdeFS is a  file  system  interface  to  the  Ode
  12148.                   object  database.   OdeFS  allows  objects  to be
  12149.                   treated and  manipulated  like  files.   Standard
  12150.                   commands  such as rm, cp and mv and tools such as
  12151.                   vi and grep can be used to manipulate objects  in
  12152.                   the database.
  12153.  
  12154.                 + CQL++ is a C++ variant  of  SQL  for  easing  the
  12155.                   transition  from  relational databases to object-
  12156.                   oriented databases such as Ode.
  12157.  
  12158.              Currently, only O++ is shipped with Ode 2.0.  A  beta-
  12159.              test version of OdeFS is available upon request.
  12160.  
  12161.          3.  Ode supports large objects  (these  are  critical  for
  12162.              multi-media    applications).    Ode   provides   both
  12163.              transparent access for large objects and a  file  like
  12164.              interface  for  large objects.  The latter can be used
  12165.              to efficiently access and  update  parts  of  a  large
  12166.              object.
  12167.  
  12168.          4.  Users can create versions of objects.  Ode will  track
  12169.              the   relationship   between   versions  and  provides
  12170.              facilities for accessing the different versions.
  12171.  
  12172.          5.  Transactions  can  be  specified  as  read-only;  such
  12173.              transactions  are  faster  because they are not logged
  12174.              and they are less likely to deadlock.
  12175.  
  12176.          6.  Users   can   run    ``hypothetical''    transactions.
  12177.              Hypothetical  transaction  allow users to pose ``what-
  12178.              if'' scenarios (as often  done  with  spread  sheets).
  12179.              User  can  change  data  and  see  the impact of these
  12180.              changes without changing the database.
  12181.  
  12182.          7.  EOS, the storage engine of Ode, is based on a  client-
  12183.              server architecture.  Some features of EOS:
  12184.  
  12185.                a.  Efficient  and  transparent  handling  of  large
  12186.                    objects.  A file-like interface is also provided
  12187.                    for very large objects.
  12188.  
  12189.                b.  Concurrency is based on  multi-granularity  two-
  12190.                    version   two-phase   locking;  it  allows  many
  12191.                    readers and one writer to access the  same  item
  12192.                    simultaneously.
  12193.  
  12194.                c.  Log  records  contain  only  after   images   of
  12195.                    updates,  thus making logs small.  Recovery from
  12196.                    system failures requires one scan over  the  log
  12197.                    resulting in fast restarts.
  12198.  
  12199.        USE MODES
  12200.  
  12201.        Ode supports two modes of use:
  12202.  
  12203.          1.  Client-server (allows multiple  users  to  access  the
  12204.              database concurrently).
  12205.  
  12206.          2.  Single user (improved performance  compared  to  using
  12207.              the client-server mode).
  12208.  
  12209.        USERS
  12210.  
  12211.        Ode 2.0 is currently being used as the multi-media  database
  12212.        engine  for  AT&T's  Interactive TV project.  Ode 1.1 (older
  12213.        version of Ode with  limited  capabilities)  has  also  been
  12214.        distributed to 30+ sites within AT&T and 135+ universities.
  12215.  
  12216.  
  12217. >21  POSTGRES (Ext. Rel. DBMS)
  12218.  
  12219. What: Version 4.0 of the POSTGRES DBMS
  12220. From: mer@gaia.CS.Berkeley.EDU (Jeff Meredith)
  12221. Date: 16 Jul 92 04:53:17 GMT
  12222.  
  12223. Version 4.0 of the POSTGRES DBMS is now available for distribution. Version 4.0 
  12224. provides significant advances in functionality over 3.1.  General improvements
  12225. in the code and some key multi-user bug fixes have resulted in a much more
  12226. reliable system than we have ever previously released.
  12227.  
  12228. Major new features include:
  12229.  o  Complete support for language (POSTQUEL) functions.
  12230.  o  Handling of nested dot expressions.
  12231.  o  Optimization of predicates with expensive functions.
  12232.  o  Binary portals
  12233.  o  Initial support of sets
  12234.  o  Indices on system catalogs.
  12235.  
  12236. Postgres runs on Sparc I, Sparc II, Sun 4 running SunOs, and DECstations
  12237. running ULTRIX >= 4.0, as well as Sequent Symmetry machines.  Postgres
  12238. consists of about 250,000 lines of C.
  12239.  
  12240. If you would like to get Postgres 4.0, you can get it in one of two ways:
  12241.  
  12242. (1)  Anonymous FTP from postgres.berkeley.edu
  12243.  
  12244. cd pub
  12245. get postgres-setup.me
  12246. binary
  12247. get postgres-v4r0.tar.Z
  12248. quit 
  12249.  
  12250. Or, if you do not have net.access, you can order a Postgres distribution
  12251. tape by sending a check payable to the Regents of the University of California
  12252. for $150.00 to:
  12253.          Postgres Project
  12254.          571 Evans Hall
  12255.          University of California
  12256.          Berkeley, CA 94720.
  12257.  
  12258. Indicate in your accompanying letter whether you want the system on a 9-track
  12259. tape at 1600 BPI, at 6250 BPI, on a cartridge tape for SUN shoeboxes (QIC 24 
  12260. format), or on a TK50 DEC cartridge tape.
  12261.  
  12262.  
  12263. >22  Sniff (C++ devel environ)
  12264.  
  12265. [See also APPENDIX C, SNiFF+, for the commercial version]
  12266.  
  12267. What: SNIFF (Sniff 1.1b (C++ Development Environment))
  12268. From: shite@sinkhole.unf.edu (Stephen Hite)
  12269. Date: 23 Aug 92 18:14:00 GMT
  12270.  
  12271. Sniff 1.1b is available from iamsun.unibe.ch in the C++ hierarchy.  It's a
  12272. development environment for C++ (minus the C++ compiler or interpreter).
  12273. It's freely available and you're gonna need OpenWindows 3.0 if you want
  12274. to play with it immediately.  I just downloaded it and haven't had a 
  12275. chance to look into whether the XView 3.0 package will be able to handle
  12276. everything Sniff requires of the OpenLook part.
  12277.  
  12278. And:
  12279.  
  12280. From: sniff@takeFive.co.at (Mr. Sniff)
  12281. Newsgroups: comp.lang.c++,comp.unix,comp.unix.osf.osf1,comp.unix.solaris,comp.object
  12282. Subject: SNiFF+ takeFive Starts Free University Distribution of Commercial C/C++ Programming Environment
  12283. Date: 22 Sep 1993 15:51:26 GMT
  12284. Organization: EUnet EDV-Dienstleistungsgesellschaft m.b.H
  12285. Keywords: programming environments, browsing, C++
  12286.  
  12287. SNiFF+: takeFive Starts Free University Distribution of Commercial C/C++
  12288. Programming Environment
  12289.  
  12290. 1. Introduction
  12291.  ===============
  12292. Since the beginning of 1993 takeFive has taken over development and support 
  12293. for SNiFF+, a leading edge C/C++ programming environment.  With SNiFF+ 
  12294. rapidly gaining commercial acceptance takeFive has decided to offer the 
  12295. product free to educational establishments. There are several reasons for 
  12296. this step.
  12297.  
  12298. ...
  12299.  
  12300. 6. How to Obtain SNiFF+
  12301.  =======================
  12302. 6.1 FTP
  12303.  -------
  12304. Sniff can be downloaded from anonymous FTP sites in USA and Europe.
  12305. You can get all details from info@takeFive.co.at.
  12306.  
  12307. And:
  12308.  
  12309. From: hueni@iam.unibe.ch (Hermann Hueni)
  12310. Subject: Re: Browsers
  12311. Date: Fri, 11 Jun 1993 12:37:28 GMT
  12312.  
  12313. Sniff is a commercial product.
  12314. Send mail to info@takeFive.co.at
  12315. AN early version is available as a SUN SPARC binary only from
  12316. siam.unibe.ch:C++/Sniff1.6/     (THIS site is in EUROPE)
  12317.  
  12318.  
  12319. >23  C++ tags
  12320.  
  12321. What: ctags/etags for C and C++
  12322. From: kendall@centerline.com (Sam Kendall)
  12323. Date: 10 Jun 92 09:31:27 GMT
  12324.  
  12325. A lot of people have requested this software!  You can now get Tags for
  12326. C/C++ version 1.0 via anonymous ftp at:
  12327.  
  12328.         ftp.centerline.com:/pub/tags-1.0.tar.Z
  12329.  
  12330. ftp.centerline.com is 140.239.2.29.  Anonymous ftp means login as "ftp" and
  12331. give your email address as the password.
  12332.  
  12333. If you don't have ftp access to the internet, you may want to wait for this
  12334. stuff to come out in comp.sources.unix.  Or, if you plan to use it right away,
  12335. send me a letter that says "I can't use ftp; please send by email" and I will
  12336. do so.
  12337.  
  12338.  
  12339. >24  short tool
  12340.  
  12341. From: neil@aldur.demon.co.uk (Neil Wilson)
  12342. Subject: New version of 'short' available
  12343. Date: Sat, 7 Aug 1993 09:38:25 +0000
  12344.  
  12345. A new beta release (1.2) of 'short' is available from the Stuttgart
  12346. Eiffel archive (ftp.informatik.uni-stuttgart.de) in directory
  12347. /pub/eiffel/eiffel-3/sig
  12348.  
  12349. Command line processing is now included in the short system. Short can
  12350. now cope with multiple input files, the standard input and deal with
  12351. most file errors.
  12352.  
  12353. Short now depends on the argument cluster which is available from
  12354. the same archive and directory.
  12355.  
  12356. Short supports the following options:
  12357.  
  12358.         -V, +version, -h, +help
  12359.                 Displays the 'short' version information and gives the
  12360.                 usage help message for the command.
  12361.  
  12362.         -e, +abstract, +eiffel
  12363.                 Produces a fully deferred version of the input class(es)
  12364.                 which will compile just like any other class (hopefully :-)
  12365.  
  12366.         -l <class_name>, +view <class_name>
  12367.                 Produces the output from the point of view of the class
  12368.                 <class_name> - the "short form for <class_name>".
  12369.                 Special handling for ANY and NONE of course. By default
  12370.                 short outputs the "short form for ANY".
  12371.  
  12372.         -f, +full
  12373.                 Produces the short form including all the feature
  12374.                 blocks.  (Implemented as the "short form for NONE".)
  12375.  
  12376.         -p, +parents
  12377.                 Retains the inheritance clause in the output. The default is
  12378.                 to drop it.
  12379.  
  12380.         -b <number>, +blank <number>
  12381.                 Indent levels by <number> characters. 
  12382.  
  12383.         -c <number>, +column <number>
  12384.                 Width of the output is <number> characters. Should be
  12385.                 greater than 20.
  12386.  
  12387. Obsolete features are not retained. Obsolete classes retain no features.
  12388.  
  12389. The output of the tool now conforms to the layout rules in Appendix A of
  12390. ETL and should look like the 'short' examples in the book. As much as is
  12391. possible the output and command line options conform to ISE's 2.3
  12392. version of 'short'.
  12393.  
  12394. This release of short has been tested on all the v1.21 Eiffel/S
  12395. libraries, itself and the argument clusters, plus any other class
  12396. fragments I had lying around at the time.
  12397.  
  12398. My biggest debt is of course to David Morgan. This version is only
  12399. really a tiny modification of his work. His ELEXER Eiffel 3 parser
  12400. remains the core of the tool.  I though am responsible for any remaining
  12401. deficiencies or problems with this release.
  12402.  
  12403. Problems, suggestions, comments, criticisms to me please. All gratefully
  12404. received - I can't improve my Eiffel if somebody doesn't tell me where I
  12405. blew it.
  12406.  
  12407.  
  12408. >25  COOL(C++, Cfront 2.1, from GE)
  12409.  
  12410. COOL is a C++ class library developed at Texas Instruments.
  12411.  
  12412. Features are:
  12413. 1. Rich set of containers like Vector, List, Hash_Table, Matrix, etc...
  12414. 2. Hierarchy is shallow with no common base class, rather than deep like NIHCL.
  12415. 3. Functionality close to Common Lisp data structures, like GNU libg++.
  12416. 4. Template syntax very close to Cfront3.x, g++2.x.
  12417. 5. Free, with good documentation, and extensive test cases.
  12418.  
  12419. ############################################################################
  12420.  
  12421.  
  12422. Path: senator-bedfellow.mit.edu!faqserv
  12423. From: Bob Hathaway <rjh@geodesic.com>
  12424. Newsgroups: comp.object,comp.answers,news.answers
  12425. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Part 11/13
  12426. Supersedes: <object-faq/part11_805979999@rtfm.mit.edu>
  12427. Followup-To: comp.object
  12428. Date: 31 Aug 1995 15:34:56 GMT
  12429. Organization: Geodesic Systems
  12430. Lines: 1274
  12431. Approved: news-answers-request@MIT.Edu
  12432. Expires: 14 Oct 1995 15:31:54 GMT
  12433. Message-ID: <object-faq/part11_809883114@rtfm.mit.edu>
  12434. References: <object-faq/part10_809883114@rtfm.mit.edu>
  12435. NNTP-Posting-Host: bloom-picayune.mit.edu
  12436. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  12437. X-Last-Updated: 1995/06/01
  12438. Originator: faqserv@bloom-picayune.MIT.EDU
  12439. Xref: senator-bedfellow.mit.edu comp.object:37593 comp.answers:13985 news.answers:51883
  12440.  
  12441. Archive-name: object-faq/part11
  12442. Last-Modified: 05/31/95
  12443. Version: 1.0.8
  12444.  
  12445. Light version of COOL from General Electric:
  12446. 1. Hairy macros, run-time type, exceptions removed for mainstream C++
  12447.    compatibility
  12448. 2. Free of memory leaks and bound violations. Leaks and bounds are checked
  12449.    with Purify.
  12450. 3. Has memory management and efficient copy in expressions like:
  12451.   Set c = a+b+c;    
  12452.   Pointers are shared with Handle and Reference count. Deep copy in
  12453.   expressions are replaced by shallow copy.
  12454. 4. Compatible with Cfront2.1, and is being converted to Cfront3.0. You can
  12455.   build both static and shared library on SunOS 4.1.x
  12456.  
  12457. 1. original version from Texas Instruments:
  12458.    at csc.ti.com, get pub/COOL.tar.Z
  12459. 2. Cfront2.1 version modified by General Electric:
  12460.    at cs.utexas.edu, get pub/COOL/GE_COOL2.1.tar.Z
  12461.  
  12462. I am working on Cfront3.0 version of COOL, using the Beta 3.0 from Sun. I am
  12463. experiencing problems with instantiation and specialization of templates.  So
  12464. Cfront3.0 version of COOL won't be available until Sun's Cfront 3.0 is
  12465. released with bugs fixed.
  12466.  
  12467. Van-Duc Nguyen
  12468. General Electric 
  12469. Research & Development Ctr
  12470. 1 River Road, Room K1-5C39.
  12471. Schenectady, NY 12301.
  12472. Phone: (518) 387-5659
  12473. Fax:   (518) 387-6845
  12474. nguyen@crd.ge.com
  12475.  
  12476.  
  12477. >26  idl.SunOS4.x, idl.Solaris2.x
  12478.  
  12479. Subject: Binaries for OMG IDL CFE placed on omg.org
  12480. Date: 11 Jun 93 00:13:11 GMT
  12481. Reply-To: jyl@toss.eng.sun.com
  12482.  
  12483.  
  12484. SunSoft has made available statically linked binaries for the OMG IDL CFE,
  12485. for both Solaris 1.x and Solaris 2.x. Because they are statically linked,
  12486. these binaries can be used on systems which do not have the SparcWorks (TM)
  12487. compilers installed.
  12488.  
  12489. It is expected that people who only want an IDL parser will prefer to
  12490. obtain these binaries instead of compiling the program on their host.
  12491. People who want to build a complete compiler, by programming their own
  12492. back-end, will continue to obtain the sources which are also provided at
  12493. the same location.
  12494.  
  12495. The binaries can be obtained by anonymous FTP to omg.org. They are
  12496. installed in the directory pub/OMG_IDL_CFE_1.2/bin, in idl.SunOS4.x and
  12497. idl.Solaris2.x. Uuencoded versions are also available, in the same
  12498. directory.
  12499.  
  12500. Please send email to idl-cfe@sun.com if you obtain these files.
  12501.  
  12502. The attached copyright applies to the provided binaries and to the source
  12503. files provided on the omg.org file server.
  12504.  
  12505.  
  12506. Copyright:
  12507. Copyright 1992 Sun Microsystems, Inc.  Printed in the United States of
  12508. America.  All Rights Reserved.
  12509.  
  12510. This product is protected by copyright and distributed under the following
  12511. license restricting its use.
  12512.  
  12513. The Interface Definition Language Compiler Front End (CFE) is made
  12514. available for your use provided that you include this license and copyright
  12515. notice on all media and documentation and the software program in which
  12516. this product is incorporated in whole or part. You may copy and extend
  12517. functionality (but may not remove functionality) of the Interface
  12518. Definition Language CFE without charge, but you are not authorized to
  12519. license or distribute it to anyone else except as part of a product or
  12520. program developed by you or with the express written consent of Sun
  12521. Microsystems, Inc. ("Sun").
  12522.  
  12523. The names of Sun Microsystems, Inc. and any of its subsidiaries or
  12524. affiliates may not be used in advertising or publicity pertaining to
  12525. distribution of Interface Definition Language CFE as permitted herein.
  12526.  
  12527. This license is effective until terminated by Sun for failure to comply
  12528. with this license.  Upon termination, you shall destroy or return all code
  12529. and documentation for the Interface Definition Language CFE.
  12530.  
  12531. [...] etc. on copyright stuff [...]
  12532.  
  12533. SunSoft, Inc.  
  12534. 2550 Garcia Avenue 
  12535. Mountain View, California  94043
  12536.  
  12537. >27  Browser for OO info
  12538.  
  12539. A search engine for Object-Oriented Information Sources on the World
  12540. Wide Web is being maintained by the Software Composition Group at the
  12541. University of Berne, Switzerland.  The URL to access is:
  12542.  
  12543. http://iamwww.unibe.ch/~scg/OOinfo/index.html
  12544.  
  12545. A mirror of the catalog is available from the University of Geneva:
  12546.  
  12547. http://cuiwww.unige.ch/OSG/OOinfo/
  12548.  
  12549. Please e-mail suggestions for new entries to: scg@iam.unibe.ch 
  12550.  
  12551. A searchable bibliography of object-oriented references is also available:
  12552.  
  12553. http://iamwww.unibe.ch/cgi-bin/oobib
  12554.  
  12555. as is a (searchable) version of the OO FAQ:
  12556.  
  12557. http://iamwww.unibe.ch/~scg/OOinfo/FAQ/index.html
  12558.  
  12559. Oscar Nierstrasz
  12560.  
  12561. ---
  12562. Prof. Dr. Oscar Nierstrasz; oscar@iam.unibe.ch; http://iamwww.unibe.ch/~oscar
  12563. Software Composition Group; CS Inst., U. Berne; Tel/Fax: +41 31 631.4618/3965
  12564.  
  12565. >28  Apertos(Meta-Obj Distr OS, research)
  12566.  
  12567. The Apertos (formerly MUSE) project at Sony Research
  12568. is a meta-object based distributed OS for turning portable wireless
  12569. hand-held computers into fully-connected Dynabook-like
  12570. terminals.  It's very very wizzy.  The papers are on: 
  12571.         scslwide.sony.co.jp:pub/CSL-Papers
  12572.  
  12573. The source is available for research; I think you have to
  12574. sign something first.
  12575.  
  12576.  
  12577. >29  Actors Paper (UIUC)
  12578.  
  12579. From: agha@cs.uiuc.edu (Gul Agha)
  12580. Subject: Actor Theory Paper available
  12581. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  12582. Date: Wed, 4 Aug 1993 15:41:02 GMT
  12583.  
  12584. A new paper providing a definitive and detailed development of the
  12585. semantics of actor systems is available via anonymous ftp.  Comments
  12586. are especially welcome.  
  12587.  
  12588.  
  12589. Title:          A Foundation for Actor Computation
  12590.  
  12591. Authors:        Gul Agha, Univerity of Illinois at Urbana-Champaign
  12592.                 Ian Mason, Stanford University
  12593.                 Scott Smith, John Hopkins University
  12594.                 Carolyn Talcott, Stanford University
  12595.  
  12596. Abstract:
  12597.  
  12598.         We present an actor language which is
  12599.         an extension of a simple functional language, and provide a precise
  12600.         operational semantics for this extension.  Actor configurations are
  12601.         open distributed systems, meaning we explicitly take into account the
  12602.         interface with external components in the specification of an actor
  12603.         system.  We define and study various notions of equivalence on actor
  12604.         expressions and configurations.
  12605.  
  12606. to ftp the compressed postscript file:
  12607.         ftp sail.stanford.edu  (or 36.28.0.130)
  12608.         login: anonymous
  12609.         send ident as password.
  12610.         cd pub/MT
  12611. the file is called:  
  12612.         93actors.ps.Z
  12613.  
  12614. Note: the paper is 76pp long.  It subsumes work reported in our paper
  12615. in CONCUR '92.  
  12616.  
  12617. (A number of other recent papers on actor languages and their
  12618. implementation may be obtained by anonymous ftp from
  12619. biobio.cs.uiuc.edu in the directory pub/papers).
  12620.  
  12621.  
  12622. >30  Chambers' Thesis
  12623.  
  12624. What: SELF optimizing compiler and Thesis
  12625. From: chambers@cs.washington.edu (Craig Chambers)
  12626. Date: 9 May 92 22:00:53 GMT
  12627.  
  12628. My Ph.D. thesis, entitled "The Design and Implementation of the Self Compiler,
  12629. an Optimizing Compiler for Object-Oriented Programming Languages," is now
  12630. available as Stanford technical report number STAN-CS-92-1420.  Copies may be
  12631. ordered from Stanford.  Stanford requires $20 (plus tax for orders from within
  12632. California), in advance, for each copy.
  12633.  
  12634. The dissertation also is available in compressed postscript form.  The
  12635. electronic version may be copied via anonymous ftp from self.stanford.edu in
  12636. the directory pub/papers/chambers-thesis.  This version is free.  Note however
  12637. that the thesis is about 250 pages long.
  12638.  
  12639.  
  12640. >31  graph drawing
  12641.  
  12642. From: rt@cs.brown.edu (Roberto Tamassia)
  12643. Subject: annotated bibliography on graph drawing algorithms
  12644. Organization: Brown University Department of Computer Science
  12645. Date: Wed, 30 Jun 1993 06:45:48 GMT
  12646.  
  12647. A new revised version of the annotated bibliography on graph drawing
  12648. algorithms by Giuseppe Di Battista, Peter Eades, Roberto Tamassia, and
  12649. Ioannis Tollis is now available via anonymous ftp from
  12650. wilma.cs.brown.edu (128.148.33.66).  The files are /pub/gdbiblio.tex.Z
  12651. and /pub/gdbiblio.ps.Z.
  12652.  
  12653.  
  12654. >32  Law of Demeter
  12655.  
  12656. From: lieber@ccs.neu.edu (Karl Lieberherr)
  12657. Subject: Law of Demeter/Adaptive Software
  12658. Organization: College of CS, Northeastern University
  12659. Date: Fri, 4 Jun 1993 20:41:49 GMT
  12660.  
  12661.  >...
  12662.  Yes, the Law of Demeter paper is available in electronic form on the
  12663.  net. Indeed, many of the Demeter project papers are available from
  12664.  the ftp server at Northeastern University (see instructions below).
  12665.  
  12666.  The Law of Demeter idea has been automated in the Demeter Tools/C++
  12667.  as an adaptive software tool which automatically makes much of your C++ code
  12668.  compliant with the Law of Demeter. The tool is an add-on tool to
  12669.  your favorite C++ development environment and is commercially available
  12670.  from Demeter International. The Demeter Tools/C++ lift
  12671.  object-oriented programming to a higher level of abstraction
  12672.  by allowing the user to focus on the essential and
  12673.  stable classes. A paper on ADAPTIVE SOFTWARE will appear in 
  12674.  the Communications of the ACM and is also available from the
  12675.  ftp server.
  12676.  
  12677.  For more information, use the ftp instructions below or call
  12678.  
  12679. Demeter International
  12680. 56 Bennett Road
  12681. Marblehead, MA 01945
  12682.  
  12683.  phone: (617) 639 1544
  12684.  fax: (617) 373 5121
  12685.  
  12686. or send e-mail to demeter@ccs.neu.edu 
  12687.  
  12688. -- Karl Lieberherr
  12689.  
  12690. FTP instructions:
  12691.  
  12692. Some of our papers are available in one package by anonymous ftp from
  12693.  
  12694. ftp.ccs.neu.edu (129.10.10.51)
  12695.  
  12696. in directory pub/demeter/documents
  12697.  
  12698. Use the following command sequence to copy the Demeter papers:
  12699.  
  12700. % ftp ftp.ccs.neu.edu or 129.10.10.51)
  12701. Name ( ... ): ftp
  12702. Password: your-email-address
  12703. ftp> cd pub/demeter/documents
  12704. ftp> ls
  12705. ftp> binary
  12706. ftp> get papers.tar.Z
  12707. ftp> quit
  12708. % uncompress papers.tar.Z
  12709. % tar xf papers.tar
  12710.  
  12711. If you want to copy individual papers and not all at once, go to 
  12712. directory pub/demeter/documents/papers and retrieve them
  12713. individually.
  12714.  
  12715. Law of Demeter paper:
  12716.   LH89-law-of-demeter.ps
  12717. Adaptive Software papers:
  12718.   LSLX93-adaptive-programming.ps
  12719.   L92a-component-enhancement.ps
  12720.   LHSLX92-pp-experience.ps
  12721.  
  12722.  
  12723. >33  OO Dyn Grping, memory
  12724.  
  12725. From: mario@cs.man.ac.uk (Mario Wolczko)
  12726. Subject: Re: OOPLs and Locality of Reference
  12727. Keywords: locality of reference
  12728. Date: 5 Jul 93 14:39:13 GMT
  12729. Organization: Dept Computer Science, University of Manchester, U.K.
  12730.  
  12731. [...]
  12732. The measurements done as part of the work here on the Mushroom project
  12733. show that temporal locality within Smalltalk objects is great (and
  12734. hence even conventional caches work reasonably well [unless the GC
  12735. scheme trashes the cache]), whereas spatial locality on a scale much
  12736. larger than the average object (which is 40 bytes) is much harder to
  12737. come by.
  12738.  
  12739. More details can be found in these papers (all available by ftp from
  12740. mushroom.cs.man.ac.uk in /pub/mushroom/papers):
  12741.  
  12742.   dgvm1.ps.Z
  12743.     "Dynamic Grouping in an Object Oriented Virtual Memory Hierarchy"
  12744.     Ifor Williams, Mario Wolczko, Trevor Hopkins, Proc. ECOOP 87,
  12745.     Springer-Verlag LNCS 276, pp.79-88.
  12746.  
  12747.   dgvm2.ps.Z
  12748.     "Realization of a Dynamically Grouped Object-Oriented Virtual
  12749.      Memory Hierarchy", Proceedings of the Workshop on Persistent Object
  12750.      Systems: Their Design, Implementation and Use, available as
  12751.      Persistent Programming Research Report PPRR-44-87, Universities
  12752.      of Glasgow and St. Andrews, Aug. 1987, pp.298--308.
  12753.  
  12754.   obma.ps.Z
  12755.     "An Object-Based Memory Architecture"
  12756.     Ifor Williams and Mario Wolczko, in Implementing Persistent Object
  12757.     Bases: Proc. Fourth International Workshop on Persistent Object Systems,
  12758.     Morgan Kaufmann, 1991, pp.114-130.
  12759.     The first three figures are in obma-fig[123].ps.Z.
  12760.  
  12761. Mario Wolczko
  12762.  
  12763.    ______      Dept. of Computer Science   Internet:      mario@cs.man.ac.uk
  12764.  /~      ~\    The University              uucp:    mcsun!uknet!man.cs!mario
  12765. (    __    )   Manchester M13 9PL          JANET:         mario@uk.ac.man.cs
  12766.  `-':  :`-'    U.K.                        Tel: +44-61-275 6146  (FAX: 6236)
  12767. ____;  ;_____________the mushroom project___________________________________
  12768.  
  12769.  
  12770. >34  Pred Classes (Cecil)
  12771.  
  12772. What: "Predicate Classes" paper
  12773. From: chambers@klamath.cs.washington.edu (Craig Chambers)
  12774. Date: Fri, 30 Apr 93 01:25:02 GMT
  12775.  
  12776. "Predicate classes are a new linguistic construct designed to
  12777. complement normal classes in object-oriented languages. Like a normal
  12778. class, a predicate class has a set of superclasses, methods, and
  12779. instance variables. However, unlike a normal class, an object is
  12780. automatically an instance of a predicate class whenever it satisfies a
  12781. predicate expression associated with the predicate class. The
  12782. predicate expression can test the value or state of the object, thus
  12783. supporting a form of implicit property-based classification that
  12784. augments the explicit type-based classification provided by normal
  12785. classes. By associating methods with predicate classes, method lookup
  12786. can depend not only on the dynamic class of an argument but also on
  12787. its dynamic value or state. If an object is modified, the
  12788. property-based classification of an object can change over time,
  12789. implementing shifts in major behavior modes of the object. A version
  12790. of predicate classes has been designed and implemented in the context
  12791. of the Cecil language."
  12792.  
  12793. Comments on the ideas in the paper are appreciated.
  12794.  
  12795. -- Craig Chambers
  12796.  
  12797.  
  12798. >35  Manchester Archive and some
  12799.  
  12800. What: Manchester Archive, SmallTalk-V
  12801. From: johnson@m.cs.uiuc.edu (Ralph Johnson)
  12802. Date: 18 Dec 91 19:41:38 GMT
  12803.  
  12804. We have a complete copy of everything in the Manchester archive, and you
  12805. can either access it by e-mail like the Manchester archive or by anonymous
  12806. ftp.  Our archive is on st.cs.uiuc.edu, and you can get information about the
  12807. e-mail server by sending to archive-server@st.cs.uiuc.edu, and putting the
  12808. line help in your message. We actually have a little more than is in the
  12809. Manchester archive.  We have the Smalltalk-V code from the defunct
  12810. International Smalltalk Association, and a few other odds and ends.
  12811.  
  12812. Also:
  12813. The University of Illinois Smalltalk Archive is now offering a WWW server
  12814. the URL is http://st-www.cs.uiuc.edu/
  12815.  
  12816.  
  12817. >36  Object Design's OO7 Results
  12818.  
  12819. What: Object Design's Results on the OO7 Benchmarks
  12820. From: dudek@odi.com (Glen Dudek)
  12821. Date: Thu, 29 Apr 93 17:17:11 GMT
  12822.  
  12823. OBJECT DESIGN'S RESULTS ON THE OO7 BENCHMARKS
  12824. April 26, 1993
  12825.  
  12826. We have made a copy of our results available to the Internet community. You
  12827. can access this information through anonymous ftp from ftp.odi.com in the
  12828. file /pub/oo7/results.ps.
  12829.  
  12830. The report includes the "official" tests done for ObjectStore by the
  12831. University of Wisconsin, and our internal execution of all the tests using
  12832. ObjectStore Release 2.0.1, the current production version.  As the report
  12833. shows, our internal execution carefully followed the agreed-upon procedures
  12834. for running OO7, and we believe the numbers that were produced accurately
  12835. represent ObjectStore's performance.
  12836.  
  12837.         For further information contact oo7info@odi.com.
  12838.  
  12839.  
  12840. >37  Graph service
  12841.  
  12842. From: north@ulysses.att.com (Stephen C. North)
  12843. Subject: free samples of directed graph layouts by mail
  12844. Keywords: graph layout, DAG, embedder
  12845. Date: 25 Jun 93 18:28:29 GMT
  12846. Organization: AT&T Bell Laboratories, Murray Hill
  12847.  
  12848. I have created an experimental service for remote users to try some of
  12849. our graph layout programs through Internet mail, for research or
  12850. educational purposes.  I'm looking for a few friendly users to try this
  12851. service.  The programs are:
  12852.  
  12853.     dag (directed graphs, old, program, works with some USL C++ utilities.
  12854.                 This may have unintentionally sparked the apparently misdirected 
  12855.                 discussion of "DAG classes" in one newsgroup recently.)
  12856.     dot (directed graphs, newer algorithms, better layouts, more features)
  12857.     neato (undirected graphs, compatible with dot, Kamada-Kawai spring embedder)
  12858.  
  12859. You can ftp PostScript files of documentation from dist/drawdag/*.Z on
  12860. research.att.com
  12861.  
  12862. To draw graphs, send a graph file to drawdag@toucan.research.att.com
  12863. and give the command line in the Subject header.  For example,
  12864.  
  12865.     From cs.Princeton.EDU!north Thu Jun 24 11:45:28 0400 1993 remote from toucan
  12866.     Date: Thu, 24 Jun 1993 11:45:28 -0400
  12867.     From: Stephen North <north@cs.Princeton.EDU>
  12868.     To: drawdag@toucan.research.att.com
  12869.     Subject: dot -Tps 
  12870.  
  12871.     digraph G { a -> b }
  12872.  
  12873. File arguments are disabled for obvious reasons.  Please let me know if
  12874. you hit any snags.  There is a reasonable limit on graph size and probably
  12875. number of invocations from a given site/account. (If you use it that much,
  12876. AT&T's Intellectual Property Division sells binary executables; their number
  12877. is 800-462-8146).
  12878.  
  12879. Stephen North, AT&T Bell Laboratories, Murray Hill NJ, (908) 582 7392
  12880. Parturiunt montes, nascetur ridiculus mus!
  12881.  
  12882.  
  12883. >38  C++SIM (Simula-like Sim Pkg)
  12884.  
  12885. From: M.C.Little@newcastle.ac.uk (Mark Little)
  12886. Subject: C++SIM Release 1.0 Announcement
  12887. Organization: Computing Laboratory, U of Newcastle upon Tyne, UK NE17RU
  12888. Keywords: C++, SIMULA, simulation, object-oriented
  12889. Date: Mon, 14 Jun 1993 15:02:33 GMT
  12890.  
  12891. C++SIM 1.0 Release Announcement.
  12892.  
  12893. This is to announce the release of version 1.0 of C++SIM, a simulation
  12894. package written in C++. C++SIM provides discrete process based
  12895. simulation similar to that provided by the simulation class and
  12896. libraries of SIMULA. The linked list manipulation facilities provided
  12897. by SIMSET are also included in the package.
  12898.  
  12899. Inheritance was used throughout the design to an even greater extent
  12900. than is already provided by SIMULA. This has allowed us to add new
  12901. functionality without affecting the overall system structure, and hence
  12902. provides for a more flexible and expandable simulation package.
  12903.  
  12904. A paper is included which describes the design and implementation of
  12905. C++SIM and includes a worked example of how to use the package. The
  12906. paper describes the class hierarchy which we have created, and
  12907. indicates how it can be used to further refine the simulation package.
  12908.  
  12909. The simulation package requires the use of a threads package and
  12910. currently only works with Sun's lightweight process library or the Gnu
  12911. thread package (which *is* included in the distribution). The package has
  12912. been used on Sun workstations, and, with the exception of the thread
  12913. library requirement, contains no system specific code which should make
  12914. porting to other systems relatively easy. The code has been compiled
  12915. with Cfront 2.1 and Cfront 3.0.1 and g++ 2.3.3
  12916.  
  12917. If you find any bugs or make modifications (e.g., ports to other thread
  12918. packages) or port it to other systems, then please let me know so I can
  12919. keep the sources up-to-date for other users.
  12920.  
  12921. The package is available via anonymous ftp from arjuna.ncl.ac.uk
  12922.  
  12923.  
  12924. >39  commercial on cd-rom
  12925.  
  12926. From: jimad@microsoft.com (Jim Adcock)
  12927. Subject: Re: Non-defense Ada applications - answering several requests
  12928. Date: 11 Jun 93 18:56:55 GMT
  12929. Organization: Microsoft Corporation
  12930.  
  12931.  >...
  12932.  
  12933. 1) Get a copy of the Computer Select Database.  [I notice the company
  12934. is offering free trial copies [the database is CD-ROM based]]
  12935.  
  12936. 2) Select "Section: Software Product Specifications"
  12937.  
  12938. 3) Select "Find: C++"
  12939.  
  12940. Behold!  A list of 734 commercially available software packages written
  12941. in C++, including some of the best known names in the software industry.
  12942.  
  12943.  
  12944. >40  C++ Signatures (subtyping)
  12945.  
  12946. From: gb@cs.purdue.edu (Gerald Baumgartner)
  12947. Newsgroups: comp.object,comp.lang.c++
  12948. Subject: signature implementation for G++ 2.5.2 and tech report available
  12949. Date: 4 Nov 1993 12:03:00 -0500
  12950. Organization: Department of Computer Sciences, Purdue University
  12951.  
  12952. Announcing the paper
  12953.  
  12954.     Signatures: A C++ Extension for
  12955.     Type Abstraction and Subtype Polymorphism
  12956.  
  12957.     by Gerald Baumgartner and Vincent F. Russo.
  12958.     Tech report CSD-TR-93-059, Dept. of Computer
  12959.     Sciences, Purdue University, September 1993.
  12960.     Submitted to Software Practice & Experience.
  12961.  
  12962. and a beta release of our implementation of
  12963.  
  12964.     signatures for GCC 2.5.2.
  12965.  
  12966.  
  12967.  How to Get that Stuff?
  12968.  ----------------------
  12969.  
  12970. You can get both the paper and the implementation by ftp from
  12971.  
  12972.     host:        ftp.cs.purdue.edu    (128.10.2.1)
  12973.  
  12974.     login:        anonymous
  12975.  
  12976.     password:    your e-mail address
  12977.  
  12978.     directory:    pub/gb
  12979.  
  12980.     files:        COPYING            Copyright notice.
  12981.  
  12982.             README            This file.
  12983.  
  12984.             Signatures.{dvi,ps}.gz    DVI and Postscript versions
  12985.                         of the paper.
  12986.  
  12987.             gcc-2.5.2.sig.diff.gz    Patch to upgrade GCC 2.5.2.
  12988.  
  12989.             test.tar.gz        Test files and script to run
  12990.                         the tests.
  12991.  
  12992. To make GCC 2.5.2 understand signatures, just copy the context diff
  12993. file into the GCC source directory, type
  12994.  
  12995.     gunzip gcc-2.5.2.sig.diff.gz
  12996.     patch < gcc-2.5.2.sig.diff
  12997.  
  12998. and rebuild and install `gcc,' `cc1plus,' the man pages, and the manual.
  12999.  
  13000. For compiling C++ code containing signatures, you need to use the
  13001. command line option
  13002.  
  13003.     -fhandle-signatures
  13004.  
  13005. We tested our extension on Sun 4 only, but since there are no changes
  13006. to the compiler backend, it is expected work on other architectures as
  13007. well.  To test whether it works on your architecture, unpack the file
  13008. `test.tar.gz' and run the shell script
  13009.  
  13010.     Test
  13011.  
  13012. It compiles the test programs and runs them.  If everything works
  13013. correctly, all the test programs (all 40 of them) should print
  13014.  
  13015.     Hello World.
  13016.  
  13017.  
  13018.  What are Signatures anyway?
  13019.  ---------------------------
  13020.  
  13021. Roughly, signatures are type abstractions or interfaces of classes.
  13022. They are related to ML's signatures, categories in Axiom, definition
  13023. modules in Modula-2, interface modules in Modula-3, and types in
  13024. POOL-I.
  13025.  
  13026. The main language constructs added are signatures and signature pointers.
  13027. For example, the signature declaration
  13028.  
  13029.     signature S
  13030.     {
  13031.       int foo (void);
  13032.       int bar (int);
  13033.     };
  13034.  
  13035. defines a new abstract type `S' with member functions `int foo (void)'
  13036. and `int bar (int).'  Signature types cannot be instantiated since they
  13037. don't provide any implementation.  Only signature pointers and signature
  13038. references can be defined.  For example,
  13039.  
  13040.     C obj;
  13041.     S * p = &obj;
  13042.  
  13043. defines a signature pointer `p' and initializes it to point to an object
  13044. of class type `C,' where `C' is required to contain the public member
  13045. functions `int foo (void)' and `int bar (int).'  The member function call
  13046.  
  13047.     int i = p->foo ();
  13048.  
  13049. executes then `obj.foo ().'
  13050.  
  13051. Class `C' is called an implementation of the abstract type `S.'  In
  13052. this example, we could have made `S' an abstract virtual class and `C' a
  13053. subclass of `S,' and we would have had the same effect.  The advantages
  13054. of signatures over abstract virtual classes are
  13055.  
  13056.     - you can build a type hierarchy separate from the class inheritance
  13057.       (implementation) hierarchy,
  13058.     - subtyping becomes decoupled from inheritance, and
  13059.     - signatures can be used with compiled classes, while you cannot
  13060.       retrofit an abstract virtual class on top of compiled class
  13061.       hierarchies.
  13062.  
  13063. For more information, please, see the paper.
  13064.  
  13065.  
  13066.  What's Implemented and what's not?
  13067.  ----------------------------------
  13068.  
  13069. Signature declarations and signature pointers are implemented and
  13070. working.  For examples of what's working and how to use them you can
  13071. have a look at the test files.
  13072.  
  13073. The following bugs are known:
  13074.  
  13075.       - The destructor of objects cannot be called though signature pointers.
  13076.       - A signature pointer cannot point to an object of a class defined
  13077.     by multiple inheritance.
  13078.       - The signature conformance check does not work if the signature
  13079.     contains other signature declarations or class declarations.
  13080.       - Operator and conversion operator member functions of signatures
  13081.     can only be called with function call syntax, such as
  13082.     `p->operator+(17),' but not with operator or conversion syntax.
  13083.  
  13084. The following language constructs and features are not yet implemented:
  13085.  
  13086.       - constants in signatures,
  13087.       - signature references,
  13088.       - signature inheritance,
  13089.       - the `sigof' (signature of a class) construct,
  13090.       - views (not even the parsing is done),
  13091.       - signature templates, and
  13092.       - exception specifications in signature member function declarations.
  13093.  
  13094. The following optimization is not implemented:
  13095.  
  13096.       - Looking up a virtual class member function through a signature
  13097.     pointer/reference requires double indirection.  This can be optimized
  13098.     by memoizing, so that only the first lookup of a member function
  13099.     requires double indirection and further lookups require only single
  13100.     indirection.
  13101.  
  13102. The items above are roughly in the order in which they will be implemented.
  13103.  
  13104. Besides bug fixes, the main features that have been implemented since the
  13105. last release are default implementations of signature member functions
  13106. and opaque types.
  13107.  
  13108.  
  13109.  Feedback
  13110.  --------
  13111.  
  13112. Please, send your questions, comments, suggestions, and complaints to
  13113.  
  13114.     gb@cs.purdue.edu
  13115.  
  13116. --
  13117. Gerald Baumgartner
  13118. Dept. of Computer Sciences, Purdue University,  W. Lafayette, IN 47907
  13119. Internet: gb@cs.purdue.edu, UUCP: ...!{decwrl,gatech,ucbvax}!purdue!gb
  13120.  
  13121.  
  13122. >41 The Texas Persistent Store
  13123.  
  13124.   The Texas Persistent Store, version 0.1
  13125.  
  13126. Texas is a simple, portable, high-performance and (best of all) FREE
  13127. persistent store for C++ using "pointer swizzling at page fault time"
  13128. to translate persistent addresses to hardware-supported virtual addresses.
  13129.  
  13130. Texas is built on top of a normal virtual memory, and relies on the
  13131. underlying virtual memory system for caching.  It uses user-level virtual
  13132. memory protections to control the faulting of data from a persistent storage
  13133. file into virtual memory.
  13134.  
  13135. All addresses in a page are translated from a persistent format to
  13136. actual virtual addresses when the page is brought into virtual memory,
  13137. and subsequent memory references (including pointer traversals) are
  13138. just as fast as for non-persistent data.
  13139.  
  13140. Texas is easy to use, and is implemented as a UNIX library.  It is small
  13141. and can be linked into applications.  It requires no special operating 
  13142. system privileges, and persistence is orthogonal to type---objects may be 
  13143. allocated on either a conventional transient heap, or on the persistent
  13144. heap, as desired.
  13145.  
  13146. Texas supports simple checkpointing of heap data.  A log-structured storage
  13147. module is under development, and will provide fast checkpointing of small
  13148. transactions.
  13149.  
  13150. Texas is beta software, and the current prerelease version supports only
  13151. simple single-machine operation.  Future releases will support client-server
  13152. operation, a flexible access control scheme, and transaction support.
  13153.  
  13154. Texas currently runs under SunOS and ULTRIX, using Sun CC or GNU C++.
  13155. Porting to other modern systems (e.g., OS/2, WNT, Mach) should be easy---it
  13156. requires only mprotect(), signal(), and sbrk() calls (or their equivalent)
  13157. to control virtual memory protection setting and trap handling.
  13158.  
  13159. Papers about the pointer swizzling scheme and Texas itself (referenced
  13160. below) are available via anonymous ftp from cs.utexas.edu (IP address
  13161. 128.83.139.9), as postscript files swizz.ps and texaspstore.ps in the
  13162. directory pub/garbage.
  13163.  
  13164. The source code for Texas is also available, in the directory
  13165. pub/garbage/texas.
  13166.  
  13167. References:
  13168.  
  13169. Paul R. Wilson and Sheetal V. Kakkad, "Pointer Swizzling at Page Fault
  13170. Time: Efficiently and Compatibly Supporting Huge Address Spaces on Standard
  13171. Hardware," Proc. Second Int'l. Workshop on Object Orientation in Operating
  13172. Systems, Sept. 1992, Dourdan, France, pp. 364--377.
  13173.  
  13174. Vivek Singhal, Sheetal V. Kakkad, and Paul R. Wilson, "Texas: an Efficient,
  13175. Portable Persistent Store", Proc. Fifth Int'l. Workshop on Persistent Object
  13176. Systems, Sept. 1992, San Miniato, Italy, pp. 11-33.
  13177.  
  13178.  
  13179. >42 OSE C++lib
  13180.  
  13181. From: Graham.Dumpleton@nms.otc.com.au (Graham Dumpleton)
  13182. Date: Tue, 9 May 1995 08:58:55 +1000 (EST)
  13183.  
  13184. OSE is a collection of programming tools and class libraries for C++. The
  13185. core of the environment is the C++ class libraries, of which three are
  13186. provided. These are:
  13187.  
  13188.   OTCLIB - A library of generic components, including support for error
  13189.   handling, error message logging, error recovery, program debugging,
  13190.   memory management, resource management, generic collections, text
  13191.   manipulation, date/time, operating system interfacing and event driven
  13192.   systems.
  13193.  
  13194.   OUXLIB - A library of components which primarily extends classes in the
  13195.   OTCLIB library to support features specific to the UNIX operating
  13196.   system.
  13197.  
  13198.   OTKLIB - A library of components which builds on the OTCLIB and OUXLIB
  13199.   libraries to allow integration of the TCL/TK library into applications
  13200.   using the event driven systems framework provided by the OTCLIB
  13201.   library.
  13202.  
  13203. The C++ libraries are portable to a wide range of C++ compilers on the
  13204. UNIX platform. Supported C++ compilers include those from ATT/USL (CFRONT),
  13205. CenterLine, DEC, HP, IBM, Lucid, ObjectStore, SGI (CFRONT), SGI (DELTA),
  13206. Sun (CFRONT) and Sun (NATIVE), as well as the freely available GNU C++
  13207. compiler. If your C++ compiler does not support templates, it is possible
  13208. to use a template preprocessor which is supplied with OSE. If your C++
  13209. compiler support exceptions, they will be used. Portability to all the
  13210. major variants of UNIX has been achieved. Supported platforms include AIX,
  13211. BSD, HPUX, IRIX, Linux, NeXT, OSF, SCO, Solaris, SunOS, SYSV and Ultrix. In
  13212. addition to being available under UNIX, the OTCLIB library has been ported
  13213. to DOS, OS/2 and Windows NT using Borland, Watcom and Microsoft C++
  13214. compilers.
  13215.  
  13216. The C++ libraries have been fully integrated with the ObjectStore OODBMS,
  13217. allowing instances of classes from the C++ libraries to be made persistent.
  13218. The C++ libraries can also be used in conjunction with applications using
  13219. Versant, although in this case instances of classes from the C++ libraries
  13220. cannot be made persistent.
  13221.  
  13222. In addition to the C++ libraries, a build environment is provided. The
  13223. build environment greatly simplifies the writing of makefiles, making the
  13224. the task of building applications, as well as the generation and
  13225. installation of both static and shared libraries easy. The details of
  13226. template instantiation for many of the C++ compilers is also hidden, making
  13227. it possible to write makefiles which are portable between different C++
  13228. compilers as well as different platforms. The build environment also
  13229. supports tasks such as schema generation for the ObjectStore and Versant
  13230. OODBMS, and testing of applications using tools such as Purify, Quantify,
  13231. PureCoverage, TestCenter and Sentinel.
  13232.  
  13233. Comprehensive documentation for the C++ libraries and build environment is
  13234. provided. Documentation for the C++ libraries comes in the form of a UNIX
  13235. style manual page for each class and higher level documentation giving
  13236. examples of how to use the classes. The UNIX style manual pages are
  13237. generated from the class header files using documentation extraction tools.
  13238. These tools are provided with OSE and are capable of generating both UNIX
  13239. style manual pages and Frame documents.
  13240.  
  13241. Development of OSE commenced in 1990, being made freely available via the
  13242. Internet in 1993. OSE was winner of CODA'94, the ComputerWorld Object
  13243. Developer Awards, held in conjunction with ObjectWorld in Sydney,
  13244. Australia. The category in which OSE was a winner was "Best implementation
  13245. of a reusable development environment for company deployment".
  13246.  
  13247. OSE (source code and documentation) can be obtained via anonymous ftp from:
  13248.  
  13249.   Europe:
  13250.  
  13251.     ftp.th-darmstadt.de [130.83.55.75]
  13252.     directory pub/programming/languages/C++/class-libraries/OSE
  13253.  
  13254.   United States
  13255.  
  13256.     -- looking for new site
  13257.  
  13258.   Australia:
  13259.  
  13260.     csis.dit.csiro.au [192.41.146.1]
  13261.     directory pub/SEG/ose
  13262.  
  13263. Documentation for OSE is also available online via WWW at:
  13264.  
  13265.   http://www.telstra.com.au/docs/ose/doc/ose-home.html
  13266.  
  13267. Questions regarding OSE can be sent to;
  13268.  
  13269.   ose@nms.otc.com.au
  13270.  
  13271. A mailing list for discussion of OSE, and a mail server providing a list of
  13272. known problems and fixes also exists.
  13273.  
  13274. OSE is made freely available by Dumpleton Software Consulting Pty Limited.
  13275. OSE contains licensed program materials which are the copyright of Telstra
  13276. Corporation Limited and which are licensed to Dumpleton Software Consulting
  13277. Pty Limited by Telstra Corporation Limited.
  13278.  
  13279. >43 Traces,kiczales,MOP,DI
  13280.  
  13281. From: gregor@parc.xerox.com (Gregor Kiczales)
  13282. Subject: Re: Dynamic Objects
  13283. In-Reply-To: rjh@geodesic.com's message of 25 Aug 93 21:52:56 GMT
  13284. Message-ID: <GREGOR.93Sep3093506@calvin.parc.xerox.com>
  13285. Organization: Xerox Palo Alto Research Center
  13286. References: <16C357BF0.MFARMER@utcvm.utc.edu> <1993Aug25.215256.8031@midway.uchicago.edu>
  13287. Date: 3 Sep 93 09:35:06
  13288.  
  13289. Earlier in this series of messages, Craig Chambers and others mentioned
  13290. his ECOOP'93 paper on predicate classes, which provide a powerful handle
  13291. on some of the problems that have been mentioned in this series of
  13292. messages, specifically, how dynamic changes to an object or its context
  13293. can be harnessed to reliably effect the object's (message receipt)
  13294. behavior.  As I see it, predicate classes are a key step towards solving
  13295. one of the most frustrating problems of OO programming: the struggle
  13296. over whether to encode some difference among objects in the value of a
  13297. slot (that is one of its parts) or in the object's `method table' (class
  13298. or that which it is one-of).
  13299.  
  13300. A closely related problem, that has also come up in this series of
  13301. messages, is how so-called factory objects can dynamically select the
  13302. behavior of the objects they create.  We have developed a new OO
  13303. language concept called Traces, that can be used to make much more
  13304. powerful factory objects, as well as handle some of the things predicate
  13305. classes do.  The two ideas are similar in that they both make behavior
  13306. selection a much more dynamic phenomena.
  13307.  
  13308. My ISOTAS'93 paper presents the concept of Traces and shows it
  13309. application to some problems.  This paper is available for anonymous FTP
  13310. from ftp.parc.xerox.com, in the /pub/mops directory.  The file is
  13311. traces.ps.
  13312.  
  13313. Gregor
  13314.  
  13315. Following is the abstract from the paper:
  13316.   
  13317. Object-oriented techniques are a powerful tool for making a system
  13318. end-programmer specializable.  But, in cases where the system not only
  13319. accepts objects as input, but also creates objects internally,
  13320. specialization has been more difficult.  This has been referred to as
  13321. the ``make isn't generic problem.''  We present a new \oo{} language
  13322. concept, called traces, that we have used successfully to support
  13323. specialization in cases that were previously cumbersome.
  13324.   
  13325. The concept of traces makes a fundamental separation between two kinds
  13326. of inheritance in \oo{} languages: inheritance of default implementation
  13327. -- an aspect of code sharing; and inheritance of specialization, a
  13328. sometimes static, sometimes dynamic phenomenon.
  13329.  
  13330.  
  13331. >44 C++ coding standard
  13332.  
  13333. From: metz@iam.unibe.ch (Igor Metz)
  13334. Subject: Re: C++ coding standard
  13335. Organization: Dept. of CS, University of Berne, Switzerland
  13336. Date: Tue, 7 Sep 1993 07:08:21 GMT
  13337.  
  13338. euagate.eua.ericsson.se   (Internet Address: 134.138.134.16)
  13339. ~ftp/pub/eua/c++/rules.ps.Z
  13340.  
  13341. [Also an archive site.  E.g. Coplien includes a dir of C++ examples]
  13342.  
  13343.  
  13344. >45 Kala Archive
  13345.  
  13346. From: sss@world.std.com (Sergiu S Simmel)
  13347. Subject: Kala White Paper now available via anonymous ftp
  13348. Message-ID: <CD4MyB.Hsn@world.std.com>
  13349. Organization: Penobscot Development Corporation, Cambridge MA
  13350. Date: Fri, 10 Sep 1993 07:18:11 GMT
  13351.  
  13352. An 8-page paper providing an overview of what Kala is and what Kala is
  13353. for is now available, in PostScript format, in the Kala Archive. The
  13354. file is accessible, via anonymous FTP, at the following location:
  13355.  
  13356.           anonymous@world.std.com:/pub/kala/TechDocs/Overview.ps
  13357.  
  13358. The outline is the following
  13359.  
  13360.         1 What is Kala For?
  13361.         2 Software Infrastructure
  13362.                 Persistent Data and Persistent Stores
  13363.         3 Data Transfer
  13364.         4 Data Visibility
  13365.                 Changing Visibility
  13366.                 Sharing Visibility
  13367.                 Transactions
  13368.                 Versions
  13369.         5 Runtime and Architectural Models
  13370.         6 Relationship to Other Technologies
  13371.  
  13372. This paper is targeted towards those who don't know anything about
  13373. Kala and would like to find out a bit in 10 pages or less.
  13374.  
  13375. Enjoy!
  13376.  
  13377. P.S. For those of you who do not have FTP access and would like to
  13378.      obtain this file, please send a brief e-mail message to
  13379.      info@Kala.com, requesting that the file be e-mailed to you.
  13380.      Beware that the file is approximately 425Kbytes long (the paper
  13381.      contains 13 illustrations!).
  13382.  
  13383.  
  13384. >46 BeBOP(seq,par,LP,OO,meta)
  13385.  
  13386. From: ad@munta.cs.mu.OZ.AU (Andrew Davison)
  13387. Subject: BeBOP v.1.0 Available
  13388. Message-ID: <9325614.15552@mulga.cs.mu.OZ.AU>
  13389. Organization: Department of Computer Sci, University of Melbourne
  13390. Follow-Up: comp.parallel
  13391. Date: Mon, 13 Sep 1993 04:08:41 GMT
  13392.  
  13393.  BeBOP and bp Version 1.0 now available
  13394.  ======================================
  13395.  
  13396.  What is BeBOP?
  13397.  ==============
  13398. The language BeBOP is a unique combination of sequential 
  13399. and parallel Logic Programming (LP), object oriented 
  13400. programming and meta-level programming. 
  13401.  
  13402. The LP component offers both don't know non-determinism
  13403. and stream AND-parallelism, a combination not possible 
  13404. with concurrent LP languages. 
  13405.  
  13406. BeBOP's object oriented features include object IDs, 
  13407. encapsulation, message passing, state updating, and 
  13408. object behaviour modification. 
  13409.  
  13410. The meta-level capabilities are based on the treatment 
  13411. of Prolog theories as first order entities, which 
  13412. enables them to be updated easily, and for fragments 
  13413. to be passed between objects in messages.
  13414.  
  13415. BeBOP is implemented by translation down to NU-Prolog,
  13416. and its parallel extension, PNU-Prolog. An unusual
  13417. aspect of this is the way that object IDs are utilized 
  13418. as a communication mechanism between objects.
  13419.  
  13420.  What is bp?
  13421.  ===========
  13422. The bp interactive interpreter supports BeBOP programming 
  13423. by allowing the flexible invocation of objects, and 
  13424. offering the means for setting up communication links 
  13425. between objects at any time. An incidental benefit is 
  13426. the ability to use `global' variables in queries. Since 
  13427. bp is an augmentation of the NU-Prolog np system, objects 
  13428. and Prolog goals can be combined, and a by-product is 
  13429. that the floundering of Prolog queries is avoided.
  13430.  
  13431.  
  13432.  Where are they?
  13433.  ===============
  13434. The BeBOP system (BeBOP and bp), and the PNU-Prolog 
  13435. preprocessor pnp, can be found at the anonymous ftp 
  13436. site munnari.oz.au (128.250.1.21), in the directory 
  13437. pub as the file bebop.tar.Z. Remember to use binary 
  13438. mode when copying it.
  13439.  
  13440. The release comes with a user manual, several papers 
  13441. (in Postscript format), sample programs, and source code.
  13442.  
  13443.  
  13444.  System requirements
  13445.  ===================
  13446. The BeBOP system requires the following:
  13447.  
  13448. * The NU-Prolog system, compiler and interpreter
  13449. * The pnp preprocessor 
  13450.   (this is included as part of the BeBOP system release)
  13451. * GCC or similar compiler
  13452. * Yacc (or Bison) and Lex
  13453.  
  13454.  
  13455.  For more details, contact:
  13456.  ==========================
  13457.         Andrew Davison
  13458.         Dept. of Computer Science
  13459.         University of Melbourne
  13460.         Parkville, Victoria 3052
  13461.         Australia
  13462.  
  13463. Email:  ad@cs.mu.oz.au
  13464. Fax:    +61 3 348 1184
  13465. Phone:  +61 3 287 9172 / 9101
  13466. Telex:  AA 35185
  13467.  
  13468.  
  13469. >47 Knowledge Media, Massive cd-rom, lots of freeware
  13470.  
  13471. A "Resource Library" of cd-rom discs .  CDs for language/OS, graphics, multi-
  13472. media, mega-media (3), and audio.  "Gathered from the resources of the
  13473. Internet, CompuServe, Genie, BIX, and other BBS's".  Some shareware.  Should be
  13474. available at your local software store.
  13475.  
  13476. From the back of the Languages CD:
  13477.  
  13478.   'Over 100 Languages'
  13479.         ...
  13480.  
  13481. This is the largest collection of compilers, interpreters, libraries, and
  13482. source code for standard and experimental computer languages and operating
  13483. systems ever assembled.  A must for anyone interested in computer programming,
  13484. this disc is just right for everyone, whether he or she is a researcher,
  13485. student, or an interested hobbist.
  13486.  
  13487. Knowledge Media Inc.
  13488. Paradise, CA  95969 USA
  13489.  
  13490.  
  13491. >48 u++, C++ Trans. and Concry RTS
  13492.  
  13493. From: nat@nataa.frmug.fr.net (Nat Makarevitch)
  13494. Subject: Re: 'Concurrent Objects' - Suggestions needed
  13495. Date: 10 Oct 1993 02:41:15 GMT
  13496. Organization: LIVIA
  13497.  
  13498.        u++ - uC++ Translator and Concurrency Runtime System
  13499.  
  13500. DESCRIPTION
  13501. The u++ command introduces  a  translator  pass  over  the
  13502. specified source files after the C preprocessor and before
  13503. the actual C++ compilation.  The translator converts  sev-
  13504. eral  new  uC++  constructs  into C++ statements.  The u++
  13505. command also provides  the  runtime  concurrency library,
  13506. which must be linked with each uC++ application.
  13507.  
  13508.                                                                  
  13509. REFERENCES                                                       
  13510. uC++:  Concurrency in the Object-Oriented Language C++, by      
  13511. P.A.  Buhr,  G.  Ditchfield,  R.A.   Stroobosscher,   B.M.
  13512. Younger, C.R.  Zarnke;   Software-Practise and Experience,
  13513. 22(2):137--172, February 1992.  This paper describes  uC++
  13514. v2.0, which has been significantly extended.
  13515.  
  13516. The  uC++  system is available via anonymous FTP
  13517. from watmsg.UWaterloo.ca:pub/uSystem.  A license agreement
  13518. is required to use uC++.
  13519.  
  13520.  
  13521. >49 Real Time
  13522.  
  13523. From: dstewart+@cs.cmu.edu (David B Stewart)
  13524. Subject: Re: Object-Oriented Systems and Realtime
  13525. Organization: The Robotics Institute, Carnegie Mellon University
  13526. Date: Mon, 11 Oct 1993 16:51:19 GMT
  13527.  
  13528. In article <1993Oct11.082519.23058@cs.tcd.ie>,
  13529. Chris Zimmermann <czimmerm@cs.tcd.ie> wrote:
  13530. >Hi community:
  13531. >
  13532. >What is the state of the art concerning real time in 
  13533. >object-oriented systems (if any)? By this, I mean the
  13534. >marriage of more or less traditional real time systems
  13535. >(including systems concerned with "soft" real time aspects
  13536. >like multimedia) with the OO paradigm.
  13537. >[...]
  13538.  
  13539. We've done significant work in that area.  Check out the following tech
  13540. report:
  13541.  
  13542. D. B. Stewart, R. A. Volpe, and P. K. Khosla, "Design of Dynamically
  13543.     Reconfigurable Real-Time Software using Port-Based Objects," 
  13544.     Carnegie Mellon University Tech Report #CMU-RI-TR-93-11, July 1993.
  13545.  
  13546.     Abstract: The current development of applications for sensor-based
  13547.     robotic and automation (R&A) systems is typically a `one-of-a-kind'
  13548.     process, where most software is developed from scratch, even though
  13549.     much of the code is similar to code written for other applications.
  13550.     The cost of these systems can be drastically reduced and the capability
  13551.     of these systems improved by providing a suitable software framework
  13552.     for all R&A sys tems. We describe a novel software framework, based on
  13553.     the notion of dynamically reconfigurable software for sensor-based
  13554.     control systems. Tools to support the implementation of this framework
  13555.     have been built into the Chimera 3.0 Real-Time Operating System. The
  13556.     framework provides for the systematic development and predictable
  13557.     execution of flexible R&A applications while maintaining the ability to
  13558.     reuse code from previous applications. It combines object-oriented
  13559.     design of software with port-automaton design of digital control
  13560.     systems. A control module is an instance of a class of port-based
  13561.     objects. A task set is formed by integrating objects from a module
  13562.     library to form a specific configuration. An implementation using
  13563.     global state variables for the automatic integration of port-based
  13564.     objects is presented. A control subsystem is a collection of jobs
  13565.     which are executed one at a time, and can be programmed by a user.
  13566.     Multiple control subsystems can execute in parallel, and operate
  13567.     either independently or cooperatively. One of the fundamental concepts
  13568.     of reconfigurable software design is that modules are developed
  13569.     independent of the target hardware. Our framework defines classes of
  13570.     reconfigurable device driver objects for proving hardware independence
  13571.     to I/O devices, sensors, actuators, and special purpose processors.
  13572.     Hardware independent real-time communication mechanisms for
  13573.     inter-subsystem communication are also described. Along with providing
  13574.     a foundation for design of dynamically reconfigurable real-time
  13575.     software, we are also developing many modules for the control module,
  13576.     device driver, and subroutine libraries. As the libraries continue to
  13577.     grow, they will form the basis of code that can eventually be used by
  13578.     future R&A applications. There will no longer be a need for developing
  13579.     software from scratch for new applications, since many required modules
  13580.     will already be available in one of the libraries.  
  13581.  
  13582. This report is available via anonymous FTP as follows:
  13583.  
  13584.     % ftp IUS4.IUS.CS.CMU.EDU    (128.2.209.143)
  13585.     Name:       anonymous
  13586.     Password:   yourname@yourmachine
  13587.     ftp> binary
  13588.     ftp> cd /usr/chimera/public
  13589.     ftp> get CMU_RI_TR_93_11.ps.Z
  13590.     ftp> quit
  13591.     % uncompress CMU_RI_TR_93_11.ps.Z
  13592.     % lpr CMU_RI_TR_93_11.ps    (must be a postscript printer)
  13593.  
  13594. For more information, 'finger chimera@cmu.edu'.
  13595.  
  13596. >50 Ada95 (compiler, GNU)
  13597.  
  13598. From: stt@spock.camb.inmet.com (Tucker Taft)
  13599. Subject: Re: which language to use ...?
  13600. Organization: Intermetrics, Inc.
  13601. Date: Mon, 1 Nov 1993 23:22:42 GMT
  13602.  
  13603.  >[...]
  13604.  
  13605. Also, there is a preliminary release of a GNU-GCC-based Ada 9X
  13606. compiler available from NYU on cs.nyu.edu in pub/gnat/...
  13607. The front end is written in Ada itself; the back end
  13608. is the usual GCC back end (enhanced as appropriate).
  13609.  
  13610. S. Tucker Taft  stt@inmet.com
  13611. Intermetrics, Inc.
  13612. Cambridge, MA  02138
  13613.  
  13614.  
  13615. >51 OO Course Slides
  13616.  
  13617. From: wellerd@ajpo.sei.cmu.edu (David Weller)
  13618. Subject: Re: Slides on OOP or OMT wanted
  13619. Organization: Sigma Software Engineering, Inc.
  13620. Date: Fri, 5 Nov 1993 11:01:44 EST
  13621.  
  13622. In article <2bdot7$3nr@news-rocq.inria.fr> ziane@lolita.inria.fr (Mikal Ziane (Univ. Paris 5 and INRIA) ) writes:
  13623. >
  13624. >Hello netters,
  13625. >
  13626. >Is anybody aware of public domain slides available on an ftp site ?
  13627. >I'd like slides on OO programming or OO design methods (esp. OMT).
  13628. >I know I am crazy to ask for that but someone told me he saw
  13629. >a very good C++ course on some ftp site ! (he does not remember which one 
  13630. >unfortunatemy)
  13631. >
  13632.  
  13633. It's true!  On WUArchive (wuarchive.wustl.edu) there is a series of
  13634. slides developed in Microsoft's PowerPoint.  The course material
  13635. includes lesson plans, tests, and workbooks, along with full notes
  13636. accompanying each slide.
  13637.  
  13638. There's one _little_ catch -- it's in the Public Ada Library.  Now,
  13639. the OOP course (there's three courses, one on OOD, OOP, and Software
  13640. Engineering) covers both C++ and Ada.  It was designed to let the
  13641. students work in both languages to get an objective opinion of the
  13642. pluses and minuses of each language (gee, what a concept!).
  13643.  
  13644. The OOD slides do NOT cover OMT.  Some material is used from Booch's
  13645. OOD book, but not the notation.  From looking at the slides, it appears
  13646. very easy to insert your own notation.  The important part for students
  13647. is communicating the concepts, which (for the price) these slides do
  13648. a DAMN good job of. <- (Safire's Violation #45: "A perposition is a 
  13649. bad thing to end a sentence with." :-)
  13650.  
  13651. Ah, but WHERE on WUArchive are they?  If you look under 
  13652. languages/ada/crsware, I believe you'll find them.  Good luck!
  13653.  
  13654. dgw
  13655. -- 
  13656. type My_Disclaimer is new Standard.Disclaimer with record
  13657.     AJPO, SEI : Cognizance := Disavow_All_Knowledge;
  13658. end record;--)
  13659.  
  13660.  
  13661. >52 GTE Distrib Reports
  13662.  
  13663. From: em02@gte.com (Emon)
  13664. Subject: Reports Available From The Distributed Object Computing Department
  13665. Date: 5 Nov 93 18:10:15 GMT
  13666. Organization: GTE Laboratories, Inc.
  13667.  
  13668.                         REPORTS AVAILABLE FROM
  13669.              THE DISTRIBUTED OBJECT COMPUTING DEPARTMENT
  13670.                      GTE LABORATORIES INCORPORATED
  13671.                         40 Sylvan Road, M/S 62
  13672.                      Waltham, Massachusetts 02254
  13673.  
  13674.  
  13675. For over six years, the primary focus of the Distributed Object Computing
  13676. Department within GTE Laboratories has been the Distributed Object
  13677. Management (DOM) project. The DOM project conducts research into
  13678. object-oriented technology for integrating heterogeneous, autonomous,
  13679. distributed (HAD) computer systems/resources. Major research areas include:
  13680. interoperable object models; interoperable, distributed object
  13681. architectures; heterogeneous, extended transaction models; and information
  13682. requests in HAD environments. We are experimenting in these areas using our
  13683. prototype DOM system which we have developed over the past five years. This
  13684. technology is based on ideas from a number of technical areas including
  13685. distributed, object-oriented, databases, multi-database systems, operating
  13686. systems, and programming languages.
  13687.  
  13688. Permission is granted at this time for the operations and uses listed
  13689. below. However, this permission is non-transferable and is subject to
  13690. revocation on a report-by-report basis, due to possible copyright transfers
  13691. that are normal in the publication process. Any additional copyright
  13692. restrictions are noted in the reports themselves. Default permissions are
  13693. for anonymous ftp, electronic viewing, and single-copy printing.
  13694. Permissible uses are research and browsing. Specifically prohibited are
  13695. SALES of any copy, whether electronic or hardcopy, of any of these reports
  13696. for any purpose. Also prohibited is copying, excerpting or extensive
  13697. quoting of any report in another work without the written permission of one
  13698. of the report's authors.
  13699.  
  13700. Reports marked with a "*" can be retrieved in postscript(ascii) form via
  13701. anonymous ftp from ftp.gte.com (132.197.8.2) in the "pub/dom" subdirectory.
  13702.  
  13703.  >>>>>>>>> 1994
  13704.  
  13705. [GEOR94a]*   Georgakopoulos, D., M. Rusinkiewicz, and W. Litwin,
  13706. "Chronological Scheduling of Transactions with Temporal Dependencies," to
  13707. appear in the VLDB journal, January 1994 (submitted in December 1990). 
  13708.  
  13709. [GEOR94b]*   Georgakopoulos, D., M. Hornick, P. Krychniak, and F. Manola,
  13710. "Specification and Management of Extended Transactions in a Programmable
  13711. Transaction Environment," to appear in the Proceedings of the 10th
  13712. International Conference on Data Engineering, Houston, Texas, February
  13713. 1994. Also published as TC-0207-02-93-165, GTE Laboratories Incorporated,
  13714. February 1993.
  13715.  
  13716. ############################################################################
  13717.  
  13718.  
  13719. Path: senator-bedfellow.mit.edu!faqserv
  13720. From: Bob Hathaway <rjh@geodesic.com>
  13721. Newsgroups: comp.object,comp.answers,news.answers
  13722. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Part 12/13
  13723. Supersedes: <object-faq/part12_805979999@rtfm.mit.edu>
  13724. Followup-To: comp.object
  13725. Date: 31 Aug 1995 15:35:03 GMT
  13726. Organization: Geodesic Systems
  13727. Lines: 1202
  13728. Approved: news-answers-request@MIT.Edu
  13729. Distribution: world
  13730. Expires: 14 Oct 1995 15:31:54 GMT
  13731. Message-ID: <object-faq/part12_809883114@rtfm.mit.edu>
  13732. References: <object-faq/part11_809883114@rtfm.mit.edu>
  13733. NNTP-Posting-Host: bloom-picayune.mit.edu
  13734. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  13735. X-Last-Updated: 1995/06/01
  13736. Originator: faqserv@bloom-picayune.MIT.EDU
  13737. Xref: senator-bedfellow.mit.edu comp.object:37594 comp.answers:13986 news.answers:51884
  13738.  
  13739. Archive-name: object-faq/part12
  13740. Last-Modified: 05/31/94
  13741. Version: 1.0.8
  13742.  
  13743.  
  13744.  >>>>>>>>> 1993
  13745.  
  13746. [BROD93a]*   Brodie, M.L., "The Promise of Distributed Computing and the
  13747. Challenge of Legacy Information Systems," in Hsiao, D., E.J. Neuhold, and
  13748. R. Sacks-Davis (eds), Proc. IFIP TC2/WG2.6 Conference on Semantics of
  13749. Interoperable Database Systems, Lorne, Australia, November 1992, Elsevier
  13750. North Holland, Amsterdam 1993.
  13751.  
  13752. [BROD93b]*   Brodie, M.L. and M. Stonebraker, "DARWIN: On the Incremental
  13753. Migration of Legacy Information Systems," DOM Technical Report,
  13754. TR-0222-10-92-165, GTE Laboratories Inc., March 1993.
  13755.  
  13756. [GEOR93a]*   Georgakopoulos, D., M. Hornick, and P. Krychniak, "An
  13757. Environment for Specification and Management of Extended Transactions in
  13758. DOMS," to appear in Proceedings of the 3rd International Workshop on
  13759. Interoperability in Multidatabase Systems, Vienna, Austria, April 1993.
  13760.  
  13761. [GEOR93c]*   Georgakopoulos, D., M. Rusinkiewicz and A. Sheth, "Using
  13762. Ticket-based Methods to Enforce the Serializability of Multidatabase
  13763. Transactions," to appear in the IEEE Transactions on Data and Knowledge
  13764. Engineering December 1993 (submitted in February 1992).
  13765.  
  13766. [GEOR93e]*   Georgakopoulos, D., M. Hornick, F. Manola, M. Brodie, S.
  13767. Heiler, F. Nayeri, and B. Hurwitz, "An Extended Transaction Environment for
  13768. Workflows in Distributed Object Computing," in IEEE Data Engineering, pp.
  13769. 24-27, vol. 16, no. 2, June 1993.
  13770.  
  13771. [MANO93a]   Manola, F., "The Need for Object Model Interoperability,"
  13772. Workshop Report, Workshop on Application Integration Architectures, Dallas,
  13773. Texas, February 1993
  13774.  
  13775. [MANO93c]*   Manola, F. and S. Heiler, "A 'RISC' Object Model for Object
  13776. System Interoperation: Concepts and Applications," TR-0231-08-93-165, GTE
  13777. Laboratories, Inc., August 1993.
  13778.  
  13779. [MITC93a]   Mitchell, G., "Extensible Query Processing in an
  13780. Object-Oriented Database," PhD Thesis, Brown University Technical Report
  13781. No. CS-93-16, May 1993. Available in hard copy from Brown University,
  13782. Computer Science Department, and postscript format via anonymous ftp from
  13783. wilma.cs.brown.edu as file techreports/93/cs93-16.ps.Z
  13784.  
  13785. [NAYE93c]*   Nayeri, F., and B. Hurwitz, "Experiments with Dispatching in a
  13786. Distributed Object System," GTE Laboratories, Inc., TR-0236-09-93-165, July
  13787. 1993.
  13788.  
  13789. [NAYE93d]*   Nayeri, F., "Addressing Component Interoperability in the OMG
  13790. Object Model," position paper submitted to ORB Implementors' Workshop, San
  13791. Francisco, June 1993.
  13792.  
  13793. [NICO93a]   Nicol, J., T. Wilkes, and F. Manola, "Object Orientation in
  13794. Heterogeneous Distributed Computing Systems," IEEE Computer, pp. 57-67,
  13795. Vol. 26, No.6, June 1993.
  13796.  
  13797. [VENT93]*   Ventrone, V. and S. Heiler, "Some Practical Advice for Dealing
  13798. with Semantic Heterogeneity in Federated Database Systems," Submitted to
  13799. USENIX.
  13800.  
  13801.  
  13802.  >>>>>>>>> 1992
  13803.  
  13804. [BGR92]*   Batra, R., D. Georgakopoulos, and M. Rusinkiewicz, "A
  13805. Decentralized Deadlock-free Concurrency Control Method for Multidatabase
  13806. Transactions," in Proceedings of 12th International Conference on
  13807. Distributed Computing Systems, Yokohama, Japan, June, 1992.
  13808.  
  13809. [BRO92b]*   Brodie, M.L. and J. Mylopoulos , "Artificial Intelligence and
  13810. Databases: Dawn, Midday, or Sunset?," Canadian Information Processing
  13811. /Informatique Canadienne, July/August 1992.
  13812.  
  13813. [BROD92c]*   Brodie, M.L. and S. Ceri, "On Intelligent and Cooperative
  13814. Information Systems," in International Journal of Intelligent and
  13815. Cooperative Information Systems 1, 2 September 1992. 
  13816.  
  13817. [BUCH92]   Buchmann, A.P., M.T. Ozsu, M. Hornick, D. Georgakopoulos, F.A.
  13818. Manola, "A Transaction Model for Active Distributed Object Systems," in
  13819. Database Transaction Models for Advanced Applications, A.K. Elmagarmid,
  13820. (ed.), Morgan Kaufmann, San Mateo, CA, Spring 1992.
  13821.  
  13822. [GEOR92]*   Georgakopoulos, D., "A Framework for Dynamic Specification of
  13823. Extended Multidatabase Transactions and Interdatabase Dependencies,"
  13824. Proceedings of Third Workshop on Heterogeneous Databases and Semantic
  13825. Interoperability, Boulder, February, 1992.
  13826.  
  13827. [HEIL92]   Heiler, S., S. Haradhvala, B. Blaustein, A. Rosenthal, and S.
  13828. Zdonik, "A Flexible Framework for Transaction Management in Engineering
  13829. Environments," in Database Transaction Models for Advanced Applications,
  13830. A.K. Elmagarmid (ed.), Morgan Kaufmann, San Mateo, CA, Spring 1992.
  13831.  
  13832. [MANO92]*   Manola, F., S. Heiler, D. Georgakopoulos, M. Hornick, M.
  13833. Brodie, "Distributed Object Management," International Journal of
  13834. Intelligent and Cooperative Information Systems 1, 1 March 1992.
  13835.  
  13836. [MANO92a]*   Manola, F. and S. Heiler, "An Approach To Interoperable Object
  13837. Models," Proceedings of the International Workshop on Distributed Object
  13838. Management, Edmonton, Canada, August 1992 (also in Distributed Object
  13839. Management, M.T. Ozsu, U. Dayal, and P. Valduriez (eds.), Morgan Kaufmann,
  13840. San Mateo, CA, 1993).
  13841.  
  13842.  
  13843.  >>>>>>>>> 1991
  13844.  
  13845. [BROD91]   Brodie, M., "Distributed Object Management Research,"
  13846. Proceedings of the Second Telecommunications Information Networking
  13847. Architecture (TINA) Workshop, pp. 297-303, Chantilly, France, March 1991.
  13848.  
  13849. [BROD91a]*   Brodie, M. and M. Hornick, "An Interoperability Development
  13850. Environment For Intelligent Information Systems," Proceedings of the
  13851. International Workshop on the Development of Intelligent Information
  13852. Systems, Niagara-on-the-Lake, April 1991.
  13853.  
  13854. [BUCH91]*   Buchmann, A.P., M. Tamer Ozsu, and D. Georgakopoulos, "Towards
  13855. a Transaction Management System for DOM," TR-0146-06-91-165, GTE
  13856. Laboratories Incorporated, June 1991.
  13857.  
  13858. [GEOR91a]*   Georgakopoulos, D., M. Rusinkiewicz, and A. Sheth, "On
  13859. Serializability of Multidatabase Transactions Through Forced Local
  13860. Conflicts," Proceedings of the 7th International Conference on Data
  13861. Engineering, Kobe, Japan, April 1991.
  13862.  
  13863. [GEOR91b]*   Georgakopoulos, D., "Multidatabase Recoverability and
  13864. Recovery," Proceedings of the First International Workshop on
  13865. Interoperability in Multidatabase Systems, Kyoto, Japan, April 1991.
  13866.  
  13867. [GRL91]   Georgakopoulos, D., M. Rusinkiewicz, and W. Litwin,
  13868. "Chronological Scheduling of Transactions with Temporal Dependencies," in
  13869. the VLDB journal, available draft also as a Technical Report from the
  13870. Department of Computer Science at the University of Houston, UH-CS-91-03,
  13871. February, 1991.
  13872.  
  13873. [HEIL91]*   Heiler, S., "Extended Data Type Support in Distributed DBMS
  13874. Products: A Technology Assessment and Forecast," TR-170-12-91-165. GTE
  13875. Laboratories Incorporated, December 1991.
  13876.  
  13877. [HORN91]*   Hornick, M.F., J.D. Morrison, and F. Nayeri, "Integrating
  13878. Heterogeneous, Autonomous, Distributed Applications Using the DOM
  13879. Prototype," TR-0174-12-91-165. GTE Laboratories Incorporated, December
  13880. 1991.
  13881.  
  13882. [MANO91]   Manola, F. and U. Dayal, "An Overview of PDM: An Object-Oriented
  13883. Data Model," in K.R. Dittrich, U. Dayal, and A.P. Buchmann (eds.), On
  13884. Object-Oriented Database Systems, Springer-Verlag, 1991.
  13885.  
  13886. [MANO91a]*   Manola, F., "Object Data Language Facilities for Multimedia
  13887. Data Types," TR-0169-12-91-165. GTE Laboratories Incorporated, December
  13888. 1991.
  13889.  
  13890. [MANO91b]   Manola, F., "The Third-Generation/OODBMS Manifesto, Commercial
  13891. Version," SIGMOD Record, Vol. 20, No. 4, December 1991.
  13892.  
  13893. [RUSI91]   Rusinkiewicz, M. and D. Georgakopoulos, "Multidatabase
  13894. Transactions: Impediments and Opportunities," Compcon Spring '91 Digest of
  13895. Papers, San Francisco, February 1991.
  13896.  
  13897. [VENT91]   Ventrone, V. and S. Heiler, "Semantic Heterogeneity as a Result
  13898. of Domain Evaluation," SIGMOD Record Special Issue: Semantic Issues in
  13899. Multidatabase Systems, Vol. 20, No. 4, December 1991.
  13900.  
  13901.  
  13902.  >>>>>>>>> 1990
  13903.  
  13904. [BREI90]   Breitbart, Y., D. Georgakopoulos, and M. Rusinkiewicz, A.
  13905. Silberschatz, "Rigorous Scheduling in Multidatabase Systems," Proceedings
  13906. of Workshop in Multidatabases and Semantic Interoperability, Tulsa, pp.
  13907. 658-667, November 1990.
  13908.  
  13909. [BROD90]*   Brodie, M.L., F. Bancilhon, C. Harris, M. Kifer, Y. Masunaga,
  13910. E.D. Sacerdoti, K. Tanaka, "Next Generation Database Management Systems
  13911. Technology," in Deductive and Object-Oriented Databases, W. Kim, J-M
  13912. Nicolas, S. Nishio, (eds.), Elsevier Science Publishers, 1990.
  13913.  
  13914. [HEIL90]   Heiler, S., F. Manola and S. Zdonik, "An Object-Oriented
  13915. Database Approach to Federated Systems," (unpublished paper), 1990.
  13916.  
  13917. [MANO90]   Manola, F., "Object-Oriented Knowledge Bases," AI Expert, 5(3),
  13918. 5(4), March and April 1990.
  13919.  
  13920. [MANO90a]*   Manola, F. and A. Buchmann "A Functional/Relational
  13921. Object-Oriented Model for Distributed Object Management: Preliminary
  13922. Description" TM-0331-11-90-165. GTE Laboratories Incorporated, December
  13923. 1990.
  13924.  
  13925. [MANO90b]*   Manola, F., M. Hornick, and A. Buchmann "Object Data Model
  13926. Facilities for Multimedia Data Types" TM-0332-11-90-165, GTE Laboratories
  13927. Incorporated, December 1990.
  13928.  
  13929. [MYLO90]*   Mylopoulos, J. and M. Brodie, "Knowledge Bases and Databases:
  13930. Current Trends and Future Directions," Lecture Notes in Computer Science,
  13931. Vol. 474: Information Systems and Artificial Intelligence: Integration
  13932. Aspects, D. Karagiannia, (ed.), Springer-Verlag, New York, 1990.
  13933.  
  13934. [RUSI90]   Rusinkiewicz, M., D. Georgakopoulos, and R. Thomas, "RDS: A
  13935. Primitive for the Maintenance of Replicated Data Objects," Proceedings of
  13936. Second IEEE Symposium on Parallel and Distributed Processing, Dallas, pp.
  13937. 658-667, December 1990.
  13938.  
  13939. [SILB90]   Silberschatz, A., M. Stonebraker, and J.D. Ullman (eds.), M.L.
  13940. Brodie, P. Buneman, M. Carey, A. Chandra, H. Garcia-Molina, J. Gray, R.
  13941. Fagin, D. Lomet, D. Maier, M.A. Niemat, A. Silberschatz, M. Stonebraker, I.
  13942. Traiger, J. Ullman, G. Wiederhold, C. Zaniolo, and M. Zemankova, P.A.
  13943. Bernstein, W. Kim, H.F. Korth, and A. van Tilborg, (co-authors), "Database
  13944. Systems: Achievements and Opportunities," ACM SIGMOD Record, 19, 4,
  13945. December 1990; also appeared in Communications of the ACM, Vol. 34, No.10,
  13946. pp. 110-120, October 1991.
  13947.  
  13948. [STON90]   Stonebraker, M. , L.A. Rowe, B. Lindsay, J. Gray, M. Carey, M.L.
  13949. Brodie, P. Bernstein, and D. Beech, "Third-Generation Data Base System
  13950. Manifesto," ACM SIGMOD Recored 19, 3, September 1990.
  13951.  
  13952. [ZERT90]   Zertuche, D.R. and A.P. Buchmann, "Execution Models for Active
  13953. Database Systems: A Comparison," TM-0238-01-90-165, GTE Laboratories
  13954. Incorporated, January 1990.
  13955.  
  13956.  
  13957.  >>>>>>>>> 1989
  13958.  
  13959. [BROD89]   Brodie, M., D. Bobrow, V. Lesser, S. Madnick, D. Tsichritzis,
  13960. and C. Hewitt, "Future Artificial Intelligence Requirements for Intelligent
  13961. Database Systems" Expert Database Systems: Proceedings From the Second
  13962. International Conference, L. Kerschberg (ed.), Benjamin/Cummings, Menlo
  13963. Park, CA, 1989.
  13964.  
  13965. [BROD89a]   Brodie, M. , J. Mylopoulos, "Future Intelligent Information
  13966. Systems: AI and Database Technologies Working Together," in M. Brodie, J.
  13967. Mylopoulos, (eds. and contributors), Readings in Artificial Intelligence
  13968. and Databases, Morgan Kaufmann, San Mateo, CA, 1989.
  13969.  
  13970. [MANO89]*   Manola, F., "Applications of Object-Oriented Database
  13971. Technology in Knowledge-Based Integrated Information Systems," GTE
  13972. Laboratories Incorporated, April 1989.
  13973.  
  13974. [MANO89a]*   Manola, F., "Object Model Capabilities For Distributed Object
  13975. Management," TM-0149-06-89-165, GTE Laboratories Incorporated, June 1989.
  13976.  
  13977. [MANO89b]*   Manola, F., "An Evaluation of Object-Oriented DBMS
  13978. Developments," TR-0066-10-89-165, GTE Laboratories Incorporated, October
  13979. 1989.
  13980.  
  13981. [WELC89]   Welch, J.L. and A.P. Sistla, "Object-Based Concurrency Control
  13982. and Recovery Mechanisms," TM-0150-06-89-165, GTE Laboratories Incorporated,
  13983. June 1989.
  13984.  
  13985.  
  13986.  >>>>>>>>> 1988
  13987.  
  13988. [MANO88]*   Manola, F., "Distributed Object Management Technology,"
  13989. TM-0014-06-88-165, GTE Laboratories Incorporated, June 1988.
  13990.  
  13991.  
  13992.  >>>>>>>>> 1987
  13993.  
  13994. [MANO87]   Manola, F., "A Personal View of DBMS Security," Database
  13995. Security: Status and Prospects, C.E. Landwehr (ed.), Elsevier Science
  13996. Publishers B.V., North Holland, 1988, 23-34; TN CS1.1, GTE Laboratories
  13997. Incorporated, December 1987.
  13998.  
  13999.  
  14000.  
  14001. _[GEOR94a]* _[GEOR94b]*
  14002. _[BROD93a]* _[BROD93b]* _[GEOR93a]* _[GEOR93c]* _[GEOR93e]*
  14003. _[MANO93a]  _[MANO93c]* _[NAYE93c]* _[NAYE93d]* _[NICO93a] 
  14004. _[VENT93]*
  14005. _[BGR92]    _[BRO92b]*  _[BROD92c]* _[BUCH92]   _[GEOR92]*
  14006. _[HEIL92]   _[MANO92]*  _[MANO92a]* 
  14007. _[BROD91]   _[BROD91a]* _[BUCH91]*  _[GEOR91a]* _[GEOR91b]*
  14008. _[GRL91]    _[HEIL91]*  _[HORN91]*  _[MANO91]   _[MANO91a]* 
  14009. _[MANO91b]  _[RUSI91]   _[VENT91] 
  14010. _[BREI90]   _[BROD90]*  _[HEIL90]   _[MANO90]   _[MANO90a]* 
  14011. _[MANO90b]* _[MYLO90]*  _[RUSI90]   _[SILB90]   _[STON90] 
  14012. _[ZERT90] 
  14013. _[BROD89]   _[BROD89a]  _[MANO89]*  _[MANO89a]* _[MANO89b]*
  14014. _[WELC89] 
  14015. _[MANO88]* 
  14016. _[MANO87]
  14017.  
  14018.  
  14019. >53  KEOBJ, OO DSP micro-kernel
  14020.  
  14021. From: clb@softia.com (Chris Bidaut)
  14022. Subject: Object kernel for DSP & RISC processors
  14023. Date: Mon, 15 Nov 1993 22:48:46
  14024. Organization: Softia, Inc.
  14025.  
  14026. This is an announcement for KEOBJ, an object-oriented micro-kernel for Digital
  14027. Signal Processors (DSP) and RISC processors.  This is also a request for 
  14028. comments from the Internet community. Feedback on the architecture and 
  14029. programming interface will be appreciated and incorporated into the next
  14030. release.
  14031.  
  14032.  
  14033. 1 DESCRIPTION
  14034. -------------
  14035.  
  14036. KEOBJ is an object-oriented micro-kernel optimized for advanced embedded 
  14037. applications, and it particularly targets Digital Signal Processors (DSP) 
  14038. and RISC processors in multimedia environments.
  14039.  
  14040. Its main features are object-orientation, real-time behavior, signal processing
  14041. support, micro-kernel architecture and scalability.
  14042.  
  14043. 1.1 Object-orientation
  14044.  
  14045. The kernel is a collection of system classes exported to the applications
  14046. (e.g Process, Thread, Memory, ...).
  14047. An object name space provides a way to locate any public object (e.g. IPC, 
  14048. memory) using a symbolic path.
  14049. The kernel is written in C++ and is easily portable.
  14050.  
  14051. 1.2 Real-time behavior
  14052.  
  14053. The design stresses fast response time and predictability to qualify for the 
  14054. real-time label. The kernel is reentrant and preeemptable.
  14055.  
  14056. 1.3 Signal processing support
  14057.  
  14058. Besides providing an architecture appropriate for most general purpose 
  14059. applications, the kernel incorporates dedicated features for signal processing
  14060. applications. This includes two phases interrupt processing, time-deadline
  14061. scheduling, Inter Process Communications, multiple memory pools, awareness of
  14062. the constraints due to a single data type (word).
  14063.  
  14064. 1.4 Micro-kernel architecture
  14065.  
  14066. Probably the most important feature of the kernel is the ability to be
  14067. extended at run-time with new services such as devices drivers, public
  14068. classes (IPC, file systems, windowing systems). Applications and system
  14069. services are dynamically loaded by a COFF compatible loader.
  14070.  
  14071. The core kernel is customizable at run-time through a personality mechanism 
  14072. to emulate other environments (Operating systems) or to tailor the processes
  14073. environments. 
  14074.  
  14075. 1.5 Scalability
  14076.  
  14077. The API supports physical and virtual memory organizations with the same 
  14078. semantics.
  14079.  
  14080. Applications source code will be portable across DSP and RISC processors.
  14081.  
  14082. The architecture supports symmetric multiprocessing and distribution (Available
  14083. by mid-1994).
  14084.  
  14085.  
  14086. 2 WHERE TO FIND THE PACKAGE
  14087. ---------------------------
  14088.  
  14089. A set of documentation about KEOBJ is available via anonymous ftp on the 
  14090. following Internet server:
  14091.         netcom.com (192.100.81.100) in file /pub/softia/keobj.zip
  14092.  
  14093.  
  14094. If you do not have access to Internet, contact me for other delivery media at:
  14095. Chris Bidaut            clb@softia.com
  14096. Telephone (408) 262-6520    Fax (408) 262-7210
  14097.  
  14098.  
  14099. >54  MindFrame for Windows
  14100.  
  14101. From: gcl@netcom.com (Geoff Lee)
  14102. Subject: "MindFrame for Windows" (freeware) application is available for ftp
  14103. Date: Tue, 16 Nov 1993 21:07:28 GMT
  14104.  
  14105.     MindFrame for Windows 1.0 Release Note
  14106.     ======================================
  14107.  
  14108. mndframe.zip (MindFrame for Windows) is available for anonymous ftp
  14109. on ftp.cica.indiana.edu. It is currently in /pub/pc/win3/uploads.
  14110.  
  14111. "MindFrame for Windows" is a freeware application developed to
  14112. teach an object modeling approach presented in the
  14113. book: "Object-Oriented GUI Application Development" Geoff Lee,
  14114. Prentice-Hall, 1993, ISBN 0-13-363086-2.
  14115.  
  14116. This application is useful in many other areas as well, for
  14117. example, in Bible studying (metaphors, parables, prophecies,
  14118. types), neural modeling, ecological modeling, and task modeling.
  14119. There are 20 sample applications covering these areas. There
  14120. are also description of each of the sample application in the
  14121. on-line Help. Read "About MindFrame..." help topic for more
  14122. information.
  14123.  
  14124. This is a copyrighted software, but you can freely redistribute if
  14125. you keep the release intact.
  14126.  
  14127. The following is the content of mdnframe.txt file in the .zip file:
  14128.  
  14129. 1. Installation Procedure:
  14130.    DOS> mkdir MndFrame
  14131.    DOS> cd MndFrame
  14132.    DOS> copy b:MndFrame.zip   (or where you kept the mndframe.zip file)
  14133.    DOS> unzip -d mndframe.zip  (extract files into subdirectories)
  14134.    DOS> copy grid.vbx \windows\systems (your local Windows system directory)
  14135.  
  14136. 2. Running the application:
  14137.    . In Windows, open your "File Manager"
  14138.    . Go to \MndFrame directory
  14139.    . Find the MndFrame.exe file
  14140.    . Drag the MndFrame.exe file icon into a "Program Manager" window
  14141.    . Open the MndFrame.exe program
  14142.  
  14143. 3. Sample applications:
  14144.    Once you are in the MindFrame application, open files in the 
  14145.    \MndFrame\Samples subdirectories. There are 20 sample files organized
  14146.    according to areas of application (e.g., object modeling, neural
  14147.    modeling, bible studying). You can also find description of each of
  14148.    these samples in the On-Line Help file.
  14149.  
  14150. 4. On-line help:
  14151.    Use the "About MindFrame..." menu item in the "Help" menu to learn more
  14152.    about this application. There is an on-line help provided for this
  14153.    application. Read through the help topics to learn about using this
  14154.    application.
  14155.  
  14156. 5. Files in this release:
  14157.    mndframe.txt: this file.
  14158.    mdnframe.exe: the executable file of "MindFrame for Windows" freeware.
  14159.    mndframe.hlp: the on-line help file for "MindFrame for Windows".
  14160.    biblnote.ps:  the PostScript file of help text on using this application
  14161.                 to study metaphors, parables, types, and prophecies in the
  14162.                 Holy Bible.
  14163.    grid.vbx:     the visual basic grid control that is necessary to run this
  14164.                 application. It must be copied into your local "system"
  14165.                 directory for Windows (\windows\system in most cases).
  14166.    samples\*:    in this directory, there are 20 samples (*.frm files) in 
  14167.                 the subdirectories for each application area 
  14168.                 (e.g., objmodel, ecology, neural, parable).
  14169.  
  14170. New MindFrame anonymous FTP Directory:
  14171.  
  14172. It has been moved to a more permanent directory: /pub/pc/win3/programr.
  14173.  
  14174. >55  ACE Lib, C++ Networking
  14175.  
  14176. From: schmidt@liege.ics.uci.edu (Douglas C. Schmidt)
  14177. Subject: Re: C++ and Semaphores
  14178. Date: 22 Nov 1993 19:27:00 -0800
  14179. Organization: University of California at Irvine: ICS Dept.
  14180.  
  14181.        THE "ADAPTIVE COMMUNICATION ENVIRONMENT" (ACE) LIBRARY:
  14182.  
  14183.       A Collection of C++ Network Programming Components
  14184.       --------------------------------------------------
  14185.  
  14186.     The ACE library is available for anonymous ftp from the
  14187. ics.uci.edu (128.195.1.1) host in the gnu/C++_wrappers.tar.Z file
  14188. (approximately .4 meg compressed).  This release contains contains the
  14189. source code, documentation, and example test drivers for a number of
  14190. C++ wrapper libraries and higher-level network programming foundation
  14191. classes developed as part of the ADAPTIVE transport system project at
  14192. the University of California, Irvine.
  14193.  
  14194.     . The C++ wrappers encapsulate many of the user-level BSD and
  14195.       System V Release 4 IPC facilities such as sockets, TLI,
  14196.       select and poll, named pipes and STREAM pipes, the mmap
  14197.       family of memory-mapped file commands, System V IPC (i.e.,
  14198.       shared memory, semaphores, message queues), and explicit
  14199.       dynamic linking (e.g., dlopen/dlsym/dlclose) using
  14200.       type-secure, object-oriented interfaces. 
  14201.  
  14202.     . The higher-level network programming foundation classes
  14203.       integrate and enhance the lower-level C++ wrappers to
  14204.       support the configuration of concurrent network daemons
  14205.       composed of monolithic and/or stackable services
  14206.  
  14207.     Many of the C++ wrappers and higher-level components have been
  14208. described in issues of the C++ Report, as well as in the proceedings
  14209. of (1) the 2nd Annual C++ World conference held in Dallas, Texas in
  14210. October, 1993, (2) the 11th Annual Sun Users Group Conference held in
  14211. San Jose, CA in December, 1993, and (3) the 2nd International Workshop
  14212. on Configurable Distributed Systems held at CMU in Pittsburgh, PA in
  14213. March, 1994.  A relatively complete set of documentation and extensive
  14214. examples are included in the release.  A mailing list is available for
  14215. discussing bug fixes, enhancements, and porting issues regarding ACE.
  14216. Please send mail to ace-users-request@ics.uci.edu if you'd like to
  14217. become part of the mailing list.
  14218.  
  14219. CONTENTS OF THE RELEASE
  14220.  
  14221.     The following subdirectories are included in this release:
  14222.  
  14223.     . apps    -- complete applications written using the ACE wrappers
  14224.     . bin      -- utility programs for building this release such as g++dep
  14225.     . build      -- a separate subdirectory that keeps links into the main
  14226.              source tree in order to facilitate multi-platform
  14227.              build-schemes
  14228.     . include -- symbolic links to the include files for the release
  14229.     . lib      -- object archive libraries for each C++ wrapper library
  14230.     . libsrc  -- the source code for the following C++ wrappers:
  14231.             ASX -- higher-level C++ network programming foundation classes
  14232.             Get_Opt -- a C++ version of the UNIX getopt utility
  14233.             IPC_SAP -- wrapper for BSD sockets
  14234.             IPC_SAP_FIFO -- wrapper for FIFOS (named pipes)
  14235.             IPC_SAP_SPIPE -- wrapper for SVR4 STREAM pipes and connld 
  14236.             Log_Msg -- library API for a local/remote logging facility
  14237.             Mem_Map -- wrapper for BSD mmap() memory mapped files 
  14238.             Message_Queues -- wrapper for SysV message queues
  14239.             Reactor -- wrapper for select() and poll()
  14240.             Semaphores -- wrapper for SysV semaphores
  14241.             Server_Daemon -- a wrapper for dynamically linking
  14242.             Shared_Memory -- wrapper for SysV shared memory
  14243.             Shared_Malloc -- wrapper for SysV/BSD shared mallocs
  14244.             TLI_SAP -- wrapper for SVR4 TLI 
  14245.     . tests -- programs that illustrate how to use the various wrappers
  14246.  
  14247.     Please refer to the INSTALL file for information on how to
  14248. build and test the ACE wrappers.  The BIBLIOGRAPHY file contains
  14249. information on where to obtain articles that describe the ACE wrappers
  14250. and the ADAPTIVE system in more detail.
  14251.  
  14252.     Also, please note that there is a companion tar file called
  14253. C++_wrappers_doc.tar.Z, which is approximately 1.5 Meg compressed.
  14254. This file is in the same ftp/gnu directory as the source code
  14255. distribution.  In this file is the following:
  14256.  
  14257.     . doc      -- LaTeX documentation (in both latex and .ps format)
  14258.     . papers  -- postscript versions of various papers describing ACE
  14259.  
  14260. COPYRIGHT INFORMATION
  14261.  
  14262.     You are free to do anything you like with this code.  However,
  14263. you may not do anything to this code that will prevent it from being
  14264. distributed freely in its original form (such as copyrighting it,
  14265. etc.).  Moreover, if you have any improvements, suggestions, and or
  14266. comments, I'd like to hear about it!  It would be great to see this
  14267. distributed evolve into a comprehensive, robust, and well-documented
  14268. C++ class library that would be freely available to everyone.
  14269. Natually, I am not responsible for any problems caused by using these
  14270. C++ wrappers.
  14271.  
  14272.     Thanks,
  14273.     
  14274.         Douglas C. Schmidt
  14275.         (schmidt@ics.uci.edu)
  14276.         Department of Information and Computer Science
  14277.         University of California, Irvine
  14278.         Irvine, CA 92717
  14279.         Work #: (714) 856-4105
  14280.         FAX #: (714) 856-4056
  14281.  
  14282. ACKNOWLEDGEMENTS
  14283.     
  14284.     Special thanks to Paul Stephenson for devising the recursive 
  14285. Makefile scheme that underlies this distribution.  Also thanks to Olaf
  14286. Kruger for explaining how to instantiate templates for shared
  14287. libraries on SunOS 4.
  14288. -- 
  14289. Douglas C. Schmidt
  14290. Department of Information and Computer Science
  14291. University of California, Irvine
  14292. Irvine, CA 92717. Work #: (714) 856-4105; FAX #: (714) 856-4056
  14293.  
  14294.  
  14295. >56  Teaching Intro to OO Slides, T. Budd
  14296.  
  14297. From: budd@daimi.aau.dk (Tim Budd)
  14298. Subject: Re: Slides on OOP or OMT wanted
  14299. Date: 8 Nov 1993 07:46:08 GMT
  14300. Organization: DAIMI, Computer Science Dept. at Aarhus University
  14301.  
  14302. >...
  14303.  
  14304. I also have a series of slides that I have developed for use with my
  14305. text ``an introduction to object-oriented programming'' (timothy budd,
  14306. addison-wesley publishers).  These can be found at cs.orst.edu
  14307. directory pub/budd/oopintro/slides/*, or there is a mail server
  14308. called almanac@cs.orst.edu and if you say
  14309.     send oopintro slides chapter1
  14310. and so on you can get them via e-mail.  Warning, it yields a lot of
  14311. e-mail, so do it one at a time.
  14312. --tim
  14313.  
  14314.  
  14315. >57  Value Dependence Graphs
  14316.  
  14317. From: Michael D. Ernst <mernst@research.microsoft.com>
  14318. Subject:  Value dependence graphs paper available
  14319. Date: Tue, 9 Nov 1993 00:59:36 GMT
  14320.  
  14321. The paper "Value Dependence Graphs: Representation Without Taxation",
  14322. which describes a new intermediate representation which is particularly
  14323. amenable to optimization, is available.  (This version corrects typos and
  14324. clarifies a few minor points that may not have been completely clear in
  14325. the version which will appear in the POPL 94 proceedings.)  You can get a
  14326. copy in three ways:
  14327.  
  14328. 1.  Via anonymous ftp, obtain file research.microsoft.com:/pub/papers/vdg.ps
  14329.     (or file vdg.ps635 if you have a HP LaserJet 4 printer).
  14330. 2.  Reply to mernst@research.microsoft.com requesting PostScript by email,
  14331.     and I will send you the PostScript file of your choice.  (The files are
  14332.     483K and 1018K bytes, respectively.)
  14333. 3.  Reply to mernst@research.microsoft.com sending me your physical mail
  14334.     address, and I will mail you a hardcopy.
  14335.  
  14336. The abstract is:
  14337.  
  14338. The value dependence graph (VDG) is a sparse dataflow-like representation
  14339. that simplifies program analysis and transformation.  It is a functional
  14340. representation that represents control flow as data flow and makes
  14341. explicit all machine quantities, such as stores and I/O channels.  We are
  14342. developing a compiler that builds a VDG representing a program, analyzes
  14343. and transforms the VDG, then produces a control flow graph (CFG) [ASU86]
  14344. from the optimized VDG.  This framework simplifies transformations and
  14345. improves upon several published results.  For example, it enables more
  14346. powerful code motion than [CLZ86, FOW87], eliminates as many redundancies
  14347. as [AWZ88, RWZ88] (except for redundant loops), and provides important
  14348. information to the code scheduler [BR91].  We exhibit a fast, one-pass
  14349. method for elimination of partial redundancies that never performs
  14350. redundant code motion [KRS92, DS93] and is simpler than the classical
  14351. [MR79, Dha91] or SSA [RWZ88] methods.  These results accrue from
  14352. eliminating the CFG from the analysis/transformation phases and using
  14353. demand dependences in preference to control dependences.
  14354.  
  14355. The paper's full citation is:
  14356.  
  14357. @InProceedings{WeiseCES94,
  14358.   author =      "Daniel Weise and Roger F. Crew and Michael Ernst and
  14359.             Bjarne Steensgaard",
  14360.     title =      "Value Dependence Graphs:  Representation Without Taxation",
  14361.     booktitle =     POPL94,
  14362.     pages =      "297-310",
  14363.     year =     1994,
  14364.     month =     jan,
  14365.     address =     "Portland, OR"
  14366. }
  14367.  
  14368. >58  Various on OO
  14369.  
  14370. I think our ftp-site should be mentioned under the PAPERS section of
  14371. appendix E of the comp.object FAQ. There are a number of interesting
  14372. papers about Object-Orientation, in particular about a new object-oriented
  14373. model, called 'Composition Filters'. Here is the uuencoded compressed
  14374. version of a postscript document that contains abstracts of the papers
  14375. which are available via ftp (ftp.cs.utwente.nl - /pub/doc/TRESE) or
  14376. WWW (http://wwwtrese.cs.utwente.nl - Recent Publications of the TRESE
  14377. project). You may also view this document from our WWW-site.
  14378.  
  14379. Greetings,
  14380.  
  14381. Richard.
  14382. ---
  14383. TRESE project
  14384. Email: stadt@cs.utwente.nl
  14385. TRESE WWW Server: http://www_trese.cs.utwente.nl
  14386.  
  14387. >59  ILU OMG CORBA
  14388.  
  14389. Date: Fri, 19 May 1995 20:51:05 PDT
  14390. From: Bill Janssen <janssen@parc.xerox.com>
  14391. Subject: New ILU 1.8 Common Lisp support available
  14392. To: ilu-interest.PARC@xerox.com
  14393.  
  14394. Revised support for using ILU with Common Lisp is now available as
  14395.  
  14396.   ftp://ftp.parc.xerox.com/pub/ilu/1.8/ilu-1.8-new-lisp.tar.gz
  14397.  
  14398. Changes include:
  14399.  
  14400. 1)  The Common Lisp support no longer has to load C code for each ILU
  14401. module loaded, so CL implementations without that capability may use
  14402. ILU.  This also speeds up loading of ILU modules considerably.
  14403.  
  14404. 2)  CORBA-style union support is now there.
  14405.  
  14406. 3)  ILU dynamic object creation is now fully supported.  That is, an
  14407. ILU kernel server may now be created which calls back to Lisp
  14408. functions to create objects on demand, rather than having to have them
  14409. available before clients make calls on them.
  14410.  
  14411. 4)  A non-threaded Franz ACL implementation of the ILU support is now
  14412. included, solely as an example of how to support ILU in Common Lisp
  14413. implementations without threads.  Of course, if your CL has threads, your
  14414. ILU support should use them.
  14415.  
  14416. 5)  A new version of the ILU manual is included, with the appropriate
  14417. changes to the CL chapter.
  14418.  
  14419. 6)  A modified version of examples/test1/ is provided, with Lisp
  14420. examples of the test1 program.
  14421.  
  14422. ``But what's ILU, anyway?''
  14423.  
  14424. The Inter-Language Unification system (ILU) is a multi-language object
  14425. interface system.  The object interfaces provided by ILU hide
  14426. implementation distinctions between different languages, between
  14427. different address spaces, and between operating system types.  ILU can
  14428. be used to build multi-lingual object-oriented libraries ("class
  14429. libraries") with well-specified language-independent interfaces.  It
  14430. can also be used to implement distributed systems.  It can also be used
  14431. to define and document interfaces between the modules of
  14432. non-distributed programs.  ILU interfaces are specified in ILU's
  14433. Interface Specification Language.
  14434.  
  14435. The 1.8 release of ILU contains support for the programming languages
  14436. Common Lisp, C++, ANSI C, Modula-3, and Python).  It has been installed
  14437. on many flavors of UNIX, including SPARC machines running SunOS 4.1.3
  14438. and Solaris 2, SGI MIPS machines running IRIX 5.2, Intel 486 machines
  14439. running Linux 1.1.78, DEC Alpha machines with OSF/1, IBM RS/6000
  14440. machines running AIX, and HP machines running HP/UX.  A port of ILU to
  14441. the Microsoft Windows 3.1 and Windows NT environments has been
  14442. finished, and will form part of the 1.9 release.  ILU supports both
  14443. threaded and non-threaded operation.
  14444.  
  14445. One of the implementation goals of ILU is to maximize compatibility
  14446. with existing open standards.  As a result, ILU provides support for
  14447. use of the OMG CORBA IDL interface description language, and can be
  14448. thought of as a CORBA ORB system (though with omissions from and
  14449. extensions to the CORBA spec).  As another result, ILU includes a
  14450. self-contained implementation of ONC RPC, and it is possible to
  14451. describe and use existing RPC services as ILU objects.  ILU is
  14452. available free from `ftp://ftp.parc.xerox.com/pub/ilu/ilu.html'.
  14453. --
  14454.  Bill Janssen  <janssen@parc.xerox.com> (415) 812-4763  FAX: (415) 812-4777
  14455.  Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA  94304
  14456.  URL:  ftp://ftp.parc.xerox.com/pub/ilu/misc/janssen.html
  14457.  
  14458. >60 Internet Info CDROM, including FAQs
  14459.  
  14460. Walnut Creek CDROM announces the release of the Internet Info CDROM.
  14461. This CDROM contains 12,000 documents about computers and networks:
  14462.  
  14463.         * Answers to Frequently Asked Questions (FAQs).
  14464.         * Internet RFCs and IENs.  
  14465.         * Computer security Documents.  
  14466.         * Internet Network maps.  
  14467.         * Usenet technical discussion Archives.
  14468.         * Ftp sites lists and descriptions of the archives they hold.
  14469.         * Extensive bibliographies and technical book reviews.
  14470.         * documents and standards from IEEE, ISO, NIST, ANSI and others.
  14471.  
  14472. The price is $39.95.  S&H is $5 for US/Canada/Mexico, and $10 for overseas.
  14473. If you live in California, please add sales tax.  You can pay by cash, check,
  14474. money order or Visa/MC/Dis/Amex.  This CDROM is fully guaranteed, if you are
  14475. dissatisfied with this disc for any reason whatsoever, you can return it for
  14476. an exchange or refund.
  14477.  
  14478.         Walnut Creek CDROM
  14479.         1547 Palos Verdes Mall, Suite 260
  14480.         Walnut Creek, CA  94596
  14481.  
  14482.         1 800 786-9907
  14483.         1 510 674-0783
  14484.         1 510 674-0821 FAX
  14485.  
  14486.         orders@cdrom.com
  14487.  
  14488. The disc is available for FREE to anyone that has contributed any of their
  14489. own work.  This includes FAQ maintainers, RFC authors, etc.  Just email me
  14490. your name, address, and the name of the files(s) that you wrote.  Overseas
  14491. addresses are ok.
  14492.  
  14493. If you would like a more detailed list of other CDROM titles published by
  14494. Walnut Creek CDROM, you can ftp the latest list from
  14495. ftp.cdrom.com:/pub/cdrom/catalog, or send email to info@cdrom.com.
  14496.  
  14497. >61  Metrics
  14498.  
  14499. From: dcp@icd.teradyne.com (Dan Proskauer)
  14500. Subject: Re: Wanted: Data on McCabe and Halstead Comple
  14501. Organization: Teradyne, Inc. Boston MA
  14502. Date: Sat, 18 Dec 1993 20:58:33 GMT
  14503.  
  14504.     There is some publically available McCabe and Halstead analysis
  14505. software for C in gatekeeper.dec.com /pub/usenet/com.sources.unix/volume20/metrics.
  14506. I believe there is some explanation of the metrics along with it.  Some other
  14507. references are:
  14508.  
  14509.     The Art of Software Testing, Myers
  14510.  
  14511.     "An Internal Approach to Testing Horizontally Reusable
  14512.      Software", Proceedings of the 5th Annual STC Conference, 93
  14513.         Goldfedder (Overall of where McCabe fits in to A testing
  14514.         process) 
  14515.  
  14516.  
  14517. >62  Amadeus, persistence
  14518.  
  14519. From: aoife@mordred.st.nepean.uws.edu.au (Aoife Cox)
  14520. Subject: Re: In Search of Persistence
  14521. Date: 14 Dec 1993 20:04:38 +1100
  14522. Organization: University of Western Sydney
  14523.  
  14524. >I have been searching the net trying to find any locations for papers about
  14525. >implementation of persistence object systems or about persistence and OOPL.  As
  14526. >yet, I have not found anything remotely related.
  14527.  
  14528. >Are there any ftp sites with such papers that someone can direct me to?
  14529. There should be some papers on the Amadeus system, developed by the
  14530. Distributed Systems Group at Trinity College, Dublin, ftp-able from
  14531. ftp.cs.tcd.ie. Look in the /pub/tcd/tech-reports directory....
  14532.  
  14533. Hope this helps.
  14534.  
  14535. Aoife
  14536.  
  14537.  
  14538. >63  Chorus,Dist,RT,MicroK
  14539.  
  14540. From Marc Maathuis (mm@chorus.fr):
  14541.  
  14542. You may want to take a look at CHORUS, a distributed real-time
  14543. microkernel that can be combined with the CHORUS/MiX subsystem, which
  14544. is a modular, fully compatible UNIX System V (R3.2 or R4.0)
  14545. implementation.  There is also an OO subsystem named COOL (CHORUS
  14546. Object Oriented Layer). CHORUS runs on i386/i486, 680x0, SPARC,
  14547. transputer and on several other processors.
  14548.  
  14549. CHORUS is available as a source technology. In Jan 94, SCO and Chorus
  14550. will release a *binary* product for the PC market: "CHORUS/Fusion for
  14551. SCO UNIX" is binary compatible with SCO UNIX and offers real-time
  14552. functionality (POSIX 1003.1b and .1c, i.e. the former .4 and .4a
  14553. interfaces) and clustering functionality.
  14554.  
  14555. COOL provides a distributed OO programming environment for
  14556. C++.  COOL supports a set of system calls that allow the creation of
  14557. dynamic objects. These objects can be sent messages in a location
  14558. transparent way, they can be migrated between address spaces and sites
  14559. and they can be stored in a persistent store; this is done in a
  14560. transparent way, as an extension of the C++ language.
  14561.  
  14562. There are several technical reports (in PostScript format) on CHORUS
  14563. and on COOL available via anonymous FTP from Chorus systemes, France:
  14564. ftp.chorus.fr [192.33.15.3], directory pub/chorus-reports. See the file
  14565. "index" for an overview.
  14566.  
  14567. There is also a set of ~90 slides on Chorus and CHORUS available in
  14568. the directory pub/chorus-slides/CS-TR-92-64 (PostScript, versions 1-up
  14569. and 2-up).
  14570.  
  14571. If VTT is a public research lab, then you might be interested by the fact
  14572. that Chorus systemes has special programs for universities. For more
  14573. information on offering, conditions, etc, ftp to ftp.chorus.fr and get
  14574. the following ASCII files
  14575.    - pub/README
  14576.    - pub/academic/README
  14577.    - pub/academic/offerings
  14578. If you have questions, you may contact Didier Irlande <di@chorus.fr>
  14579. for license issues or Xavier Galleri <xg@chorus.fr> for technical
  14580. issues.
  14581.  
  14582.  
  14583. >64  Self Opt.
  14584.  
  14585. From: urs@cs.stanford.edu (Urs Hoelzle)
  14586. To: self-interest@otis.Stanford.EDU
  14587. Subject: thesis available for ftp
  14588. Date: Fri, 2 Sep 94 11:15:29 PDT
  14589. Reply-To: urs@cs.stanford.edu
  14590.  
  14591. Dear self-interesters,
  14592.  
  14593. My thesis is now available via ftp and Mosaic (see below).  Yes, I
  14594. have graduated!  Though many things will change, I'm planning to keep
  14595. on working on Self at UCSB; my new e-mail address is urs@cs.ucsb.edu.
  14596. However, I am no longer maintaining the self-interest list, for
  14597. questions/requests please contact self-request@self rather than
  14598. writing directly to me.
  14599.  
  14600. -Urs
  14601.  
  14602. ---------------
  14603.  
  14604. Urs Hoelzle. "Adaptive Optimization for Self: Reconciling High
  14605. Performance with Exploratory Programming." Ph.D. thesis, Computer
  14606. Science Department, Stanford University, August 1994.
  14607.  
  14608. The report is available in PostScript form via ftp from
  14609. self.stanford.edu:/pub/papers/hoelzle-thesis.ps.Z or via Mosaic from
  14610. http://self.stanford.edu.  In a few weeks, it should be available in
  14611. printed form as a Stanford CSD technical report and as a Sun
  14612. Microsystems Laboratories technical report.
  14613.  
  14614. Abstract: Crossing abstraction boundaries often incurs a substantial
  14615. run-time overhead in the form of frequent procedure calls.  Thus,
  14616. pervasive use of abstraction, while desirable from a design
  14617. standpoint, may lead to very inefficient programs.  Aggressively
  14618. optimizing compilers can reduce this overhead but conflict with
  14619. interactive programming environments because they introduce long
  14620. compilation pauses and often preclude source-level debugging. Thus,
  14621. programmers are caught on the horns of two dilemmas: they have to
  14622. choose between abstraction and efficiency, and between responsive
  14623. programming environments and efficiency. This dissertation shows how
  14624. to reconcile these seemingly contradictory goals by performing
  14625. optimizations lazily.
  14626.  
  14627.  
  14628. >65 ORBELINE: CORBA
  14629.  
  14630. PostModern Computing is making its CORBA-compliant ORBeline product
  14631. available free of charge to the academic community for teaching and
  14632. research purposes.  ORBeline is available via anonymous ftp from
  14633. labrea.stanford.edu under pub/pomoco.
  14634.  
  14635. We are making the SunOS 4.x, Solaris 2.3, and OSF/1 versions of
  14636. ORBeline available.  We will consider making other platforms available
  14637. as well if there is enough interest.
  14638.  
  14639. Suresh Challa
  14640. PostModern Computing
  14641. suresh@pomoco.com
  14642.  
  14643. What follows is the README file of this release: 
  14644.  
  14645. -------------------------------------------------------------------------------
  14646.  
  14647.                                 ORBELINE
  14648.                                 --------
  14649.  
  14650.                     The SMART Object Request Broker
  14651.  
  14652.  
  14653. ORBeline is a complete implementation of OMG's Common Object Request
  14654. Broker Architecture (CORBA).  ORBeline goes beyond the standard 
  14655. specification to provide a SMART communication framework allowing
  14656. you to easily develop large distributed applications that are robust,
  14657. scalable, flexible and maintainable.  ORBeline incorporates PostModern's
  14658. proven communication framework that links thousands of nodes.
  14659.  
  14660. Highlights
  14661. ----------
  14662.  
  14663. ORBeline's SMART Agent dynamically tracks the communication taking place
  14664. between all objects and their clients:
  14665.  
  14666.    o Smart Binding and Protocol Selection
  14667.  
  14668.      ORBeline automatically picks the best communication mechanism as
  14669.      soon as you try to access an object.  If the object is in your process,
  14670.      it bypasses the ORB and the network altogether.  When the object is on
  14671.      a remote node, ORBeline's SMART and efficient on-the-wire protocol
  14672.      is selected.  When the object is implemented using another vendor's
  14673.      ORB, that vendor's on-the-wire protocol is used.
  14674.  
  14675.    o Built-in Fault Tolerance
  14676.  
  14677.      ORBeline's SMART Agent monitors communication between objects and their
  14678.      clients.  In case of a failure, the SMART agent and ORBeline cooperate
  14679.      to reestablish connections between processes or their replicas.
  14680.  
  14681.    o Dynamic Directory Service
  14682.  
  14683.      ORBeline's Dynamic Directory Service tracks all registered and active
  14684.      objects, providing a high degree of efficiency, total location
  14685.      transparency and easy administration.  There is no need for 
  14686.      cumbersome configuration files, and no need for heavyweight object
  14687.      migration and replication mechanisms.
  14688.  
  14689.    o Platforms
  14690.  
  14691.      ORBeline runs on all classes of computers ranging from Cray 
  14692.      supercomputers, to workstations, to personal computers and
  14693.      embedded systems.
  14694.  
  14695. Complete CORBA implementation
  14696. -----------------------------
  14697.  
  14698. ORBeline is the most complete ORB implementation currently on the
  14699. market.  It features the following:
  14700.  
  14701.    o IDL Compiler implementing the entire Interface Definition 
  14702.      Language.
  14703.  
  14704.    o Static and Dynamic Invocation Interfaces
  14705.  
  14706.    o Complete Interface and Implementation Repositories.
  14707.  
  14708.    o Support for Object Activation.
  14709.  
  14710.    o Complete set of object administration tools.
  14711.  
  14712.  
  14713. Features
  14714. --------
  14715.  
  14716.  
  14717.    o High Performance and Low Overhead
  14718.  
  14719.      ORBeline provides high performance while adding little overhead
  14720.      to your application.  ORBeline is the only ORB product available
  14721.      on the market today suitable for running on real-time, embedded
  14722.      systems.
  14723.  
  14724.    o Flexible and Easy to Use
  14725.  
  14726.      With ORBeline it is easy to develop, deploy and maintain large
  14727.      distributed applications.  ORBeline provides a high degree of 
  14728.      flexibility and takes care of cumbersome details allowing 
  14729.      developers to focus on their applications.
  14730.  
  14731.    o WAN Connectivity
  14732.  
  14733.      ORBeline uses PostModern's proven communication technology to 
  14734.      connect wide area networks.
  14735.  
  14736.    o Scalability
  14737.  
  14738.      ORBeline's smart use of network resources and communication protocols
  14739.      allows applications to scale to networks of thousands of nodes.
  14740.  
  14741.    o Object Migration and Replication
  14742.  
  14743.      ORBeline's SMART agent and Dynamic Directory Service allow easy object
  14744.      migration and replication.
  14745.  
  14746.  
  14747. Platforms
  14748. ---------
  14749.  
  14750. We are making the SunOS 4.x, Solaris 2.3, and OSF/1 versions of
  14751. ORBeline available free of charge to the academic community.  
  14752. We will consider making other platforms available as well if there
  14753. is enough interest.  
  14754.  
  14755. The following compilers are supported in this release:
  14756.  
  14757. Solaris 2.3:    Sun C++ 4.0 (native), SparcWorks 3.0
  14758. SunOS 4.x:      Sun C++ 3.0 (cfront), SparcWorks 2.0.1
  14759. OSF/1 1.3:      DEC C++
  14760.  
  14761. If there is enough interest, we can make versions compatible with
  14762. other compilers available as well.
  14763.  
  14764.  
  14765. LICENSING
  14766. ---------
  14767.  
  14768. ORBeline is provided free of charge to the academic community for
  14769. teaching and research purposes.  After installing ORBeline, call us at
  14770. (415) 967-6169 or send e-mail to info@pomoco.com and we will send you
  14771. a perpetual license for your site.
  14772.  
  14773. If you are interested in ORBeline for commercial purposes, contact us
  14774. and we can provide a limited time evaluation license.
  14775.  
  14776.  
  14777. ACKNOWLEDGEMENTS
  14778. ----------------
  14779.  
  14780. We would like to thank Stanford University for providing us with
  14781. a high-speed ftp site from which to distribute this ORBeline
  14782. release.
  14783.  
  14784.  
  14785.  
  14786.                     PostModern Computing Technologies, Inc.
  14787.                             1897 Landings Drive
  14788.                           Mountain View, CA  94043
  14789.                              Tel: (415) 967-6169
  14790.                              Fax: (415) 967-6212
  14791.                                info@pomoco.com
  14792.  
  14793.  
  14794. >66 OO Designer CASE Tool
  14795.  
  14796.        **************** Object Oriented Designer ***************
  14797.  
  14798.             Prof. Taegyun Kim [ktg@taejo.pufs.ac.kr]
  14799.               Pusan University of Foreign Studies
  14800.                   Pusan, Korea
  14801.  
  14802.                  Version : Version 1.3.1
  14803.                  Revised : October 6 1994
  14804.  
  14805.        *********************************************************
  14806.  
  14807. Let me introduce myself. I am an assistant professor working at Department of
  14808. Computer Engineering in Pusan University of Foreign Studies which resides in
  14809. Pusan, Korea. My major interest is in software engineering especially in the
  14810. area of object oriented methodologies. In teaching courses in systems analysis
  14811. and software engineering I found a need for a good case tool that could be used
  14812. by my students. Unfortunately, commercial case tools are too expensive for a
  14813. university to purchase so I developed OOD. I have spent 17 man months building
  14814. OOD. Because this is my first project combining object oriented methods, Motif,
  14815. and C++, some of the source code may be a little clumsy. However, it does work
  14816. well and it is still evolving.  This project is very hard but is also very
  14817. interesting. Let's enjoy it together.
  14818.  
  14819. P.S.: I am anxious for your criticism or comment on this product. So, if it
  14820. works on your system, please respond to me with even a one line (very short)
  14821. message.  It will give me some encouragement. Moreover please inform me your
  14822. status (student, professor etc.) if possible.
  14823.  
  14824. -Taegyun Kim
  14825.  
  14826.              --------------- Contents --------------
  14827.                      0. Summary
  14828.                      1. System Environment
  14829.                      2. Building OOD
  14830.                      3. Initializing the Working Environment
  14831.                      4. Functions
  14832.                      5. Examples
  14833.                      6. Reference Books
  14834.                      7. Cautions
  14835.                      8. FAQ
  14836.             ----------------------------------------
  14837.  
  14838. 0. Summary
  14839. ----------
  14840.  
  14841. The Object Modeling Technique [OMT] by James Rumbaugh et al. is a methodology
  14842. for object oriented development with a graphical notation for representing
  14843. object oriented concepts.  Object Oriented Designer [OOD] is a case tool for
  14844. constructing the object diagrams defined in OMT. In order to use OOD it is
  14845. necessary to understand OMT and its graphical notation. See reference (2).
  14846.  
  14847. Why "OMT"? OMT evolved from the Extended Entity Relationship [EER] model which I
  14848. have studied since the mid 80's. There are a number of other approaches to
  14849. expressing object oriented concepts but I believe that OMT is superior to most
  14850. of these. Yourdon's Object Oriented Analysis [OOA] notation, for example, is
  14851. another excellent approach to the problem but has some limits in functionality,
  14852. particularly with respect to data modeling, that are present in OMT.
  14853.  
  14854. Currently, OOD has following primary functions:
  14855.  
  14856.     - general graphics editor (with limited functionality)
  14857.  
  14858.     - object diagram layout (with some additions w.r.t. original OMT notation)
  14859.  
  14860.     - C++ code skeleton generation (header file + source file)
  14861.       The comments and codes for individual member functions can be documented,
  14862.       or edited within OOD directly.
  14863.       The C++ code generator supports inheritance. 
  14864.  
  14865. I have attempted to make OOD as user-friendly as possible. My students learn to
  14866. use it in a day even without a manual. The user-friendliness of OOD is due to my
  14867. own object oriented, user interface mechanisms.
  14868.  
  14869. Currently OOD generates a C++ code skeleton from an object diagram.  I have a
  14870. short term final goal to develop an object oriented "environment" with
  14871. flexibility and portability. I think that about additional 20 man months effort
  14872. could lead me to the final goal. Because I am currently working very hard to
  14873. enhance its functionality, I am not especially concerned with system portability
  14874. issues at the moment so building OOD on your particular platform may require a
  14875. little work on your part. Please inform me of any changes that you need to make
  14876. to build OOD on your system.
  14877.  
  14878.  
  14879. 1. System Environment
  14880. ---------------------
  14881. OOD was built on a SPARC station running OS4.1.x, X11-R5 and Motif-1.2 and
  14882. C++-2.0. OOD has also been successfully built on a SPARC using gcc-2.5.8 and
  14883. libg++-2.5.3. It should build on most UNIX systems with X11-R5, Motif-1.2 and a
  14884. "reasonable" C++ compiler.
  14885.  
  14886. 2. Building OOD
  14887. ---------------------
  14888.     1) In ood directory edit the Makefile to reflect your environment
  14889.     2) run "make depend"
  14890.     3) run "make"
  14891.  
  14892. 3. Initialize Working Environment
  14893. --------------------------------
  14894. OOD requires the user to select a working repository in which to store various
  14895. output files. If this is the first time you are running OOD:
  14896.  
  14897.     1) point at the top-menu,
  14898.     2) select "Environment",
  14899.     3) select "Setup",
  14900.     4) define your working repository.
  14901.  
  14902. If a working repository has been previously defined, select it:
  14903.  
  14904.     1) point top-menu
  14905.     2) select "change to"
  14906.     3) set your working repository 
  14907.  
  14908.   ...
  14909.  
  14910.  
  14911. >67 OOTher OO CASE Tool
  14912.  
  14913. From: conrozi@kk90.ericsson.se (Roman Zielinski TT/TSM)
  14914. Subject: CASE OOTher 1.06f released (free/shareware)
  14915. Organization: Ericsson
  14916. Date: Tue, 20 Sep 1994 07:15:09 GMT
  14917.  
  14918. Product:
  14919.     OOTher
  14920.     OO Documentation & CASE Tool Release 1.06f
  14921.  
  14922. Environment:
  14923.     MS-Windows 3.1
  14924.  
  14925. Short description:
  14926.     The tool is a complete documentation development package for
  14927.      the following methods/notations:
  14928.     - Peter Coad's OOA method (Coad/Yourdon)
  14929.     - State Machine diagrams using a subset of SDL
  14930.     - allocation of objects to processors and processes
  14931.     - Use Case diagrams and Object Interaction diagrams
  14932.       as proposed by Ivar Jacobson in his OOSE book
  14933.  
  14934.     The tool also performs verification of consistency between the 
  14935.     diagrams, and by direct coupling assures for consistent naming
  14936.     of objects and methods/services.
  14937.  
  14938.     The tool is build around 5 easy to use graphic editors and is 
  14939.     capable of documenting all objects, their attributes, services 
  14940.     and also associations between objects. 
  14941.  
  14942. ############################################################################
  14943.  
  14944.  
  14945. Path: senator-bedfellow.mit.edu!faqserv
  14946. From: Bob Hathaway <rjh@geodesic.com>
  14947. Newsgroups: comp.object,comp.answers,news.answers
  14948. Subject: Comp.Object FAQ Version 1.0.8 (05-31) Part 13/13
  14949. Supersedes: <object-faq/part13_805979999@rtfm.mit.edu>
  14950. Followup-To: comp.object
  14951. Date: 31 Aug 1995 15:35:05 GMT
  14952. Organization: Geodesic Systems
  14953. Lines: 1258
  14954. Approved: news-answers-request@MIT.Edu
  14955. Distribution: world
  14956. Expires: 14 Oct 1995 15:31:54 GMT
  14957. Message-ID: <object-faq/part13_809883114@rtfm.mit.edu>
  14958. References: <object-faq/part12_809883114@rtfm.mit.edu>
  14959. NNTP-Posting-Host: bloom-picayune.mit.edu
  14960. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  14961. X-Last-Updated: 1995/06/01
  14962. Originator: faqserv@bloom-picayune.MIT.EDU
  14963. Xref: senator-bedfellow.mit.edu comp.object:37595 comp.answers:13987 news.answers:51885
  14964.  
  14965. Archive-name: object-faq/part13
  14966. Last-Modified: 05/31/95
  14967. Version: 1.0.8
  14968.  
  14969.     Each service may have a state machine (FSM) diagram.
  14970.     C++ Headers may be generated automatically from the OOA diagram -
  14971.     it assures consistent naming of member functions and attributes.
  14972.     The applied mark-up notation for C++ headers should be powerful 
  14973.     to give compiler ready headers for at least 80% of applications.
  14974.  
  14975.     For a better integrability with other windows applications and to
  14976.     allow esthetical control, the tool allows free font selection and
  14977.     a copy-paste transfer of diagrams via clipboard in meta file format 
  14978.     to e.g. Word for Windows 2.0.
  14979.  
  14980.     The resulting file is ASCII with open & documented format,
  14981.     i.e. it's easy to add own utilities for data extraction.
  14982.  
  14983.     Complete user documentation is attached in form of a hypertext
  14984.     windows-help file.
  14985.  
  14986.     The tools distributed as:
  14987.     - freeware for students, schools and home users
  14988.     - as shareware for others (USD $170 for corporate 1-5 user license).
  14989.     - free upgrade form 1.0x to 1.06f for registered users if they
  14990.       fetch files from e.g. SimTel Software Repository
  14991.     - free evaluation in 4 weeks
  14992.  
  14993.     - an evaluation copy may be ordered from the author (USD $70, 
  14994.       rest of the license fee if/when you register)
  14995.         Roman M. Zielinski
  14996.         Tre Kaellors Vaeg 7
  14997.         S-145 65 Norsborg
  14998.         Sweden
  14999.       (You may also reach me at conrozi@KK.ericsson.se until July-94)
  15000.  
  15001. *****   Version 1.06f contains bug corrections and updates of zoom-handling.
  15002.                 Roman M. Zielinski
  15003.                 [author]
  15004.  
  15005. ----------------------------------------------------------------------
  15006. SimTel id:
  15007. pub/msdos/windows3/
  15008. oot-106f.zip    OOTher OO Doc Tool 1.06f CASE OOA+OOSE
  15009. ----------------------------------------------------------------------
  15010. mail a message 
  15011. To: listserv@vm1.nodak.edu       (***se below, for other internet server names***)
  15012. Subject: SimTel-request
  15013. Body:
  15014. /PDGET MAIL /SimTel/msdos/windows3/oot-106f.zip uuencode
  15015.  
  15016. (some TRICKLE-servers don't like the arguments 'MAIL' and 'UUENCODE', so
  15017. thay may need to be omitted. Thay also may need the old path specification, 
  15018. example for the Swedish TRICKLE:
  15019. /PDGET <msdos.windows3>oot-106f.zip
  15020. )
  15021.  
  15022. You may also use Archie to find sites storing OOTher. 
  15023. Instructions for archie and paths for OOTher can be fetched via e-mail 
  15024. from e.g. archie@archie.doc.ic.ac.uk
  15025. with a body:
  15026.  
  15027. Help
  15028. find oot
  15029.  
  15030. [... On Simtel Retrieval ...]
  15031.  
  15032. or fetch via anonymous ftp or ftpmail from OAK.Oakland.Edu
  15033. /SimTel/msdos/windows3
  15034.  
  15035. or its mirrors:
  15036.  
  15037. St. Louis, MO:  wuarchive.wustl.edu (128.252.135.4)
  15038.   /systems/ibmpc/msdos
  15039. Corvallis, OR:  archive.orst.edu (128.193.2.13)
  15040.   /pub/mirrors/oak.oakland.edu/simtel20/msdos
  15041. Falls Church, VA:  ftp.uu.net (192.48.96.9)
  15042.   /systems/ibmpc/msdos/simtel20
  15043. Australia:  archie.au (139.130.4.6)
  15044.   /micros/pc/oak
  15045. England:  src.doc.ic.ac.uk (146.169.2.1)
  15046.   /pub/packages/simtel20
  15047. Finland:  ftp.funet.fi (128.214.6.100)
  15048.   /pub/msdos/SimTel-mirror
  15049. Germany:  ftp.uni-paderborn.de (131.234.2.32)
  15050.   /msdos
  15051. Israel:  ftp.technion.ac.il (132.68.1.10)
  15052.   /pub/unsupported/dos/simtel
  15053. Switzerland:  ftp.switch.ch (130.59.1.40)
  15054.   /mirror/msdos
  15055. Taiwan:  NCTUCCCA.edu.tw (140.111.1.10)
  15056.   /PC/simtel
  15057. Thailand:  ftp.nectec.or.th (192.150.251.32)
  15058.   /pub/mirrors/msdos
  15059.  
  15060. ----------------------------------------------------------------------
  15061. To run ftpmail send e-mail to e.g. ftpmail@doc.ic.ac.uk
  15062. with the message body:
  15063.  
  15064. connect ??hostname??
  15065. binary
  15066. uuencode
  15067. cd pub/msdos/windows
  15068. get oot-106f.zip
  15069. quit
  15070. ----------------------------------------------------------------------
  15071.  
  15072.  
  15073. >68 OS Papers (OO?)
  15074.  
  15075. From: axb@defender.dcrl.nd.edu (Arindam Banerji)
  15076. Newsgroups: comp.object
  15077. Subject: The Paper Trail database
  15078. Date: 21 Sep 1994 14:39:20 GMT
  15079. Organization: University of Notre Dame
  15080.  
  15081.             THE PAPER TRAIL
  15082.  
  15083. The "Paper Trail" - an experimental database of ftp'able OS papers
  15084. is now available through http://pclsys64.dcrl.nd.edu/papers. This
  15085. database allows users to find and access papers that are available for
  15086. ftp on the internet. We have initially populated this database with
  15087. about 5500 entries. Most of these entries reflect our own area of
  15088. interest, that is Operating Systems and related areas. We'll add
  15089. entries to the database from time to time. However, it'll probably
  15090. be very difficult to keep this up-to-date without help from other
  15091. users of this database. Hence, the database provides any user the added
  15092. facility to submit entries.
  15093.  
  15094. We hope that the xmosaic interface to this database is intuitive and
  15095. simple. If you have any suggestions and criticisms, please do let us
  15096. know - including how this compares with other such services.  
  15097.  
  15098.  
  15099. -----------------------------------------------------------------------------
  15100. Arindam Banerji                             Michael Casey
  15101.             384 FitzPatrick Hall
  15102.            Dept. of Computer Science and Engineering
  15103.           University of Notre Dame
  15104. (219)-631-5772    Notre Dame, IN 46556       (219)-631-5273
  15105. axb@cse.nd.edu                        mrc@cse.nd.edu
  15106.  
  15107.  
  15108. >69 Trellis
  15109.  
  15110. From: bruno@tk.telematik.informatik.uni-karlsruhe.de (Bruno Achauer)
  15111. Subject: Trellis compiler available
  15112. Date: 23 Oct 1994 00:16:02 GMT
  15113. Organization: Telematics Department, Karlsruhe University, Germany
  15114.  
  15115. The beta release of version 0.2 of the TNT Trellis system is now
  15116. available for anonymous ftp from tk.telematik.informatik.uni-karlsruhe.de.
  15117.  
  15118. Enclosed is ANNOUNCE file from the distribution:
  15119.  
  15120. What are Trellis and TNT
  15121. ~~~~~~~~~~~~~~~~~~~~~~~~
  15122.  
  15123. Trellis is an object-oriented language developed within Digital
  15124. Equipment Corp. The language features compile-time type checking,
  15125. multiple inheritance, parametrized types, exception handling and
  15126. iterators.
  15127.  
  15128.  
  15129. TNT is a new implementation of Trellis, consisting of a compiler, a
  15130. library of predefined types and a (rudimentary) run time system:
  15131.  
  15132.   - The compiler implements the language as defined by the reference
  15133.     manual (except for a few esoteric constructs), plus a few minor
  15134.     extensions.
  15135.  
  15136.   - Predefined types are standard types such as integers, strings,
  15137.     arrays etc. (in Trellis, no type is built into the language!),
  15138.     an IO system and a (rudimentary) hierarchy of collection types.
  15139.  
  15140.   - The run time system is pretty incomplete right now; in particular,
  15141.     neither garbage collection nor threads are implemented yet.
  15142.  
  15143. The system is available for several architectures:
  15144.  
  15145.   - the Digital Alpha (running OSF/1),
  15146.   - the HP Precision Architecture (under HP-UX),
  15147.   - the Intel 386 (under Linux),
  15148.   - Digital's Mips workstations,
  15149.   - Sun's Sparc workstations (running SunOS).
  15150.  
  15151. Both source code and prebuilt kits are available.
  15152.  
  15153. Further work will concentrate on supporting transparently distributed
  15154. objects a la DOWL.
  15155.  
  15156.  
  15157. Changes since last version
  15158. ~~~~~~~~~~~~~~~~~~~~~~~~~~
  15159.  
  15160. * The HP-PA, Linux and Sparc ports.
  15161.  
  15162. * Building the compiler no longer requires the SFIO library.
  15163.  
  15164. * The compiler now can use the GNU assembler to generated object files;
  15165.   at least on small MIPS machines, this will speed up compilation
  15166.   considerably.
  15167.  
  15168. * Several minor bugs have been fixed.
  15169.  
  15170.  
  15171. Requirements
  15172. ~~~~~~~~~~~~
  15173.  
  15174. The prebuilt kits require disk space ranging from 800 KB (Linux) to
  15175. 2.4 MB (OSF/1); a C compilation system (assembler, linker and the C
  15176. library) must be installed. In addition, the Mips and HP-PA versions
  15177. will benefit if the GNU assembler is present.
  15178.  
  15179. Building the system from scratch requires from 5.2 MB (Linux) to 16 MB
  15180. (Alpha). You will also need some auxiliary tools and libraries:
  15181.  
  15182.   - Cocktail V9208 (the Karlsruhe Compiler toolbox),
  15183.   - GNU make V3.68 or later,
  15184.   - patch,
  15185.   - makedepend.
  15186.  
  15187. Most of these should be available on a nearby ftp site (makedepend is
  15188. part of the X distribution; GNU make and patch are distributed by the
  15189. FSF).
  15190.  
  15191. Cocktail is available from several ftp sites, but most of the versions
  15192. floating around will not work on the Alpha. A patched version is
  15193. available on tk.telematik.informatik.uni-karlsruhe.de (see below).
  15194.  
  15195. If you plan to build the MIPS or the SPARC version, you will also need
  15196. the GNU C compiler.
  15197.  
  15198.  
  15199. How to get it
  15200. ~~~~~~~~~~~~~
  15201.  
  15202. A source kit is available via anonymous FTP from
  15203.  
  15204.     tk.telematik.informatik.uni-karlsruhe.de (129.13.3.200)
  15205.     file directory /pub/tnt/tnt-0.1.tar.gz.
  15206.  
  15207. There are also some additional kits in the same directory:
  15208.  
  15209.     * doc    -- PostScript versions of DEC-TR-372 (language
  15210.            reference manual) and DEC-TR-373 (language primer).
  15211.  
  15212.     * prebuilt    -- binary kits.
  15213.  
  15214.     * tools    -- source kits for Cocktail.
  15215.  
  15216.  
  15217. Please direct bug reports, requests, comments etc to
  15218.  
  15219.     tnt@tk.telematik.informatik.uni-karlsruhe.de.
  15220.  
  15221.  
  15222. Acknowledgements
  15223. ~~~~~~~~~~~~~~~~
  15224.  
  15225. The development of TNT has been supported by Digital Equipment's
  15226. Campus-based Engineering Center in Karlsruhe.
  15227.  
  15228. Special thanks to Jean Fullerton and Lutz Heuser at Digital for
  15229. making the technical reports available.
  15230.  
  15231.  
  15232. Copyright
  15233. ~~~~~~~~~
  15234.  
  15235. Copyright â€™ 1994, Universitît Karlsruhe, Germany; parts Copyright â€™ 1994
  15236. Digital Equipment Corp, Maynard, Mass.
  15237.  
  15238. The TNT Trellis software, both binary and source (hereafter, Software) is
  15239. copyrighted by Universitît Karlsruhe, Germany (UKA), and ownership
  15240. remains with the UKA. Parts of the software are copyrighted by Digital
  15241. Equipment Corp., Maynard, Mass.
  15242.  
  15243. The UKA grants you (hereafter, Licensee) a license to use the Software
  15244. for academic, research and internal business purposes only, without a
  15245. fee.  Licensee may distribute the binary and source code (if released)
  15246. to third parties provided that the copyright notice and this statement
  15247. appears on all copies and that no charge is associated with such
  15248. copies.
  15249.  
  15250. UKA MAKES NO REPRESENTATIONS ABOUT THE SUITABILITY OF THIS SOFTWARE FOR
  15251. ANY PURPOSE.  IT IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED
  15252. WARRANTY.  THE UKA SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY THE
  15253. USERS OF THIS SOFTWARE.
  15254.  
  15255. --
  15256. --Bruno.
  15257.  
  15258. ---------------------------------------------------------------
  15259. | Bruno Achauer, U of Karlsruhe, Telecooperation              |
  15260. | Kaiserstr. 12, D-76128 Karlsruhe, Germany                   |
  15261. | bruno@tk.telematik.informatik.uni-karlsruhe.de              |
  15262. | Phone +49-721-6084792, Fax +49-721-388097                   |
  15263. ---------------------------------------------------------------
  15264.  
  15265. >70 CooL-SPE
  15266.  
  15267. From: Gerhard.Mueller@sietec.de (Dr. Gerhard Mþller)
  15268. Subject: Announcement of the CooL Software Production Environment
  15269. Date: Tue, 25 Oct 1994 11:42:28 UNDEFINED
  15270. Organization: Sietec Systemtechnik
  15271.  
  15272.         ANNOUNCEMENT
  15273.  
  15274. The CooL-Software Production Environment - a new object-
  15275. oriented development environment in Public Domain
  15276.  
  15277. The CooL-SPE is a modern software production environment 
  15278. for the development of object-oriented application systems 
  15279. supporting grafical user interfaces and relational database 
  15280. technology. In the landscape of existing software production 
  15281. technologies the CooL-SPE is more closely settled to 4GL 
  15282. environments than to the usual C++ environments, mostly 
  15283. more dedicated to system programming. The CooL-SPE was 
  15284. developed by Siemens Nixdorf Informationssysteme (SNI) 
  15285. within the ESPRIT project ITHHACA and is used since in a 
  15286. number of large projects.
  15287.  
  15288. Allthough the CooL-SPE as a programming environment is 
  15289. functional quite rich, it is also very lean and thus comparable 
  15290. fast to learn and reliable tu use. In one project, which we sup-
  15291. ported recently, we could learn that newly assigned engineers 
  15292. to a fairly large project (400 classes with some 100.000 lines 
  15293. of code) were able to learn the environment, to understand the 
  15294. application and to become productive within a month - and 
  15295. that without any practical experience on object-oriented pro-
  15296. gramming before.
  15297.  
  15298. The system has product quality and is implemented in major 
  15299. parts in itself.
  15300.  
  15301. The CooL-SPE is available for Linux 1.0.1, Solaris 2.3 and 
  15302. SINIX 5.41. You may receive the system (sources and docu-
  15303. mentation) via ftp.fu-berlin.de in the directoy /pub/unix/lan-
  15304. guages/cool.The file itself is named cool-2.1.tar.Z.
  15305.  
  15306. >71 Contra-/Co- Variance
  15307.  
  15308. From: castagna@oeillet (Giuseppe Castagna)
  15309. Subject: Paper on covariance and contravariance
  15310. Date: 25 Oct 1994 17:09:51 GMT
  15311. Organization: Ecole Normale Superieure
  15312.  
  15313.                             PAPER ANNOUNCEMENT
  15314.                             ==================
  15315.  
  15316. The following short (13 pages long) note
  15317.  
  15318.  
  15319.         "COVARIANCE AND CONTRAVARIANCE: CONFLICT WITHOUT A CAUSE"
  15320.                                      
  15321.                             Giuseppe Castagna
  15322.                 Laboratoire d'Informatique de l'ENS, Paris
  15323.  
  15324.  
  15325. is available by anonymous ftp at ftp.ens.fr in the file
  15326.  /pub/reports/liens/liens-94-18.A4.dvi.Z
  15327.  
  15328. ADVERTISEMENT: This paper tries to explain
  15329. -------------
  15330.  
  15331. 1. What covariance and contravariance serve for.
  15332.  
  15333. 2. Why covariance and contravariance are not opposing views but both
  15334.    *must* be integrated in a *type-safe* formalism. I.e.: don't choose
  15335.    just one of them.
  15336.  
  15337. 3. Where the "objects as records" analogy hides covariance.
  15338.  
  15339. 4. How to type binary methods in the models based on the analogy "objects
  15340.    as records" (i.e. how to have ColorPoint < Point even if they respond
  15341.    to a message "equal")
  15342.  
  15343. 5. How to have multiple dispatch when objects are modeled by (recursive)
  15344.    records.
  15345.  
  15346. 6. Why all the previous points are strictly related one to each other.
  15347.  
  15348.                                  ABSTRACT
  15349.  
  15350. In type theoretic research on object-oriented programming the ``covariance
  15351. versus contravariance  issue'' is a  topic of continuing  debate.  In this
  15352. short note  we   argue that covariance  and   contravariance appropriately
  15353. characterize  two distinct  and  independent  mechanisms.    The so-called
  15354. contravariance  rule correctly captures   the {\em  substitutivity\/},  or
  15355. subtyping relation (that establishes which  sets of codes can replace {\em
  15356. in every context\/} another   given set).  A covariant relation,  instead,
  15357. characterizes the {\em specialization\/} of  code (i.e.\ the definition of
  15358. new code that replaces   the old one  {\em  in some particular  cases\/}).
  15359. Therefore,  covariance  and contravariance  are  not  opposing  views, but
  15360. distinct  concepts that each have   their place in object-oriented systems
  15361. and that  both   can  (and  should)  be type    safely  integrated in   an
  15362. object-oriented language.
  15363.  
  15364. We  also show  that   the  independence of    the two  mechanisms  is  not
  15365. characteristic of  a  particular model  but is  valid  in  general,  since
  15366. covariant specialization is present also  in  record-based models, but  is
  15367. hidden by a deficiency of all calculi that realize this model.
  15368.  
  15369. As an aside, we show that  the lambda&-calculus can  be taken as the basic
  15370. calculus both for an  overloading-based and for  a record-based model.  In
  15371. that  case, one not only obtains  a more uniform vision of object-oriented
  15372. type  theories but, in   the case of  the  record-based approach, one also
  15373. gains  multiple dispatching,  which   is  not  captured by   the  existing
  15374. record-based models.
  15375.  
  15376. >72 Quality
  15377.  
  15378. From: melo@umiacs.UMD.EDU (Walcelio Melo)
  15379. To: drenth@tpd.tno.nl
  15380. Cc: ami@aut.alcatel.at
  15381. Subject: Quality Research
  15382.  
  15383. Paper on these topics can be found by anymous
  15384. ftp at: ftp.cs.umd.edu:pub/sel/papers
  15385.  
  15386. or
  15387.  
  15388. web:http://cs.umd.edu/projects/SoftEng/tame
  15389.  
  15390.  
  15391. - what quality aspects (of the process and the product) are measured and
  15392. when are they measured (early on in the development process or merely in
  15393. the testing phase);
  15394. - what metrics are used to measure quality aspects (f.e. Lines Of Code,
  15395. number of Function Points, complexity);
  15396. - are the measurement results used for prediction of the quality of the
  15397. final product;
  15398. - are the measurement results used for process improvement;
  15399. - what methods for process assessment (and improvement) are used (f.e. CMM,
  15400. Bootstrap, AMI);
  15401. - are there certificates (f.e. ISO);
  15402.  
  15403. Best regards,
  15404.  
  15405. walcelio
  15406.  
  15407.  
  15408. >73  Quality
  15409.  
  15410. Re (to >72):
  15411. You might try looking at the Softw Engineering Inst technical report
  15412. "Measurement in Practice," which surveyed the practices of software
  15413. measurement leaders:
  15414.  
  15415. Date: Sat, 2 Jul 1994 09:19:19 +0800 (SST)
  15416. From: Ajith Narayanan <ajith@ncb.gov.sg>
  15417. Subject: MiP techreport available by ftp
  15418. To: Stan Rifkin <sr@seas.gwu.edu>
  15419.  
  15420.     Hi Stan,
  15421.     
  15422.     The GZIP-compressed PostScript of your technical report
  15423.     "Measurement in Practice" is available for anon ftp from
  15424.     ftp:ftp.informatik.uni-stuttgart.de/pub/doc/techreports/Metrics.ps.gz
  15425.  
  15426.     regards
  15427.  
  15428. --Ajith
  15429.  
  15430.  
  15431. >74 TRILLIUM (CMM)
  15432.  
  15433. From: fcoallie@qc.bell.ca (Francois Coallier)
  15434. To: ami@aut.alcatel.at
  15435. Subject: TRILLIUM Release 3.0 available.
  15436.  
  15437. Dear Colleagues,
  15438.  
  15439. The release 3.0 of the TRILLIUM Model is now available
  15440. through the Internet.
  15441.  
  15442. The TRILLIUM model is a software product development and
  15443. support capablity model based on the SEI's Capability
  15444. Maturity Model (CMM).
  15445.  
  15446. TRILLIUM differs from the CMM in its roadmap structure and
  15447. its product and customer focus.
  15448.  
  15449. This release of TRILLIUM is substancially different from
  15450. 2.3d:
  15451.  
  15452.    1) The introductory chapters explaining the model and its
  15453.       application have been extensively rewritten and expanded.
  15454.  
  15455.    2) Practices are updated to provide 100% coverage of the CMMM
  15456.       version 1.1, ISO 9001:1994 and ISO 9000-3, and Bellcore TR-
  15457.       NWT-000179.
  15458.  
  15459.    3) Traceability tables to external source documents are
  15460.       generated automatically.  The verification of all references
  15461.       is thorough.
  15462.  
  15463.    4) The glossary has been updated.
  15464.  
  15465. The TRILLIUM model is in the public domain.  Copies (as a series of
  15466. uuencoded Poscript files) are distributed freely through the Internet.
  15467.  
  15468. To receive your copy via E-Mail, all you have to do is to send me a
  15469. request with your complete coordinates.
  15470.  
  15471. Bounded hard copies are available from the Bell Canada Acquisitions
  15472. department.  Pricing and shipping information are available on
  15473. request (Sorry: this is purely for budgetary reasons).
  15474.  
  15475. Regards,
  15476.  
  15477. Francois Coallier
  15478.  
  15479. ===========================================================================
  15480.  
  15481. Francois Coallier
  15482.  
  15483. Bell Canada,                      TEL:     +1 (514) 448-5100
  15484. 2265 Roland Therrien              FAX:     +1 (514) 448-2090
  15485. Longueuil, Quebec                       or +1 (514) 647-3163
  15486. Canada J4N 1C5
  15487. Internet: fcoallie@qc.bell.ca     Numerical Pager: +1 (514) 749-7937
  15488.  
  15489. >75  Dylan
  15490.  
  15491. From: straz@cambridge.apple.com (Steve Strassmann)
  15492.  
  15493. [...] Dylan (name derived from "Dynamic Language"), an object-oriented language
  15494. developed here at Apple.
  15495.  
  15496. Our home web page is  http://www.cambridge.apple.com.
  15497. Our main ftp site is ftp://cambridge.apple.com/pub/dylan, including
  15498. experimental implementations, the FAQ, literature, etc.
  15499.  
  15500. Dylan combines the major efficiency advantages of static languages
  15501. (C/C++, Pascal) with the flexibility advantages of dynamic languages
  15502. (Scheme, Smalltalk). Dylan is not proprietary; in addition to Apple's
  15503. own compiler effort, there are at least 9 non-Apple implementations 
  15504. under way, including alternative and commercial environments for 
  15505. Windows and unix.
  15506.  
  15507. [...]
  15508.  
  15509. Steve Strassmann, PhD
  15510. straz@apple.com
  15511.  
  15512. >76 Object Domain (Shareware Case Tool)
  15513.  
  15514.   See also appendix D.
  15515.  
  15516. From: dirkv@netcom.com (Dirk Vermeersch)
  15517. Date: Thu, 23 Mar 1995 17:09:55 -0800
  15518.  
  15519.   I've written a shareware program for drawing Booch 93 notation diagrams.
  15520.   All 6 diagrams can be entered in this tool : 
  15521.     - Class diagrams
  15522.     - Object diagrams
  15523.     - Module diagrams
  15524.     - State diagrams
  15525.     - Process diagrams
  15526.     - Interaction diagrams
  15527.  
  15528.   C++ stubs can be generated from the diagrams.
  15529.  
  15530.   FTP address: oak.oakland.edu:/SimTel/win3/pgmtools/domain.zip
  15531.  
  15532.   Best Regards,
  15533.  
  15534.      Dirk Vermeersch
  15535.  
  15536. >77 Cecil
  15537.  
  15538. From: jdean@pysht.cs.washington.edu (Jeffrey Dean)
  15539. Subject: Re: Cecil
  15540. Organization: University of Washington
  15541. Date: Fri, 18 Nov 1994 10:18:54 GMT
  15542.  
  15543. In article <1707013D67.UDIS2@earn.cvut.cs>, UDIS2@earn.cvut.cz writes:
  15544. |> Where can I find info about Cecil language?
  15545. |> 
  15546. |> Thanks,
  15547. |> Peter P.B.
  15548. |> 
  15549.  
  15550. Cecil is a new purely object-oriented language intended to support
  15551. rapid construction of high-quality, extensible software. Cecil
  15552. combines multi-methods with a classless object model, object-based
  15553. encapsulation, and optional static type checking.
  15554.  
  15555. Ongoing research in the Cecil project is in two major areas: language
  15556. design issues and type systems for languages like Cecil, and
  15557. implementation research on making languages like Cecil run faster.
  15558.  
  15559. Ongoing research in the Cecil project is in two major areas: language
  15560. design and object-oriented language implementation.  Our language
  15561. design research addresses modules and typechecking for multi-method
  15562. based languages, and language mechanisms for implicit object
  15563. classification.  Our implementation research is exploring a variety of
  15564. optimization techniques for object-oriented languages, including
  15565. profile-guided type feedback, whole program analysis, specialization,
  15566. and interprocedural type inference algorithms.
  15567.  
  15568. Further information about Cecil is available from our WWW site:
  15569.  
  15570.   http://www.cs.washington.edu/research/projects/cecil/www/cecil-home.html
  15571.  
  15572. Papers about Cecil are also available via anonymous ftp from cs.washington.edu
  15573. in the directory /pub/chambers.  See the README file in that directory for a
  15574. description of the available papers.
  15575.  
  15576. Check out our WWW site: we'd appreciate any feedback people might have.
  15577.  
  15578. [...]
  15579.  
  15580. Producing readable, on-line text versions is difficult, because the
  15581. papers contain embedded figures and formatted text.  Many of the
  15582. papers are available as UW CSE Technical reports, however.  Full
  15583. details can be via anonymous ftp in:
  15584.   cs.washington.edu:/pub/chambers/README.
  15585.  
  15586. Hard-copies of the technical reports may also be requested via
  15587. electronic mail. Send email to: tr-request@cs.washington.edu. Orders
  15588. will be filled via surface mail, subject to availability. Please be
  15589. sure to include a complete snail-mail address with your request.
  15590.  
  15591. As for the compiler, we plan to have an initial release to "friendly,
  15592. interested parties" sometime in the first half of 1995.  The release
  15593. will include full source code for the compiler (currently about 45,000
  15594. lines of Cecil code), and will include both a C-code based back end
  15595. (for portability) and a native Sparc back end.
  15596.  
  15597. We're maintaining a list of people who are interested in this initial
  15598. release.  If you would like to be added to this list, send e-mail to
  15599. me (jdean@cs.washington.edu).
  15600.  
  15601.  
  15602. -- Jeff
  15603.  
  15604. --------------------------------------------------------------------------
  15605. Jeffrey Dean (jdean@cs.washington.edu)      Cecil Project Graduate Student
  15606. Dept. of Computer Science & Engineering           University of Washington
  15607.            http://www.cs.washington.edu/homes/jdean/index.html
  15608. --------------------------------------------------------------------------
  15609.  
  15610. >78  Meta-Case Info
  15611.  
  15612. From: Ian Ferguson <ian.ferguson@sunderland.ac.uk>
  15613. Newsgroups: comp.software-eng
  15614. Subject: metacase home page available on www
  15615. Date: 28 Nov 1994 11:50:36 GMT
  15616. Organization: University of Sunderland
  15617.  
  15618. ANNOUNCEMENT - please forward as appropriate
  15619. ============
  15620.  
  15621. MetaCASE on the World Wide Web
  15622. ======== == === ===== ==== ===
  15623.  
  15624. I am developing an new World Wide Web Home-Page on the subject of MetaCASE.  Its URL is :-
  15625.  
  15626. http://osiris.sunderland.ac.uk/rif/metacase/metacase.home.html
  15627.  
  15628. It contains information on MetaCASE tools, standards, conferences, suppliers, researchers, mailing lists, products, ftp sites etc.
  15629.  
  15630. I am, however, still looking for information.  If you have any information that you think should be included, please let me know and I will be glad to give you full credit when that information is displayed.
  15631.  
  15632. Regards,
  15633. Ian Ferguson
  15634.  
  15635. --------------------------------------------------------------------------------
  15636. R.I.Ferguson                                    
  15637. Research Associate                                           
  15638.                                               
  15639. University of Sunderland                       
  15640. School of Computing and Information Systems     
  15641. Priestman Building                              
  15642. Green Terrace
  15643. Sunderland              Email : ian.ferguson@sunderland.ac.uk
  15644. Tyne/Wear               Tel   : (+44) 0191-515-2754
  15645. SR1 3SD                 Fax   : (+44) 0191-515-2781
  15646. United Kingdom          Web   : http://osiris.sunderland.ac.uk/rif/welcome.html
  15647. --------------------------------------------------------------------------------
  15648.  
  15649.  
  15650. >79  C++ Std Temp. Lib
  15651.  
  15652. From: khan@xraylith.wisc.edu (Mumit Khan)
  15653. Newsgroups: comp.object
  15654. Subject: Re: C++ Collection Classes
  15655. Date: 25 May 1995 01:38:05 GMT
  15656.  
  15657. [...]
  15658.  
  15659. The C++ standard draft includes the spec for Standard Template Library
  15660. (STL) which gets you pretty much any collection you need in C++. Check
  15661. out the C++ faq (somewhere under ftp://rtfm.mit.edu/...) for where to
  15662. find it. If you're using GNU C++ 2.6.3 (or a more recent snapshot), the
  15663. hacked version of STL that comes with libg++-2.6.2 (or w/today's 2.6.9
  15664. snapshot) is quite usable. ObjectSpace and Modena are two vendors selling
  15665. STL implementations that cover a wide variety of compiler/platform combos
  15666. (info@objectspace.com, 1-800-MODENA-1 for more info). Also welcome to
  15667. take a look at my STL newbie file (http://www.xraylith.wisc.edu/~khan/
  15668. and follow the 'STL Newbie doc' link). If you're using Borland 4.5 on a
  15669. PC, you can use the HP implementation from ftp://butler.hpl.hp.com/stl.
  15670.  
  15671. Here's a snippet from FAQ:
  15672.  
  15673. ====
  15674.  
  15675. STL HP official site:    ftp://butler.hpl.hp.com/stl
  15676. STL code alternate:    ftp://ftp.cs.rpi.edu/stl
  15677. STL code + examples:    http://www.cs.rpi.edu/~musser/stl.html
  15678. hacks for GCC-2.6.3:    ftp://ftp.uni-bremen.de/pub/.mount/ruin/C++/STL 
  15679.  
  15680. ====
  15681.  
  15682. btw, c.l.c++ is the group you should watch for this type of info.
  15683.  
  15684. enjoy
  15685. mumit -- khan@xraylith.wisc.edu
  15686.  
  15687. >80 Phantom (Distr Prog)
  15688.  
  15689. From: acourtny@cs.tcd.ie (Antony Courtney)
  15690. Subject: Announcing: Phantom language, home page, alpha release
  15691. Keywords: languages, distributed, interpreted
  15692. Organization: Computer Science, Trinity College Dublin
  15693. Date: Mon, 15 May 1995 10:37:36 GMT
  15694.  
  15695. Announcing:
  15696.  
  15697.     Phantom, an Interpreted Language for Distributed Programming
  15698.  
  15699. This message is an announcement for the Phantom home page, mailing list,
  15700. and prototype interpreter for the centralised language core.
  15701.  
  15702. -------------------------------------------------------------------------------
  15703. >From  the Phantom home page:
  15704.  
  15705. What is Phantom?
  15706.  
  15707. Phantom is a new interpreted language designed to address some of the problems
  15708. presented by large-scale, interactive, distributed applications such as
  15709. distributed conferencing systems, multi-player games, and collaborative work
  15710. tools. Phantom combines the distributed lexical scoping semantics of Obliq with
  15711. a substantial language core. The language core is based on a safe, extended
  15712. subset of Modula-3, and supports a number of modern programming features,
  15713. including:
  15714.  
  15715.    * static structural-equivalence typing
  15716.    * objects
  15717.    * modules and interfaces
  15718.    * lightweight threads
  15719.    * exceptions
  15720.    * garbage collection
  15721.    * higher-order functions and lambda expressions
  15722.    * a keyword binding mechanism
  15723.    * dynamically sized lists and slice indexing notation
  15724.    * type-safe implicit declarations
  15725.  
  15726. The Phantom interpreter is implemented entirely in ANSI C, and provides a
  15727. binding to the Tk GUI toolkit.
  15728.  
  15729. Phantom has similar goals to Java, but was developed independently.
  15730.  
  15731. ------------------------------------------------------------------------------
  15732.  
  15733. Information about Phantom, the mailing lists, differences from Java,
  15734. documentation on the language, and the current status and availability of
  15735. the interpreter can be found on the Phantom home page:
  15736.  
  15737.         http://www.cs.tcd.ie/acourtny/phantom/phantom.html (in Europe)
  15738. or
  15739.         http://www.apocalypse.org/pub/u/antony/phantom/phantom.html (US mirror)
  15740.  
  15741. Please feel free to drop by and have a look!
  15742.  
  15743.     Antony Courtney <Antony.Courtney@cs.tcd.ie>
  15744.     Trinity College Dublin
  15745.     Ireland
  15746.  
  15747. >81 Java (Distr Prog)
  15748.  
  15749. This recent article discusses and quotes Java.
  15750.  
  15751. From: Greg Wilkins <gregw>
  15752. Newsgroups: comp.object
  15753. Subject: Java vs. C++
  15754. Date: 25 May 1995 03:42:36 GMT
  15755. Organization: Telstra Corporation
  15756.  
  15757. I have been reading about the Java language from Sun Labs:
  15758.   http://java.sun.com/index.html
  15759.  
  15760. The way I use C++ looks like it would transfer to Java
  15761. very easily, giving me access to the featurs of C++ I
  15762. like, without the danger of the many extra C++ "features."
  15763.  
  15764. I'm interested in hearing opinions on Java from the many 
  15765. posters that dislike C++.   While the chances of a new 
  15766. language taking off are very very slim, looking at
  15767. languages like Java are good ways of refining the way
  15768. we learn/teach/review/use languages like C++.
  15769.  
  15770. Just to steal a bit of the Java doco:
  15771.  
  15772.  
  15773.      Java: A simple, object-oriented, distributed, 
  15774.            interpreted, robust, secure, architecture neutral, 
  15775.            portable, high-performance, multithreaded, 
  15776.            and dynamic language.
  15777.  
  15778.  
  15779. We wanted to build a system that could be programmed easily without a lot of
  15780. esoteric training and which leveraged today's standard practice.
  15781. Most programmers working these days use C, and most programmers doing
  15782. object-oriented programming use C++. So even though we found
  15783. that C++ was unsuitable, we designed Java as closely to C++ as possible in
  15784. order to make the system more comprehensible.
  15785.  
  15786. >82  Reflection Paper
  15787.  
  15788. From: lady0065@sable.ox.ac.uk (David Hopwood)
  15789. Subject: Reflection (was Re: Has C++ had its day?)
  15790. Organization: Oxford University, England
  15791. Date: Wed, 31 May 95 02:59:04 BST
  15792.  
  15793. In article <3pq7eo$e50@nova.umuc.edu>, Ell <COATES@EUROPA.UMUC.EDU> wrote:
  15794. [snip]
  15795. >Curious what you mean by "reflective" design?
  15796.  
  15797. Reflection is the ability to change aspects of the implementation of a
  15798. language (eg. method dispatch, memory allocation, synchronization
  15799. policies), on a per-object (or per-class) basis.
  15800.  
  15801. For example, reflection can be used to add distributed message passing to a
  15802. language that doesn't have this hard-wired into the compiler, simply by
  15803. changing how method dispatch is implemented for remote objects.
  15804.  
  15805. A typical (but not the only) model of reflection has a 'meta-object'
  15806. associated with each object. There is a default meta-object which defines the
  15807. basic capabilities of the language (in practice, calls to this are usually
  15808. inlined). The code emitted by the compiler for operations like method
  15809. dispatch, etc. is modified to check whether the object in question is
  15810. reflective (has a meta-object other than the default).
  15811.  
  15812. So, the code for a method call
  15813.     "receiver.method (param1, param2, ...)"
  15814. might look something like:
  15815.  
  15816. if (receiver is non-reflective)
  15817.     inline code for a standard method call
  15818. else
  15819.     m := the meta-object for receiver
  15820.     m.perform (receiver, method_id, parameter-list)
  15821.  
  15822. m can also be reflective (which leads some research papers to talk about an
  15823. infinite tower of objects and corresponding meta-objects), but normally only
  15824. one or two levels are used.
  15825.  
  15826. The meta-object can implement dispatch however it likes, for example using
  15827. RPC to a distributed object, or whatever. The interface of a meta-object
  15828. (which includes 'perform' in this case) is called the meta-object protocol.
  15829.  
  15830. Other applications of reflection include:
  15831.  
  15832. - memoized calls
  15833.   (the result of a function call is cached, for use on subsequent calls with
  15834.   the same parameters)
  15835. - future objects
  15836.   (an object is calculated in a parallel thread; any access to the object
  15837.   blocks until it is ready)
  15838. - transaction messages
  15839.   (as used in ODBMSs)
  15840. - asynchronous messages
  15841.   (as used in Actor languages)
  15842. - interfaces to other languages and type systems
  15843. - implementation of garbage collection
  15844. - heaps optimized for different granularities of object
  15845. - persistence
  15846. - checkpointing
  15847. - replication
  15848.  
  15849. and so on.
  15850. A good summary of reflection is
  15851.  
  15852. ftp://ftp.gte.com/pub/dom/reports/MANO93d.ps
  15853.  
  15854. David Hopwood
  15855. david.hopwood@lmh.ox.ac.uk
  15856.  
  15857. >83 OZ++ (Distr Env)
  15858.  
  15859. From: hamazaki@etl.go.jp (Youichi Hamazaki)
  15860. Subject: OZ++ system released with compiler, execution system and management systems
  15861. Date: 30 May 1995 12:21:14 GMT
  15862. Organization: Electrotechnical Laboratory, Tsukuba Science City
  15863.  
  15864. I'm pleased to announce our second release of OZ++ :an object-oriented 
  15865. distributed environment.
  15866. This software is copyrighted, but can be used free of charge by anyone.
  15867.  
  15868.  In this release, it includes compiler of object-oriented distributed
  15869. language oz++, execution system and distributed management systems.
  15870.  You can compile programs written in oz++ language, and execute it in
  15871. distributed environment.  all source codes of distributed management systems
  15872. and libraries are included also.
  15873.  
  15874.  Version control of classes will be provided on next release at late June.
  15875.  
  15876. If you are interested in OZ++, please anonymous FTP the file:
  15877.  
  15878.    etlport.etl.go.jp:/pub/OZ++/OZ++-R2.tar.gz
  15879.  
  15880. *Execution Environment
  15881.  
  15882. The system of OZ++ should be executed in the following environment:
  15883.  
  15884. -SunOS 4.1.3, whose
  15885.         kernel has been configured to access shared memory, required.
  15886. -Disk space of 50MB required.
  15887. -Swap space of 40MB required at the time of exceution.
  15888. -Sparc Station 2, or faster desired.
  15889. *Execution Environment
  15890.  
  15891. Information about OZ++ project is available on WWW
  15892.  
  15893.   http://www.etl.go.jp/Organization/Bunsan/OZ/OZ.html    .
  15894.  
  15895. Any questions , advices and suggestions are welcome. Please send e-mail to
  15896.  
  15897.  oz++admin@oz.ipa.go.jp
  15898.  
  15899.  
  15900. === From ReleaseNote.R2 ===
  15901.                   OZ++ System, Version 1, Release 2
  15902.  
  15903.                             Release Notes
  15904.  
  15905.  Tsukuba Research Laboratory Of Open Fundamental Software Technology
  15906.  
  15907. Copyright (c) 1994 Information-Technology Promotion Agency, Japan (IPA)
  15908.  
  15909. All rights reserved.  No guarantee.  
  15910. This technology is a result of the Open Fundamental Software Technology
  15911. Project of the Information-Technology Promotion Agency, Japan (IPA)
  15912.  
  15913.    This document  describes  the  objectives  and  the  configuration  of  this
  15914. software and the features of this release.
  15915.    Details  on  the  copyrights  of  this  software  are  described in the file
  15916. 'COPYRIGHT'.
  15917.  
  15918. 1. What is OZ++ ?
  15919.  
  15920.    In the software industry, people throughout the world have been  continually
  15921. developing  software  with  very  similar  features;  and thus "reinventing the
  15922. wheel" as it were.  Such  redundancy  has  been  impeding  the  improvement  of
  15923. software  productivity and reliability. Therefore, the sharing and distribution
  15924. of not only information but also of software is needed over the  network  (i.e.
  15925. Internet).  However,  this  cannot  be  achieved  merely by opening the network
  15926. infrastructure and making software publicly available.
  15927.  
  15928.    The OZ++ system has therefore  been  developed  to  solve  this  problem  of
  15929. software transfer.  Based on the concept of object-orientation, the OZ++ system
  15930. provides distribution, upgrading, and authorization function of  software  over
  15931. the network. The high modularity of object-oriented systems and the conformance
  15932. checking  of  interface  between  objects  promotes  the  re-using  of software
  15933. components.  The infrastructure is now being put into place so that  components
  15934. of different software products can be combined in much the same way as hardware
  15935. products.  Because the OZ++ systems enables the distribution of software  (i.e.
  15936. program),  software  can  be  brought  from all over the world; furthermore, it
  15937. allows such software to  run  without  complicated  installation.  Because  the
  15938. versions  of  software  are automatically recognized by the system, old and new
  15939. versions are available at the same time and the newer version is  automatically
  15940. distributed.  In  addition,  validation functions have been included to confirm
  15941. the source of the software so that everyone can use it without  worrying  about
  15942. viruses.  Because  of these functions, OZ++ system users are always able to use
  15943. the newest and most appropriate types of software available.
  15944.  
  15945. 2.The configurations of the OZ++ system
  15946.  
  15947.    In OZ++, the computation takes place by  communicating  distributed  objects
  15948. placed  over  the network. Objects are run on processes called $BTe(Jxecutors$BU.(J  An
  15949. executor can run an arbitrary number of  objects  and  is  managed  by  process
  15950. called  'nucleus'.  Each  station  is always managed by a nucleus and a nucleus
  15951. can manage an arbitrary number of executors.
  15952.  
  15953.    See README.first for how to install and startup the OZ++ system.
  15954.  
  15955. 3. About this release
  15956.  
  15957.    This release contains the following:
  15958.  
  15959. *Nucleus
  15960. *Executor
  15961. *Launcher
  15962. *Compiler-front-end
  15963. *Object-images for demonstration
  15964.  
  15965.    By this release you can you can compile and execute OZ++ program.
  15966.  
  15967.    To compile your OZ++ program, you  can  use  the  `compiler-front-end'.  How
  15968. to use of it is described in the file doc/README.compile.
  15969.  
  15970.    To  execute  your  OZ++  program, you can use the `launcher'.  How to use of
  15971. it is described in the file doc/README.launcher.
  15972.  
  15973.    To create new object image, a tool called `newimage'  is  provided.  How  to
  15974. use of this tool is described in the file doc/README.newimage
  15975.  
  15976.    Furthermore, you can see two kind of demonstrations of the OZ++ system:
  15977.  
  15978. *Application 'Encyclopedia'
  15979.  
  15980. Showing the method invocations between remote stations.
  15981.  
  15982. *Application 'Object mail system'
  15983.  
  15984. Showing where a  new  version  of  a  program  is  automatically  selected  and
  15985. distributed.
  15986.    A tutorial of these demonstrations is provided in doc/DemoTutorial.
  15987.  
  15988.    The Release schedule for future versions is as follows:
  15989.  
  15990. *Release 3
  15991.  
  15992. Around 6/20.  You can compile, manage, and run OZ++ programs distinguishing its
  15993. versions.  The first version of debugger will be included.
  15994. -- 
  15995.  $@IM:j!!M[0l!!!!!!!wJ,;6%7%9%F%`8&5f<<!%EE;R5;=QAm9g8&5f=j(J
  15996. $@!N6=L#!OJ,;6=hM}!"(J$@#S#F!"#S(Jcience$@#N(Jon$@#F(Jiction$@!"#N(Jon$@#S(Jence$@#F!"<r(J
  15997. Yoichi Hamazaki , ElectroTechnical Laboratory , Tsukuba, Japan
  15998. E-mail address:    hamazaki@etl.go.jp        Telephone:    (+81)-298-58-5903
  15999.  
  16000.  
  16001.  
  16002.  
  16003. APPENDIX F  MAGAZINES, JOURNALS AND NEWSLETTERS
  16004. ===============================================
  16005.  
  16006. ACM
  16007. ---
  16008.   OOPSLA - Association For Computing Machinery's yearly conference on Object-
  16009.     Oriented Programming Systems, Languages, and Applications.
  16010.     Addison-Wesley
  16011.     Order Dept.
  16012.     Jacob Way
  16013.     Reading, MA 01867
  16014.     (800) 447-2226
  16015.   ACM OO Messenger    - Quarterly on Object-Oriented Languages and Systems
  16016.   ACM SigPlan Notices - Special Interest Group on Programming Languages
  16017.     Publications Office
  16018.     ACM, 1515 Broadway
  16019.     NY, NY 10056
  16020.     (212)869-7440, FAX: (212)869-0481
  16021.   Additional information can be obtained from ACMpubs@acm.org.
  16022.  
  16023. American Programmer (Yourdon's Newsletter)
  16024. ------------------------------------------
  16025. Monthly Newsletter on Software Engineering including quality, the CMM, object-
  16026. oriented technology, and etc.  $395/year.  Send for complementary copy.
  16027.   American Programmer, Inc.
  16028.   Dept. 13
  16029.   161 West 86th Street
  16030.   New York, NY  10024-3411
  16031.  
  16032. CASE Trends Magazine
  16033. --------------------
  16034. Sorry, still no reference.
  16035.  
  16036. The Coad Letter
  16037. ---------------
  16038. From Peter Coad (pronounced "Code"), of Coad/Yourdon OOA/D fame.
  16039.   Object International, Inc.
  16040.   3202 W. Anderson Lane, Suite 208-724
  16041.   Austin, TX  78757-1022
  16042.   Tel: 800-926-9306, 512-795-0202
  16043.   Fax: 512-795-0332
  16044.  
  16045. The C+@ Quarterly
  16046. -----------------
  16047. On the C+@ language (pronounced "Cat").
  16048. Unir Technology, Inc.
  16049. 184 E. Shuman Blvd.
  16050. Naperville, IL 60563
  16051.  
  16052. DE FACTO - The ami Newsletter
  16053. -----------------------------
  16054. Reports on the progress of ami (application of metrics in industry).
  16055.   ami User Group
  16056.   Centre for Systems and Software Engineering
  16057.   South Bank University
  16058.   103 Borough Road, London SE1 OAA
  16059.   Phone: +44 71 815 7504
  16060.   Fax:   +44 71 928 1284
  16061.  
  16062. Eiffel Outlook
  16063. --------------
  16064. *Eiffel's clear and powerful OO software engineering framework has strongly
  16065.  influenced the object industry.  For four years, the independent editors of
  16066.  Eiffel Outlook have delivered news, reviews, and technical information about
  16067.  Eiffel and Eiffel standards.  Articles from Eiffel and OO experts provide
  16068.  methods, strategies, and principles that you can apply on any OO project.
  16069. *Free sample copies available.
  16070.  
  16071. Eiffel Outlook
  16072. 1501 West Koenig Lane
  16073. Austin, Texas 78756   USA
  16074. TEL: 800 285 5124 or 512 452 9455
  16075. FAX: 512 452 1721
  16076. email: tower@twr.com
  16077.  
  16078. The Guerilla Programmer
  16079. -----------------------
  16080. For the practicing professional programmer.
  16081.   New, by Ed Yourdon.
  16082.   Phone:  800-964-8702 or 617-648-9702
  16083.   Fax:    800-888-1816 or 617-648-1950
  16084.  
  16085. HOTT-LIST - FREE NEWSLETTER
  16086. ---------------------------
  16087. Free, electronic newsletter features article summaries on new generation
  16088. computer and communications technologies from over 100 trade magazines
  16089. and research journals; key U.S. & international daily newspapers, news
  16090. weeklies, and business magazines; and, over 100 Internet mailing lists &
  16091. USENET groups.  Each monthly issue includes listings of forthcoming &
  16092. recently published technical books and forthcoming shows & conferences. 
  16093. Bonus: Exclusive interviews with technology pioneers.  E-mail
  16094. subscription requests to: listserv@ucsd.edu  (Leave the "Subject" line
  16095. blank.)  In the body of the message, type: SUBSCRIBE HOTT-LIST (do not
  16096. include first or last names).  For a person: hott-list-relay@ucsd.com.
  16097.  
  16098. Object-Oriented Systems (New)
  16099. -----------------------------
  16100. EMail: journal@chall.mhs.compuserve.com
  16101. http://www.cs.ucl.ac.uk/coside/oos/index.html  (new)
  16102.     Russel Winder <R.Winder@cs.ucl.ac.uk>
  16103.  
  16104.   USA/Canada:
  16105.   Journals Promotion Dept., Chapman & Hall, 29 West 35th
  16106.   Street, New York, NY 20001-2299, USA.
  16107.   Tel: (212) 244 3336
  16108.   Fax: (212) 244 3426
  16109.   EMail: 71201.1651@compuserve.com
  16110.  
  16111.   EC/RoW:
  16112.   Journals Promotions Dept., Chapman & Hall, 2-6 Boundary Row, London
  16113.   SE1 8HN, UK.
  16114.   Tel: +44 (0)71 865 0066
  16115.   Fax: +44 (0)71 522 9623
  16116.  
  16117. SIGS Publications (9/yr)
  16118. ------------------------
  16119. These publications have staff writers from among the most popular OO authors
  16120. and methodologists.
  16121.   Object Magazine        - Manager's Guide to Object Technology        $39
  16122.   Journal of Object-Oriented Programming - For Progs/Devls using OO    $59
  16123.   C++ Report             - Get most out of C++                         $69
  16124.   The Smalltalk Report   - How-To Advice for Smalltalk Users           $79
  16125.   Report on Object Analysis and Design - Lang Ind/Arch on OOA/D/Mdling $99
  16126.  
  16127.   SIGS Publications, Inc.
  16128.   P.O. Box 2027
  16129.   Langhorne, PA 19047
  16130.   Fax:   215-785-6073
  16131.   Phone: 215-785-5996
  16132.  
  16133.  
  16134.  
  16135. APPENDIX G  COMMERCIAL OBJECT-ORIENTED LIBRARIES AND SYSTEMS
  16136. ============================================================
  16137.  
  16138. A new C++ libraries FAQ is posted monthly to comp.lang.c++ and should be on
  16139. rtfm soon.  Contact cpplibs@trmphrst.demon.co.uk.  It contains anonymous ftp
  16140. sites and commercial libraries and may be merged with this FAQ eventually.
  16141.  
  16142. This is a new APPENDIX and sending in new entries is strongly encouraged by
  16143. both vendors and customers.
  16144.  
  16145. FORMAT:
  16146.     tool name
  16147.     *description and methods
  16148.     *operating systems
  16149.     Vendor name, 
  16150.     city/state, phone (if known)
  16151.  
  16152. Great Circle
  16153. ------------
  16154. *First real commercial Automatic Memory Mgmt System for C and C++.
  16155. *Garbage collection obviates need for free and delete.
  16156. *Eliminates leaks and premature frees in existing programs 
  16157.  and libraries without programmer intervention.
  16158. *Contains transparent (only linking required) and smart-pointer GC interfaces.
  16159. *Supports unions, polymorphism, multiple inheritance, arrays, 
  16160.  exceptions, real-time operation, multi-threading, and provides metrics.
  16161. *Provides both conservative and treadmill collection.
  16162. *OS: DOS, Extended DOS, Windows, NT, Unix, OS/2.
  16163. *Compilers: Borland, CenterLine, Cfront, g++, MetaWare, Microsoft, SparcWorks.
  16164. *Price: PC: $300-500, WorkStation: $700-1100, Compiler/OS ind. C++ source avail.
  16165. Geodesic Systems, Inc.
  16166. 4745 N. Ravenswood Avenue, Suite 111
  16167. Chicago, IL  60640
  16168. Tel:   800-360-8388
  16169. Fax:   312-728-6096
  16170. email: sales@geodesic.com, info@geodesic.com
  16171. www:   http://www.geodesic.com
  16172.  
  16173. LOOK!
  16174. -----
  16175. *Award-winning C++ Dynamic Visualization System.
  16176. *Parses (symbol-rich) C++ executables and animates dynamic object diagrams of
  16177.  executing applications, exposing vital object-level interactions.
  16178. OS:       Unix (SunOS;Solaris;AIX); Windows; NT
  16179. Compilers: Borland;Microsoft; SPARCWorks; CenterLine; Gnu; Lucid (SunOS only)
  16180. Objective Software Technology
  16181. tel:    +44 (0) 1506 472217
  16182. fax:    +44 (0) 1506 472219
  16183. email: info@ost.co.uk
  16184. www:   http://www.scotnet.co.uk/ost/
  16185.  
  16186. Tools.h++, Canvas.h++, DBTools.h++ Heap.h++, Math.h++, Money.h++, View.h++, etc.
  16187. ----------------------------------------------------------------------------
  16188. C++ libraries for containers and more
  16189. Rogue Wave Software, Inc.
  16190. 260 SW Madison Ave.
  16191. P.O Box 2328
  16192. Corvallis, OR 97339 USA
  16193. Ph:    800-487-3217
  16194. Fax:   503-757-6650
  16195. email: sales@roguewave.com
  16196. www:   http://www.roguewave.com
  16197.  
  16198. C++ Booch Components
  16199. --------------------
  16200. Rational
  16201. 1-800-767-3237 ext. 23
  16202.  
  16203. Zapp Portable C++ Application Framework
  16204. ---------------------------------------
  16205. *multi-platform object-oriented windowing libraries.
  16206. Inmark Development Corporation
  16207. 2065 Landings Drive
  16208. Mountain View, CA 94043
  16209. ph:  415-691-9000
  16210. fax: 415-691-9099
  16211. bbs: 415-691-9990
  16212.  
  16213. Zinc Application Framework
  16214. --------------------------
  16215. *multi-platform object-oriented windowing libraries.
  16216. Zinc Software Incorporated
  16217. 405 S. 100 East, @nd Floor
  16218. Pleasant Grove, UT 84062
  16219. ph:        801-785-8900
  16220. tech supp: 801-785-8998
  16221. Fax:       801-785-8996
  16222. info@zinc.com, tech@zinc.com
  16223.  
  16224. ############################################################################
  16225.  
  16226.  
  16227.