Object model key
The diagram notation used on the ArcObjects OMDs is based on the Unified Modeling Language (UML) notation, an industry diagramming standard for object-oriented analysis and design, with some modifications for documenting Component Object Model (COM) specific constructs.
OMDs are an important supplement to the information you receive in object browsers. Your development environment—Visual Basic or other—lists all of the classes and members but does not show the structure or relationships of those classes. OMDs complete your understanding of the ArcObjects components.
You can access OMDs from the Help system's table of contents (TOC) by clicking the Namespace reference node, expanding the node for the applicable assembly, expanding the node for the proper namespace named node, then clicking the applicable <Namespace> Object Model Diagram node. You can also access OMDs from their install location at <ArcObjects developer kit install location>\Diagrams.
The following illustration shows the symbology used on OMDs:
Class types
The following are the types of classes shown on UML OMDs:
- Abstract classes—Abstract classes cannot be used to create objects (they are a specification for subclasses through type inheritance). For example, a "line" can be an abstract class for "primary line" and "secondary line" classes. Abstract classes are important for developers who want to create their own subclass (they show which interfaces are required and which are optional for the type of class they are implementing). Required interfaces must be implemented on any subclass of the abstract class to ensure the new class behaves correctly in the ArcObjects system.
- Coclasses—Coclasses represent objects that you can directly create using the object declaration syntax in your development environment.
-
Classes—Classes cannot directly create objects, but objects of a class can be created as a property of another class or instantiated by objects from another class.
See the following illustration:
The previously discussed abstract class example—primary and secondary line classes that each meet the specification of the abstract line class—is an illustration of type inheritance. For more information, see the Type inheritance section in this topic.
Relationship types
The following are the types of possible class relationships among abstract classes, coclasses, and classes:
To keep the OMDs as simple and usable as possible, only key relationships or associations are shown.
Associations
Associations represent relationships between classes and have defined multiplicities at both ends. On the following illustration, an owner can own one or many land parcels, and a land parcel can be owned by one or many owners:
A multiplicity is a constraint on the number of objects that can be associated with another object. Association and composition relationships have multiplicities on both sides. The following is the notation for multiplicities:
- 1—One and only one. Showing this multiplicity is optional. If none is shown, "1" is implied.
- 0..1—Zero or one.
- M..N—From M to N (positive integers).
- * or 0..*—From zero to any positive integer.
- 1..*—From one to any positive integer.
Type inheritance
Type inheritance defines specialized classes that share properties and methods with the superclass, and have additional properties and methods. The following illustration shows that a primary line (creatable class) and secondary line (creatable class) are a type of line (abstract class):
Instantiation
Instantiation specifies that one object from one class has a method with which it creates an object from another class. A pole object might have a method to create a transformer object. See the following illustration:
Composition
Composition is a stronger form of aggregation in which objects from the "whole" class control the lifetime of objects from the "part" class. A pole contains one or many crossarms. In this design, a crossarm cannot be recycled when the pole is removed. The pole object controls the lifetime of the crossarm object. See the following illustration:
N-ary association
An N-ary association specifies that more than two classes are associated. A diamond is placed at the intersection of the association branches. See the following illustration:
Interfaces and members
Interfaces are the access points for development with COM objects. There are inbound interfaces, which expose the properties and methods of a class, and outbound interfaces, which allow the class to interact with other classes. See the following illustration:
For a discussion of COM and the IUnknown interface, see Introduction to COM for ArcObjects developers.
Interface inheritance
Since interfaces in ArcObjects are COM interfaces, they all inherit from IUnknown, which is the basis for COM. Additionally, as shown on the OMDs, some interfaces inherit from other ArcObjects interfaces. If one interface is inherited by another interface, the members of the initial interface are also members of the inheriting interface. For example, since IPoint inherits from IGeometry, the members of the IGeometry interface are also members of the IPoint interface. This inheritance allows you to access the IPoint interface and use the members of IGeometry directly, without needing to query interface (QI) to the IGeometry interface. See the following illustration:
Interface inheritance is used extensively to, in effect, add functionality to existing interfaces. Although the rules of COM dictate that an interface signature—once deployed—cannot change, an interface can be created that inherits from the original interface. For example, the IEditor2 interface extends the IEditor interface with additional members.
Inbound interfaces
Some inbound interfaces are shown on OMDs with special notations that provide information in addition to the usual list of members. See the following:
-
Interfaces defined in other libraries—If the interface name is prefixed with a library name—such as, esriSystem.IName—the interface is inherited from a library other than the one implementing it. The library name reflects the library in which the interface is defined. On the following illustration, the Name abstract class, an object in the GeoDatabase library, is shown. As shown by the library name prefix, the interface implemented by Name is actually defined in the System library.
-
Optional interfaces—Some interfaces can be inherited optionally by other classes. For example, abstract classes can have optional interfaces that can be included or excluded from its subclasses. These are designated by the prefix (Optional). If you are creating a GxView class, you do not need to implement the IGxViewPrint interface to be a GxView class; however, you do need to implement the IGxView interface. See the following illustration:
As a developer, if you intend to utilize an optional interface, verify that the interface was implemented by the object with which you are working. Attempts to access an optional interface that is not implemented, produces a run-time error message. -
Interfaces implemented in select instances—Some classes have varying implementations instead of having multiple classes that inherit from a single base or abstract class. In these cases, certain interfaces are implemented in select instances. For example, the RasterDataset class can be instantiated by different workspace classes depending on the type of data being accessed. When file-based data is used to instantiate a RasterDataset class, the ITemporaryDataset interface is implemented; however, if ArcSDE software-based data is used to instantiate the RasterDataset class, the IRasterPyramid2 interface is implemented. See the following illustration:
Interfaces implemented in select instances are designated with the prefix (Instance). Attempts to access a selected instance interface that is not implemented, produces a run-time error message.
Outbound interfaces
Outbound interfaces, also known as event interfaces, provide notification when a certain event occurs. Interaction with the members of an outbound interface requires that another object exists to catch the event occurrences (this is commonly referred to as an event sink). Event sinks have code that responds when certain events occur, for example, an editing operation.
-
Secondary outbound interfaces (nondefault)—When a class implements more than one outbound event, the secondary interface name is preceded by a class name, for example, (EditEvents2)IEditEvents2, where the class name indicates the name of a Helper class. The Helper class is an artificial coclass that solves the Visual Basic problem with multiple outbound interfaces on an object. See the following illustration:
Interface members
The members of an interface include its properties, which specify the state of an object, and its methods, which perform some action.
Properties are designated as read-only (get), write-only (put), or read_write (get/put). Additionally, the value of a property can be a simple data type, a long for the x-value of a point object, or another class, such as a coordinate system class (for example, GeographicCoordinateSystem) for the SpatialReference property. See the following illustration:
Each property on the OMD is listed with the required or returned data type. The symbolization and syntax of properties that can be set with an object varies based on whether the property is put by value (put) or put by reference. If ObjectG is assigned to a property by value on ObjectM, ObjectG is contained within ObjectM. When an object is passed by reference, an association is formed between the two objects. This is advantageous because an object can be reused in many associations, using less memory space.
Abstract class example
On the following illustration, the Name abstract class implements the IName interface. Its inheritance relationship to all other name objects indicates that they each implement the IName interface as well. Although neither the FeatureClassName nor WorkspaceName coclass shows the IName interface on the OMDs, you know it is there because of this inheritance. The Open() method on the IName interface is used to instantiate the FeatureClass object. This usage guarantees that the new FeatureClass object is properly created and includes all necessary information.
