COMP.OBJECT FAQ Version: 1.0.9 Date: 4/2/96 Author: Bob Hathaway Geodesic Systems, Inc. Cyberdyne Systems Corporation rjh@geodesic.com http://www.geodesic.com/people/Bob 75027.1663@compuserve.com Copyright 1992-1995 Bob Hathaway All rights reserved. Permission is granted to freely copy and distribute this document but only with this full header attached and at no cost to others with the exception of a nominal distribution fee, if any. No sale, resale or reprinting is granted without the explicit written permission of the author. Anonymous FTP Sites and Hypertext Server: anonymous@zaphod.uchicago.edu:/pub/CompObj9.faq(.Z) (128.135.72.61) anonymous@rtfm.mit.edu:/pub/usenet/comp.object/*_Part_* (18.181.0.24 Tmp) http://iamwww.unibe.ch/~scg/OOinfo/FAQ/index.html (new IAM location) Mail Server: (See also section 1.24) mail mail-server@rtfm.mit.edu Subject: send usenet/comp.object/* Zaphod is preferred over rtfm for anonymous ftp retrieval, as it provides a single file. Rtfm contains the FAQ as posted. To use the hypertext system, see APPENDIX E, entries 27. Comp.Object Archive: A new and workable comp.object archive is now available on the www, with much thanks to Markus A. Beckmann, beckmann@informatik.mathematik.uni-mainz.de. http://aaimzb.mathematik.uni-mainz.de/Personal/Mitarbeiter/comp.object.idx.html Object Currents: A related and free new on-line Object resource edited by yours truly: http://www.sigs.com/objectcurrents - Please take a look! Contributors: Per Abrahamsen, Margaret Burnett, Edwardo Casais, Stewart Clamen, Dennis De Champeaux, Mike DeVaney, Eric Dujardin, Piercarlo Grandi, Tim Harvey, Brian Henderson-Sellers, Urs Hoelzle, Paul Johnson, Bill Kinnersley, Oscar Nierstrasz, James Odell, David Wheeler, Eoin Woods, and many others whose contributions have helped this document to fulfull its objective of bringing object-oriented concepts and systems to everyone. Special thanks to Object Systems, Geodesic Systems and Cyberdyne Systems for providing the support and resources needed to make this effort possible. Object Systems was primarily a "think tank" and producer of object-oriented technologies, Geodesic Systems brings the latest in object-oriented theory and technique to practical and widespread use, as does Cyberdyne. And to kick off the new Appendix G, Commercial OO Libraries and Systems, I'm introducing our own new product (partly developed by me:-), the Great Circle (TM) automatic memory management system for C and C++. I've used it on several of my own projects where it automatically fixed all memory leaks instantly. New formatted and submitted entries for Appendix G are most welcome. Objective: In the spirit of other FAQs, to provide a simple document to answer the most frequently asked and recurring questions and to allow new users to understand frequently discussed topics and terms used in comp.object. This should bring new comp.object readers and/or writers to at least an introductory level of comprehension as soon as possible. Other goals (hopes) are to provide a quick and current reference on available systems such as object- oriented languages, CASE, OODB and etc. and to provide good references to current and relevant OO systems, groups, texts and literature. Disclaimer: This document does not necessarily reflect the opinions of the author's or any contributor's companies. There are no explicit or implicit guarantees implied by this document. While object systems are a constantly changing and moving target with a broad diversity of often conflicting methodologies, constructs, terminologies, approaches, languages, implementations and etc. and comp.object has a wide diversity of readers and writers ranging from students, professors and researchers in academia to beginners, professionals, top-notch experts and leaders in industry with a broad range of experience and backgrounds ranging across many paradigms, this FAQ can certainly not aspire to satisfy all of them completely but instead attempts to provide the most well-rounded treatment of object-oriented concepts and realizations primarily from the mainstream and popular authors and systems and further to provide a collection of available systems and tools in the appendices. Several improvements are planned for future FAQs, including a glossary. SECTION 1: BASICS 1.1) What Is An Object? 1.2) What Is Object Encapsulation (Or Protection)? 1.3) What Is A Class? 1.4) What Is A Meta-Class? 1.5) What Is The Infinite Regress Of Objects And Classes? 1.6) What are MOPs and Reflection? 1.7) What Is Inheritance? 1.8) What Is Multiple Inheritance? 1.9) Does Multiple Inheritance Pose Any Additional Difficulties? 1.10) What Is Dynamic Inheritance? 1.11) What Is Shared (Repeated) Inheritance? 1.12) Why Use Inheritance? 1.13) Why Don't Some People Like Inheritance? 1.14) What Is Specialization/Generalization/Overriding? 1.15) What Is The Difference Between Object-Based And Object-Oriented? 1.16) Is A Class An Object? 1.17) Is An Object A Class? 1.18) What Is A Method? (And Receiver And Message) 1.19) What Are Multi-Methods And Multiple-Polymorphism? 1.20) What Is OOP? 1.21) What Is OOA/OOD (And Where Can I Get What I Need On It)? 1.22) Where Did Object-Orientation Come From? 1.23) What Are The Benefits Of Object-Orientation? 1.24) What Other FAQs Are available? SECTION 2: TYPING 2.1) What Is Polymorphism? 2.2) What Does Polymorphism Boil Down To In OO Programming Languages? 2.3) What Is Dynamic Binding? 2.4) Is There A Difference Between Being A Member Or Instance Of A Class? 2.5) What Is This I Read About ML And Functional Programming Languages? 2.6) What Is the Difference Between Static And Dynamic Typing? 2.7) What Is A Separation Between Type And Class (Representation)? 2.8) What Are Generics And Templates? SECTION 3: GENERAL 3.1) What Is The "Classical" Object-Oriented Paradigm? 3.2) What Is The "Delegation/Prototyping" Object-Oriented Paradigm? 3.3) Are There Any Other Object-Oriented Paradigms? 3.4) What Are The Major Object-Oriented Programming Languages Today? 3.5) What Are Object-Oriented Databases And Persistence? 3.6) What Are Object-Oriented Operating Systems? 3.7) What Are The Current Object-Oriented Methodologies? 3.8) What Is The OMG/OMA/ORB/CORBA? 3.9) Why Is Garbage Collection A Good Thing? 3.9b) Why is Garbage Collection Necessary For Object-Oriented Programming? 3.10) What Can I Do To Teach OO To The Kids? 3.11) What Is Available On Object-Oriented Testing? 3.12) What Distributed Systems Are Available? 3.13) What Is The MVC Framework? 3.14) What Is Real-Time? 3.15) What Is Available on OO Metrics? 3.16) What Are Visual Object-Oriented Programming Systems? 3.17) What Tutorials Are Available On Object-Oriented Concepts and Languages? SECTION 4: COMMONLY ASKED LANGUAGE SPECIFIC QUESTIONS 4.1) What Is Downcasting? 4.2) What Are Virtual Functions? 4.3) Can I Use Multiple-Polymorphism Or Multi-Methods In C++? 4.4) Can I Use Dynamic Inheritance In C++? ANNOTATED BIBLIOGRAPHY APPENDIXES APPENDIX A VIPS APPENDIX B OBJECT-ORIENTED DATABASES AND VENDORS APPENDIX C OBJECT-ORIENTED LANGUAGES AND VENDORS APPENDIX D OBJECT-ORIENTED CASE (OOA/D/P TOOLS) AND VENDORS APPENDIX E ANONYMOUS FTP SITES APPENDIX F MAGAZINES, JOURNALS AND NEWSLETTERS APPENDIX G COMMERCIAL OBJECT-ORIENTED LIBRARIES AND SYSTEMS [Another appendix on commercial object-oriented class libraries should be added soon] SECTION 1: BASICS ================== Suggested Readings: [Booch 91, 94] Others to be added... 1.1) What Is An Object? ----------------------- There are many definitions of an object, such as found in [Booch 91, p77]: "An object has state, behavior, and identity; the structure and behavior of similar objects are defined in their common class; the terms instance and object are interchangeable". This is a "classical languages" definition, as defined in [Coplien 92, p280], where "classes play a central role in the object model", since they do not in prototyping/delegation languages. "The term object was first formally applied in the Simula language, and objects typically existed in Simula programs to simulate some aspect of reality" [Booch 91, p77]. Other definitions referenced by Booch include Smith and Tockey: "an object represents an individual, identifiable item, unit, or entity, either real or abstract, with a well-defined role in the problem domain." and [Cox 91]: "anything with a crisply defined boundary" (in context, this is "outside the computer domain". A more conventional definition appears on pg 54). Booch goes on to describe these definitions in depth. [Martin 92, p 241] defines: "An "object" is anything to which a concept applies", and "A concept is an idea or notion we share that applies to certain objects in our awareness". [Rumbaugh 91] defines: "We define an object as a concept, abstraction or thing with crisp boundaries and meaning for the problem at hand." [Shlaer 88, p 14] defines: "An object is an abstraction of a set of real-world things such that: * all of the real-world things in the set - the instances - have the same characteristics * all instances are subject to and conform to the same rules" and on identifying objects: "What are the *things* in this problem? Most of the things are likely to fall into the following five categories: Tangible things, Roles, Incidents, Interactions, and Specifications." [Booch 91, 4.3] covers "Identifying Key Abstractions" for objects and classes based on an understanding of the problem domain and [Jacobson 92] provides a novel approach to identifying objects through use-cases (scenarios), leading to a use-case driven design. Jacobson also calls for managing complexity with specialized object categories [Jacobson 94]: Ordinary Objects - Typical OOPL objects Use-Cases and Actors - Actors <--> Use-Cases <--> Object Model Objects Megaobjects - Composite objects (~ subsystems with inheritance) Frameworks*(Typical) - Abstract MO meant for reuse and extension Patterns** (Typical) - Framework-like, crsp. classes and comm patterns only Application Objects - In the Object Model Interface - E.g. GUI Control - Introduced in design for control purposes Entity - Correspond to real-world objects Component Objects - Utility and Implementation hiding objects Utility - Set, Array, ... Impl. Hiding - Distr. Arch., specific DBMS, OS Unrelated to Ivar Jacobson but relevant to the topic: * There was a Software Frameworks Assoc. and magazine until last year, but a review of their last conference is available by email thanks to Adam Wildavsky, send requests to adamw@panix.com. **There is a patterns mailing list, email: patterns-request@cs.uiuc.edu, with the HEADING "subscribe". See also st.cs.uiuc.edu for some info on patterns. See also http://st-www.cs.uiuc.edu/users/patterns/patterns.html The implementation of objects could roughly be categorized into descriptor- based, capability-based, and simple static-based approaches. Descriptor- based approaches (e.g. Smalltalk handles) allow powerful dynamic typing, as do the capability-based approaches which are typically found in object- oriented databases and operating systems (object id's). A "proxy" based approach with an added layer of indirection to Smalltalk's handles is found in Distributed Smalltalk which allows transparent, distributed, and migrating objects [Kim 89, ch 19 and Yaoqing 93]. Simple static approaches are found in languages such as C++, although the new RTTI facility will supply simple dynamic typing (checked downcasting) similar to those introduced by Eiffel in 1989 through the notion of assignment attempt, also known as type narrowing. Descriptor-based approaches can have pointer semantics and can be statically typeless (or just "typeless", as in Smalltalk) where references (variables) have no type, but the objects (values) they point to always do. An untyped pointer (such as void* in C++) and an embedded dynamic typing scheme are used in more conventional languages to fully emulate this style of dynamically typed programming (see sections 2.3, 4.3, and [Coplien 92]). Below is a simple example to show a most trivial case of OO implementation. It is primarily intended to introduce new terms. See [Cardelli 85] for another semantic definition of OO using functions for methods and for a view of types as sets of values. Simple statically-typed objects (static and auto vars and temps in C++ and expanded types in Eiffel) can be viewed as instances of a record type, whose record fields are called instance variables (Smalltalk) or member data (C++). The record (class) may also contain operations which are called methods (Smalltalk) or member functions (C++) which are equivalent to a function taking an object of the record type, called the receiver, as the first parameter. The receiver is called self (Smalltalk) or this (C++). Members will denote both instance variables and methods. Inheritance is roughly equivalent to a loosely coupled variant record, with derived classes as variant parts and with multiple-inheritance concatenating several records to serve as a base. A virtual member in statically typed languages is a base class member that can be set or respecified by a derived class. This is roughly equivalent to a pointer or function pointer in the base class being set by the derived class. [Stroustrup 90] covers the implementation details of virtual member functions in C++, which also involve an offset for the receiver to handle multiple- inheritance. This is an example of dynamic binding, which replaces a switch statement on variant parts with a single call, reducing code size and program complexity (fewer nested programming constructs) and allowing variants to be added without modifying client code (which causes higher defect injection rates during maintanance and debugging). Virtual members in dynamically typed languages are more flexible because static typechecking requirements are dropped. See section 2.5. The terms method/member function, instance variable/member data, subclass/ derived class, parent class/base class, and etc. will be used interchangeably. As pointed out in [Stroustrup 90, p197], the base/derived class terminology may be preferable to the sub/super-class terminology, and is preferred in this document also. Delegation/prototyping languages [Kim 89, ch3; Ungar 87, Sciore 89] have a more flexible kind of object which can play the role of classes in classical OO languages. Since there is no separate class construct in these languages, and only objects, they are referred to as single-hierarchy, or 1 Level systems. Objects contain fields, methods and delegates (pseudo parents), whereas classical object-oriented languages associate method, field and parent definitions with classes (and only associate state and class with objects, although vtables of function pointers for dynamic binding are an exception). However, one-level objects often play the role of classes to take advantage of sharing and often instances will simply delegate to parents to access methods or shared state, otherwise idiosyncratic objects, a powerful and natural concept, will result. Typical 1 Level objects can contain any number of fields, methods and parents and any object can be used as a template/exemplar, thus performing the classical role of a class. In typical prototyping systems, parents (as any other member) can be added or changed dynamically, providing dynamic multiple inheritance (or more typically simple delegation). Here, the term "Prototype" usually refers to prototype theory, a recent theory of classification where any object can be inherited from or cloned to serve as a prototype for newly created instances. [The Author also uses the term for languages providing high quality support for rapid prototyping, although this usage is atypical] See [Booch 94, pp 154-155] for a brief discussion of prototype theory in the context of OOA and OOD. It is common in such systems for an object to "become" another kind of object by changing its parent. A good example is a window becoming an icon, as window and icon objects display different behavior (although cognitive differences are significant too:-) Delegation refers to delegating the search for an attribute to a delegate, and is therefore more of a pure message passing mechanism (as with dynamic scoping) than inheritance, which also typically specifies non-shared state when used for representation. Chambers has proposed an interesting variation called "Predicate Classes" [Chambers 93] as a part of his Cecil language. These classes will only be parents when certain predicates are true. This can support a types/classes as collections of objects view, which is the same as the types as sets of values view taken by [Cardelli 85]. [Martin 92] provides some examples of this view applied during OOA. 1 level systems therefore provide the most flexible and powerful capabilities. Self is a good example of a delegation-based single hierarchy language [Ungar 87]. 1.2) What Is Object Encapsulation (Or Protection)? --------------------------------------------------- [Booch 91, p. 45] defines: "Encapsulation is the process of hiding all of the details of an object that do not contribute to its essential characteristics." [Coad 91, 1.1.2] defines: "Encapsulation (Information Hiding). A principle, used when developing an overall program structure, that each component of a program should encapsulate or hide a single design decision... The interface to each module is defined in such a way as to reveal as little as possible about its inner workings. [Oxford, 1986]" Some languages permit arbitrary access to objects and allow methods to be defined outside of a class as in conventional programming. Simula and Object Pascal provide no protection for objects, meaning instance variables may be accessed wherever visible. CLOS and Ada allow methods to be defined outside of a class, providing functions and procedures. While both CLOS and Ada have packages for encapsulation, CLOS's are optional while Ada's methodology clearly specifies class-like encapsulation (Adts). However most object-oriented languages provide a well defined interface to their objects thru classes. C++ has a very general encapsulation/protection mechanism with public, private and protected members. Public members (member data and member functions) may be accessed from anywhere. A Stack's Push and Pop methods will be public. Private members are only accessible from within a class. A Stack's representation, such as a list or array, will usually be private. Protected members are accessible from within a class and also from within subclasses (also called derived classes). A Stack's representation could be declared protected allowing subclass access. C++ also allows a class to specify friends (other (sub)classes and functions), that can access all members (its representation). Eiffel 3.0 allows exporting access to specific classes. For another example, Smalltalk's class instance variables are not accessible from outside of their class (they are not only private, but invisible). Smalltalk's methods are all public (can be invoked from anywhere), but a private specifier indicates methods should not be used from outside of the class. All Smalltalk instance variables can be accessed by subclasses, helping with abstract classes and overriding. Another issue is per-object or per-class protection. Per-class protection is most common (e.g. Ada, C++, Eiffel), where class methods can access any object of that class and not just the receiver. Methods can only access the receiver in per-object protection. This supports a subtyping model, as any object other than the receiver is only satisfying an abstract type interface, whereby no method or object structure can be inferred in the general case. 1.3 What Is A Class? -------------------- A class is a general term denoting classification and also has a new meaning in object-oriented methods. Within the OO context, a class is a specification of structure (instance variables), behavior (methods), and inheritance (parents, or recursive structure and behavior) for objects. As pointed out above, classes can also specify access permissions for clients and derived classes, visibility and member lookup resolution. This is a feature-based or intensional definition, emphasizing a class as a descriptor/constructor of objects (as opposed to a collection of objects, as with the more classical extensional view, which may begin the analysis process). Original Aristotlean classification defines a "class" as a generalization of objects: [Booch 91, p93] "a group, set, or kind marked by common attributes or a common attribute; a group division, distinction, or rating based on quality, degree of competence, or condition". [Booch's definition in the context of OOD] "A class is a set of objects that share a common structure and a common behavior." "A single object is simply an instance of a class." The intension of a class is its semantics and its extension is its instances [Martin 92]. [Booch 94, 4.2] proposes 3 views of classification as useful in OO analysis and design: classical categorization (common properties), conceptual clustering (conceptual descriptions), and prototype theory (resemblance to an exemplar). He advocates starting with the former approach, turning to the second approach upon unsatisfactory results, and finally the latter if the first two approaches fail to suffice. 1.4) What Is A Meta-Class? --------------------------- [See also section 1.6] A Meta-Class is a class' class. If a class is an object, then that object must have a class (in classical OO anyway). Compilers provide an easy way to picture Meta-Classes. Classes must be implemented in some way; perhaps with dictionaries for methods, instances, and parents and methods to perform all the work of being a class. This can be declared in a class named "Meta-Class". The Meta-Class can also provide services to application programs, such as returning a set of all methods, instances or parents for review (or even modification). [Booch 91, p 119] provides another example in Smalltalk with timers. In Smalltalk, the situation is more complex. To make this easy, refer to the following listing, which is based on the number of levels of distinct instantiations: 1 Level System All objects can be viewed as classes and all classes can be viewed as objects (as in Self). There is no need for Meta-Classes because objects describe themselves. Also called "single-hierarchy" systems. There is only 1 kind of object. 2 Level System All Objects are instances of a Class but Classes are not accessible to programs (no Meta-Class except for in the compiler and perhaps for type-safe linkage, as in C++). There are 2 kinds of distinct objects: objects and classes. 3 Level System All objects are instances of a class and all classes are instances of Meta-Class. The Meta-Class is a class and is therefore an instance of itself (really making this a 3 1/2 Level System). This allows classes to be first class objects and therefore classes are available to programs. There are 2 kinds of distinct objects (objects and classes), with a distinguished class, the metaclass. 5 Level System What Smalltalk provides. Like a 3 Level System, but there is an extra level of specialized Meta-Classes for classes. There is still a Meta-Class as in a 3 Level System, but as a class it also has a specialized Meta-Class, the "Meta-Class class" and this results in a 5 Level System: object class class class (Smalltalk's Meta-Classes) Meta-Class Meta-Class class The "class class"es handle messages to classes, such as constructors and "new", and also "class variables" (a term from Smalltalk), which are variables shared between all instances of a class (static member data in C++). There are 3 distinct kinds of objects (objects, classes, and metaclasses). 1.5) What Is The Infinite Regress Of Objects And Classes? ---------------------------------------------------------- In the authors opinion, a myth. The story goes an object is an instance of a class (Meta-Object), a class is an instance of a Meta-Class, which must also be an instance of a Meta-Meta-Class, which must also be an instance of a Meta- Meta-Meta-Class, ... Closure can be achieved with an instance-of loop, as with a Meta-Class being an instance of itself or with a "Meta-Class - Meta-Class class" instance-of loop (as in Smalltalk). 1.6) What Are MOPs And Reflection? ----------------------------------- MOP is an acronym for Meta-Object Protocol. This is a system with Meta-Classes accessible to users [Kiczales 92, Paepcke 93]. In CLOS terminology, an introspective protocol provides a read only capability (e.g. what is this object's class, give info on this class, etc.) and an intercessory protocol provides a write capability which allows system modification (e.g. add the following method or instance to this class, perform inheritance this way, etc.). Because inheritance can be used to perform differential changes, intercessory protocols allow users to not only define new frameworks but to specialize existing system frameworks differentially without affecting them and their extant objects. Thus, many frameworks can interoperate together simultaneously. This is a good example of object-oriented reuse, since the compiler itself is reused thru specialization to provide new frameworks. "Reflective" systems are systems with MOPs (not to be confused with reflexive systems, which often refer to systems implemented in terms of themselves, or bootstrapped). Reflective systems are inevitably reflexive (as are most quality compilers), providing a direct program interface to the system. 1.7) What Is Inheritance? -------------------------- Inheritance provides a natural classification for kinds of objects and allows for the commonality of objects to be explicitly taken advantage of in modeling and constructing object systems. Natural means we use concepts, classification, and generalization to understand and deal with the complexities of the real world. See the example below using computers. Inheritance is a relationship between classes where one class is the parent (base/superclass/ancestor/etc.) class of another. Inheritance provides programming by extension (as opposed to programming by reinvention [LaLonde 90]) and can be used as an is-a-kind-of (or is-a) relationship or for differential programming. Inheritance can also double for assignment compatibility (see section 2.7). In delegation languages, such as Self, inheritance is delegation where objects refer to other objects to respond to messages (environment) and do not respecify state by default. Inherited parents can specify various flavors of state. Delegation languages don't specify new state by default (to do so requires cloning), C-based (C++, Objective-C, etc.), lisp-based (CLOS, Flavors, Scheme, etc.), and Pascal-based (Ada95, Modula-3, Object Pascal, etc.) OO languages do, but with multiple- inheritance can also share parents within a class lattice (CLOS and Eiffel provide this as a default at the level of slots and features, respectively). Inheritance also provides for member lookup, or internal environment. Various schemes exist, for example C++ finds the closest match within a scope but causes an ambiguity error iff more than one parent has match, CLOS creates a linear precedence list, Self provides parent priorities, and Eiffel forces renaming for any parent member conflicts. Defining inheritance (with a thorough description or denotational semantic definition, or both) can avoid confusion about which inheritance scheme is being used (especially in OOD), because inheritance has many variations and combinations of state and environment (sometimes with complex rules). Inheritance can also be used for typing, where a type or class can be used to specify required attributes of a matching object (see sections 2.1, 2.7 and [Cardelli 85]). It would be more judicious to have discussions on how inheritance should be defined instead of over what it is, since it has many existing uses and semantics. An example of the is-a-kind-of relationship is shown below. Is-a is often used synonymously, but can be used to show the "object is-a class" instantiation relationship. In classical OO, inheritance is a relationship between classes only. In one-level systems, is-a (object instantiation) and is-a-kind-of (inheritance) are merged into one [Ungar 87, Madsen 93, Sciore 89]. Computer / | \ Mainframe Mini Personal / \ ... / \ Data Proc Scientific PC Workstation Class hierarchies are subjective [Booch 91, 4.2; Lakoff 87] and usually drawn with the parent class on top, but more demanding graphs (as is often the case in [Rumbaugh 91]) allow any topology, with the head of an arrow indicating the base class and the tail indicating the derived class. Differential programming is the use of inheritance to reuse existing classes by making a small change to a class. Creating a subclass to alter a method or to add a method to a parent class is an example. 1.8) What Is Multiple Inheritance? ----------------------------------- Multiple Inheritance occurs when a class inherits from more than one parent. For example, a person is a mammal and an intellectual_entity, and a document may be an editable_item and a kind of literature. Mixin's is a style of MI (from flavors) where a class is created to provide additional attributes or properties to other classes. They are intended to be inherited by any class requiring them. Method combination, or calling sequences of before, after, and around methods or even several primary methods [Kim 89, ch 4], make good use of mixins by invoking their methods without explicitly calling them, allowing client class code to remain unchanged [Booch 91, p 113]. 1.9) Does Multiple Inheritance Pose Any Additional Difficulties? ----------------------------------------------------------------- Yes, it does. Any name can be simply resolved to a class member with single inheritance by simply accessing the first name encountered for data members and by accessing the first signature match (or ambiguity) encountered for methods (at least one way, C++ hides some member functions). Since several distinct parents can declare a member within a multiple inheritance hierarchy, which to choose becomes an issue. Eiffel forces derived classes to rename parent members that conflict. Self prioritizes parents. CLOS merges member "slots" (instance variables) with the same name into a single slot, as did the earlier flavors. C++ declares an error iff a conflict arises, but a class qualifier can be used to explicitly disambiguate. Smalltalk renders same names for instance variables of subclasses illegal. On the other hand, multiple-inheritance can be seen as required for basic object-oriented programming, because many objects in the real world belong to several classes. In classical systems without MI, a class which should inherit from more than one class must textually include all but one of those classes in its interface, causing code duplication (and a messy interface). 1.10) What Is Dynamic Inheritance? ----------------------------------- Dynamic inheritance allows objects to change and evolve over time. Since base classes provide properties and attributes for objects, changing base classes changes the properties and attributes of a class. A previous example was a window changing into an icon and then back again, which involves changing a base class between a window and icon class. More specifically, dynamic inheritance refers to the ability to add, delete, or change parents from objects (or classes) at run-time. Actors, CLOS, and Smalltalk provide dynamic inheritance in some form or other. Single hierarchy systems, such as Self, provide dynamic inheritance in the form of delegation [Ungar 87]. See also [Kim 89, chs 1, 3] for a discussion and [Coplien 92] for some implementation discussion in C++. 1.11) What Is Shared (Repeated) Inheritance? --------------------------------------------- Multiple Inheritance brings up the possibility for a class to appear as a parent more than once in a class graph (repeated inheritance), and there is then a potential to share that class. Only one instance of the class will then appear in the graph (as is always the case in CLOS, because all *members* with the same name will be shared (receive a single slot) with the greatest common subtype as its type). C++ provides an alternative, where only parents specified as virtual (virtual bases) are shared within the same class lattice, allowing both shared and non-shared occurrences of a parent to coexist. All "features" in Eiffel (C++ members) of a repeated parent that are not to be shared must be renamed "along an inheritance path", else they are shared by default. This allows a finer granularity of control and consistent name resolution but requires more work for parents with many features. 1.12) Why Use Inheritance? --------------------------- Inheritance is a natural way to model the world or a domain of discourse, and so provides a natural model for OOA and OOD (and even OOP). This is common in the AI domain, where semantic nets use inheritance to understand the world by using classes and concepts for generalization and categorization, by reducing the real-world's inherent complexity. Inheritance also provides for code and structural reuse. In the above Computer class diagram, all routines and structure available in class Computer are available to all subclasses throughout the diagram. All attributes available in Personal computers are also available to all of its subclasses. This kind of reuse takes advantage of the is-a-kind-of relationship. Class libraries also allow reuse between applications, potentially allowing order-of-magnitude increases in productivity and reductions in defect rates (program errors), as library classes have already been tested and further use provides further testing providing even greater reliability. With differential programming, a class does not have to be modified if it is close to what's required; a derived class can be created to specialize it. This avoids code redundancy, since code would have to be copied and modified otherwise. See [Raj 89] for an alternative approach as found in Jade. Polymorphism is often explicitly available in many OO languages (such as C++, CLOS, Eiffel, etc.) based on inheritance when type and class are bound together (typing based on subclassing, or subclass polymorphism), since only an object which is a member of (inherits from) a class is polymorphically assignment compatible with (can be used in place of) instances or references of that class. Such assignment can result in the loss of an object's dynamic type in favor of a static type (or even loss of an object's representation to that of the static class, as in C++ slicing). Maintaining the dynamic type of objects can be provided (and preferred); however, C++ provides both sliced and non- sliced replacement in a statically typed environment (see section 2.1). 1.13) Why Don't Some People Like Inheritance? ---------------------------------------------- Some people complain that inheritance is hierarchical (which is what most object-oriented languages provide). They would also like to see more operations available (set operations are quite common in specialized systems). The former is a kind of language dependent feature commonly found in object- oriented languages which are then associated with the term "inheritance" (although they don't need to be. For example, delegation languages allow graph inheritance stuctures). Some don't like the coupling of classes (as in Jade), but in the author's opinion many of their complaints are easily answered. In systems that provide inheritance, inheritance provides a simple and elegant way to reuse code and to model the real world in a meaningful way. Others complain multiple inheritance is too complicated because it brings up the issues of shared bases and member conflict resolution. But most modern systems support Multiple Inheritance by employing semantic resolution strategies or renaming, and most consider MI to be highly desirable. See the latter part of section 1.9 for an example of why MI is important. Some prefer association to MI, claiming "roles" (as defined in [Rumbaugh 91]) should be associations and inheritance should be reserved for a single hierarchy "creation" mechanism, however this loses polymorphism and loses the use of inheritance for typical classification. Representation "roles" can be supported by dynamic multiple inheritance (DMI) in many situations. 1.14) What Is Specialization/Generalization/Overriding? -------------------------------------------------------- To create a subclass is specialization, to factor out common parts of derived classes into a common base (or parent) is generalization [Booch 91, p56]. Overriding is the term used in Smalltalk and C++ for redefining a (virtual in Simula and C++) method in a derived class, thus providing specialized behavior. All routines in Smalltalk are overridable and non- "frozen" features in Eiffel can be "redefined" in a derived class. Whenever a method is invoked on an object of the base class, the derived class method is executed overriding the base class method, if any. Overriding in Simula is a combination of overloading and multiple-polymorphism because parameters do not have to be declared. Eiffel and BETA are examples of languages allowing any member to be redefined and not just methods, as is typical. 1.15) What Is The Difference Between Object-Based And Object-Oriented? ----------------------------------------------------------------------- Object-Based Programming usually refers to objects without inheritance [Cardelli 85] and hence without polymorphism, as in '83 Ada and Modula-2. These languages support abstract data types (Adts) and not classes, which provide inheritance and polymorphism. Ada95 and Modula-3; however, support both inheritance and polymorphism and are object-oriented. [Cardelli 85, p481] state "that a language is object-oriented if and only if it satisfies the following requirements: - It supports objects that are data abstractions with an interface of named operations and a hidden local state. - Objects have an associated type. - Types may inherit attributes from supertypes. object-oriented = data abstractions + object types + type inheritance These definitions are also found in [Booch 91, Ch2 and Wegner 87]. [Coad 91] provides another model: Object-Oriented = Classes and Objects + Inheritance + Communication with messages Stroustrup's first edition of [Stroustrup 91, '86 p. 37] defines object based as: "... storing type identification in each object, brings us to a style of programming often referred to as "object based"", which is quite different from C+W's. A more modern definition of "object-oriented" includes single-hierarchy languages and perhaps object id's for unique objects. Object id's support the modern notion of relocatable, persistent and distributed objects that can even migrate across machines. Distributed Smalltalk's proxy objects [Kim 89, ch 19 and Yaoqing 93] provide another example of a distributable and migratable object facility. Separate type system support is another extension. [Booch 94, 2.2] proposes 7 "Elements of the Object Model"; 4 major and 3 minor: Major: Abstraction Encapsulation Modularity Hierarchy (Inheritance) Minor: Typing Concurrency Persistence 1.16) Is A Class An Object? ---------------------------- In C++ no, because C++ classes are not instances of an accessible class (a Meta-Class) and because C++ classes are not accessible to programs. Classes are objects in 3 Level Systems and above because classes are instances of meta-classes. But classes play a dual role, because objects can only be declared to be instances of a class (and class objects instances of a meta-class). In 1 Level (single-hierarchy) systems, all classes are objects. 1.17) Is An Object A Class? ---------------------------- In a Level 3 System and above yes, but only instances of a Meta-Class are Classes. Instances of a Class (ordinary objects) are not classes (excluding hybrid systems). However, all objects may be classes in single hierarchy systems, since any object may act as a class (provide object instantiation or act as a shared parent). 1.18) What Is A Method? (And Receiver And Message) --------------------------------------------------- A method implements behavior, which is defined by [Booch 91, p80]: Behavior is how an object acts and reacts, in terms of its state changes and message passing. A method is a function or procedure which is defined in a class and typically can access the internal state of an object of that class to perform some operation. It can be thought of as a procedure with the first parameter as the object to work on. This object is called the receiver, which is the object the method operates on. An exception exists with C++'s static member functions which do not have a receiver, or "this" pointer. The following are some common notations for invoking a method, and this invocation can be called a message (or message passing, see below): receiver.message_name(a1, a2, a3) receiver message_name: a1 parm1: a2 parm3: a3 Selector would be another good choice for message_name in the above examples, although keywords (or formal parameter names, like named parameters) are considered part of the selector in Smalltalk (and hence Objective-C). If done statically, this can be referred to as invocation, and message passing if done dynamically (true dynamic binding). Statically typed dynamic binding (e.g. C++ and Eiffel) is really in between (checked function pointers). See also section 1.19 below for a discussion on the functional (prefix) verses message based (receiver based) notation. 1.19) What Are Multi-Methods And Multiple-Polymorphism? -------------------------------------------------------- Multi-methods involve two primary concepts, multiple-polymorphism and lack of encapsulation. These issues are orthogonal. Multiple-polymorphism implies more than one parameter can be used in the selection of a method. Lack of encapsulation implies all arguments can be accessed by a multi-method (although packages can be used to restrict access, as in CLOS). Multi-methods can also imply a functional prefix notation, although the CLOS designers (who coined the term "multi-method") consider the functional and receiver based forms (messages) equivalent. Functional syntax was chosen "in order to minimize the number of new mechanisms added to COMMON LISP" [Kim ch 4, p70 (D. Moon)]. [Chambers 93] discusses multi-methods in his new OO language, Cecil. Multiple-polymorphism allows specialized functions or methods to be defined to handle various cases: +(int, int) +(int, float) +(int, complex) +(int, real) +(float, complex) +(float, real) +(float, float) The above functions are specialized to each of the cases required allowing single, highly cohesive and loosely coupled functions to be defined. This is also the true essence of object-oriented polymorphism, which allows objects to define methods for each specific case desired. In addition to better coupling and cohesion, multiple-polymorphism reduces program complexity by avoiding coding logic (switch statements) and because small methods further reduce complexity, as code complexity doesn't grow linearly with lines of code per method, but perhaps exponentially. This should be distinguished from double dispatch, a fancy name for single dispatch after a call, which only provides switching on a single argument per call (but for 2 levels), consistently ignoring the inherent type of parameters in messaging. Double dispatch is used in languages with static typing for simplicity and efficiency considerations. If all of the above types are Numbers, code can be written without concern for the actual classes of objects present: fn(one, two: Number): Number return one + two; The addition expression above will invoke the correct "+" function based on the inherent (true, actual, or dynamic) types of one and two. Only the inherent type of "one" would be used with double dispatch! In the author's opinion, this is a serious shortcoming. Further, double dispatch would only allow switching to the "fn" function based on the type of "one" also. This could lead to the use of switch statements based on type or complex coding in many real-world programming situations, unnecessarily. In the author's opinion, this should only be used as necessary, e.g. if the implementation language doesn't support multiple-polymorphism and either efficiency considerations dominate and double dispatch can be suffered, or an embedded dynamic typing scheme is used. Why do multi-methods allow open access to parameters? It allows efficient handling, like C++ friends, usually by allowing representation details of more than one object to be exposed. See [Kim ch 4, pp70-71 (D. Moon)] for an alternative explanation. While open access can be useful in some cases, it typically isn't recommended as a general OO practice (see section 1.15, C+W's requirement 1 for OO languages and Section 1.2 on Encapsulation) and also violates subtype polymorphism, because only subclass polymorphism is based on representation and not type. Polymorphic languages can be statically typed to provide strong type checking, efficiency, and to support a static programming idiom, but require restrictions in many cases, such as requiring overriding methods to have identical signatures with the methods they substitute (as in C++) or allowing covariant parameters but limiting base class usage (as in Eiffel). If these restrictions are dropped, multiple-polymorphism results. Thus a single overridable function declared in a base class may have several functions overriding it in a derived class differentiated only by their formal argument types. This therefore requires both static and dynamic typing, because no formal argument differentiation is possible without static types, as in Smalltalk, and no actual argument differentiation is possible without dynamic types (as in C++ and Eiffel). See section 2.3 for another example of multiple-polymorphism. There is some concern about the efficiency of run-time method selection as can occur with multiple-polymorphism (or even dynamic message passing). However, static analysis optimizations are commonly available in the literature, potentially providing a single static selection in many cases [See Agrawal 91, Chambers 92, Mugridge 91, and etc.]. But coupling the two cases of selector variables (as found in CLOS, Objective-C, and etc.) and several possible known selectors together with the general undecidability of dynamic types at compile-time renders dynamic typing and run-time selection (or checking) as unavoidable in the general case [a point often mistaken in comp.object. E.g. simple statically/strongly typed multi-methods still require dynamic types!] See [Booch 91], multiple-polymorphism, for a good CLOS example. 1.20) What Is OOP? ------------------- OOP stands for Object-Oriented Programming, the usual programming/hacking and etc. most programmers think of. Modern software engineering methodologies; however, consider OOP as the implementation/evolution of an OOD. 1.21) What Is OOA/OOD (And Where Can I Get What I Need On It)? --------------------------------------------------------------- See also section 3.7, the Annotated Bibliography, and APPENDIX D. The classified bibliography in [Booch 94] also contains entries on OOA(B), OOD(F) and OOP(G). [Booch 91] "In OOA, we seek to model the world by identifying the classes and objects that form the vocabulary of the problem domain, and in OOD, we invent the abstractions and mechanisms that provide the behavior that this model requires." [Coad 91] "OOA is the challenge of understanding the problem domain, and then the system's responsibilities in that light". "To us, analysis is the study of a problem domain, leading to a specification of externally observable behavior; a complete, consistent, and feasible statement of what is needed; a coverage of both functional and quantified operational characteristics (e.g. reliability, availability, performance)". "Design. The practise of taking a specification of externally available behavior and adding details needed for actual computer system implementation, including human interaction, task management, and data management details." And on Domain Analysis: "Whereas OOA typically focuses upon one specific problem at a time, domain analysis seeks to identify the classes and objects that are common to all applications within a given domain, [...]". - [Booch 91] [The following quotes on domain analysis are from [Berard 93]] "An investigation of a specific application area that seeks to identify the operations, objects, and structures that commonly occur in software systems within this area. - Dan McNicholl "Systems analysis states what is done for a specific problem in a domain while domain analysis states what can be done in a range of problems in a domain. ...A domain analysis is only useful in many similar systems are to be built so that the cost of the domain analysis can be amortized over the cost of all the systems. The key to reusable software is captured in domain analysis in that it stresses the reusability of analysis and design, not code. - Jim Neighbors "The process of identifying, collecting, organizing, and representing the relevant information in a domain based on the study of existing systems and their development histories, knowledge captured from domain experts, underlying theory, and emerging technology within the domain." - Kang et al. Object-oriented domain analysis (OODA) seeks to identify reusable items localized around objects, e.g., classes, instances, systems of interacting objects, and kits [frameworks]. OORA analysts and OOD designers will interact on a fairly frequent basis with the domain analysis effort. OOA and OOD stand for Object-Oriented Analysis and Object-Oriented Design, respectively. OOA strives to understand and model, in terms of object-oriented concepts (objects and classes), a particular problem within a problem domain (from its requirements, domain and environment) from a user-oriented or domain expert's perspective and with an emphasis on modeling the real-world (the system and its context/(user-)environment). The product, or resultant model, of OOA specifies a complete system and a complete set of requirements and external interface of the system to be built, often obtained from a domain model (e.g. FUSION, Jacobson), scenarios (Rumbaugh), or use-cases (Jacobson). [Shlaer 88] is often credited as the first book on OOA, although their method adds OO techniques to the traditional structured analysis principles of Yourdon and Constantine. Their complete approach ([Shlaer 88, 92]) consists of information modeling and recursive design, or OOA/RD and represents a recent addition to the structured analysis family (as does Martin and Odell). [Yourdon 92] provides a critique, although may only refer to their earlier work. Many other methodologies including Rumbaugh's OMT, Martin and Odell's OOA/D, and many others, also share common ground with SA and other existing analysis methodologies with such constructs as associations (E-R), functional models, and even DFD's. Booch, Jacobson, and Wirfs-Brock are examples of OO methodologies representing a greater departure from the conventional "structured" techniques, with greater emphasis on objects. OOram [Reenskaug 91] provides support and emphasis on types and roles as guiding principles, which is quite powerful. [Booch 94] presents a methodology which is an evolutionary step beyond the first edition by incorporating a collection of the best features from several of the major OO methodologies, as does HP's new FUSION methodology. A new Unified Modeling Language (previously Unified Method) is now being worked on by Grady Booch, James Rumbaugh, and Ivar Jacobson at Rational Software which should be made into a public standard, perhaps to be adopted by the OMG. The .8 docs can be found online from the Rational home page, http:/www.rational.com. The usual progression is from OOA to OOD to OOP (implementation) and this Universal Process Model roughly corresponds to the Waterfall Model [Royce 70]. See [Humphrey 89] and [Yourdon 92] for a few of many discussions on software life-cycle models and their use. Humphrey also details Worldy and Atomic Process Models for finer grained analysis and design in the Defined Process (see below) and discusses other alternatives to the task oriented models. He also provides the following critisisms on the Waterfall Model which had led to Boehm's seminal work on the Spiral Model: * It does not adequately address changes * It assumes a relatively uniform and orderly sequence of development steps * It does not provide for such methods as rapid prototyping or advanced languages Modern OO methodologies directly address these points and emphasize the incremental, iterative, evolutionary, concurrent and situational nature of software development. [Boehm 86] presents a seminal spiral life-cycle model with a risk-driven incremental prototyping approach. [Booch 91, 6.1] proposes a "round-trip gestalt" design with analyze-design iterations and an overall system perspective and [Berard 93] proposes an (incremental) "parallel-recursive design" with analyze-design-implement-test iterations. [Coad 91b] presents the following development cycle breakdown: Waterfall- Analysis Design Programming Spiral- Analysis, prototyping, risk management Design, prototyping, risk management Programming, prototyping, risk management [Boehm, 1988] Incremental- A little analysis A little design A little programming Repeat [Gilb, 1988] [Author's note: The spiral model is often incremental and may waterfall if called for.] Since classes and objects are used in all phases of the OO software life-cycle, the process is often referred to as seamless, meaning there is no conceptual gap between the phases as is often the case in other software development methodologies, such as the analysis (DFD's) to design (structure charts) to programming gaps found in traditional structured analysis and design. Seamlessness together with naturalness is a big advantage for consistency. A problem domain has many realizations, or differing OOAs. An OOA has many realizations, or differing OODs, but a similar notation is often used for the two. An OOD also has many realizations, or differing OOPs, but allows a selection from among various languages for implementation (choosing the best language to implement the design). But some, such as Bjarne Stroustrup, don't like OOA and OOD getting too far from OOP (implementation independent), for fear that great discrepancies could occur between OOD and OOP by losing sight of the implementation language, which in some cases is predetermined. See also [Stroustrup 91]. From a greater perspective, the SEI has developed the Capability Maturity Model (CMM), a process-based TQM model for assessing the level of an organization's software development and which is often required of government contractors in the US [Humphrey 89]. The CMM also serves as a 5 level improvement process by specifying steps for organizations to progress to the next level, ultimately leading to statistical (process) control and sustained improvement. Watts S. Humphrey is now working on the Personal Software Process (PSP), a scaled down version of the CMM for individuals [Humphrey 95]. Next should follow a team- based software process (TSP?). Other CMM's in the works at the SEI include a personnel management CMM (PM-CMM). Level 1: Initial: Every project is handled differently; ad hoc and chaotic. Level 2: Repeatable: Every project is handled similarly. Level 3: Defined: Standard processes are defined and used for all projects. Level 4: Managed: A measurable basis for all improvements to the process. Level 5: Optimizing: Emphasis on defect prevention and optimizing/continually improving the process. CMM documentation is available online from: http://ricis.cl.uh.edu/CMM and ftp.sei.cmu.edu/pub/cmm/ See also: Kitson, D.H. and Masters, S. "An Analysis of SEI Software Process Assessment Results 1987-1991", CMU/SEI-92-TR-24 Humphrey, W., Snyder, T. and Willis, R. "Software Process Improvement at Hughes Aircraft", IEEE Software, July 1991 Dion, R., "Elements of a Process Improvement Program," IEEE Software, July 1992. "Concepts on Measuring the Benefits of Software Process Improvement," CMU/SEI-93-TR-9. See also [Yourdon 92], [Wilkie 93], and [Booch 94] for discussions on this often cited model. There is also an ISO 9000 standard [ISO] applicable to software quality and ami working group in Europe helping to creat the ISO SPICE [Rout 95] standard (among other work), which is similar in scope to the CMM. To join the ami mailing list email to: ami-request@aut.alcatel.at with the following message: subscribe firstname, lastname, e-mail address. Object-oriented analysis now includes "Enterprise Modeling" [Martin 92], also found in [Jacobson 92], and along with recent business process "reengineering" efforts places information systems within an organizational perspective by modeling entire organizations or a large part of them, with the information processing system and software products development as integrated components. [Yourdon 92] even calls for "global modeling"! 1.22) Where Did Object-Orientation Come From? ---------------------------------------------- Simula was the first object-oriented language providing objects, classes, inheritance, and dynamic typing in 1967 (in addition to its Algol-60 subset). It was intended as a conveyance of object-oriented design. Simula 1 was a simulation language, and the later general-purpose language Simula 67 is now referred to as simply Simula. Smalltalk was the next major contributor including classes, inheritance, a high-powered graphical environment and a powerful dynamic typing mechanism (although these existed to some extent in Simula). Self is somewhat of a Smalltalk-based next generation language, as is BETA a followup to Simula (by its original designers). [Meyer 88] contains a brief summary and history of Simula and Smalltalk, among other OO languages. 1.23) What Are The Benefits Of Object-Orientation? --------------------------------------------------- Reuse, quality, an emphasis on modeling the real world (or a "stronger equivalence" with the RW than other methodologies), a consistent and seamless OOA/OOD/OOP package, naturalness (our "object concept"), resistance to change, encapsulation and abstraction (higher cohesion/lower coupling), and etc. On resistance to change, system objects change infrequently while processes and procedures (top-down) are frequently changed, providing object-oriented systems with more resilient system organization. [Harmon 93]: Faster development Increased Quality Easier maintenance Enhanced modifiability [Booch 94]: Exploit power of OOPs Reuse of software and designs, frameworks Systems more change resilient, evolvable Reduced development risks for complex systems, integration spread out Appeals to human cognition, naturalness 1.24) What Other FAQs Are Available? ------------------------------------- FAQ's are cross-posted to news.answers and are archived on anonymous ftp from: rtfm.mit.edu:/pub/usenet (also usenet-by-hierarchy, etc.) rtfm archives several FAQs pertinent to OO (alternative/original sites are listed). comp.lang.ada ajpo.sei.cmu.edu:public/comp-lang-ada/cla-faq[12] comp.lang.beta ftp.daimi.aau.dk:pub/beta/faq/beta-language-faq.txt comp.lang.c++ sun.soe.clarkson.edu:pub/C++/FAQ [128.153.12.3] comp.lang.clos comp.lang.eiffel ftp.cm.cf.ac.uk:/pub/eiffel/eiffel-faq comp.lang.modula3 comp.lang.oberon comp.lang.objective-c http://www.marble.com/people/dekorte/Objective-C/objc.html comp.lang.sather ftp.ICSI.Berkeley.EDU:pub/sather [not on rtfm] comp.lang.scheme ftp.think.com:/public/think/lisp/scheme-faq.text comp.lang.smalltalk xcf.Berkeley.EDU:misc/smalltalk/FAQ/SmalltalkFAQ.entire comp.object zaphod.uchicago.edu:/pub/CompObj8.faq(.Z) (also www) comp.object.logic ftp.cs.cmu.edu:(2)prg_1.faq,prg_2.faq [128.2.206.173] comp.software-eng Notes: 1) xcf.Berkeley.EDU is 128.32.138.1 2) /afs/cs.cmu.edu/project/ai-repository/ai/pubs/faqs/prolog/ 3) BETA FAQ www (most current): http://www.daimi.aau.dk/~beta/FAQ http://www.daimi.aau.dk/~beta/info Email: info@mjolner.dk with body: send BETA beta-faq 4) Modula-3: ftp.vlsi.polymtl.ca:pub/m3/m3-faq.ps. http://froh.vlsi.polymtl.ca/m3/m3-faq.html. Archives: gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3 Newsgroup relay mailing list; message to m3-request@src.dec.com 5) comp.lang.eiffel archive: http://www.cm.cf.ac.uk/CLE/archive_index.html See APPENDIX E:60 for a CDROM with Internet FAQs. A new C++ libraries FAQ is posted monthly to comp.lang.c++ and should be on rtfm soon. Contact cpplibs@trmphrst.demon.co.uk. It contains anonymous ftp sites and commercial libraries and may be merged with this FAQ eventually. Many FAQs are also available from mail-servers, however most can be accessed by the rtfm mail-server. Mail to mail-server@rtfm.mit.edu with help and index in the body with no leading spaces and on separate lines for more information. Example Unix Command (will retrieve this FAQ in about 26 pieces (and growing)): mail mail-server@rtfm.mit.edu Subject: send usenet/comp.object/* There is also a great ftp site for sci.virtual-worlds on: stein.u.washington.edu (140.142.56.1) - home of sci.virtual-worlds, huge faq w/ great info! - if unable to use try ftp.u.washington.edu /public/virtual-worlds [While VR may not be directly related to comp.object, it is most interesting! - The Author] SECTION 2: TYPING ================== There are many definitions of type (and class and related concepts). Many authors define the terms as applied by their particular approach or language, however we shall proceed in the face of this diversity. References [Blair 89] Some Typing Topics. [Booch 91] Small Section on Typing. [Cardelli 85] Discussion on Object-Oriented Typing. [Gunter 94] Theoretical Aspects of Object-Oriented Programming. [Kim 89, ch1] Discussion on Some Research Topics. 2.1) What Is Polymorphism? --------------------------- Polymorphism is a ubiquitous concept in object-oriented programming and is defined in many ways, so many definitions are presented from: Websters', Author, Strachey, Cardelli and Wegner, Booch, Meyer, Stroustrup, and Rumbaugh. Polymorphism is often considered the most powerful facility of an OOPL. > Webster's New World Dictionary: Polymorphism 1. State or condition of being polymorphous. 2. Cryall. crystallization into 2 or more chemically identical but crystallographically distinct forms. 3. Zool., Bot. existence of an animal or plant in several forms or color varieties. polymorphous adj. having, assuming, or passing through many or various forms, stages, or the like. Also, polymorphic. [ Author's Definition: Polymorphism is the ability of an object (or reference) to assume (be replaced by) or become many different forms of object. Inheritance (or delegation) specifies slightly different or additional structure or behavior for an object, and these more specific or additional attributes of an object of a base class (or type) when assuming or becoming an object of a derived class characterizes object-oriented polymorphism. This is a special case of parametric polymorphism, which allows an object (or reference) to assume or become any object (possibly satisfying some implicit or explicit type constraints (parametric type), or a common structure), with this common structure being provided by base classes or types (subclass and subtype polymorphism, respectively). "Poly" means "many" and "morph" means "form". The homograph polymorphism has many uses in the sciences, all referring to objects that can take on or assume many different forms. Computer Science refers to Strachey's original definitions of polymorphism, as divided into two major forms, parametric and ad-hoc. Cardelli and Wegner followup with another classification scheme, adding inclusion polymorphism for subtyping and inheritance. > Strachey's Original Definition [Strachey 67]: "Parametric polymorphism is obtained when a function works uniformly on a range of types; these types normally exhibit some common structure. Ad-hoc polymorphism is obtained when a function works, or appears to work, on several different types (which may not exhibit a common structure) and may behave in unrelated ways for each type." Parametric polymorphism is also referred to as "true" polymorphism, whereas ad-hoc polymorphism isn't (apparent polymorphism). > Cardelli and Wegner's Definition [Cardelli 85]: C+W refine Strachey's definition by adding "inclusion polymorphism" to model subtypes and subclasses (inheritance). Strachey's parametric polymorphism is divided into parametric and inclusion polymorphism, which are closely related, but separated to draw a clear distinction between the two forms, which are then joined as specializations of the new "Universal" polymorphism. |-- parametric |-- universal --| | |-- inclusion polymorphism --| | |-- overloading |-- ad hoc --| |-- coercion Polymorphic Languages: some values and variables may have more than one type. Polymorphic Functions: functions whose operands (actual parameters) can have more than one type. [...] If we consider a generic function to be a value, it has many functional types and is therefore polymorphic. Polymorphic Types: types whose operations are applicable to operands of more than one type. Parametric Polymorphism: a polymorphic function has an implicit or explicit type parameter which determines the type of the argument for each application of that function. Inclusion Polymorphism: an object can be viewed as belonging to many different classes that need not be disjoint; that is, there may be inclusion of classes. The two forms of "Universal Polymorphism", parametric and inclusion are closely related, but are distinct enough in implementation to justify separate classifications. Parametric polymorphism is referred to as generics. Generics can be syntactic, where each instantiation creates a specialized version of the code allowing fast running execution, but in a "true polymorphic system", only a single implementation is used. On inheritance is subtype polymorphism: "Subtyping on record types corresponds to the concept of inheritance (subclass) in languages, especially if records are allowed to have functional components." Author's Notes: Implicit parametric polymorphism can be implemented with type inferencing schemes [Aho 85]. ML is prototypical in providing this facility. Inclusion polymorphism is common and is found in languages such as Simula, Ada95, C++, CLOS, Eiffel and etc. (subclass polymorphism). Smalltalk also uses inclusion polymorphism; its used in declaring classes, and subclass polymorphism is used in practice but not enforced. For inheritance, inclusion polymorphism specifies an instance of a subclass can appear wherever an instance of a superclass is required. For subtyping (subtype polymorphism), the same applies because all operations required by the supertype are present in the subtype (subtype is subset of supertype). Cardelli and Wegner view classes as sets of objects (resulting in subtype objects are a subset of supertype objects, or an extensional view), as contrasted with a feature based (intensional) approach (where subtypes are supersets of (contain) supertypes). MI provides an interesting example here, as it is set intersection with an extensional view and set union with an intensional view. Details are left as an exercise for the reader. Ada generics and C++ templates provide explicit syntactic generics. While Ada may infer some actual generic parameters (operations) and C++ doesn't require explicit instantiation of its template functions, formal generic parameters must still be declared and many bodies are generated. Inclusion polymorphism can refer to subtyping, or having at least as much or more than required. Since derived classes can inherit structure and behavior from base classes, such inheritance is an example of inclusion polymorphism with respect to representation (subclassing). An example of inclusion polymorphism with respect to assignment (and initialization, or replacement if viewed in an almost symbolic way) occurs when object types may be specified and assignment is based on actual object membership in that type (often of the CLOS is-a-member-of form in OO). Emerald provides another example of an object- oriented language using inclusion polymorphism with respect to replacement; however, inclusion is with respect to subtyping only with abstract types ("bounded quantification" by C+W. C+W's parameters are subtype polymorphic but lose the inherent type). Any object possessing all required operations is acceptable and no inheritance relation is required (subtype polymorphism). They refer to this as "best-fitting" types [Black 86]. The original Trellis/ Owl also had such a facility but with two separate inheritance hierarchies, although it was abandoned in favor of a single class-based approach for simplicity. See also section 2.7. [As inclusion polymorphism covers both subtype and subclass polymorphism, perhaps IP could be further divided in C+W's above classification.] > Booch's Definition [Booch 91, p. 517]: polymorphism A concept in type theory, according to which a name (such as a variable declaration) may denote objects of many different classes that are related by some common superclass; thus, any object denoted by this name is able to respond to some common set of operations in different ways. Booch also has several sections devoted to polymorphism. [The author notes Booch's definition above is clearly in the context of conventional, classical OO and subclass polymorphism.] > Meyer's Definition [Meyer 88, sect. 10.1.5 Polymorphism]: "Polymorphism" means the ability to take several forms. In object-oriented programming, this refers to the ability of an entity to refer at run-time to instances of various classes. In a typed environment such as Eiffel, this is constrained by inheritance: ... [The Author notes Meyer has a following section 10.1.7 on Static Type, dynamic type, which is relevant, but claims "... there is no way the type of an object can ever change. Only a reference can be polymorphic: ...". Meyer is clear between the concept and the Eiffel realization in his polymorphism definition above, but here neglects the "becomes" facility as found in several dynamically typed OO languages such as Actors, CLOS, Self and Smalltalk, which allows an object (and not just a reference) to change its class.] > Stroustrup's Definition [Stroustrup 90, p. 209]: The use of derived classes and virtual functions is often called "object- oriented programming". Furthermore, the ability to call a variety of functions using exactly the same interface - as is provided by virtual functions - is sometimes called "polymorphism". [The Author notes this is a functional view of polymorphism (as provided in C++). [Stroustrup 91, p. 136] has an example of polymorphism with void *'s, but a newer template function is incomparably preferable, as implied in [Stroustrup 90, ch 14]] Rumbaugh's Definition [Rumbaugh 91, p. 2]: "Polymorphism" means that the same operation may behave differently on different classes. 2.2) What Does Polymorphism Boil Down To In OO Programming Languages? ---------------------------------------------------------------------- In C++, virtual functions provide polymorphism. This is because a polymorphic object (pointer or reference (or such parameter)) is assignment compatible with any object of a derived class. Is this polymorphism in itself? Objects can take on objects of different forms (the derived classes), but of what use is it? To make any difference, the differing forms must have some effect. In dynamically typed languages, polymorphic objects are passed messages and will respond in whatever way the object has defined (usually starting from its most derived class and working its way up). But for static objects, a virtual function is invoked. This is the stored method from the derived class that overrode the virtual method from its base class, providing specialized behavior for the polymorphic object; and hence, polymorphism. This common pure statically typed example is, of course, an example of inclusion polymorphism, subclass polymorphism to be more specific (see section 2.1). Pure statically typed subtype polymorphism, as provided in Emerald, can be implemented similarly [Black 86]. 2.3) What Is Dynamic Binding? ------------------------------ Dynamic binding has two forms, static and dynamic. Statically-typed dynamic binding is found in languages such as C++ (virtual functions) and Eiffel (redefinition). It is not known which function will be called for a virtual function at run-time because a derived class may override the function, in which case the overriding function must be called. Statically determining all possibilities of usage is undecidable. When the complete program is compiled, all such functions are resolved (statically) for actual objects. Formal object usage must have a consistent way of accessing these functions, as achieved thru vtables of function pointers in the actual objects (C++) or equivalent, providing statically-typed dynamic binding (this is really just defining simple function pointers with static typechecking in the base class, and filling them in in the derived class, along with offsets to reset the receiver). The run-time selection of methods is another case of dynamic binding, meaning lookup is performed (bound) at run-time (dynamically). This is often desired and even required in many applications including databases, distributed programming and user interaction (e.g. GUIs). Examples can be found in [Garfinkel 93, p80] and [Cox 91, pp 64-67]. To extend Garfinkels example with multiple-polymorphism, a cut operation in an Edit submenu may pass the cut operation (along with parameters) to any object on the desktop, each of which handles the message in its own way (OO). If an (application) object can cut many kinds of objects such as text and graphical objects, multiple-polymorphism comes into play, as many overloaded cut methods, one per type of object to be cut, are available in the receiving object, the particular method being selected based on the actual type of object being cut (which in the GUI case is not available until run-time). Again, various optimizations exist for dynamic lookup to increase efficiency (such as found in [Agrawal 91] and [Chambers 92]). Dynamic binding allows new objects and code to be interfaced with or added to a system without affecting existing code and eliminates switch statements. This removes the spread of knowledge of specific classes throughout a system, as each object knows what operation to support. It also allows a reduction in program complexity by replacing a nested construct (switch statement) with a simple call. It also allows small packages of behavior, improving coherence and loose coupling. Another benefit is that code complexity increases not linearly but exponentially with lines of code, so that packaging code into methods reduces program complexity considerably, even further that removing the nested switch statement! [Martin 92] covers some of these issues. 2.4) Is There A Difference Between Being A Member Or Instance Of A Class? -------------------------------------------------------------------------- Yes (but be careful of context). To use C++ terminology, an object (not a reference) is defined to be an instance of exactly one class (in classical OO), called its most derived class. An object not directly contained in any other is called the complete object [Stroustrup 90]. An object is a member of several classes, including all of the classes its declared (or most derived) class inherits from. With static typing and inclusion polymorphism based on class, if a polymorphic object (or reference) is made to refer to an object, that object must be a member of the polymorphic object's class. This also provides a good example of differing definitions among object- oriented languages, since a member is defined as above in CLOS, but a member of a class is one of its instance variables in C++. 2.5) What Is The Difference Between Static And Dynamic Typing? --------------------------------------------------------------- Static typing refers to types declared in a program at compile-time, so no type information is available on objects at run-time. Dynamic typing uses the inherent types of polymorphic objects, keeping track of the types of objects at run-time. Statically typed dynamic binding is a compromise (usually implemented with tables of function pointers and offsets), and is how statically-typed OO languages provide polymorphism. Some approaches provide both static and dynamic typing, sometimes with static typing providing type- safe programs and dynamic typing providing multiple-polymorphism [Agrawal 91] [Mugridge 91]. See also section 2.3. Static typing is more efficient and reliable, but loses power. Typical restrictions include only allowing a common set of base class functions (or any common functions for the more general subtyping or parametric polymorphic cases) to be available on formal objects and a lack of multiple-polymorphism (see section 1.19), both of which are overcome with dynamic typing. Many languages provide dynamic typing: Smalltalk, Self, Objective-C, and etc. A limited dynamic typing scheme, called RTTI (Run Time Type Identification), is even being considered for the C++ standard. A similar facility to safe downcasting (historically known as type narrowing), the thrust of RTTI, can also be found in recent versions of Eiffel. See section 3.4 for a categorization of common OO languages by type system. 2.6) What Is This I Hear About ML And Functional Programming Languages? ------------------------------------------------------------------------ ML, Metalanguage, is a functional programming language with a strongly typed polymorphic type system [Wikstrom 87]. Russell (see Appendix E) is a more recent functional language and Haskell [Hudak 92] provides a more modern and "pure" example. Section 2.5 discusses why static typing has less power/ flexibility than dynamic typing and the same applies to ML (although see the appendixes for an experimental dynamic extension to ML, Alcool-90 and [Cardelli 85] for a proper placement of ML's type system). ML doesn't use inheritance for polymorphism; unlike OO languages, but provides the prototypical example of parametric polymorphism, so no inheritance is required. This is "true" or "pure" statically (or strongly) checked parametric polymorphism, by Strachey's (and Cardelli and Wegner's) definitions. Smalltalk is an example of a dynamically-typed language which does not check types during assignment (and hence for parameters) and therefore provides parametric polymorphism without static constraints (by Strachey's definition). However, Smalltalk's style uses inclusion polymorphism in practise and inheritance for subclassing (representation). 2.7) What Is A Separation Between Type And Class (Representation)? ------------------------------------------------------------------- For a short answer: Subtype Polymorphism, as opposed to Subclass Polymorphism, is the best answer in OO. Parametric polymorphism is a related concept where this is also true, but is of a different flavor (and usually requires object attributes by use. See also section 2.1). A type can be considered a set of values and a set of operations on those values. This can insure type-safe programming. However, the representation of types (classes in OO) can be separated from the notion of type allowing many representations per type while still maintaining reasonable type-safety. In many languages, a type has a single representation insuring all operations performed on that type are well defined (statically bound) and providing for efficiency by taking advantage of that representation wherever used. In many OO languages, subclassing and dynamic binding provides for greater flexibility by providing object specialization. However, in many OO languages classes are used for assignment compatibility forcing an assigned object to inherit (transitively) from any polymorphic object's class (inclusion polymorphism based on class, or subclass polymorphism). This insures all operations to be performed on any polymorphic object are satisfied by any replacing objects. This also insures all types share a common representation, or at least a common base interface specification. By separating type from class, or representation (or perhaps separating class from type, by the aforementioned definition of type), a replacing object must satisfy the operations or type constraints of a polymorphic object (subtype polymorphism) but are not required to do to do so by an inheritance relation (subclass polymorphism), as is typical in most OOPLs. Dropping this restriction is somewhat less type-safe, because accidental matches of method signatures can occur, calling for greater care in use. [Black 86] discusses this issue in Emerald. The same issue arises in parametric polymorphism (generics/templates), as any method matching a required signature is accepted, calling for careful matching of actual and formal generic parameters. The difference between static and dynamic binding in OO and dynamic binding and subtyping seems similar. A possible loss of semantic integrity/similarity is contrasted with greater power. It is possible to specify desired abstract properties of type specifications with mechanisms similar to Eiffel's pre-, post-, and invariant conditions. This helps to insure the semantic integrity of replacing objects and their behavior. [Liskov 93] provides a recent exposition. Abstract classes ([Stroustrup 91] and [Meyer 88]) in typing provide a facility similar to subtype polymorphism; however, ACs require type compatible classes to inherit from them, providing a subclass polymorphism facility, and ACs can also specify representation. Subtyping is therefore most useful to avoid spreading knowledge of classes throughout a system, which is a high priority for loosely coupled modules and in distributed programming [Black 87]. The formal type system found in [Cardelli 85], Emerald/Jade [Black 86] and [Raj 89], original trellis/Owl, an experimental C++ extension (See Appendix E, Signatures), Sather (originally Eiffel-based), and an Eiffel superset [Jones 92] are all examples of OO systems providing subtype polymorphism. Functional languages such as ML, Russell, and Haskell provide a separation with pure parametric polymorphism (as is also commonly found in OO languages in addition to inclusion polymorphism). See also [Cook 90], "Inheritance Is Not Subtyping", for a formal approach. 2.8) What Are Generics And Templates? -------------------------------------- Short Answer: Parametric Polymorphism (although various implementations provide various subsets). Generics (or Templates in C++) refer to the ability to parameterize types and functions with types. This is useful for parameterized classes and polymorphic functions as found in languages such as Ada, C++, Eiffel, and etc., although these are "syntactic" or restricted forms [Cardelli 85]. Generics are orthogonal to inheritance, since types (and classes) may be generically parameterized. Generics provide for reusability in programming languages. An example is a Stack with a generically parameterized base type. This allows a single Stack class to provide many instantiations such as a Stack of ints, a Stack of any fundamental or user defined type, or even a Stack of Stacks of ... Another example is a polymorphic sort function taking a base type with a comparison operator. The function can be called with any type (containing a comparison operator). See [Booch 87b] for several examples in Ada and [Stroustrup xx] and [Murray 93] for examples in C++. While generics have many advantages, typical limitations include a static nature, which is an advantage for strong typechecking but a potential disadvantage when causing dynamic compilation (leading to a time/space efficiency tradeoff), and sources can cause inlining and create source code dependencies and expand code size (unlike a single-body or "true" parametrically polymorphic implementation. Generics can also be viewed as a special case of type variables. Functions are typically generic in statically-typed parametrically-polymorphic languages. One such popular functional language is ML, in which all functions are generic. Russell and Haskel are more modern variants (references are forthcoming, however see APPENDIX E). SECTION 3: GENERAL =================== References: (many more are to come) [Coplien 92] Covers C++, symbolic, exemplar (single-hierarchy), etc. [Kim 89] Covers many OO systems. 3.1) What Is The "Classical" Object-Oriented Paradigm? ------------------------------------------------------- This refers to the usual class and object model. Its any 2+ level system as described in section 1.4. See also [Coplien 92]. 3.2) What Is The "Delegation/Prototyping" Object-Oriented Paradigm? -------------------------------------------------------------------- See [Kim 89, ch 1,3]. This is the 1 Level System as Described under Meta-Classes. Delegation refers to the delegating of responsibility and can be applied to inheritance. When a derived class does not have a desired attribute, it "delegates" responsibility to one of its base classes. In delegation systems, each object has a delegate list instead of a parent list. Thus, delegation's primary emphasis is on message passing where an object could delegate responsibility of a message it couldn't handle to objects that potentially could (its delegates). Any object can be added to the delegate list, giving dynamic inheritance (of a sort). Typically, delegation and prototyping languages also have "part inheritance" in which fields and methods can be added and deleted from objects. This makes for easy "prototyping", which allows for objects to be constructed piece by piece at run-time, although the term "prototyping" in the context of delegation languages usually refers to objects serving as prototypes for object instantiation, or exemplars. Next's NextStep OS provides delegation using Objective-C, providing an example of delegation in a class-based language [Garfinkel 93]. 3.3) Are There Any Other Object-Oriented Paradigms? ---------------------------------------------------- There are many alternatives in OO. Emerald/Jade ([Black 86] and [Raj 89]) provides one, where inheritance is replaced with a roughly equivalent form where reuse occurs at a finer degree of granularity - method and instance variables - with subtype polymorphism making up the difference. CLOS [Kim 89, ch 4] has a looser coupling of methods to classes and doesn't distinguish a receiver, but packages can help make up the difference. Object Specialization [Sciore 89] is an example of a hybrid approach between delegation and classical systems, where parent classes have an extra level of indirection and inheritance hierarchies are specified on a per object/class basis. 3.4) What Are The Major Object-Oriented Programming Languages Today? --------------------------------------------------------------------- Statically-Typed: Add 1 To Cobol giving Cobol with Objects. C++ Classic-Ada Dragoon Emerald/Jade Java (comp.lang.java, http://java.sun.com/, Java Report & Conf: http://www.sigs.com, See Anon FTP) Object Pascal Trellis/Owl Dynamically-Typed: Actors Languages C+@ Flavors Python (new WWW, see http://www.python.org/) Self Smalltalk Both: Actor Ada95 BETA C++ (With RTTI) Cecil CLOS Eiffel Modula-3 Objective-C (http://www.marble.com/people/dekorte/Objective-C/objc.html) Sather 3.5) What Are Object-Oriented Databases And Persistence? --------------------------------------------------------- See also Appendices B and E and the comp.database.object newsgroup. Refs to be included in future FAQs. Object-Oriented Databases are databases that support objects and classes. They are different from the more traditional relational databases because they allow structured subobjects, each object has its own identity, or object-id (as opposed to a purely value-oriented approach) and because of support for methods and inheritance. It is also possible to provide relational operations on an object-oriented database. OODBs allow all the benefits of object-orientation, as well as the ability to have a strong equivalence with object-oriented programs, an equivalence that would be lost if an alternative were chosen, as with a purely relational database. Another way of looking at Object-Oriented Databases is as a persistent object store with a DBMS. Persistence is often defined as objects (and their classes in the case of OODBs) that outlive the programs that create them. Object lifetimes can be viewed as a hierarchy, with locals/automatics having the shortest default lifetime and objects stored indefinitely in an OODB (which are persistent) having the longest. Persistent object stores do not support query or interactive user interface facilities, as found in a fully supported OODBMS. Appendix B also contains references for object-oriented interfaces to relational databases and see APPENDIX E, Papers, Persistent Operating Systems. From the net: From: dbmsfacts@aol.com (DBMSfacts) Subject: ODMG Gopher and Web Addresses Date: 24 Oct 1994 13:10:02 -0400 The Object Database Management Group (ODMG) has set up Gopher and Web Servers at the following addresses: Gopher: gopher.odmg.org, port 2073 WWW: http://www.odmg.org:3083 These are still under construction. What you can find right now are addresses and contact information for ODBMS vendors, ODMG membership information, updates to Release 1.1 of The Object Database Standard: ODMG-93 along with ODL lex and yacc files. In the future, we will be adding more links to related sites, bibliographies, and a FAQ for ODBMSs. If you cannot access these servers, but would like information on the ODMG, send an email message to info@odmg.org and you will receive an automated reply. Doug Barry ODMG Executive Director 3.6) What Are Object-Oriented Operating Systems? ------------------------------------------------- Refs to be included in future FAQs. See also Appendix E. Object-Oriented Operating Systems provide resources through objects, sometimes all the way down to to the machine (OO architectures are found at the bottom). They are almost always distributed systems (DOS or DPOS), allowing objects to be passed freely between machines. They are typically capability-based since objects, and hence system resources, can only be accessed if a capability to them is available to programs. Here are some abstracts taken from several postings to the net. This list is by no means exhaustive. Apertos (Meta-Object-based Mikro-Kernel. See Appendix E, Papers:28) Chorus Micro-kernel (written in C++, COOL, See Appendix E, Papers:63) Choices (research OS, UofI, C++, supports SVR4, See Appendix E, Papers) GEOS (GeoWorks', written in Object Assembler, OO superset of 8086) Mach (CMU, supports BSD 4.3, really message-based) NachOS (written in C++, OS teaching/learning OS) Ouverture Project (ESPRIT funded OMG IDL defines inter-module interfaces) Peace (OO family-based parallel OS, See Appendix E, General) SOS Spring (Sun, written in C++) PenPoint OS (Go, written in C++) For the Spring Papers (free), Contact: Sun Microsystems Laboratories, Inc. M/S 29-01 2550 Garcia Avenue Mountain View, CA USA 94043 See also APPENDIX E, PAPERS, Persistent Operating Systems entry. From: whitney@oberon.Meakins.McGill.CA () Insight ETHOS: On Object-Orientation in Operating Systems ISBN 3 72811948 2 This thesis covers the design of an extensible object-oriented operating systems. The language used was Oberon-2. It includes a generalization of the Rider/Carrier principle, Object Directories as well as basic OS issues such as memory, file, tasking management. It covers extensible objected-oriented programming from hardware up. It reviews other designs such as Clouds and Choices which where written It reviews other designs such as Clouds and Choices which where written on C++. [[ The lack of type-tests in C++ was a problem in other designs.]] ETHOS was implemented as an operating system for the Ceres computers at the ETH. 3.7) What Are The Current Object-Oriented Methodologies? --------------------------------------------------------- Here is a list of OOSE Methodologies: Berard [Berard 93] BON [Nerson 92] Booch [Booch 94] Coad/Yourdon [Coad 91] Colbert [Colbert 89] de Champeaux [de Champeaux 93] Embley [Embley 92] EVB [Jurik 92] FUSION [Coleman 94] HOOD [HOOD 89] IBM [IBM 90,91] Jacobson [Jacobson 92] Martin/Odell [Martin 92] Reenskaug (OOram, was OORASS) [Reenskaug 91] ROOM [Selic 94] Rumbaugh et al. [Rumbaugh 91] Shlaer and Mellor [Shlaer 88 and 92] Wasserman [Wasserman 90] Winter Partners (OSMOSYS) [Winter Partners] Wirfs-Brock et al. [Wirfs-Brock 90] Further Ideas And Techniques: Meyer [Meyer 88] Stroustrup [Stroustrup 91] See APPENDIX D for CASE systems supporting these methodologies (several from the originators themselves). See also section 1.21 for a discussion on OOA/OOD and etc. Summaries and comparisons will be provided in future FAQs. Suggestions for inclusion of other major or new methodologies should be sent to the FAQ author. Here are some comparison studies posted to the net: Arnold, P., Bodoff, S., Coleman, D., Gilchrist, H., Hayes, F., An Evolution of Five Object Oriented Development Methods, Research report, HP Laboratories, June 1991 de Champeaux, Dennis and Faure, Penelope. A comparative study of object- oriented analysis methods. Journal of Object Oriented Programming (JOOP), pp 21-32. Vol.5, No. 1, 3/4-92 Fichman R.G. & Kemerer C.F. OO and Conventional Analysis and Design Methodologies. Computer, Oct 1992, Vol 25, No. 10, p 22-40 Fichman, Robert and Kemerer, Chris. Object-Oriented and Conventional Analysis and Design Methods - Comparison and Critique. IEEE-Comp, Oct, 1992, pp 22-39. OOA, OOD, conventional analysis, conventional design, DeMarco SA, Yourdon SA, Bailin OO requirements specification, Coad-Yourdon OOA, Shlaer-Mellor OOA, Yourdon-Constantine SD, Martin information engineering design, Wasserman OOSD, Booch OOD, Wirfs-Brock responsibility-driven design. The following 2 reports are out of print. [van den Goor et.al., 1992] G. van den Goor, S. Hong and S. Brinkkemper, A Comparison of Six Object-oriented Analysis and Design Methods. Report Center of Telematics and Information Technology, University of Twente, the Netherlands, and Computer Information Systems Department, Georgia State University, Atlanta, USA, 1992, 163 pages. [Hong et.al. 1992] S. Hong, G. van den Goor, S. Brinkkemper, A Formal Approach to the Comparison of Object Oriented Analysis and Design Methodologies, Hawaii International Conference on System Sciences (HICSS) (IEEE Computer Society Press, Hawaii) 1993, Vol. IV, pp. 689-698. [From Shuguang...] readers may download the paper if they want, though they may continue to request hard copies. We are currently extending the paper to compare ten OO methods and should be available shortly. My URL is: http://cis.gsu.edu/~shong =================================================================== * Shuguang Hong, Ph.D. cisssh@gsusgi2.gsu.edu * * Computer Information Systems Dept. Tel: (404)651-3887 * * College of Business Administration Fax: (404)651-3842 * * Georgia State University * * Atlanta, GA 30302-4015 www: http://cis.gsu.edu/~shong/ * =================================================================== Monarchi, David and Puhr, Gretchen I. A Research Typology for Object-Oriented Analysis and Design. CACM/September 1992/Vol.35, No.9, pp35. [Wilkie 93] summarizes, compares, and provides examples of Booch, Wirfs-Brock, Hood, Coad and Yourdon, Winter Partners, Shlaer and Mellor, Jacobson, Wasserman et al, Rumbaugh, Reenskaug et al, and Colbert. Wirfs-Brock, R.J. and Johnson, R.E., "Surveying Current Research in Object- Oriented Design," The Communications of ACM, (33, 9) Sept. 1990, pp. 104-1124. Fowler, M. "Describing and Comparing Object-Oriented Analysis and Design Methods," In Object Development Methods, Carmichael, A. ed., SIGS Books, (1994), pp.79-109. A new version is going to be published soon. Contact the author <100031.3311@compuserve.com> for details on its availability'. Also commercially available: An Evaluation of Object-Oriented Analysis and Design Methodologies (9) J. Cribbs, C Roe, S. Moon SIGS Books (212) 274-0640 $149. Object-Oriented Methodology Comparison Study (10 methodologies) Berard, Booch, Coad/Yourdon, Colbert, Embley, IBM, Martin/Odell, Rumbaugh, Shlaer/Mellor, Wirfs-Brock. Also contains refs to several previous studies. Berard Software Engineering 101 Lakeforest Blvd., Suite 360, Gaithersburg, MD 20877 Contact Person: Jim Youlio Phone: 301-417-9884 Fax: 301-417-0021 email: info@bse.com [Hong et.al. 1992], [van den Goor et.al., 1992] The authors have prepared a revision (See above) that includes the following OO methods: Booch, G. - Object-oriented analysis and design with applications, 1994. Champeaux, D. de - Object-oriented system development, 1993. Coad, P., and Yourdon, E. - Object-oriented analysis (2nd edition), 1991a. Coad, P., and Yourdon, E. - Object-oriented design, 1991b. Coleman, D. - Object-oriented development, the Fusion method, 1994. Henderson-Sellers, B. and Edwards, J.M. - Methodology for Object-oriented Software Engineering of Systems, draft manuscript, 1994. Jacobson, I. - Object-oriented software engineering, 1993. Martin, J., Odell, J. - Object-oriented analysis and design, 1992. Martin, J., Odell, J. - Principles of object-oriented analysis and design, 1993. Rumbaugh, J. et.al. - Object-oriented modeling and design, 1991. Shlaer, S., Mellor, S.J. - Object-oriented systems analysis: Modeling the world in states, 1992. Wirfs-Brock, R. et.al. - Designing object-oriented software, 1990. We are currently approaching publishers for the publication of this report as a book. This book should be out in the spring of 1995. If you are interested in obtaining this book you can send an e-mail to Sjaak Brinkkemper (sjbr@cs.utwente.nl), which we will forward to the publisher. The authors, regretfully, cannot supply ftp, postscript, TEX, or whatsoever. 3.8) What Is the OMG/OMA/ORB/CORBA? ------------------------------------ Contents: (3.8.1) Contact Information (3.8.2) OMG Summary (3.8.3) Mail Server Access (3.8.4) OMG Publications - First Class (Bi-Monthly Newsletter) - Object Management Architecture Guide (OMA) - The Common Object Request Broker: Arch. and Spec. (Corba) - Pricing (3.8.5) Implementations (Brief) (3.8.6) Implementation Descriptions (3.8.7) Books, Articles, And Literature 3.8.1 Contact Information __________________________ Contact Person: Richard Soley (technical director) soley@omg.com FTP Sites: omg.org:pub/* omg.org:pub/NEC_DII/93-1-2.tar... *CORBA (DII) (corba.ps.Z) omg.org:pub/OMG_IDL_CFE_1.2/bin* idl.SunOS4.x, idl.Solaris2.x claude.ifi.unizh.ch:under pub/standards/spec CORBA Spec WWW: http://www.omg.org/ http://conf4.darpa.mil/corba-ada/ORBs.html http://www.acl.lanl.gov/sunrise/DistComp/Objects/corba.html http://www.cs.wustl.edu/~schmidt/corba.html http://www.dstc.edu.au/AU/research_news/omg/corba.html Headquarters: Marketing Office: 492 Old Connecticut Path 3823 Birchwood Drive Framingham, MA 01701 Boulder, CO 80304 Tel: 508-820-4300 Tel: 303-444-8129 Fax: 508-820-4303 Fax: 303-444-8172 3.8.2 OMG Summary __________________ From: soley@emerald.omg.ORG (Richard Mark Soley) Subject: OMG In answer to your general question about the OMG, here's a brief overview. Feel free to call, fax or email for more information. -- Richard Soley Vice President & Technical Director Object Management Group, Inc. and coincidentally, MIT '82, SM '85, PhD '89 (EECS) The Object Management Group (OMG) is an international software industry consortium with two primary aims: (*) promotion of the object-oriented approach to software engineering in general, and (*) development of command models and a common interface for the development and use of large-scale distributed applications (open distributed processing) using object-oriented methodology. In late 1990 the OMG published its Object Management Architecture (OMA) Guide document. This document outlines a single terminology for object-oriented languages, systems, databases and application frameworks; an abstract framework for object-oriented systems; a set of both technical and architectural goals; and an architecture (reference model) for distributed applications using object-oriented techniques. To fill out this reference model, four areas of standardization have been identified: 1) the Object Request Broker, or key communications element, for handling distribution of messages between application objects in a highly interoperable manner; 2) the Object Model, or single design-portability abstract model for communicating with OMG-conforming object-oriented systems; 3) the Object Services, which will provide the main functions for realising basic object functionality using the Object Request Broker - the logical modeling and physical storage of objects; and 4) the Common Facilities will comprise facilities which are useful in many application domains and which will be made available through OMA compliant class interfaces. The OMG adoption cycle includes Requests for Information and Proposals, requesting detailed technical and commercial availability information from OMG members about existing products to fill particular parts of the reference model architecture. After passage by Technical and Business committees to review these responses, the OMG Board of Directors makes a final determination for technology adoption. Adopted specifications are available on a fee-free basis to members and non-members alike. In late 1991 OMG adopted its first interface technology, for the Object Request Broker portion of the reference model. This technology, adopted from a joint proposal (named "CORBA") of Hewlett-Packard, NCR Corp., HyperDesk Corp., Digital Equipment Corp., Sun Microsystems and Object Design Inc. includes both static and dynamic interfaces to an inter- application request handling software "bus." Unlike other organizations, the OMG itself does not and will not develop nor sell software of any kind. Instead, it selects and promulgates software interfaces; products which offer these interfaces continue to be developed and offered by commercial companies. In order to serve OMG membership interested in other object-oriented systems arenas besides the distributed system problem, the Group supports Special Interest Groups for discussion of possible standards in other areas. These groups at present are: 1) Object Oriented Databases; 2) OO Languages; 3) End-User Requirements; 4) Parallel Processing; 5) Analysis & Design Methodologies; 6) Smalltalk; and 7) Class Libraries. Any company, university/research institution or individual, whether end-user or vendor, can become a member of this body. Administrative details are given at the end of this paper. 3.8.3 Mail Server Access _________________________ Information via Mail Server: Send the following commands in a letter to the mail server. mail omg_server@omg.org help (how to use file server) index (return a list of all available files) get (get files returned by index) log (logs info on server) address [match] (index a directory, pattern 'match' files) size (max file size to send) list mail list docs get docs/doclist.txt get docs/91-12-1.ps CORBA spec [although it looks a little old] Recommended (from the net): mail omg_server@omg.org Subject: help index list list mail list docs get docs/doclist.txt 3.8.4 OMG Publications _______________________ Below is from omg.org:pub/CORBA > First Class (Bi-Monthly Newsletter) First Class is OMG's non-commercial bi-monthly 28-page newsletter. First Class provides current information on Object Technology developments, both technically and commercially. First Class offers an open editorial forum on numerous Object Technology topics and issues. This publication features commentaries from software industry leaders, informative user case histories, OT training information and the latest object- oriented product announcements. All OMG activities and the ongoing development of the Object Management Architecture are regularly reported. > Object Management Architecture Guide (OMA) The members of the OMG have a shared goal of developing and using integrated software systems. These systems should be built using a methodology that supports modular production of software; encourages reuse of code; allows useful integration across lines of developers, operating systems and hardware; and enhance long- range maintenance of that code. As an organization, OMG believes that the object-oriented approach to software construction best supports their goals. The OMA publication outlines the groundwork for technology response to Request for Proposals (RFP) and the adoption of specifications. > The Common Object Request Broker: Arch. and Spec. (Corba) The CORBA, as defined by the OMG's Object Request Broker (ORB), provides the mechanisms by which objects transparently make requests and receive responses. The ORB provides interoperability between applications on different machines in heterogeneous distributed environments and seamlessly interconnects multiple object systems. The Common Object Request Broker Architecture and Specification described in this published document is a self- contained response to the Request for Proposals (RFP) issued by the ORB Task Force of the OMG. > Pricing [Here's why you don't see the specifications posted to the net or available via ftp! These are from the list of literature and periodicals listed in omg.org:pub/CORBA] o I would like a one year subscription to First Class ______ for $40 U.S., ______ for $50 outside U.S. o I would like to order ______ copy(s) of the Object Management Architecture (OMA) Guide for $50 each. o I would like to order ______ copy(s) of the CORBA for $50 each. o [Combinations] Contact documents@omg.org or omg_documents@omg.org for more of the same... 3.8.5 Implementations (Brief) ______________________________ > DEC ObjectBroker Version 2.5 (Version 2.1 was ACA) Full implementation of OMG CORBA 1.1. Digital's ObjectBroker is a 100 % compliant implementation of CORBA and is available on these platforms: IBM AIX, IBM MVS(port in progress), HP-UX, Macintosh, MS-Windows 3.1, NT, OSF/1, SunOS, ULTRIX, Digital VAX/VMS, Digital OpenVMS Contact: Andrew Comas comas@nyo.dec.com (212) 856-2507 Digital Equipment Corporation. ObjectBroker 110 Spit Brook Road Nashua, New Hampshire 03062-2698 > DOME - The C++ Object Request Broker runs on VAX/VMS, Unix, PC http://www.octacon.co.uk/onyx/external/oot.co.uk Anon ftp: ftp.octacon.co.uk/external/oot/domedemo.exe; also from http. > HP ORB Plus and HP Distributed Smalltalk Full implementation of the OMG CORBA 1.1 Object Request Broker. Also DOMF. Hewlett-Packard Distributed Computing Group 19447 Pruneridge Avenue Cupertino, CA 95014-9974 (USA) Ian Fuller ian@cup.hp.com (408) 447-4722 > HyperDesk (Westborough MA) HD-DOMS, rich_fraser@hyperdesk.com Runs on SPARC, HP/UX, IBM RS-6000, Data General Aviion, MS-Windows (client API only), NetWare (planned, Novell owns part of HyperDesk). > IBM SOM (System Object Model) Available on AIX and OS/2. See Distributed Computing Monitor, March 93 for a detailed review. > ILU (free, see APPENDIX E entry 59) Object RPC compatible with OMG CORBA 1.2 spec (will compile OMG IDL and generate OMG compliant code for OMG-specified languages). parcftp.parc.xerox.com:/pub/ilu/ilu.html > IONA Technologies, Dublin Orbix, info@iona.ie First full and complete implementation of OMG's CORBA. > NCR 'Cooperative Frameworks' -- a Distributed Object Foundation (1) C++ ORB toolkit consisting of over 300 C++ classes and runtime libraries (2) CORBA 1.1 toolkit > ORBELINE - The SMART Object Request Broker - PostModern Computing Complete implementation of CORBA. Free academic; com. eval licence avail. SunOS 4.x, Solaris 2.3, and OSF/1 versions of ORBeline available; will consider making other platforms available if enough interest. See Appendix E. http://www.pomoco.com/ > ROLSCH CONSULTING (RC-ORB) Implements ORB spec, DOS/Windows 3.1, 12 user license: $99. Ref: Datamation, LOOK AHEAD Section, August 1. German Company. > SUITESOFTWARE (SuiteDOME) - an open system, standards compliance, object-oriented architecture, support for heterogeneous environments, support for Remote Data Access (RDA), Remote Procedure Calls (RPC), Message-Oriented Middleware (MOM), and Object Request Broker (ORB). > Sun DOE > Tivoli > CS Dept. University of Zurich, Switzerland. maffeis@ifi.unizh.ch The ELECTRA Toolkit (not finished) 3.8.6 Implementation Descriptions ___________________________________ The OMG also has a (Corporate) Membership list and "known CORBA supporters" list with their info package. > The ELECTRA Toolkit CS Dept. University of Zurich, Switzerland. maffeis@ifi.unizh.ch The ELECTRA Toolkit Subject: ORB Implementations Date: Tue, 4 May 1993 13:12:36 +0200 (MET DST) From: Silvano Maffeis something like an Object Broker, but it is *not* CORBA compatible (yet). Electra is a research project and not available yet. Its a toolkit for building failure resilient, distributed applications in C++. It supports object-groups, virtual synchrony, multithreading etc. Electra is based on the HORUS toolkit (which is "the new ISIS implementation" developed at Cornell, Ithaca NY.) An overview paper to electra is available from: ftp.ifi.unizh.ch: pub/techreports/electra.ps.Z > HD_DOMS HD-DOMS (HyperDesk Distributed Object Management System). A CORBA-compliant DOMS. Includes a GUI API driver for prototyping and exercising objects, a bundled object database for persistent object storage, a Kerberos-based authentication service, a location service, a set of base classes to speed development, and a test script language. Revision 1.0 has been shipping since beginning of '92. Revision 1.1 (which includes support for CORBA's static client interface) is available now, and a NetWare version is in the works. Submitted a C++ language mapping for IDL to the OMG recently. HyperDesk Corporation 2000 West Park Drive Westboro, MA 01581 (508)366-5050 > HP ORB Plus and HP Distributed Smalltalk ============================================================================ SUBJECT: HP INTRODUCES DISTRIBUTED-COMPUTING SOLUTION FOR BUILDING SCALABLE, OBJECT-ORIENTED APPLICATIONS DATE: September 27, 1993 ---------------------------------------------------------------------------- PALO ALTO, Calif.--(BUSINESS WIRE) via First! -- Hewlett-Packard Company today introduced a distributed-computing solution for building scalable, object-oriented applications. With HP ORB Plus, programmers can develop scalable, object-based applications that can be distributed throughout the enterprise. HP also introduced an enhanced version of HP Distributed Smalltalk. HP ORB Plus and HP Distributed Smalltalk are major components of HP's overall distributed-computing strategy, which is designed to give customers integrated, desktop access to enterprise-wide information and resources in distributed heterogeneous systems environments. Of all computer companies, HP believes it is best positioned to help customers take advantage of distributed computing. HP provides a wide variety of distributed-computing products, understands how to help customers adopt new technology for maximum business benefit, and offers worldwide support and training programs, ranging from analysis and design to deployment. HP ORB PLUS: CORBA AND DCE COMBINED HP ORB Plus is the only environment that combines the complete CORBA 1.1 specification from the Object Management Group with the DCE standard from the Open Software Foundation(tm) as its transport mechanism. DCE is designed to let developers write one application and then deploy it -- without modification -- on any other system that supports DCE. HP ORB Plus reduces the complexity of developing distributed applications so programmers can concentrate on the application itself without needing to know multiple operating systems, networking protocols or where application objects are stored. The DCE (Distributed Computing Environment) standard provides an integrated set of services that can be used separately or together to provide a distributed computing environment that's easy to administer. The CORBA (common-object-request-broker architecture) specification provides a standard for how objects (in applications, repositories or class libraries) make requests and receive responses across a distributed network. HP ORB PLUS DETAILS HP ORB Plus consists of several components: the Distributed Object Management Facility (DOMF), object services, developers' and administrative tools, and sample applications. HP's DOMF provides a location-transparent object-communication mechanism across heterogeneous networks by using the DCE standard. This object- enabling technology specification was jointly developed with SunSoft. By following a common specification, HP and SunSoft have made it easier for their customers to port applications between their platforms. In addition, HP is working with IBM to integrate HP's DOMF with IBM's System Object Model with extensions for distribution. This integration will eventually provide users with complete scalability, portability and interoperability of distributed applications across HP and IBM platforms. This is part of the companies' planned approach toward a standards-based, "plug-and-play" object-oriented environment. This will give developers, system administrators and end users language-neutral, enterprise-wide, heterogeneous support for building, managing and using distributed object- oriented applications. "We're so convinced of the value of object technology that we're staking our entire company on it," said Richard Tanler, president and chief executive officer of Information Advantage, Inc. "Our object-based applications for retailers provide the means to a competitive business edge. We plan to use HP ORB Plus to develop new object-based products that retailers can distribute to end users throughout headquarters, all chain stores, and warehousing and distribution operations." HP DISTRIBUTED SMALLTALK 2.0 In a related announcement, HP introduced Version 2.0 of HP Distributed Smalltalk. This toolset works with VisualWorks from ParcPlace Systems to provide programmers with a rapid development environment for creating and running distributed applications. These applications can use object databases (currently OpenODB from HP and Gemstone from Servio) as their storage mechanism to facilitate the reuse of objects. Applications built using HP Distributed Smalltalk currently run without modification on HP, Sun and IBM UNIX(R) system-based workstations. They also will run on Apple Macintosh computers and on any PC running the Windows 3.1 or Windows NT operating systems from Microsoft(R) Corp., once VisualWorks 2.0 is released (expected within two months.) New HP Distributed Smalltalk 2.0 features include the following: -- easier deployment, with the ability to run multiple HP Distributed Smalltalk-based applications on a single system; -- up to 400 percent increased performance, through quicker sending and receiving of remote messages, and reusable object libraries; -- run-time version, for full production deployment; and -- easier development, with remote object browsing so developers can find and use objects more quickly. TECHNICAL DETAILS AND AVAILABILITY HP's DOMF includes the object request broker, interface- definition- language compiler, static and dynamic invocation interface and interface repository. In addition to these OMG-specific features, most developers writing distributed, object-oriented applications require additional interfaces to use objects effectively. So developers don't need to create their own, HP has supplied several object-service interfaces for developers to use. That's why HP ORB Plus includes OMG interfaces and implementations for properties, life cycle, associations, event notification and naming. HP's limited release of HP ORB Plus to key developers is designed so that customer input can be incorporated into the product early in its development cycle. The initial version will work with the C++ programming language. For the generally available Developer's Kit, C++, C and Smalltalk interoperability is planned so objects written in different languages can be combined into one application. The Developer's Kit is scheduled to be available mid- 1994; prices will be announced then. HP ORB Plus runs on the HP Apollo 9000 Series 700 workstations and HP 9000 Series 800 business servers. Hewlett-Packard Company is an international manufacturer of measurement and computation products and systems recognized for excellence in quality and support. The company's products and services are used in industry, business, engineering, science, medicine and education in approximately 110 countries. HP has 94,900 employees and had revenue of $16.4 billion in its 1992 fiscal year. EDITORIAL CONTACTS: Hewlett-Packard Company Lynne Hanson, 408/447-1415, Cupertino, Calif. Jill Kramer, 408/447-4275, Cupertino, Calif. ================== For more information about HP ORB Plus, contact Kathy Litch (litch_k@apollo.hp.com). For more information about HP Distributed SmallTalk, contact Jerry Boortz (jerry_boortz@hp4000.desk.hp.com). > Iris RDOM From: rcbc@cs.cornell.edu (Robert Cooper) Subject: Re: DCE vs. CORBA Reply-To: rcbc@isis.com Product: Isis Reliable Distributed Object Manager(tm) (RDOM) Company: Isis Distributed Systems, Inc., Ithaca NY, USA. Isis RDOM(tm) is a fault tolerant distributed ORB platform for reliable multi-lingual object-oriented applications. RDOM provides an "object group" paradigm for constructing complex applications out of collections of cooperating objects. RDOM is built on top of the Isis Distributed Toolkit(tm). RDOM provides interfaces from Smalltalk (Parcplace), Objective-C, and C++, and runs on most Unix workstations. RDOM is currently not CORBA compliant, but will be brought to compliance during 3Q93. Status: RDOM has been at beta test sites since January. General release of the Smalltalk and Objective-C language interfaces is expected in June. The C++ interface in August. Customers include AMD, Consilium and Swiss Bank Corp). > Object-Oriented Technologies DOME Product: DOME - Distributed Object Management Environment Company: Enquiries: info@oot.co.uk Object Oriented Technologies Ltd, 1st Floor, Lawrence House, 1A Morrell St, Leamington Spa, England CV32 5SZ Telephone: +44 (0) 1926 833488 Fax: +44 (0) 1926 883370. Short Description: DOME provides heterogenous distribution across many platforms and networks, including: UNIX, Windows, Windows NT, OS/2, OSF/1 (AXP), OpenVMS, SunOs, Solaris, HP-UX, SGI Unix, Stratus FTX, TCP/IP, NetBIOS, XTI As a fully peer-to-peer product DOME can be used to build systems using any combination of the above. Long Description: DOME is an ORB toolkit for the production of user-configured ORBs and servers. It is a multi-threaded high performance ORB suitable for use in large scale commercial systems and embedded real-time systems. DOME is non-intrusive, meaning that the application development is separated from the means of distribution and the problem of distributed object management; this allows the application to be built and tested on a single machine using local resources. Existing software can also be incorporated easily, providing integration for legacy systems. DOME is constructed as a C++ class library, from which ORBs can be configured and constructed to best suit the runtime environment. This provides great flexibility since new classes can be derived from existing ones and the resulting configurations implemented to user-specific requirements. Database distribution can be as simple persistent files, RDBMSs, OODMS, or a combination of these. DOME has a CORBA-conformant interface, and is CORBA 1.0 compliant with the following divergences - additions: - full C++ binding, - integral support for GUI development, - network monitoring & analysis, - transaction management, - location broking, - enhanced security; ommissions: - dynamic invocation, which is seen as detrimental to performance and network security; however, DOME does allow stream operators to perform the same function. DOME was first released in August 1993; version 2 in May 1994. > ORBELINE - The SMART Object Request Broker ORBeline is a complete implementation of OMG's Common Object Request Broker Architecture (CORBA). ORBeline goes beyond the standard specification to provide a SMART communication framework allowing you to easily develop large distributed applications that are robust, scalable, flexible and maintainable. ORBeline incorporates PostModern's proven communication framework that links thousands of nodes. See Appendix E:65 for a complete description and anon FTP info. > Orbix Orbix Iona Technologies Ltd. 8-34 Percy Place Dublin 4 Ireland The latest release of Orbix, Version 1.2, includes an Object Loader function for the first time, as well as an upgraded Interface Repository, a new approach to filtering, and more code examples to guide programmers. Orbix was launched in June 1993 as the first full and complete implementation of the Object Management Group's (OMG's) Common Object Request Broker Architecture (CORBA) standard. With Orbix, programmers can develop distributed, object oriented applications following a consistent and straightforward, standards-based model. With Orbix Version 1.2 IONA has added the ability to dynamically load objects at runtime through its Object Loader function. This enables developers to more easily integrate Orbix applications with existing data stores be they traditional flat file databases, relational databases or object oriented databases. The improved Interface Repository is an integral part of IONA's CORBA implementation. The Interface Repository operates as a dynamic browser which is populated with all objects or services available at runtime keeping programmers informed of the functions, attributes and characteristics of objects and services. In version 1.2 IONA has also extended the whole approach to filtering of requests, and has made it easier for users to integrate Orbix with their security systems providing for improved reliability of distributed systems built using Orbix. IONA has also extensively extended the number, and scope, of code examples it ships with the product to help developers learning how to use the system. IONA released Orbix for SunSoft Solaris and SunOS at the Object World exhibition in San Francisco, Calif., June 1993. Since then it has rolled out versions of Orbix for Microsoft Windows NT, Silicon Graphics IRIX and HP/UX. IONA demonstrated a version of Orbix for Microsoft Windows 3.1 at Object World in London, England last October. Orbix for Microsoft Windows 3.1 is now in beta. In January 1994, IONA and SunSoft Inc. signed an agreement to align their implementations of CORBA. The two companies demonstrated interoperability between IONA's Orbix running on Microsoft Windows 3.1 and SunSoft's Distributed Objects Everywhere (DOE) on Solaris. In addition Orbix-TP, integration with Tuxedo for transaction processing, has just entered beta testing. Work is underway on Orbix-FT, integration with the Isis distributed system, will deliver a fault-tolerant ORB. Paul Hickey, tel: +353-1-6686522 Iona Technologies Ltd., fax: +353-1-6686573 8-34 Percy Place, email: pth@iona.ie Dublin 4 Ireland Availability ------------ The full Orbix availability and release schedule looks like: Operating System C++ Compiler Release Date ------------------------------------------------------- SunOS 4.1 SPARCompiler 2.1 NOW SunOS 4.1 SPARCompiler 3.0.2 NOW SunOS 4.1 Lucid 3.1 NOW SunOS 4.1 GNU 2.5.8 NOW Solaris 2.x SPARCompiler 3.0.2 NOW Solaris 2.x SPARCompiler 4.0 NOW Solaris 2.x GNU 2.5.7 NOW IRIX 4.0.5H Native NOW IRIX 5.x Native NOW HP-UX Native NOW Microsoft Windows NT Visual C++ NOW Microsoft Windows NT Borland NOW Microsoft Windows 3.1 Visual C++ In Beta IBM AIX C Set++ 4th Qtr OSF/1 DEC C++ 4th Qtr SCO Native 4th Qtr UnixWare Computer Innovations 4th Qtr Ultrix DEC C++ 4th Qtr Release of Orbix on OS/2 is also imminent. Documents Available from IONA ----------------------------- electronic mail server - server@iona.ie anonymous ftp file server - ftp ftp.iona.ie World Wide Web - http://www.iona.ie/ > NCR 'Cooperative Frameworks' -- a Distributed Object Foundation From: Randy Volters Subject: re-post: NCR Cooperative Frameworks (new phone no.) November 19, 1993 NCR ANNOUNCES BETA AVAILABILITY OF 'Cooperative Frameworks' -- a Distributed Object Foundation Product Background - NCR Cooperative Frameworks(TM) were first released for sale in 10/1991 as "the frameworks" part of the NCR COOPERATION(TM) product, and are based on NCR's submission to OMG. Cooperativ