featuresmatrix intro pageOMG Core Object Model
4.2.1 Basic Concepts
The OMG Object Model is based on a small number of basic concepts: objects,operations, types, and subtyping. An object can model any kind of entity,for example a person, a ship, a document, a department, a tuple, a file,a window manager, or a lexical scanner. A basic characteristic of an objectis its distinct identity, which is immutable, persists for as long as theobject exists, and is independent of the object's properties or behavior.
4.1.5 Profiles
There exists a wide range of domains that place requirements on theobject model, for example databases, user interfaces, and programming languages.Unfortunately, not all of these domains agree on the importance/relevanceof all aspects that could be defined to the object model. Thus, the CoreModel, defined in section 4.2, has been defined to capture a set of objectmodel concepts that all domains must support, and components, describedin the OMG OM Components Guide, have been defined to permit important extensionsto the core model.
Editor's note: the OMG OM Components Guide exists in draft form only.
Profiles exist to group components. A particular domain will group componentswhich provide extensions that the domain considers important to meet theneeds to its specific user community. Profiles can be technology-based;for example databases or programming languages. Profiles can also be application-based;for example CAD or Finance.
Some example profiles that are being considered include:
o Object request broker
o Object database
o Requirements and Analysis
o User interface
OMG CORBA IDL
The CORBA Specification, published by the Object Management Group, isboth an architecture which encompasses an object model and a specificationwhich defines among other things, an Interface Definition Language (IDL).IDL permits interfaces to objects to be defined independent of an objectsimplementation. After defining an interface in IDL, the interface definitionis used as input to an IDL compiler which produces output that can be compiledand linked with an object implementation and its clients.
CORBA supports clients making requests to objects. The requests consistof an operation, a target object, zero or more parameters and an optionalrequest context. A request causes a service to be performed on behalf ofa client and results of executing the request returned to the client. Ifan abnormal condition occurs during execution of the request an exceptionis returned.
Interfaces can be used either statically or dynamically. An interfaceis statically bound to an object when the name of the object it is accessingis known at compile time. In this case, the IDL compiler generates thenecessary output to compile and link to the object at compile time. Inaddition, clients that need to discover an object at run time and constructa request dynamically, can use the Dynamic Invocation Interface (DII).The DII is supported by an interface repository which is defined as partof CORBA. By accessing information in the interface repository, a clientcan retrieve all of the information necessary about an objects interfaceto construct and issue a request at run time. Since the static and dynamicrequests are equally expressive semantically there will be no further distinctionin this discussion between these two methods of invoking operations onobjects.
CORBA has been postured as being both language-neutral and independentof ORB and CORBA object implementations. CORBA supports bindings for Cbut it is anticipated that it will eventually support language mappingsfor C++, Smalltalk and COBOL.
The basic concepts are objects, types, operations, properties, identityand subtyping. Objects have state (defined by the values of their properties),behavior (defined by operations) and identity. All objects of the sametype have common behavior and properties.
Types are objects so may have their own properties. A type has an interfaceand one or more implementations. All things are instances of some typeand subtyping organizes these types in a lattice. A type definition candeclare that an extent (set of all instances) be maintained for the type.
EXPRESS
EXPRESS specifies an information domain in terms of Entities (classesof objects sharing common characteristics). Entities have associated attributesand constraints, which represent these common characteristics. Constraintsare written using a very expressive mix of declarative and procedural language.
Management Information Model
Managed objects are abstractions of data processing and data communicationsresources for the purposes of management... The design of systems managementrequires that an approach be adopted that will allow the specificationsto be standardized in a modular fashion and provide the extensibility ofthe protocol and procedures. The information model makes use of object-orienteddesign principles because they provide the above capabilities and providefor reuse of pieces of specification. [Part 1]
Managed objects are defined for the purpose of managing systems. Eachmanaged system may contain a Management Information Base (MIB). In theMIB, managed objects are used to represent the resources that may be managedwithin the system. A MIB is the conceptual repository of the managementinformation within an open system. It represents the resources in a managedsystem that have been externalized for communication with a managing system.They are externalized in the sense that a managing system has knowledgeof the MIB, not of the actual data structures of the managed system's internaldatabase; and the two may be vastly different. Resources that are not manageddo not need managed object representations. By managing this MIB, a managingsystem can control the managed system's actual resources. This controlincludes the ability to retrieve information about the resources and toprovision, reconfigure, or inhibit the capabilities of the resources withina managed system.
SQL3
ANSI (X3H2) and ISO (ISO/IEC JTC1/SC21/WG3) SQL standardization committeeshave for some time been adding features to the SQL specification to supportobject-oriented data management. The current version of SQL in progressincluding these extensions is often referred to as "SQL3" [ISO96a,b].SQL3 object facilities primarily involve extensions to SQL's typefacilities; however, extensions to SQL table facilities can alsobe considered relevant. Additional facilities include control structuresto make SQL a computationally complete language for creating, managing,and querying persistent object-like data structures. The added facilitiesare intended to be upward compatible with the current SQL92 standard (SQL92).This and other sections of the Features Matrix describing SQL3 concentrateprimarily on the SQL3 extensions relevant to object modeling. However,numerous other enhancements have been made in SQL as well [Mat96]. In addition,it should be noted that SQL3 continues to undergo development, and thusthe description of SQL3 in this Features Matrix does not necessarily representthe final, approved language specifications.
The parts of SQL3 that provide the primary basis for supporting object-orientedstructures are:
One of the basic ideas behind the object facilities is that, in additionto the normal built-in types defined by SQL, user-defined types may alsobe defined. These types may be used in the same way as built-in types.For example, columns in relational tables may be defined as taking valuesof user-defined types, as well as built-in types. A user-defined abstractdata type (ADT) definition encapsulates attributes and operations ina single entity. In SQL3, an abstract data type (ADT) is defined by specifyinga set of declarations of the stored attributes that represent the valueof the ADT, the operations that define the equality and ordering relationshipsof the ADT, and the operations that define the behavior (and any virtualattributes) of the ADT. Operations are implemented by procedures calledroutines. ADTs can also be defined as subtypes of other ADTs. Asubtype inherits the structure and behavior of its supertypes (multipleinheritance is supported). Instances of ADTs can be persistently storedin the database only by storing them in columns of tables.
A row type is a sequence of field name/data type pairs resemblinga table definition. Two rows are type-equivalent if both have the samenumber of fields and every pair of fields in the same position have compatibletypes. The row type provides a data type that can represent the types ofrows in tables, so that complete rows can be stored in variables, passedas arguments to routines, and returned as return values from function invocations.This facility also allows columns in tables to contain row values. A namedrow type is a row type with a name assigned to it. A named row typeis effectively a user-defined data type with a non-encapsulated internalstructure (consisting of its fields). A named row type can be used to specifythe types of rows in table definitions. A named row type can also be usedto define a reference type. A value of the reference type definedfor a specific row type is a unique value which identifies a specific instanceof the row type within some (top level) database table. A reference typevalue can be stored in one table and used as a direct reference ("pointer")to a specific row in another table, just as an object identifier in otherobject models allows one object to directly reference another object. Thesame reference type value can be stored in multiple rows, thus allowingthe referenced row to be "shared" by those rows.
Collection types for sets, lists, and multisets have also beendefined. Using these types, columns of tables can contain sets, lists,or multisets, in addition to individual values.
Tables have also been enhanced with a subtable facility. A tablecan be declared as a subtable of one or more supertables (it is then adirect subtable of these supertables), using an UNDER clause associatedwith the table definition. When a subtable is defined, the subtable inheritsevery column from its supertables, and may also define columns of its own.The subtable facility is completely independent from the ADT subtype facility.
See also 2. Objects and 7. Types and Classes.
Matisse
A convergence of view between the object technology and relational databasecommunities has recently emerged. All parties are agreed that object orientedfeatures outlined in The Object-Oriented Database System Manifesto [1]are highly desirable. The X3H2 Database Standards Committee has releaseda draft SQL3 Specification that incorporates a number of object-orientedfeatures [see SQL3 entries in this matrix]. The relational database communitypublished the Third-Generation Database System Manifesto [2] to specifythree tenets that new database technologies must support to be generallyuseful.
The first tenet specifies that "third generation DBMSs will providesupport for richer object structures and rules," a view that is consistentwith the object database community. The second tenet specifies that "thirdgeneration DBMSs must subsume second generation DBMSs." In particular,the authors note that second generation systems (relational databases)improved over first generation systems (CODASYL and hierarchical databases)by providing non-procedural access (SQL) and data independence (ANSI/X3/SPARCThree Schema Architecture [3]). The third tenet requires that third generationDBMSs be open to other subsystems. Friendly access from many programminglanguages, tools, and applications running on a variety of operating systemsand hardware is mandatory.
Matisse claims to support language independence, an open systems environment,and multiple data models, including a complete object model, and to meetthe requirements of both the Object-Oriented Database System Manifestoand the Third Generation Database System Manifesto. [4]
C++
In C++, an object is a region of storage with associated semantics.In the context of the object model of C++, the term object refersto an instance of a class. A class defines the characteristics of its instancesin terms of members: data members (state) and member functions (methodsor operations), and the visibility of these members to other classes. C++is statically typed.
OOCOBOL
OO COBOL includes the following:
Smalltalk
Smalltalk is uniformly object-oriented because everything that the Smalltalkprogrammer deals with is an object, from a number to an entire application.Within the context of Smalltalk, objects are implemented in code throughencapsulation and polymorphism.
Encapsulation is the approach used in Smalltalk to bundle everythingneeded into an object to preserve the integrity of the enclosed data. Thecode within an object performs operations on the objects internal data.Operations in Smalltalk are performed as the result of a messages beingsent to an object to execute a specific portion of its code (usually calleda "method"). For instance the statement "2 + 3" isa request to the receiver object "2" to perform the "+"method using the passed value "3." Intuitively it is assumedthat "2" is being asked to add "3" to itself and returna value of "5." The message "CorporateBudget updateWith:lastRevision" could be equally meaningful, but in both cases, howthe receiver object implements the operation is hidden from external viewthrough encapsulating the details within the object.
Polymorphism is the way that the Smalltalk language allows methods ofthe same name to have predictable and meaningful results in related instances,yet perform the operations differently to achieve the results. The method"updateWith," introduced in the prior paragraph, might reasonablyhave different code logic if it were encapsulated in the "ProjectBudget"object rather than the "CorporateBudget," but we can surmisethat if the method name reflects predictability, the effects should bethe same in either object.
Polymorphism is typically implemented in Smalltalk through the abstractionof the common properties of a group of objects into classes and hierarchicallysubclassing shared properties using inheritance-along with specializationof the subclass to define the differences.
Classes serve as templates because they define the instance variablesfor all the class instance variables and methods. The instance ofa class is created by sending a new message to the class which uniquelyidentifies the object instance and allocates space for its variable(s).
Eiffel
Eiffel is based on a pure object model. All entities in an Eiffel programare objects and all objects are instantiated from one (and only one) basegenerating class.
An Eiffel class is an implementation of an abstract data type i.e.,a class describes the operations available to the type and formal propertiesof those operations. A class describes possible run-time objects.
Eiffel is strongly typed. Every entity is declared of a particular type.
An Eiffel program is a collection of classes with one class designatedas the `root' class from which execution begins. This involves the creationof an object of the root class and subsequent creation of other objectsby that newly created object.
Emerald
Emerald is a strongly-typed object-oriented language. All entities inEmerald are objects. This includes small entities, such as Booleans andintegers, and large entities, such as directories and compilers. All objectsexhibit uniform (object) semantics even though they may be implementedwith different techniques. Objects are the units of programming and distribution,and the entities between which communication takes place. An object canbe manipulated only through invocation of its exported operations; no externalaccess to an object's data is permitted. Operations can be invoked on non-local(in the network) objects, and objects can move from node to node. [BHJL86]
Cecil
Cecil is based on a pure object model. All data are objects, and objectsare manipulated solely by passing messages. Cecil uses a classless (prototype-based)object model, in which (conceptually) self-sufficient objects implementdata abstractions, and objects inherit directly from other objects (delegation)to share code. Cecil also supports a general form of dynamic binding basedon multiple dispatching. Cecil attempts to combine multi-methods with traditionalobject-oriented language concepts, such as encapsulation and static typechecking.
SELF
SELF is a dynamically-typed object-oriented language. Like Smalltalk,SELF has no type declarations. Also like Smalltalk, SELF provides blocks(lexically-scoped function objects related to closures) as a basic construct.Standard control structures for iteration and Boolean selection, as wellas programmer-defined control structures, are constructed out of theseblocks. However, unlike Smalltalk and many other object-oriented languages,SELF has no classes. Instead it is based on the use of prototypes.In this approach, new objects are created by cloning (shallow-copying)existing objects (the prototypes). The state of the new objects can thenbe set to instance-specific values. Each object conceptually defines itsown object-specific behavior, and may borrow behavior from other objects(called parents) using delegation (instance-level inheritance). Also unlikeSmalltalk, a SELF object accesses its state entirely by sending messagesrather than using special syntax for accessing a variable or changing itsvalue. This results in many messages sent to "self", hence thename of the language. [US87, CUL89]
System Object Model (SOM)
SOM (System Object Model) is a library packaging technology that enableslanguages to share class libraries regardless of the language they werewritten in. This ability to share class libraries between various objectoriented languages solves many interoperability and re-use problems betweenobject oriented and non object oriented languages as well.
Key characteristics of SOM in support of these key commercial requirementsinclude:
- the ability to create portable shrink wrapped binaries
- the ability to create class libraries in one language that can beaccessed and used by other languages
- the ability to subclass from binaries even if they were written ina different language
- the ability to add new methods and relocate existing methods withoutre-compilation of the application
- the ability to insert new classes into the inheritance hierarchy withoutrecompiling the application.
SOM provides an object model distinct from those contained in objectoriented programming languages yet does not interfere with the use of thosemodels in the same application that is using SOM. In addition, SOM canbe used with procedural programming languages thus providing an objectmodel for those languages that do not have one.
SOM consists of an Interface Definition Language (with an accompanyingcompiler), a run-time environment with procedure calls, and a set of enablingframeworks.
SOM is an IBM technology that is being licensed to other companies inanticipation of extending its benefits to heterogeneous environments. Inaddition, a number of language vendors are working on providing nativeSOM capability for their compilers.
OLE Component Object Model
Microsoft's OLE provides an application integration framework for MicrosoftWindows. OLE defines the Component Object Model, which specifiesa programming-language-independent binary standard for object implementations(i.e., it specifies what the implementation of the objects has to looklike). Any object conforming to this standard is a legitimate Windows Object,no matter what language is used to implement it. The programming modelis synchronous, based on a "Lightweight Remote Procedure Call"(lightweight because, at least at the moment, the calls are not reallyremote; they are all made on one machine).
In the Component Object Model, the concept of interface assumesgreat importance. An interface is "a set of semantically relatedfunctions implemented on an object" [Bro94a]. The Component ObjectModel uses the word "interface" by itself to refer to the definition(signatures) of those functions. An implementation of an interface is anarray of pointers to functions. Any code that has a pointer to that arraycan call the functions in that interface. A Windows Object implements oneor more interfaces, i.e., provides pointers to function tables for eachsupported interface.
Users of objects always obtain and act through pointers to object interfaces;users never obtain pointers to an entire object. For example, when theuser of some object first obtains a pointer to the object, the user actuallygets a pointer to one of the object's interfaces. This pointer allows theuser to call only the functions in that one interface's function table.Through this pointer, the user has no access to any state of the object,nor does the user have any direct access to functions in other interfaces.
OLE defines a standard function, called QueryInterface, throughwhich the user of one interface of an object can obtain a pointer to anotherinterface of the same object. QueryInterface is part of an interfacecalled IUnknown, which defines a group of fundamental functionsthat all Windows Objects support (thus IUnknown is supported byall objects). All other interfaces in OLE are derived from IUnknown,so all interfaces contain the QueryInterface function. This insuresthat navigation is always possible between the interfaces of a given object.
Using QueryInterface, the user of an object can discover thecapabilities of that object at run-time by asking for pointers to specificinterfaces. This enables an object to implement as many interfaces as itwants. Because all Windows Objects implement at least IUnknown,there is always some basic way for a user to communicate with any object.
The function table that implements an interface is designed to havea layout that is identical to the one generated by many C++ compilers.This layout allows a single indirection (->) on the pointer to callan interface function. However, while this makes the use of C++ to programOLE convenient, this is not a requirement. An object implementation isonly required to provide separate function tables for each supported interface.How these tables are created can differ, depending on the particular languageused. Because neither use or implementation of a Windows Object is dependenton the programming language used, the Component Object Model is referredto as a binary standard. This provides for language independencewithout involving the definition of a separate language (e.g., an InterfaceDefinition Language).