CA2371050C - Managing object relationships using an object repository - Google Patents

Abstract

A method for maintaining consistency between objects in a computer system by defining relationship patterns. A relationship pattern is a collection of entities having relationships with a common entity called an active entity. A semantic entity is associated with the active entity describing the actions to be performed for updating one or more entities of the relationship pattern in response to modification, copying, or deletion of one or more entities participating in the relationship pattern.

Description

MANAGING OBJECT RELATIONSHIPS USING AN OBJECT
REPOSITORY
CROSS-REFERENCES TO RELATED APPLICATIONS
This application claims priority from the following provisional patent application, the disclosure of which is herein incorporated by reference for all purposes:
U.S. Provisional Patent Application No. 60/131,970 in the names ofYann L. Duparcmeur, et al. titled, "Object Relationship Management System," filed April 30, 1999.
The following commonly owned previously filed applications are hereby incorporated by reference in their entirety for all purposes:
U.S. Patent Application Serial No. 09/258/595 in the names of Mark D.
Fortenbery, et al. titled, "OLE for Design and Modeling," filed February 26, 1999; and U.S. Patent Application Serial No. 09/459,812 in the names of Jean-Louis Ardoin et al. titled, "Object Relationship Management System", filed December 13, 1999.
COPYRIGHT NOTICE
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
The present invention relates generally to the field of object based software systems, and more particularly to techniques for managing relationships between objects of the software systems and maintaining data and referential integrity of the software systems when an object is changed, for example, modified, copied, or deleted.
With the increase in the number of heterogeneous application programs used by consumers, it become increasingly important that these applications be able to communicate with each other in a consistent manner without having to know the implementation details of the applications involved. Traditionally, this was accomplished by using applications developed by a common vendor or by a group of vendors who had agreed upon a common interface between the various applications. While this approach achieved a limited degree of success in integrating heterogeneous applications, the approach soon became unfeasible as the number of vendors and the number of applications rapidly increased.
More recently vendors are attempting to solve the application integration problem by developing applications using object-oriented frameworks and repository technology. Repositories enable sharing and reuse of information by providing a common hub for storing metadata which describes the structure and meaning of software components. Metadata enables heterogeneous applications to manipulate software components without knowing the implementations of the components. To promote sharing and reuse of metadata information among heterogeneous applications, information models are defined to standardize the structure and semantics of the metadata. A repository, using a standardized information model, provides a global and consistent mechanism for accessing metadata for application development.
An example of a repository is the Microsoft Repository developed by Microsoft Corporation of Redmond, Washington. The Microsoft Repository uses the Open Information Model (OIM) for describing metadata specifications and provides an environment for sharing, reuse, and integration of metadata for application development.
Information stored in the Microsoft Repository is exposed using Microsoft's Common Object Model (COM) which forms the basis for the Object Linking and Embedding (OLE) technology which allows objects to share data and capabilities. COM
defines a binary standard for object implementation that is independent of the implementation programming language. COM objects are in-memory representations of the information stored in the repository. A repository may include a object-oriented or relational or mixed database.
The repository information model defines the classes of the objects, types of relationships that can exist between the objects, and various properties that are attached to the object classes and the relationship types. A "class" may contain properties, methods, and collections which are grouped into functionally related groups which are implemented as COM "interfaces." In COM, a class may have multiple interfaces which are publicly accessible to users of the object-oriented framework and enable communication between applications.
A repository object is defined in terms of the interfaces that it exposes.
The set of interfaces that an object exposes describes the object's state, the manner in which the object can be manipulated, and the associations the object can have with other objects. Relationships may also be defined between interfaces of different objects or of the same object. Further information and details about COM and OLE may be obtained from "Inside OLE 2" by Kraig Brockschmidt, 1994, Microsoft Press, and "Inside COM, Microsoft's Component Object Model," by Dale Rogerson, 1997, Microsoft press, both of which are hereby incorporated by reference for all purposes.
Fig. 1 depicts a convention representation of a COM interface 10, for an object 11 (another term for object 11 is component) and a user 12 of the object. Object 11 is said to have an "interface implementation", including interfaces 13 and 14, that are analogous to an object oriented programming "class." Interfaces 13 and 14 include member functions 15 and 16, respectively. User 12 can manipulate object 11 by calling functions 15, and 16 of interfaces 13 and/or interface 14, respectively. In response to the function calls, object 11 may return specific data about itself to user 12.
Object 11, however maintains exclusive control of its own data 17. In some cases user 12 may only be aware of one of several interfaces available in object 12. The available interface may then be queried for additional interfaces. A pointer to the queried interface is returned if the queried interface is supported by the object. For example, the IUnknown interface 13 is a COM interface that is typically available to all users of COM objects.
The IUnknown interface may then be queried to obtain pointers to other interfaces supported by the object, such as interface 14. After obtaining a pointer to interface 14, user 12 can call member functions 16 belonging to interface 14.
As previously stated, relationships may be established between interfaces of one or more objects or between interfaces of the same object. A
relationship describes the way in which one object refers to another object, as exposed through their interfaces.
The participants in a relationship are usually referred to as "entities"
participating in the relationship. Relationships are usually binary, for example relationships in Microsoft Repository, may be directed or bi-directional. A relationship typically includes an origin of the relationship, referred to as the "origin" entity, and a destination of the relationship, referred to as the "destination" entity. In Microsoft Repository, each relationship conforms to a particular relationship type and is associated with an object of the class RelationshipDef. This object contains the metadata associated with the relationship.
Several actions have to be preformed when entities involved in a relationship are changed, for example, modified, copied, or deleted. These operations are important for maintaining referential and data integrity of the object system.

Accordingly, an important aspect of any object-oriented framework system is the manner in which referential and data integrity of the system is maintained when entities involved in a relationship are changed.
Several techniques have been developed for maintaining integrity of the object system when entities participating in relationships are changed. In conventional systems, the actions be performed upon a change operation are usually associated with each occurrence of the relationship. In addition, the code implementing the actions is typically spread through out the object implementation and thus is difficult to understand and maintain. The increased complexity of the implementation also makes it unsuitable for modification or customization.
Thus, there is a need for a relationship management system which allows generalized relationships to be defined between objects and which provides a simplified technique for maintaining referential and data integrity of the object system when objects involved in a relationship are changed.
SUMMARY OF THE INVENTION
One embodiment of the present invention provides a method of maintaining consistency between objects in a computer system. The method includes providing a first relationship between a first entity and a second entity. A
semantic is also provided, including an action to be performed in response to a change in the first entity.
A semantic object is associated with the second entity and making a change in the first entity invokes the action. In a second embodiment, the method may also include providing a second relationship between a third entity and the second entity.
And after the action is invoked, performing the action on the third entity. The action may be selected from a group consisting of copy, delete, and modify.
In another embodiment a computer system for maintaining consistency between objects is provided. The computer system includes a processor; and a memory coupled to the processor. The memory stores relationship pattern information and modules for execution by the processor. The pattern information includes information defining a first relationship between a first entity and a second entity, information defining a second relationship between a third entity and the second entity, and information defining a semantic object with actions to be performed for changing the third entity in response to changes in the first entity. The modules include a module for associating the semantic object with the second entity and a module for invoking the actions when the first entity is changed.
In yet another embodiment a method of assembling information in order to maintain integrity of objects in a database is provided. The method includes establishing S a relationship pattern, having a binary relation between a first entity and a second entity.
A semantic object having an action to be performed in response to a change in the first entity is provided and is associated with the second entity. Metadata having information from the relationship pattern and arguments of the semantic object are then determined.
The metadata and the semantic object are stored. In one embodiment the metadata is stored in a COM or CORBA repository and the semantic object is stored in a DLL
file.
In another embodiment a method for updating information in a database, having a first relation between a first entity and a second entity and a second relation between a second entity and a third entity is provided. A first object of the first entity is next changed. The first relation associated with the first object is identified and using the first relation and repository metadata, the second entity is identified. The second entity is also identified as an active entity. A semantic object associated with the active entity is next found, where the semantic object has an action to be performed in response to a change in the first entity. Using arguments of the semantic object, the third entity is identified. Lastly, the action is evaluated to change the third entity.
In another embodiment a method for providing consistency among persistent objects in a computer system is disclosed. The technique includes using the metadata in a repository to construct a graph having entities and relations; A
semantic object is associated with each active entity. A passive entity having a persistent object is then changed in the graph; and the graph is traversed to update the entities using the semantic objects.
BRIEF DESCRIPTION OF THE DRAWINGS
Fig. 1 depicts a convention for representing COM/OLE interface for an object and a consumer of the object according to an embodiment of the present invention;
Fig. 2 depicts a block diagram of a system incorporating an embodiment of the present invention;
Fig. 3 depicts the various components of a relationship pattern according to an embodiment of the present invention;

Fig. 4 depicts an example of a relationship pattern according to an embodiment of the present invention;
Fig. 5 shows a block diagram illustrating the steps to create metadata for a relationship pattern in a specific embodiment of the present invention;
Fig. 6 shows an example of a relationship pattern that represents two parallel pipes;
Fig. 7 shows a UML diagram describing Fig. 6 of another embodiment of the present invention;
Fig. 8 illustrates two objects: a dimension and a line ;
Fig. 9 illustrates a graphic representation of the COM interfaces for line and dimension of Fig. 8;
Fig. 10 illustrates a UI~IL representation for line and dimension of Fig. 8 using a specific embodiment of the present invention;
Fig. l0A illustrates another UML representation for line and dimension of Fig. 8 using another specific embodiment of the present invention;
Fig. 11 shows a relationship pattern of Fig. 10 at the business model level;
Fig. 12 gives a flowchart illustrating the updating process for one embodiment of the present invention;
Fig. 13 illustrates a UML diagram for parallel lines; and Fig. 14 depicts relationship pattern information for Fig. 13 as seen using a repository browser of one embodiment of the present invention.
DESCRIPTION OF THE SPECIFIC EMBODIMENTS
Fig. 2 is a block diagram of a system 60 incorporating an embodiment of the present invention. System 60 includes a display monitor 61, a computer 62, a keyboard 63, and a mouse 64. Computer 62 includes familiar computer components such as a processor 65, and memory storage devices such as a random access memory (RAM) 66, a disk drive 67, and a system bus 68 interconnecting the above components.
Mouse 64 is but one example of a graphical input device, a digitizing tablet 65 is an example of another. In the embodiment depicted in Fig. 2, system 60 includes a IBM PC
compatible personal computer, running WindowsTM operating system or one of its variants, OLE and COM software developed by Microsoft Corporation, and ASSOC GSCAD product currently under development by Intergraph Corporation. Fig. 2 is representative of one type of system for embodying the present invention. It will be readily apparent to one of ordinary skill in the art that many system types and configurations are suitable for use in conjunction with the present invention.
According to one specific embodiment of the present invention a relationship pattern includes a set of entities related to one common entity by binary relationships and a semantic object. The types ofbinary relationships include dependency and equivalence. A further description is given in United States Patent No.
5,692,184, "Object Relationship Management System," by Jean-Louis Ardoin, et.
al, filed May 9, 1995, assigned to Intergraph Corporation, which is herein incorporated by reference in its entirety for all purposes (referred to herein as "Patent No.
5,692,184") .
For sake of documentation, the common entity in a relationship pattern definition is referred to as an "active" entity. The active entity is, for example, an interface definition or an instance of the Microsoft Repository class InterfaceDef. In this embodiment relationship definitions between entities are stored in the Microsoft Repository and relationship pattern definitions are defined based on the relationship definitions stored in the Microsoft repository, which includes a database.
The set of entities related to the active entity by binary relationships are referred to as "passive" entities. These passive entities are connected to the active entity by membership in one or more binary relationships. A relationship describes the functional way in which the passive entities contribute to or respond to changes in the active entity. Accordingly, a passive entity may serve either as an input entity or as an output entity or as a constraint for a relationship pattern. A cardinality value is associated with each end of a relationship describing the expected number of participants or elements on either side of a relationship. The cardinality may comprise zero or more elements. When a relationship has a directionality, i.e., a dependency relationship, then one end of the relationship is called the "origin" while the other end of the relationship is called a "destination." The cardinality and/or end designation, i.e., origin or destination, of each end of a binary relationship is called a "role." It should be noted that the words "active" and "passive" are used only for documentation purposes and do not in any manner limit the scope of the present invention.
The semantic object describes actions to be performed to maintain referential and data integrity of the object system or database when any entity of a relationship pattern is changed, for example, modified, copied, or deleted.
The actions include a delete action describing processing to be triggered when a relationship pattern entity is deleted, a copy action describing processing to be triggered when a relationship pattern entity is copied, and one or more modify (or "compute") actions describing processing to be triggered when a relationship pattern entity is modified or a computation on an objects) is performed. A semantic object is a functional unit and does not store any state information about the relationship pattern from one invocation to the next. In one embodiment a semantic object is realized as a COM interface, for example, IJCompute, for the compute/modify semantic object.
The semantic object has one or more arguments related to the semantic object by repository relationships. The arguments include the relationship type.
Typically, the arguments are part of information that provides a navigation path from the active entity to the passive entity/entities. An argument may be classified as input, output, or constraint, where constraint occurs in an equivalence relationship.
A semantic object may be associated with any interface in the object system. The interface with which the semantic is associated becomes the active entity.
This facilitates the extensibility of the obj ect system. Further, in one embodiment of the present invention, the arguments of a semantic object and their type in the relationship pattern, i.e. input, output, or constraint, are readily definable. This improves ease of use of the object system.
In sum, in one embodiment, a relationship pattern includes an active entity, one or more passive entities, the binary relationships with accompanying roles, and a semantic object.
Fig. 3 depicts an example of a relationship pattern 70 entities A 72, B 74, C 76, D 78 and semantic object 80. Entity C 76 is the active entity since it is the common entity which is involved in a binary relationship with the other entities in the relationship pattern. Entities A 72, B 74, and D 78 are passive entities. Fig. 3 also shows three binary relationships: Relation A 81, Relation B 86, and Relation C 88. Relation A 81 shows a dependency relationship with a Origin 82 and a Destination 84, where Origin 84 and Destination 86 are two roles of Relation A. A semantic object 80 is associated with active entity C 76 and controls the processing to be triggered, in the context of an active entity, when an entity belonging to the relationship pattern is change, for example, modified, copied, or deleted.
Fig. 4 depicts an example of a relationship pattern 100 including active entity IJMakeParaAtDistance 102 and three passive entities 104, 106, and 108 defined as IJDLine interfaces. Entities 104 and 106 are the input entities while entity 108 is the output entity for relationship pattern 100. According to the relationship pattern of Fig. 4, output entity 108 is drawn parallel to input entity 104 and at a predetermined distance from input entity 106. Passive entity 104 is in a relationship "Para11e1To"
120 with active entity 102, passive entity 106 is in a relationship "DistanceFrom" 122 with active entity 102, and output passive entity 108 is in a relationship "MakeParallelAtDistanceResult (MPADResult)" 124 with active entity 102. Further, all three relationship have a 1-1 cardinality on the origin of the active entity relationship. This implies that one IJDLine entity 108 established via relationship MPADResult 124 is parallel to one IJDLine entity 104 established via relationship Para11e1To 120 and a specific distance from one IJDLine entity 106 established via relationship Distancefrom 122. The cardinalities on the destination sides of the relationship are 0-1 implying that the IJDLine entities do not have to be in the relationship, but if they are, then at most one JDLine can be in the relationship. There are several roles, for example, 120-a, 120-b, 122-a, 122-b, 124-a, and 124-b. An illustrative example is the roles for the "Para11e1To" 120 relationship, which are "Para11e1ToDestination: 0..1" 120-a on the destination side and "Para11e1ToOrigin:
0..1" 120-b on the origin side A semantic object 130 is associated with active entity 102. Semantic object 130 shown in Fig. 4 has an accompanying evaluate method, which recomputes the output entity when changes are made to the input entities 104 or 106. In one embodiment the semantic object 130 is implemented as a COM object. An example of a class definition, i.e., COM object, for the MakePara11e1ComputeSem semantic object 130 is:
Class CMakePara11e1ComputeSem : IJCompute ( public:
STDMETHODIMP Evaluate( LPENUMJARGDESC
pRelatedValues );
STDMETHODIMP PreValueModify( LPJARGDESC
pPreModifyValue, LPENUMJARGDESC pArgsOfsemantic );
IJCompute is the base class for CMakePara11e1ComputeSem and is the interface for Class CMakeParallelComputeSem. In one embodiment IJCompute may have the following format:
Interface IJCompute: ILTnknown IJCompute::EnumValues Enumerates the arguments of the semantic and qualifies them as input / output / constraint. A return code of RELATION_S_IMPLICIT_L~PUT / OUTPUT indicates that entities enumerating the corresponding relation should be considered as argument of the semantic even if not enumerated by this function IJCompute::Evaluate Asks the semantics) to update its output after a change of one or more of its inputs. This function is called only if arguments of the semantics have been actually been modified.
IJCompute::GetSolver Only used on constraint to fmd the corresponding constraint solver.
IJCompute::PreValueModify Tells the semantics) that the passed in argument is about to be modified. This occurs before the modification actually happens. The modification could come from a command, a recompute semantic or a solver.
IJCompute::ImplementDeferOrError Indicates if the semantic is defer / error aware.
The code implementing the Evaluate method may be, for example, the following (stub format):
STDMETHODIMP CMakeParallelComputeSem::Evaluate (LPENIJMJIDREF pRelatedValues) // Code to recompute the output entity 108 when changes are made // to the input entities 104 or 106 return S OK;
The MakeParallelComputeSem semantic object 130 takes two input arguments, Parellelto:IDJLine=INPUT 132, and DistanceFromOrgin:IDJLine=INPUT
134 and one output argument, MPADResult:IDJLine=OUTPUT 136. In alternate embodiments, a delete and copy semantic may also be associated with active entity 102.
For the example of Fig. 4, active entity 102 exists solely for providing a context around which to build the relationship pattern. The active entity is thus an interface to a "stub"
object. However, in alternate embodiments a "real" object or a business object may also act as an active entity.
Fig. 5 shows a block diagram illustrating the steps to create metadata for a relationship pattern in a specific embodiment of the present invention. First the relationship pattern is described (step 210) either using an informal figure such as Fig. 4 or using a Universal Modeling Language (UML) diagram. Next the passive entities must be created or located using a GUID (Globally Unique Identifier) or a IID
(Interface Identifier) - OBJID (Object Identifier) pair (step 212). The active entity is then created or located (step 214) using another GUID or IID-OBJID pair. In step 216 the relationships between the active entity and one or more passive entities are added. These binary relationships may have a cardinality and/or a direction. The relationships may have roles, for example, a dependency relationship has an "Origin" role and a "Destination" role.
The semantic objects) is declared (step 218) and any arguments that the semantic needs to function are identified (step 220). The preceding steps created metadata that at step 222 can be stored in the Repository.
Fig. 4 may be used as an example of using the steps of Fig. 5 for creating metadata for the Repository, in a specific embodiment. The code is in Appendix 1, which is incorporated herein. The ASSOC update engine is given in Appendix 2, which is incorporated herein. Fig. 4 describes the relationship pattern (step 210).
At step 212 OBJIDs and IIDs for passive entities are declared. A
relationship pattern uses objects via their interfaces. Thus the object-interface pairs for all passive contributors to each relationship in the pattern need to be specified.
In our example, we have the same JDLine accessed via its IJDLine interface for each of the three relationships 120, 122, and 124. Thus we define an OBJID (which is a GUID
appended by a long identifier) and refer to an existing IID. This GUID should be the same as the interface IID to be used.
// Define OBJID and IIDs that serve as (Passive) JDLines define IID IJDLine Ox260E0A 1 F Ox04F 18 Ox 11 D 1 0x97 0x70 0x08 Ox 00 0x36 0x75 0x42 Ox 03 define OBJID JDLine Ox260E0A 1 F Ox04F 18 Ox 11 D 1 0x97 0x70 0x08 Ox 00 0x36 0x75 0x42 Ox 03 0x00 Now that the participating OBJID and IID are specified, an interface for the Repository may be created. The createINTERFACE key word is used, followed by the participating OBJID and IID:
createINTERFACE IJDLine objid JDLine iid IJDLine Note that we could have called the OBJID, IID and INTERFACE by any names we chose. It is not the name ("IJDLine") but the actual value of the IID that marks it as an IJDLine interface.
At step 214 an OBJID and IID for the active entity is declared. In our example, the active entity is a stand-alone. That is, it exists for the sole reason of tying the passive entities of the relationship pattern together, and does not have serve as an independent business object. The name of the active object is:
MakeParaAtDistanceHub and its corresponding interface: IJMakeParaAtDistanceHub. The process in step 214 is similar to step 212.
define IID IJMakeParaDistanceHub Ox42D921B7 0x7567 OxllDl OxBD 0x31 0x08 0x00 0x36 OxF4 0x17 0x03 define OBJID IJMakeParaDistanceHub Ox42D921B7 0x7567 Ox11D1 OxBD 0x31 0x08 0x00 0x36 OxF4 0x17 0x03 0x00 createINTERFACE IJMakeParaDistanceHub objid IJMakeParaDistanceHub iid IJMakeParaDistanceHub In step 216, we define the participating relationships and roles. Our example incorporates JDLines as the passive entities in all relationships, of which there are three: "Para11e1To", "DistanceFrom" and "MPADResult". The following shows the code for specifying the "Para11e1To" relation. The full specification for all three relations can be found in Appendix 1.
First, we define an OBJID for the relationship and name it "ParallelTo".
Then we create a GUID using the GuidGen tool (in Visual C++) and with the addition of a long integer, we get:
~2 define OBJID ParallelTo OxE6FAEAE2 Ox77BA Oxl ldl OxBD 0x33 0x08 0x00 0x36 OxF4 0x17 0x03 0x00 Having defined a OBJID for "Para11e1To", we use it in the createRELATION declaration and name the relation "ParallelToRelation ". We specify the origin as IJMakeParaDistanceHub (and name the origin role "ParallelToOrigin"), the destination as IJDLine (and name the destination role "Para11e1ToDestination"), and the type as COLLECTION NAMING:
createRELATION ParallelToRelation Origin IJMakeParaDistanceHub ParallelToOrigin Destination IJDLine ParallelToDestination Type COLLECTION NAMING
The other two relationships are declared similarly (with different GUIDs, of course).
In step 218 a semantic object is declared. Our example has only one semantic, compute. We declare a compute semantic named MakeParallelComputeSem.
The process begins with defining an OBJID, in this case the identifier of our semantic instance:
define OBJID MakeParallelComputeSem OxE6FAEAE4 Ox77BA
Ox 11 d 1 OxBD 0x33 0x08 0x00 0x36 OxF4 Ox 17 0x03 Ox 10 Next an instance of the semantic object is created (using the createINSTANCE SemanticDef key phrase) and is connected to the relationship pattern active entity, IJMakeParaDistanceHub (using the ConnectTo key word). In the ConnectTo statement, we specify an interface (IHoldSemantic) and a collection name (Semantics). This is the collection of semantics managed by this active entity. The active entity knows nothing about this collection of its semantics; it is the act of defining them to the Repository via these statements that actually connects them. This is a major advantage of the metadata approach: entities and relationships and patterns and semantics can all be glued together outside the compiled code. The syntax is:
createINSTANCE SemanticDef MakeParallelComputeSem ConnectTo IJMakeParaDistanceHub IHoldSemantic Semantics ~3 A semantic has two properties: Property 1 is the type of semantic:
Compute, Delete or Copy; and Property 2 is the progid of the object that provides the semantics' implementation. Our type is Compute.
setPROPERTY MakePara11e1ComputeSem ISemantic noname type char index 1 value Compute setPROPERTY MakeParallelComputeSem ISemantic noname type char Index 2 value AnchorSemantics.MakePara11e1Compute.l We next declare the arguments of the semantic at step 220. Our semantic has three arguments. The first two are input arguments that provide the parallel line and the distance line. The third argument is the output line. The declaration of the parallel input line is shown below. The other two are similar (see Appendix 1).
We begin declarations by creating OBJID's. Each argument has a corresponding OBJID. We name each argument according to the relation that it represents. We then connect each argument to the semantic. Note that the use of the ConnectTo keyword in this situation employs an additional argument following the collection name (Arguments): the index (1, 2, or 3) of the argument. This determines the order of arguments evaluated by the Evaluate method.
define OBJID Para11e1To_Arg OxE6FAEAES Ox77BA Oxl ldl OxBD 0x33 0x08 0x00 0x36 OxF4 0x17 0x03 0x00 insertINSTANCE ArgumentDef Para11e1To Arg ConnectTo MakeParallelComputeSem ISemantic Arguments 1 Each argument has two properties. Property 1 specifies whether the argument is INPUT or OUTPUT. Property 2 specifies the OBJID of the relationship)to which this argument corresponds.
setPROPERTY Para11e1To_Arg IHaveArguments noname type char Index 1 value INPUT
setPROPERTY ParallelTo Arg IHaveArguments noname type OBJID
Index 2 value ParallelToRole At step 222 MakeRepos is used to build the target Repository file and thus store the metadata in the Microsoft Repository.
Fig. 6 shows an example of a relationship pattern 300 that represents two parallel pipes(oriented relationship) 310 and 312 with the direction and distance that is given by a line 314. In short, the second pipe 312 is parallel to the first pipe 310 at a distance equal to the length of the line 314 and using the line 314 for the direction.
Fig. 7 shows a UML diagram 400 describing Fig. 6 of another embodiment of the present invention. The UML shows this relationship pattern by using an interface hub, IJXFormPipe (active entity) 410 that has relations 412, 416, 418 to the passive entities, IJDPipe 422 and IJLine 424, and is tied to the compute semantic SXFormPipe 450. The descriptions of various metadata of one embodiment of the present invention that can be stored in a Repository are given in Appendix 3. The extensions to UML for one embodiment of the present invention are given in Appendix 4. Both Appendices 3 and 4 are incorporated herein.
In order to create metadata to be stored in the Repository for this embodiment using the example UML diagram of Fig. 7, the steps in Fig. 6 are followed, although not necessarily in the same order. Step 210 describes the relationship pattern in the UML diagram of Fig. 7. In step 212 the passive entities 422, 424 need to be added. A
class IJDPipe is first added:
In the TypeInrepository "Value" column, change the value to Interface Change the "Value" of GUID and put in the GUID of IJDPipe:
{EOC4E513-6EBD-11 D2-BDEF-080036801 C04}
There are two ways to find the GUID of an interface: (1) look at the corresponding .idl file where the interface has been defined, or (2) use the registry (regedit) and do a search for the interface name such as IJDPipe 422. Next the IJLine 424 interface is added. For this example it is assumed the IJLine interface already exists. In step 214 the active entity, IJXFormPipe 410, is added:
In the TypeInrepository "Value" column, change the value to Interface Change the value of GUID and put in the GUID of IJXFormPipe:
{4AC243C0-70F8-11D2-BDEF-080036801 C04}

In this embodiment step 218 is performed before step 216. In step 216 a semantic object is added by adding a class SXFormPipe 450:
In the TypeInrepository "Value" column, change the value to Semantic Change the "Value" of SemanticType to Compute Change the "Value" of SsemanticProgID to SXFormGSCADPipe.SXFormPipe.l. (It is the ProgID of the compute semantic.) Next an association, TieToSXFormPipe, is created between IJXFormPipe 410 and SXFormPipe 450.
At step 216 binary relationships are added:
Create an association between IJDPipe and IJXFormPipe:
Name: InputPipe 412 Role A (IJXFormPipe side): InputPipeDst 420 Role B (IJDPipe side): InputPipeOrg 422 GSCD B Tab, change IsOrign: True Create an association between IJDPipe and IJXFomzPipe Name: OutputPipe 416 Role A (IJXFormPipe side): OutputPipeDst 426 Role B (IJDPipe side): OutputPipeOrg 424 GSCD B Tab, change IsOrign: True Create an association between IJXFormPipe and IJLine Name: InputTranslation 418 Role A (IJLine side): InputTranslationOrg 428 Role B (IJXFormPipe side): InputTranslationDst 430 GSCD A Tab, change IsOrign: True At step 220 the arguments of the semantic are defined for SXFormPipe:
InputPipeOrg, SXFormPipe, String, Input 452 InputTranslationOrg, SXFormPipe, String, Input 454 OutputPipeOrg, SXFormPipe, String, Output 456 At step 222 our LTML model, i.e., Fig. 7, is defined with all the necessary information (metadata) needed to define the relationship pattern for Fig. 6 and can be exported to the Repository.
In one embodiment of the present invention, after the metadata is created and deposited and the semantic objects defined, changes to a passive entity may be propagated consistently through the system by using the metadata and the semantic object(s). Use of the information in the relation objects and/or the active entities, i.e., at the business model level, is not needed, as opposed to prior art which needed to access to one and/or the other. An example will show the differences.
Fig. 8 illustrates two objects: a dimension 512 and a line 510 and is described in Fig. 8 of Patent No. 5,692,184. In this example, the dimension 512 depends on the line 510 such that whenever the geometry of the line 510 changes the dimension 512 is re-calculated.
Fig. 9 illustrates a graphic representation of the COM interfaces for line 510 and dimension 512 of Fig. 8 and is described in Fig. 9 of Patent No.
5,692,184 (col.
63, line 49 to col. 64, line 37). The three nodes in the associative graph are a value node 530 representing the line's geometry (identified by line 540, and interface IJLine 550), a function node 560 representing the evaluation function, "ComputeCFun,"
(identified by interface IJCompute 520), and a value node 570 representing the line's dimension (identified by dimension 580, and interface IJDimension 590).
The evaluation function of function node 560 is called every time the IJLine interface 550 is changed. The evaluation function determines how the output entity, in this case IJDimension 590, is modified due to the change in input entity, IJLine 550. The evaluation function is accessed through its interface IJCompute 520, which is in turn accessed through IJRelation 515. Thus the evaluate function is accessed through a relation interface (IJRelation 515) and its interface, IJCompute 520 is part of the dimension object 570, 580.
Fig. 10 illustrates a UML representation for line 510 and dimension 512 of Fig. 8 using a specific embodiment of the present invention. Besides the IJLine Interface 550 (input passive entity) of Line object 610 and IJDimension interface 590 (output passive entity)of Dimension object 612, there is a IJHub interface 620 (active entity)for the hub object 614. IJHub 620 has no method or properties and serves solely as a hub between the two passive entities 550 and 590. There are two binary relationships, Relation A 622 and Relation B 624. The relationships 622 and 624 are different than those of Fig. 9, IJRelationValue 517 and IRelation 515 above, in that 622 and 624 do not point to a function. In one embodiment the evaluation function is in the semantic object 630 and is accessed through the IJCompute interface (not shown). The semantic has two arguments: Relation A: IJLine = INPUT 632 and Relation B: IJDimension = OUTPUT
634. Thus the semantic object 630 is separate from the entities X50, 590, and 620.

Fig. l0A illustrates another UML representation for line 510 and dimension S 12 of Fig. 8 using another specific embodiment of the present invention. In this embodiment the IJDimension interface 590 has been combined with the IJHub interface 620 into IJDimension 640. IJDimension 640 is both a passive entity, as it receives the output of the semantic object 656, as well as active entity, as it tied to the semantic object 656. Note that more than one semantic may be associated with one active entity. The relationship between IJLine 550 and IJDimension 640 is SpecialRelationForThatPattern 650 and it has an origin role 652 and a destination role 654.
Fig. 11 shows a relationship pattern of Fig. 10 at the business model level.
Fig. 11 has instances of the classes given in Fig. 10 and has no semantic object 630.
"xxx" 610-a is an instance of class Line 610. "yyy" 612-a is an instance of class Dimension 612. "Instance of Hub" 614-a is an instance of class Hub 614. There is also an instance 622-a of Relation A 622-a and an instance 624-a of Relation B 624-a. Thus a change on "xxx" 610-a may cause a change in "yyy" 612-a. However, how the change is accomplished is not part of the business level, but is part of the metadata and semantic object (see Fig. 10).
Fig. 12 gives a flowchart illustrating the updating process for one embodiment of the present invention. At step 710 the value of an object is changed for example, modified (or the object may be deleted or copied). Next at step 712 the relations associated with the changed object are identified. At step 714 the metadata is examined to find the active entity that has a relation to the changed object.
A semantic objects) is then identified for the active entity (step 718). The other passive entities are identified by following the relations (given in the semantic object arguments ) from the active entity (step 720). A list is created of the passive entities, where each passive entity is qualified with a input/output/constraint identification (step 722). The IJcompute interface for the semantic is called and the Evaluate method is performed on the list of qualified entities, and the output (and some constraint) objects) is updated with the results) of the Evaluate method (step 724). Note the evaluate method is in charge of updating the output object(s).
An example of the steps in Fig. 12 applied to Figs. 10 and 11 is:
1. Modify a line (interface IJLine 5~0 on object xxx 610a).

2. Look at the relations enabled on object xxx 610a and find an instance of Relation A 622-a.
~B

3. Look in the metadata for the definition of relation A 622 and see that relation A 622 is attached to IJHub 620.

4. Look at all the semantics associated to IJHub 620 and find semantic object 630.

5. Look at the arguments 632, 634 of that semantic object 630 and find one that takes Relation A:IJLine 632 as input. If a line was attached to IJHub using another relation type, e.g. Relation Z, the semantic would not need to be triggered. From now on the semantic must be triggered to update the outputs. Look in the metadata for the other arguments required and find IJDimension 590 following Relation B 624 from IJHub 620.

6. Navigating the instances, construct a structure containing a pointer on xxx.IJLine (qualified as INPUT) and a pointer on yyy.IJDimension (qualified as OUTPUT).

7. Look at the CLSID(Class Identifier) associated with the semantic in the metadata. The CLSID is an identifier used to get the filename of the DLL
(Dynamic Link Library) file containing the semantic object 630.

8. Cocreate the object having CLSID found in step 7 and query its IJCompute interface. "CoCreateInstance" creates an instance of the semantic object 630.

9. Call the evaluate method on the IJCompute interface of step 8 with the arguments of the structure constructed in step 6. The evaluate method updates the Dimension (interface IJDimension 590 on object yyy 612-a).
By using the metadata types and the associative graph and applying the steps in Fig. 12, consistency can be maintained for any number of persistent objects or any objects in a object-oriented or relational database (persistent objects is further described in "The Essential Distributed Objects, Survival Guide," Robert Orfali, Dan Harkey, and Jeri Edwards, 1996, John Wiley and Sons, which is herein incorporated by reference. Thus a change in one entity could be propagated though out the persistent objects or database. This is accomplished by using the metadata to construct the associative graph starting from the changed entity and then traversing the graph to update the connected entities.
Fig. 13 illustrates a UML diagram for parallel lines. The output line (with XFormResult relation 802) is parallel to the Model line (with XFormModel relation 804) and is at distance and direction given by a translation line (with XFormTranslation relation 806). IJDLine 810 is a passive entity. IJCopyXForm 812 is an active entity.
SCopyXForm 814 is the semantic object tied to the active entity 812.
Fig. 14 depicts relationship pattern information for Fig. 13 as seen using a repository browser of one embodiment of the present invention. The active entity ICopyXForm 812 is displayed in a tree format. IJDLine 810 is also displayed (not shown on Fig. 14) on the same level as ICopyk~orm 812. Semantic SCopyXForm 814 has a collection of arguments associated with it including arguments XFonnModelOrigin 816, XFormTranslationOrigin 818, and XFormResultOrigin 820. The arguments are qualified as input, output, or constraint arguments as indicated by the "the type of argum..."
property 830. Accordingly, Fig. 13 depicts that the XFormModelOrigin entity is an input argument 816. The "type of the Relship" property 832 indicates which relationship to follow to find the argument starting from the active entity. It should be noted that the active entity itself may be qualified as an input, output, or constraint argument to the semantic associated with the relationship pattern definition.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. Other embodiments will be apparent to those of ordinary skill in the art. For example, embodiments of the present invention could be realized using CORBA (Common Object Request Broker Architecture) rather than COM. A comparison is given in the text "COM and COBRA
Side by Side," by Jason Pritchard, Ph.D, 1999, Addison-Wesley and is herein incorporated by reference in its entirety for all purposes. Thus, it is evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the appended claims and their full scope of equivalents.

///////////////////////////////////////////////////////////////////////
// Add new TIM (type information model)for the purpose of adding a // new relationship pattern, S // IJMakeAnchorLineParallelAtDistance.
CreateTIM AnchorParallelAtDistance-TIM
///////////////////////////////////////////////////////////////////////
// Declare Passives for relationships.
// IJMakeAnchorLineParallelAtDistance uses only LTDLines, so here // define IJDLine IID, OBJID and declare Interface/Objid connection // The value of the IID comes from the IDL file in the project that // creates IJDLine define IID IJDLine Ox260E0A1F Ox4F18 OxllDl 0x97 0x70 0x08 0x00 0x36 0x75 0x42 0x03 1 S define OBJID JDLine Ox260E0A1 F Ox4F 18 Ox 11 D 1 0x97 0x70 0x08 0x00 0x36 0x75 0x42 0x03 0x00 createINTERFACE IJDLine objid IJDLine iid IJDLine ///////////////////////////////////////////////////////////////////////
// Declare Active Entity for a relationship pattern.
// define IJMakeParaDistanceHub IID, OBJ)D and INTERFACE connection define IID IJMakeParaDistanceHub Ox42D921B7 0x7567 Oxl 1D1 OxBDOx31 0x08 0x00 0x36 OxF4 0x17 0x03 define OBJID IJMakeParaDistanceHub Ox42D921B7 0x7567 Ox11D1 OxBDOx31 0x08 0x00 0x36 OxF4 0x17 0x03 createINTERFACE IJMakeParaDistanceHub objid IJMakeParaDistanceHub iid IJMakeParaDistanceHub ///////////////////////////////////////////////////////////////////////
// Declare relationships that participate in Pattern.
//
// Declare Parallel-defining a relationship // ParallelToRelation. Use GuidGen, DEFINE-GL'ID format, and delete // extraneous stuff, then tack on long "0"
define OBJID ParallelToRelation OxE6FAEAE2 Ox77BA Oxl ldl OxBD 0x33 0x08 0x00 0x36 OxF4 0x17 0x03 0x00 createRELATION ParallelToRelation Origin IJMakeParaDistanceHub ParallelToOrigin Destination IJDLine Para11e1ToDestination Type COLLECTION NAMING
///////////////////////////////////////////////////////////////////////
// Declare Distance-defining Relation DistanceFromRelation.
define OBJID DistanceFromRelation OxE6FAEAE6 Ox77BA Oxl ldl l OxBD 0x33 0x08 0x00 0x36 OxF4 0x17 0x03 0x00 createRELATION DistanceFromRelation Origin IJMakeParaDistanceHub DistanceFromOrigin Destination IJDLine DistanceFromDestination Type COLLECTION NAMING
///////////////////////////////////////////////////////////////////////
// Declare Result-defining Relation MPADResultRelation.
define OBJID MPADResultRelation OxE6FAEAEB Ox77BA Oxl ldl OxBD 0x33 0x08 0x00 0x36 OxF4 0x17 0x03 0x00 createRELATION MPADResultRelation Origin IJMakeParaDistanceHub MPADResultOrigin Destination IJDLine MPADResultDestination Type COLLECTION NAMING
///////////////////////////////////////////////////////////////////////
// Declare a compute semantic: ComputeParaDistance. Note that in // this case, the long ID is 0x10 as opposed to our customary 0x00 define OBJID ComputeParaDistance OxE6FAEAE4 Ox77BA Oxl ldl OxBD 0x33 0x08 0x00 0x36 OxF4 0x17 0x03 0x10 ///////////////////////////////////////////////////////////////////////
// Create an instance of the semantic and attach it to the // relationship pattern via Active: IJMakeParaDistanceHub // Then set Property 1 (type of semantic: Compute) and Property 2 // (progid of object that provides semantic implementation).
// IHoldSemantic & ISemantic are defined in IMSCoreRelPats.RLP
createINSTANCE SemanticDef MakeParallelComputeSem ConnectTo IJMakeParaDistanceHub IHoldSemantic Semantics setPROPERTY ComputeParaDistance ISemantic noname type char index 1 value Compute setPROPERTY ComputeParaDistance ISemantic noname type char Index 2 value AnchorSemantics. ComputeParaDistance.l ///////////////////////////////////////////////////////////////////////
// Declare semantic arguments. Each argument has a corresponding // OBJID. We will name each argument according to the Relation it // represents. We connect each argument to the semantic. Note that // the ConnectTo keyword uses an extra argument when connecting // arguments: the index (1, 2, or 3) of the argument. This specifies // the order of arguments evaluated by the Evaluate method.
// ArgtunentDef & IHaveArguments are defined in IMSCoreRelPats.RLP
define OBJID ParallelTo_Arg OxE6FAEAES Ox77BA Oxl ldl OxBD 0x33 0x08 0x00 0x36 OxF4 0x17 0x03 0x00 insertINSTANCE ArgumentDef ParallelTo Arg ConnectTo ComputeParaDistanceObjid ISemantic Arguments 1 ///////////////////////////////////////////////////////////////////////
// Each argument has two properties: Property 1 specifies whether // the argument is INPUT or OUTPUT. Property specifies the GUID of // the Relation (e.g., relationship) to which this argument corresponds setPROPERTY ParallelTo Arg IHaveArguments noname type char Index 1 value INPUT
setPROPERTY Para11e1To Arg IHaveArguments noname type GUID
Index 2 value Para11e1ToRelation ///////////////////////////////////////////////////////////////////////
// Declare DistanceFrom argument define OBJID DistanceFrom Arg OxE6FAEAE7 Ox77BA Oxl ldl OxBD 0x33 0x08 0x00 0x36 OxF4 0x17 0x03 insertINSTANCE ArgttmentDef DistanceFrom Arg ConnectTo ComputeParaDistanceObjid ISemantic Arguments 2 setPROPERTY DistanceFrom Arg IHaveArguments noname type char Index 1 value INPUT

setPROPERTY DistanceFrom Arg IHaveArguments noname type GUID
Index 2 value DistanceFromRelation ///////////////////////////////////////////////////////////////////////
// Declare MPADResultRelation argument. Note that it is an OUTPUT argument define OBJID MPADResultRelation_Arg OxE6FAEAE9 Ox77BA Oxlldl OxBD33 0x08 0x00 0x36 OxF4 0x17 0x03 insertINSTANCE ArgumentDef MPADResultRelation Arg ConnectTo ComputeParaDistanceObjid ISemantic Arguments 3 setPROPERTY MPADResultRelation A IHaveArguments noname type char Index 1 value OUTPUT
setPROPERTY MPADResultRelation A IHaveArguments noname type GUID
Index 2 value MPADResultRelation ///////////////////////////////////////////////////////////////////////

< , ",--2.3 Semantics In A Recompute Graph Assoc recognizes two kinds of semantics: associative functions and constraints. This paragraph will describe them. It will also introduce solvers and interface dependencies, that play also an active role during the update process.
2.3.1 Associative Functions Consider a cell in a spreadsheet that calculates the sum of a row of numbers.
Whenever a number in the row is modified, the sum is updated. In associative terms, this would be the result of an associative function which ~ takes for input the row of numbers ~ produces the relevant sum for output.
We say that the sum depends on the numbers in the row. Notice that you cannot directly edit the sum.
The sum only exists as the output of the dependency relation. To change the sum you must change one or more of the values it depends on or make the sum depend on a new set of values. You can only affect the output of a recompute semantic by changing its input.
Now, consider another cell that calculates an average by dividing the sum.
When a number in the row is changed: the sum would be updated first then the average would be updated.
associative functions imply an ordering of evaluation When an associative function is evaluated, it entirely replaces its output value. For this to produce predictable results:
~ A value cannot be the output of more that one associative function. If this were the case, it could not keep a consistent and predictable content. It would only represent the result of which ever function was evaluated last.
~ If declared output, the value can only be changed by the re-evaluation that declares it output.
As seen in the spreadsheet example above, you cannot directly edit an associative output. Any direct modification of an output would be over-written at the next re-evaluation of the function which declares it output.

For example, suppose a .,unction that sets the start and end points of a line:
"Lino...y2Pts(Line, P1,P2)" is an associative function that has a line for its output. When called, this function updates the geometry of the line from the input values P1, P2. If either of the two points changed, the evaluation function would compute a new value for the line. Notice that if the line is modified without modifying the associative function, nor the input point, the evaluation function LineBy2Pts function is re-evaluated, and post back to the line its initial geometry. You can never directly modify the output of a dependency relation.
2.3.2 Constraints In case of constraint, the related entities play sytrtmetrical roles. Both can be edited and it may have an effect on the other entity in relationship.
Consider a graphics system that can create a parallel constraint between two lines: linel and line2.
The end-user can grab line 1 with the mouse and move it. In response, the system moves line2 so that it remains parallel to linel.
The end-user can also move line2 and the system would move line 1 to remain parallel.
In associative tetzns, the lines would be in an constraint relationship.
Notice the difference between dependency and constraint ~ In the dependency example above you could not directly modify the sum.
~ In contrast, in an equivalence relation any of the entities tray be modified. (Outputs are treated equally with inputs.) Equivalence is not a one-way relation. Because of this, there is no possible ordering. An associative application updates equivalence relations by examining a set of entities and their related constraints as a whole. A decision is made as to which entities can be modified to satisfy all of the constraints.
A predicate or constraint is used to define an equation or a constraint between values.
Several simultaneous predicates can be associated to the same value.
Therefore, unlike an associative function, a predicate onlypartially defines a value(s). An external mechanism, called asolver , is used to modify value respecting all the predicates applied to it. (However, if a value that is the output of an associative function is used as an argument of a predicate, it cannot be modified by a solver .
The solver treats these as a "constant".) For example, suppose a predicate that constraints the begin point of a line to match a given point:
"IsBeginPoint(LO,P1)". The line geometry is only partially defined by this predicate. If LO or P1 changes, the predicate, LO and P1 are passed to a solver. The solver would modify LO or P1 to make LO's begin point coincident with P1. If any other values were related by predicates to LO and P1, those values along with their predicates would be passed to the solver at the same time.
2.3.3 Solvers Constraints end up being quite inactive during the update process : They ~ enumerate their arguments and qualifies them input / constraint ~ Indicates which solver to use for that type of constraints, the dialog to get from the solver the nature of the constraint being established by interface that Assoc is not aware of.
And that's up to the solver to find the adequate solution.

The solver is given as argument a list of values (qualified input or constrained) a list of constraints, and for each the list of values that the constraint take for argument. These constraints will implement additional interfaces, that Assoc is not aware of.
The solver can query them additional information, example the type of the constraint.
An argument that a constraint enumerates and qualifies CONSTRAINED may be presented to the solver INPUT only because the same value is output of another semantic.
2.3.4 Internal Granularity For Values Coming From the Same Object An argument of a recompute semantic is a pair (pObject,IlD). This means that a single COM object may become several values in the recompute graph. (The I1D may be an interface implemented by the COM object, or just a 'virtual interface', only defined to support relationship connection, without an associated Vtable, as MS Repository does.
But are these values totally independent the one from the other? Is the value obtained from (pObject, IID 1), affected by what's posted on (pObject,IlD2)?
That's why Assoc is adding additional recompute semantics when a COM object plays the role of several value in the recompute graph. This is such that Ordering of semantic outputting to the object versus semantics taking their input from the same object is correct ~ Propagation of the MODIFIED bit is done correctly In 0.5, all the values coming from the same COM object are considered independent the one from the other. The version 1.0 will complete this and detail how to describe this interface dependency in meta data.
These concepts will be discussed paragraph 2.7 of this document.
2.4 Update Is Performed On the Associative Dependent Graph Update is performed on an associative dependent graph, by the following successive steps:
Definition of initial elements, elements that have been modified or inserted, and declared such to the revision manager (IJRevision::Update, IJRevision::Add) Search and sort of the dependent graph to obtain a set of values and an ordered list of associative functions and solvers ~ Evaluate the ordered list of functions and solvers - An evaluation function is evaluated by callingIJCompute::Evaluate.
- A solver is evaluated by calling IJConstraintSolver::Solve. Constraints and related values are passed in. It is up to the solver by the technique of its choice to satisfy the predicates by modifying related values.
~ Recatch the dependent graph if a semantic or a solver asks so. It requires an incremental search and sort of the dependent graph, before update calls are resumed.
2~

We're using for that purpose DAG (Directed Acyclic Graph) technic to optimize the update process. This ensures that recomputes semantic are called only one time, when adequate. But this requires that the recompute semantics modifies only what they declare output (or that the constraint solvers only modifies the constrained arguments of their constraints).
In certain situations, a recompute semantic may need to modify something not declare output. The modified entities are then kept in a look aside list. At completion of the recompute process in the current DAG, a secondary recompute is then performed on the secondary DAG issued from that look aside list.
This means that modifying non output values of semantic has a negative impact on performances. This should be only used carefully, and we don't want it to be current processing. That's why Assoc asserts if a semantic modifies a non output argument, without turning ON the "reentry mode" by calling IJRevision::BatchReentry. Our purpose doing so is to make sure this is really necessary, done by design. And that it doesn't just happen because of some mistake.
2.5 Pre-Notification Of Value Change The function IJCompute::PreValueModify is called on a semantic when a related value is going to be modified. This means that the call is performed before the modification is actually performed.
To achieve it :commands, associative functions and constraint solvers should notify the revision managerbefore they modifies the element, manipulated by the command, or output argument /
constraint argument of the associative function / constraint solver.
This lets a chance to the semantic to capture relevant information about the entity in its initial state before its value gets affected.
2.6 Incremental Re-catch Of the Dependent Graph When a dependent graph updates, an incremental re-catch of the graph is necessary in 2 different cases 2.6.1 Constraint System With Incremental Solving When elements that participates a constraint system are modified, the update engine could catch entire constraint systems and present complete to the adequate solver.
That's the simplest solution for a constraint system of a reasonable size, example a profile, and it's done for solver which are note "incremental enable" (API
IJRelationSolver::IsIncrementalEnable). It becomes extremely expensive when the constraint systems grows in size, example a the floor plan of an hospital, or a P&ID
schema.
The idea of incremental solving is to try to reduce the size of the constraint system that is presented to the solver to the immediate neighbors of the modified elements. The solver could:
fmd a local solution, ie a solution that only changes value of immediate neighbors of the modified elements. But the value of an element should only be changed if all the constraints applied to it participates the caught graph. This means that elements at the boundary of the caught constrained system, presented to the solver because certain constraints applied to them are part of the system to solve, but some other are not, should not be modified. Such elements are flagged "RELATION FROZEN".
If a local solution could not be found, the constraint solver should ask the associative subsystem to perform an incremental re-catch of the graph that adds all the constraints on ZO

certain FROZEN elements. In addition to these constrains, this will intro~,.ce some more elements other arguments of these added constraints, that may be in tum frozen. Several solver call and re-catch of the graph can then be performed. Refer the API
description here bellow to see how the solver could indicate how many elements should be introduced in the initial constraint system, and how many more should be added at each re-catch (IJRelationSolver::GetWidth).
Incremental catch of the dependent graph with a solver width of 1 Frozen Limits of the Value ~ explored graph Frozen Value Modified Va lue Mo dified Value Non explored Frozen r constraint may exist Value Frozen on frozen value Value ??
Width of the incremental catch, ie how many values on a constraint path between a modified value and a frozen value 2.6.2 Edition Of the Graph By the Evaluate Function Of a Recompute Semantic As part of its processing, an evaluate function may modified certain relations of the dependent in the sense of - semantic that the relation contains - connectivity of the relation, ie removing or adding connected value to the relation.
2.6.3 What's Done In Case Of Incremental Solving As described in earlier paragraphs the different steps of an update operation are 1. Find the set of interested values and functions or constrained 2. Order the functions and solver associated to the solver such that a function which declares a value output is called before the function that takes it for input 3. Call in that order each evaluation function and solver.
If at step 3, the dependency graph is modified (edition of the relation), or if some more elements need to be taken in the domain of interest (incremental solve), this means that step 1 and 2 should be completed before step 3 can terminate.
2.6.4 What's Relevant To That Technique In the ~ssoc Interfaces 2.6.4.1 API For Constraint System with Incremental Solving IJRelationSolver::IsIncrementalEnable This API is called by Assoc to figure out if the solver is incremental enable or not. If incremental enable, a partial catch of the constraint system can be performed.
The system to can be later on complete at the request of the solver per the incremental solving technique described here above.
A solver that is incremental enable should return S OK.
IJRelationSolver::GetWidth This API is called by Assoc to controls how many elements are retained initially in a incremental constraint system, and to extend the constraint system when the solver asks for incremental catch. The "width" returned is the minimum number of non-frozen values between elements modified, or unfrozen, and the first frozen value.
When representing a value by a node and a constraint by edges that connect constrained arguments, the minimum path between a modified element (or an unfrozen element) and a frozen element contains at least width nodes that can be edited.
A returned value from 1 to 3 is recommended. Maximum is 8.
IJRelationSolver::Solve If the solver can not find a correct solution without modifying values marked RELATION_FROZEN, it should return these values inppAddedValues and return the status RELATION_S_INCREMENTAL SEARCH to ask the recompute machine for a more complete graph.
All the semantics acting on these values and all the values that are values related to these semantics are then added to the graph. After the graph is re-ordered, the evaluation functions with the added values for output are called before the constraint solver is called again with the extended system.
An alternate solution is to ask for a complete search of the constraint system by returning RELATION S FULL CONSTRAINT.
2.6.4.2 API For Edition Of the Graph During IJCompute::Evaluate When an Evaluate function changes the relationships in the dependent graph, it should return I~...~.TION_S_SEARCH to notify the update engine the. ~e current graph is no longer valid, and ask for the incremental graph.
2.7 Internal Atomicity Of Elements That Participate Recompute 2.7.1 Description Of the Problem The overview of the associative subsystem describes how relationship types are defined to interfaces, and how an element by exposing several interfaces can participate multiple relationships of different types.
If these relationship types and patterns are associated recompute semantics, the element becomes argument of several recompute semantics. These recompute semantics consider for arguments distinct interfaces of the element.
Ezample : The object P0, exposes interfaces IID1 and IID2. It participates by these interfaces relationships Rl and RZ. Because of meta data associated to these relationships - (P0, IIDl) is output of a semantic S1 - (P0, nD2) .is input of another semantic S2.
Now the problem: How much these 2 values of the recompute graph(P0, IH)1) and (P0, IID2) can be seen independent from each other ?
They are totally independent, IIDI is representing for example the geometry of the entity, and IID2 its user properties. That's then irrelevant to the associative subsystem that the 2 entities of the recompute graph are coming from the same COM objet.
They are not so independent from each other: Posting new data to(P0, IID1) changes the data obtained from the other (P0, IID2). When proceeding the update graph, the semantic S l, outputting to IIDl, should then be proceeded before S2. In that configuration, certain restrictions may also apply to guarantee consistency of the data model after all the recompute are performed. That's what will be developed in the rest of the paragraph.
2.7.2 Eutities Seen As a Structure An entity is seen as a structure, containing fields or nested sub structures.
This organises the internal data of the COM object into a tree, and it defines its internal atomicity.
Interface IID used to connect relationships are paired to the atoms of the tree (fields, intermediate sub-structure, top most structure).
As a result of this tree like structure, when an element is modified through an IID
All the atoms nested (or scoped) in that modified atom (field or nested structures) are considered modified.
~ All the atoms containing the modified atom are considered modified ~ But the sibling are not For the semantics taking them for argument ~ If a semantic declares an IID for input, and if anything has changed under the atom corresponding to that IID, the semantic should recompute ~ When an IID is modified, all the atoms of the ttee structure bellow that IID
are considered modified, and the semantics taking them for INPUT should recompute.
3'I

~ Because outputnng to an outer IID is affecting the inner, the ordering of ~..e semantic should be such that the semantic outputting to the outer IID is called before the semantics) taking the inner for input.
2.7.3 Member Assignment The question is: Do we allow ~ Semantic 1 to declare IID 1 for input ~ Semantic2 to declare I1172 for output With IID2 corresponding to an inner atom of Iml?
This violates somehow the rule that an entity can be OUPUT of only one semantic at the time, since the recompute of both Semanticl and Semantic2 will affect what IID2 represents. We propose to allow that with the following logic:
~ Semanticl affects globally the structure corresponding to IID1 ~ Semantic2 is evaluated after, and overrides the specific IID2 part of it.
2.7.4 Final Recompute Order ~ The semantic that outputs to the outer atom recomputes first ~ The inner atoms are marked modified ~ Semantics that outputs to the inner atoms recomputes.
Semantics that takes the inner atoms for input can then update.
Outer atoms are marked modified, up to the outermost (that represents the complete element) ~ Semantics inputting from the outer atoms can then update.
2.7.5 Example The diagram bellow ilustrates an object that exposes following IID
Im_Full Object. It represents the complete object Im_Geometry. It represents the geometric part of the object,and it's scoped into IID_Full Object.
IID_Attributes. It represents the user attribution on the object. It's scoped under IID_Full Object.
It's a sibling of IID_Geometry, which means thay modifying IID-Geometry and IID_Atiributes (or what's scoped under it) has no effect on each other.
IID_Attrl and IID Attr2 represents specific user attributes. Their are sibling and scoped under IID -Attributes.
Relationships to that object, and associated meta data are such that (object, IID_Attributes) is output of semantic S 1 (object, IID Attrl) is output of semantic S2 (object, IID Attr2) is input of semantic S3 (object, IID Geometry) is input of semantic S.
3z (object, I1T7 Full Object) is input of semantic SS
If another entity that is input argument of S 1 is modified, the sequence of recompute will be - Sl recomputes first. This may change what is read from IID Attrl, IID Attr2 - S2 recomputes after, per "the member assignement rule"
- S3 and SS will then recompute (the order is not defined, S3 may recompute before or after SS) But S4 will not recompute.
2.7.6 Atomicity Defined On Classes The above description of the element atomicity comes from the meta data of the application. We may consider 2 possible ways of defining it At the interface level.
That's what we did initialy. Meta data of an interface defines in which other interface this interface is 'scoped'. This means that all the class exposing this interface will present for it the same atomicity model, and that we have a unique scoping tree for all the intf, all the classes of the system.

This showed nou pratical and caused unsolvable conflict in establishing ~..s unique tree.
~ At the class level.
The scoping tree is defined per class: All the entities of the same class expose the same atotnicity model. But it will defer from one class to the nexthow an interface is scoped an be different from one class to another.
We will use the same to define in the repository the roles that objects expose for the connection of relationships.
If no scoping information is explicitly defined for a given IID, this IID is considered directly scoped under IID FULL OBJECT (topmost atom representing the complete object).
?.7.7 API
Internal atomicity is described as follow:
~ A specific IID : IID_FULL OBJECT is associated to the complete object.
~ HRESULT IJRelationMetaData:: GetScoping( const GUID Atom, GUID*
ContainingAtom);
with Atom IN, Inquired atoms ContainingAtom OUT Containing atom Remarks:
- Depending from Im-FULL OBJECT should be the preferred way to depend on the complete object - GetScoping(IID_FULL OBJECT) should be the only call that returns S FALSE, and no scoping int~
3. API And Interfaces What's bellow is just an introduction to the API. Please refer to the complete Assoc API documentation for much more information on each function, what it does, its argument list and its possible return code.
3.1 IJCompute: Interface For Associative Function Or Predicate 3.1.1 IJCompute::Evaluate Pur ose Asks the semantics to update its output after a change of some of its inputs.
This function is called only if arguments of the semantics have been actually been modified.
Modified arguments can be detected by - getting the argument from the enumerator pRelatedValues - getting the flags associatiated to that argument by pArgDesc->GetArgumentFlags(&flags) - testing if that flag containts the bit RELATION MODIFIED.
This function should notify the revision manager of the output argument about to be modified by calling IJRevision->Update(pObject,iid). This should be done before the output is assigned a new value.
Parameters LPENUMJARGDESC IN Enumerates the arguments of the semantic pRelatedValues Return code S OK Successfull completion E FAIL, Failure 3.1.2 IJCompute::PreValuel~Iodify Purpose Tells the semantics that a related entity is about to be modified. This occurs before the modification actually happens. The modification could come from a command / a recompute semantic or a solver.
Parameters LPJARGDESC IN Value about to be modified pModifiedValue LPENUMJARGDESC IN Enumerates the complete list of arguments of the semantic pRelatedValues Precaution of use For performance reasons, PreValueModify of a semantic may be called for a value that is not actually argument of the semantic. This is up to the semantic to control.
The semantic has no persistance at all, not even between the call toPreValueModify and to Evaluate. This means, that if the semantics has something to persist (example initial value for a constraint solver in order to find the solution the closest to the initial state), the semantics needs to return to persistent entity, by the mean of the pModifiedValue->GetCollection.
The "initial state" can the be stored for example in the active entity, or in the solver, associating it to the runtime (pUnknoivn) or persistent identity of the element to be modified.
3.1..3 IJCompute::ImplementDeferOrError Indicates if the semantic is defer / error aware.
If the semantic is defer / error aware, its evuluate function will be called even if some of its arguments are in error / out of date.
If not, the associative system will propagate automatically the out of date /
error status to the output argument This will be implentented in latter cycle of the system, not there in 1Ø
3.2 IJRelationSolver: Interface For Solver ~5 3.2.1 IJRelationSolver::Solve Purpose Solves the constraints system after values or constraints participating it have been modified. Like IJCcmpute::Evaluate; this function should notified the revision manager of modified elementsbefore the modifications are performed.
Parameters LPENUMJARGDESC IN Values in the constraint system pRelatedValues LPENUMCONSTRAINTDESC IN Constraint in the constraint system pRelatedConstraints LPENUMJARGDESC* OUT Used by incremental solver only, to ask values to be "unfrozen", when ppAdditionalValue an acceptable solution can not be found.
A value is presented FROZEN to the solver can not be modified by the solver, when all the relationships that it participates have not been expored yet.
3.2.2 IJRelationSolver::IsIncrementalEnable Purpose Indicates if the solver is "incremental enable", and how many elements away from modified values should be presented "not frozen" to the solver. Please refer to the paragraph about incremental solving techniques for more infotination on the matter.
Return code S OK The solver is incremental enable S FALSE The solver is not incremental enable 3.2.3 IJRelationSolver::CetWidtli Purpose For a solver incremental enable, indicates how many unfrozen values should be left between any modifed value, and the first frozen value Parameters ULONG *witdh OUT Width, between 0 and 7. A value of 1 or 2 is recommended 3.2.4 IJRelationSolver::l.mplementDeferOrError Same as IJCompute::ImplementDeferOrError 3.3 IJArgDesc: Description Of An Argument Arguments of this type (or enumerators of them, of the type LPENUMJARGDESC) are present in several interface functions described above. They are used to communicate between the associative subsystem and the associative functions or solver that it triggers, by the mean of the following member functions.
An alternate implementation could have been to pass for argument / enumerate directly a structure containing the corresponding fields. This is not pratical because - more difficult to enable marshalling - not VB compatible - reference count nightmare since the stucture would containt intf pointer to be released by the caller.
3.3.1 IJArgDesc:: GetArgumentOb j ect LPUNKNOWN pArgument O Real unknown of the argument This should be the unique intf pointe that you get when doing a QI
(IID IUnknown) on the object, and not one of the misc intf that it implements 3.3.2 IJArg.Desc::GetArgumentILD
LPIID pIlD O IID of the argument 3.3.3 IJArgDesc:: GetArgumentFlags ULONG *flags O Flags associated to the argument. When used as argument of Solve or Evaluate, this is made of the binary combination of RELATION_INPUT: This is a input arg of the semantic RELATION_OUTPUT This is a output arg of the semantic RELATION CONSTRAINT This is a constraint arg of the semantic RELATION MODIFIED This arg has been modified 3.3.4 IJArgDesc::GetArgumentCollection LPUNNOWN pCollection O The object is presented argument of the semantic, because it belongs to a relationships'collection of an active entity. This API lets the semantic retrieve the collection, and from there get more information (type of the relationship, identity of the active entity, etc).
3.3.5 IJArg.Desc::GetIndexInCollection ULONG *pIndex O Returns the index of the argument in the collection (NB This is 1 based: The first member of the collection is at the index 1) 3.3.6 IJArgDesc::Getlnde~cInSolverArgument ULONG *pIndex O Only of use when the pointer IJArgDesc is obtained from the enumerator returned by IJConstraintDesc::EnumConstraintArgs.
A solver is given for arguments the list of values and the list of constraint in the system. The list of values is the accumlation of all the constraint arguments For a given constraint argument, this function returns the index of the corresponding value in the accumulated list of values:
(NB 1 based, or 0 based???) 3.4 IJConstraintDesc: Description Of a Constraint In the Constraint System An enumerator of this type is passed in to constraint solver to describe the constraint participating the constraint system currently solved:
3.4.1 IJConstraintDesc::GetConstraint LPUNKNOWN *pConstraint O Return the constraint That participates the constraint system. The constraint solver may need then to Query and use other interfaces on that object to figure out its type. Example, a solver to solve 2d profile will define by the mean of another intf a protocol to figure out if the constraint is concidence, parallelisme, orthogonality, etc.
3.4.2 lJConstraintDesc::EnumArgOfConstraint LPENLTMJARGDESC * O Enumerates the arguments of this constraint as they participate the constraint ppArgDesc system : The argument may be RELATION_MODIFIED or not. It could be INPUT only in the solver, while presented CONSTRAINT in the meta data, because of the presence of other semantics outputting to it.
3.5 IJRelationGraphInfo: Additional Information About the Graph That Recomputes Recompute semantics in IJCompute::Evaluate and solvers in IJRelationSolver::Solve can query the first passed in argument (enumerator of related values) for this interface, and obtain such additional information about the graph that recomputes.
3.5.1 IJRelationGrapliInfo::IsCommitted No Parameters Returned Value S OK The current recompute corresponds to a modification about to be committed, hence to a call to ITransaction::Commit.
S FALSE The current recompute corresponds to an intermediate evaluation during the transaction. asked for by a call to IJRevision::Flush. Not to the final evaluation, done at cornmut time of the transaction 3.5.2 lJRelationCraphlnfo:: Enum:~ddedRelationships i~VO 00/67156 PCT/US00/11364 Purpose A recompute semantic can be fired just because relationships have been added to the active entity that the recompute semantic is associated to. This without any of the related object being marked RELATION MODIFIED. This function allows identifying such configuration to implement optimized recompute by - enumerating relationship added to the active entity - by the interface IJDRelationship on the enumerated relationship controls the impact that the added relationship may have (or may not have) on the current semantic.
Parameters LPUNKNOWN pObject IN Inquired object LPENUMLTNKNOWN OUT enumerator of added relationships. The passed-in pObject can be ppEnumAddedRel origin or destination of the relationship.
If no relationship has been added on pObject, a NULL enumerator is returned Returned Value S OK
E OUTOFMEMORY
3.5.3 IJRelationGraphlnfo:: EnumRemovedRelationships Purpose This function is for the same purpose as EnumAddedRelationships, to optimize recompute semantic with respect to deleted relationships.
Parameters LPUNKNOWN pObject IN Inquired object LPENiJMLINKIVOWN OUT enumerator of removed relationships. The passed-in pObject can be ppEnumAddedRel origin or destination of the relationship.
If no relationship has been removed on pObject, a NULL enumerator is returned Returned Value S OK
E OUTOFMEMORY
4. Symbolic E~al~ple 3~

LEGEND:
Assoaative --~-functi on Each node contains an identifier along with a value or function (associative function or a predicate.) - "a", "b"', "c", "d" and "e" are value - "Z" and "X" are predicates - "Y" is an associative function From the description of recompute above, when the node "a" is modified from 4 to 2, successive steps of the update will be - Prenotify Y and Z that a is about to be modified. This means Y and Z are told about it when the value of a is still 4.
- Affect the new value 2 to a - accumulate the modified values and relations:
In this case, only one node was modified "a".
- search for all related nodes to evaluate:
This results in the nodes: "a", "Z", "c", "Y", "b", "X", "d", "e".
- order the nodes to evaluate:
Given the relationships above, "a", "Z" and "c" are equivalent. "a" must be evaluated before "Y", "Y" before "b". "b" must be evaluated before "X". "d", "X" and "e" are equivalent. This ordering can be expressed as: a = Z~= c < Y < b < X = d =f - evaluate the ordered nodes:
1. "a", "Z" and "c" would be passed to a solver to satisfy the predicate "Z".
In this case, "c" could be changed to 10 to satisfy the predicate.
2. The associative evaluation function "Y" would be called to calculate a new value for "b". Since "a" now has a value of 2, the new value of "b" would be 4.

3. "d", "X" and "e" would be passed to a solver to satisfy the predicate "X".
Since "b" now has a value of 4, "e" could be change to 4 to satisfy the predicate.
The new values after the modification of "a":
Notice that even though "e" was considered as part of the recompute it was not changed. (A solver can have more than one way to change values to satisfy predicates.) It is an important optimization to recognize values that don't change. In a graphics system, this can avoid needless erase/display. If there were other nodes dependent on "e"
they would not have to be updated.

Appendix3 : Metadata 1. Introduction This Appendix describes the changes made to the Microsoft Repository needed to contain the additional metadata for an embodiment of the present invention.
2. Repository Class Definitions 2.1 ReposRoot Class Definition There is one root object in each repository. The root object is the starting point for navigating to other objects in the repository. The root object serves as the starting point for both type and instance data navigations.
~ Type data navigation:
When you create a tool information model, the corresponding repository type library is attached to the root object via the ReposTypeLibs collection. This collection can be used to enumerate all of the tool information models (type data) that are contained in the repository.
~ Instance data navigation:
Once a tool information model is defined, the repository can be populated with instance data.
This instance data consists of objects and relationships that conform to the classes and relationship types of the tool information model.
Because the objects are connected via relationships, you can navigate through this data.
However, to enable general purpose repository browsers to navigate this data, the first navigational step must be from the root object of the repository through a root relationship collection to the primary objects of your tool information model. Primary objects are objects that make a good starting point for navigating to other objects of your tool information model.
Because this root relationship collection is different for each tool information model, it must be defined by the tool information model. There are two options for attaching this relationship collection to the root object:
1. The ReposRoot class implements the IReposRoot interface. This interface is provided to tool information model creators as a connection point. You can add your connecting relationship collection to this intertace.
2. You can extend the ReposRoot class to implement a new interface that is defined in your tool information model. This interface implements a relationship collection that attaches the root object to the primary objects in your tool information model.
To facilitate navigation, the root object in all repositories always has the same object identifier. The symbolic name for this object identifier is OBJID_ReposRootObj.
When to Use Use the ReposRoot class to:
~ Obtain a starting point for navigating to objects in the repository.
~ Create a new tool information model.
~ Attach a relationship collection to the root object of the repository that connects to the primary objects of your tool information model.

Appendix3 : Metadata (AnnotationalProps ~/
i i implements IRepositoryObject implements ReposRoot implements IManageReposTypeLib implements IReposRoot Interfaces Interface Description IAnnotationalPropsGets and sets annotational properties.

IManageReposTypeLibAdds tool information models (repository type libraries) to a repository.

IRepositoryDispatchProvides enhanced dispatch support.

IRepositoryltem Manages repository objects and relationships.

IRepositoryObject Retrieves repository object identifiers.

IRepositoryObjectStorageCreates and loads repository objects.

IReposRoot Provides an attachment point for tool information model instance data.

2.2 ReposTypeLib Class Definition There is one repository type library for every tool information model contained in the repository database. Each tool information model provides a logical grouping of all of the type definitions related to a particular tool (or tool set). Repository type libraries are instances of the ReposTypeLib class.
To insert a new tool information model into the repository database, use the ReposRoot class.
When to Use Use the ReposTypeLib class to:
~ Define new classes, relationship types, and interfaces for a tool information model.
~ Retrieve or modify the global identifier associated with a repository type library.
~ Determine which type definitions are associated with a particular repository type library.
~-3 Appendix3 : Metadata i IAnnotationalProps implements i ReposTypeLib -implements- - IRepositoryObject w implements w IReposTypeLib Interfaces Interface Description IAnnotationalProps Gets and sets annotational properties.
IRepositoryDispatch Provides enhanced dispatch support.
IRepositoryltem Manages repository objects and relationships.
IRepositoryObject Retrieves repository object identifiers.
IRepositoryObjectStorage Creates and loads repository objects.
IReposTypeLib Creates class, interface, and relationship definitions for a repository type library.
2.3 CIassDef Class Definition When you define a tool information model in the repository, you define classes of objects, types of relationships that can exist between objects, and various properties that are attached to these object classes and relationship types. The object classes that you define in your tool information model are represented by instances of the CIassDef class.
To insert a new class definition into a tool information model, use the ReposTypeLib class.
When to Use Use the CIassDef class to complete the definition of a new repository class.
You can define new interfaces and attach them to the class definition. You can also attach existing interfaces to the class definition.

Appendix3 : Metadata ICIassDef i implements IAnnotationalProps i implements ' CIassDef implements IRepositoryObject implements IReposTypelnfo Interfaces Interface Description IAnnotationalProps Gets and sets annotational properties.
ICIassDef Manages class definitions.
IRepositoryDispatch Provides enhanced dispatch support.
IRepositoryltem Manages repository objects and relationships.
IRepositoryObject Retrieves repository object identifiers.
IRepositoryObjectStorage Creates and loads repository objects.
IReposTypelnfo Contains the collection of definition objects that are associated with a tool information model's repository type library.
2.4 InterfaceDef Definition The properties methods, and collections that a class implements are organized into functionally related groups. Each group is implemented as a COM interface. The properties, methods, and collections of each interface are members of the interface. An interface definition is the template to which an interface conforms. Interface definitions are instances of the InterfaceDef class.
To create a new interface definition, use the CIassDef class or the ReposTypeLib class.
When to Use Use the InterfaceDef class to:
~ Retrieve or modify properties of an interface definition.
~ Determine which members are attached to an interface definition.
~ Determine which classes implement an interface.
~ Determine the base interface from which an interface derives.
~ Determine what interfaces derive from a particular interface.
~ Determine what repository objects expose a particular interface.
~ Add a new property, method or collection type to an interface definition.

Appendix3 : Metadata IAnnotationalProps i im%ements IRepositoryObject P

i _ implements InterfaceDe implements implements I
InterfaceDef v IReposTypelnfo I

Interfaces Interface Description IAnnotationalProps Gets and sets annotational properties.
IlnterfaceDef Manages interface definitions.
IRepositoryDispatch Provides enhanced dispatch support.
IRepositoryltem Manages repository objects and relationships.
IRepositoryObject Retrieves repository object identifiers.
IRepositoryObjectStorage Creates and loads repository objects.
IReposTypelnfo Contains the collection of definition objects that are associated with a tool information model's repository type library.
2.5 RelationshipDef Definition When you define a tool information model in the repository, you define classes of objects, types of relationships that can exist between objects, and various properties that are attached to these object classes and relationship types. The relationship types that you define in your tool information model are represented by instances of the RelationshipDef class.
When to Use Use the RelationshipDef Class to access the properties of a relationship definition (also referred to as a relationship type).
To insert a new relationship type into a tool information model, use the ReposTypeLib class.
~-6 Appendix3 : Metadata ICIassDef , / IAnnotationalProps ~i RelationshipDef I
- - IRepositoryObject w IReposTy pe Info Interfaces Interface Description IAnnotationalProps Gets and sets annotational properties.
IRepositoryDispatch Provides enhanced dispatch support.
IRepositoryltem Manages repository objects and relationships.
IRepositoryObject Retrieves repository object identifiers.
IRepositoryObjectStorage Creates and loads repository objects.
IReposTypelnfo Contains the collection of definition objects that are associated with a tool information model's repository type library.
2.6 MethodDef Class Definition When you define a class for a tool information model, you specify the interfaces that the class implements. For each of those interfaces, you specify the members (properties, methods, and collections) that are attached to the interface.
The definition of a method as a member of an interface does not result in the method's implementation logic being stored in the repository. However, it does add the method name to the set of defined member names for that interface. It also reserves the method's dispatch identifier in the set of defined dispatch identifier values for the interface.
Instances of the MethodDef class represent method definitions.
To attach a new method to an interface, use the InterfaceDef class.
When to Use Use the MethodDef class to access or modify the characteristics of a method definition, or to determine the interface definition to which a particular method is attached.

Appendix3 : Metadata IAnnotationalProps i i i implements i i i MethodDef -implements- - IRepositoryObject I
v implements v IlnterfaceMember I
Interfaces Interface Descri ption IAnnotationalProps Gets and sets annotational properties.
IlnterfaceMember Relates a member to an interface.
IRepositoryDispatchProvides enhanced dispatch support.

IRepositoryltem Manages repository objects and relationships.

IRepositoryObject Retrieves repository object identifiers.

IRepositoryObjectStorageCreates and loads repository objects.

2.7 PropertyDef Class Definition When you define a class for a tool information model, you specify the interfaces that the class implements. For each of those interfaces, you specify the members (properties, methods, and collections) that are attached to the interface.
In order to attach a property to an interface, a property definition must exist for the property. The characteristics of the property (it's name, dispatch identifier, data type, and various storage details) are stored in the property definition. Property definitions are instances of the PropertyDef class.
To attach a new property to an interface, use the InterfaceDef class.
When to Use Use the PropertyDef class to access or modify the characteristics of a property definition, or to determine the interface definition to which a particular property is attached.
~f-Appendix3 : Metadata IAnnotationalProps /~

implements IRepositoryObject implements PropertyDef implemen ts \ IPro ert Def p y implements , \

IlnterfaceMember Interfaces Interface Description IAnnotationalProps Gets and sets annotational properties.

IlnterfaceMember Relates a member to an interface.

IPropertyDef Retains property characteristics.

IRepositoryDispatch Provides enhanced dispatch support.

IRepositoryltem Manages repository objects and relationships.

IRepositoryObject Retrieves repository object identifiers.

IRepositoryObjectStorage Creates and loads repository objects 2.8 CollectionDef Class Definition Repository objects are related to each other via relationships. The set of relationships, all of the same type, that relate one object to zero or more other objects, is a relationship collection.
A collection type (also referred to as a collection definition) defines how instances of a particular collection type will behave. The characteristics of the collection type determine:
~ The minimum and maximum number of items in a collection.
~ Whether or not the collection type is an origin collection type.
~ Whether or not the collection type permits the naming of destination objects, and if so, whether those names are case sensitive, and required to be unique.
~ Whether or not the collection type permits the explicit sequencing of items in the collection.
~ What happens to related objects when objects or relationships in the collection are deleted.
~ The kind of relationship that a particular collection type uses to relate objects to each other.
A collection is attached to an interface as a member of the interface. To add a new collection type to an interface definition, use the InterfaceDef class.
When to Use Appendix3 : Metadata Use the CollectionDef class to retrieve or modify the properties of a collection type, or to determine the kind of relationship that the collection implements.
IAnnotationalProps /i implements IRepositoryObject / implements CollectionDef implements ICoIlectionDef I

implements IlnterfaceMember Interfaces Interface Description IAnnotationalProps Gets and sets annotational properties.

ICoIlectionDef Manages collection definitions.

IlnterfaceMember Relates a member to an interface.

IRepositoryDispatch Provides enhanced dispatch support.

IRepositoryltem Manages repository objects and relationships.

IRepositoryObject Retrieves repository object identifiers.

IRepositoryObjectStorage Creates and loads repository objects 3. Repository Interface Definitions This chapter describes the various interfaces that are part of the type Infromation Model defined by Microsoft and exposed through the Repository Browser. As for the previous chapter documentation from the Visual basis Books Online has been copied to this chapter to explain each of these interfaces.
3.1 IAnnotationalProps Interface Annotational properties are repository properties that can be associated with individual repository objects or relationships. When a normal property is defined as a member of a repository interface, it is defined for all objects that implement that interface. Normal properties cannot be associated with repository relationships.
In order to be able to attach an annotational property value to a particular repository object, two requirements must be met:
1. The object must conform to an object class that exposes the IAnnotationalProps interface.
2. A property definition object must exist for an IAnnotationalProps interface property with a name that matches the name of your annotational property.

Appendix3 : Metadata If these two requirements are met, then you can attach an annotational property value to an object by using the IReposProperty::put Value method to set the value of the annotational property for that particular object.
When to Use Use the IAnnotationalProps interface to access the annotational properties of a repository object or relationship.
Methods (Unknown Method Descri~~tion ~uerylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRehositorvDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Remarks Annotational properties are maintained by the repository as string data. The creator and users of the annotational property must get and set the property value using the appropriate data type via the VARIANT structure. If a data type other than string is used, the repository will perform the appropriate data conversion.
Since all annotational properties in the repository must be defined as interface members of the IAnnotationalProps interface, all annotational property names share the same name space. When you choose a name for an annotational property, make the name as specific and unique as possible.
3.2 ICIassDef Interface The ICIassDef interface helps you create tool information models, by adding interfaces to a class.
To insert a new class definition into a tool information model, use the IReposTypeLib interface.
To complete a class definition, once you have added all of the interlaces, commit the transaction that brackets your class definition modifications.
When to Use Use the ICIassDef interface to:
~ Add a new or existing interface to a class definition.

Appendix3 : Metadata ~ Retrieve the global identifier for the class.
Access the collection of interfaces that are part of a class definition.
Properties Property Description CIassID The global identifier of the class.
Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IReposito Dispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
ICIassDef Method Description Addlnterface Adds an existing interface to the class definition.
CreatelnterfaceDef Creates a new interface and adds it to the class definition.
Objectlnstances Materializes an IObjectCol interface pointer for the collection of all objects in the repository that conform to this class.
Collections Collection Description interfaces The collection of all interfaces that are implemented by a class.
3.3 ICollectionDef Interface A collection type (also referred to as a collection definition) defines how instances of a particular type of collection will behave. The properties of the collection type determine:

Appendix3 : Metadata ~ The minimum and maximum number of items in a collection.
~ Whether or not the collection type is an origin collection type.
~ Whether or not the collection type permits the naming of destination objects, and if so, whether those names are case sensitive, and required to be unique.
~ Whether or not the collection type permits the explicit sequencing of items in the collection.
~ What happens to related objects when objects or relationships in the collection are deleted.
The kind of relationship that a particular collection type uses to relate objects to each other is determined by its Collectionltem collection. The Collectionltem collection associates a single relationship type to the collection type.
To add a new collection type, use the IlnterfaceDef interface.
When to Use Use the ICoIlectionDef interface to retrieve or modify the properties of a collection type, or to determine the kind of relationship that the collection implements.
Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositor~~rDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Properties Property Description Flags Flags that determine the behavior of this type of collection.
IsOrigin Indicates whether or not collections of this type are origin collections.
MaxCount The maximum number of target objects that can be contained in a collection of this type.
MinCount The minimum number of target objects that must be contained in a collection of this type.

Appendix3 : Metadata Collections Collection Description Collectionltem The collection of one relationship type that defines the relationship between target objects of this type of collection and a single source object.
3.4 IlnterfaceDef Interface The properties, methods, and collections that a class implements are organized into functionally related groups. Each group is implemented as a COM interface. The properties, methods, and collections of each interface are members of the interface. An interface definition is the template to which an interface conforms.
To add a new interface to the repository, use the ICIassDef interface or the IReposTypeLib interface.
When to Use Use the IlnterfaceDef interface to:
~ Retrieve or modify properties of an interface definition.
~ Determine which members are attached to an interface definition.
~ Determine which classes implement an interface.
~ Determine the base interface from which an interface derives.
~ Determine what interfaces derive from a particular interface.
~ Determine what repository objects expose a particular interface.
~ Add a new property, method or collection type to an interface definition.
Properties Property Description Flags Flags that specify whether the interface is extensible, and whether the interface should be visible to Automation interface queries.
InterfacelD The global interface identifier for the interface.
TabIeName The name of the SQL table that is used to store instance information for the properties of the interface.
Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Descrit~tion GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.

Appendix3 : Metadata GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositoryDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.

IlnterfaceDef Descrilotion Method CreateMethodDef Creates a new method definition, and attaches it to the interface definition.

CreatePropertyDefCreates a new property definition, and attaches it to the interface definition.

CreateRelationshipCoIDefCreates a relationship collection type.
The collection type is attached to the interface definition.

Objectlnstances Materializes an IObjectCol interface pointer for the collection of all objects in the repository that expose this interface.

Collections CollectionDescription Ancestor The collection of one base interface from which this interface derives.

Classes The collection of classes that implement the interface.

DescendantsThe collection of other interfaces that derive from this interface.

Members The collection of members that are attached to the interface definition.

3.5 IlnterfaceMember Interface The properties, methods, and collections that a class implements are organized into functionally related groups. Each group is implemented as a COM interface. The properties, methods, and collections of each interface are members of the interface.
The IlnterfaceMember interface maintains this information for an interface member:
~ The member dispatch identifier.
~ Information about member visibility.
~ The relationship to the interface that exposes a particular interface member.
This information is common to properties, methods, and collection types. The PropertyDef, MethodDef, and CollectionDef classes all implement this interface.
When to Use Use the IlnterfaceMember interface to access the common properties of an interface member, or to determine which interface definition has a member of a particular property, method, or collection type.
Properties 5~

Appendix3 : Metadata Property Description DispatchlD The dispatch identifier to use when accessing an instance of this type of member.
Flags Flags that specify details about this type of member.
Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
IDisaatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypelnfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositoryDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Collections Collection Description Interface The collection of one interface that exposes this type of member.
3.6 IManageReposTypeLib Interface Each tool information model that is stored in the repository is represented by a repository type library.
When to Use Use the IManageReposTypeLib interface to:
~ Create a repository type library for a new tool information model.
~ Determine what tool information models are currently stored in the repository.
Methods (Unknown Method Description Appendix3 : Metadata Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositoryDisaatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
IMana4eReposTyaoeLib Method Description CreateTypeLib Creates a repository type library for a new tool information model.
Collections Collection Description ReposTypeLibs The collection of repository type libraries that are currently stored in the repository.
3.7 INamedObject Interface Normally, a name is associated with a repository object via a naming relationship. The collection for such a relationship provides the scope for the name, and can require that all names in the collection be unique. This is the preferred method for naming objects, when a given object will be the destination of only one naming relationship.
If your tool information model contains a class that is not the destination of a naming relationship type, or is the destination of multiple relationship types, but no single relationship type is the obvious choice to be the naming relationship type, then you can attach the name property to the class. This is accomplished by defining your class to implement the INamedObject interface. If your class implements the INamedObject interface, the repository engine will use that interface when asked to retrieve or set an object name.
When to Use Use the INamedObject interface to access the Name property of a repository object that exposes this interface.
Properties 5~

Appendix3 : Metadata Property Description Name The name of the object.
Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositoryDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the persistent members exposed by the INamedObject interface.
Remarks None of the standard repository engine or Type Information Model classes implement the INamedObject intertace. However, the repository engine does use the INamedObject interface, if it is exposed by a repository object.
When the IRepositoryltem::get_Name method is invoked for a repository object, the repository engine will perform these steps to retrieve the name:
1. If the object exposes the INamedObject interface, the repository engine returns the value of the Name property.
2. Otherwise, the repository engine searches for a naming relationship for which the current object is the destination object.
3. If such a relationship is found, the repository engine returns the name associated with that relationship.
4. If the object is not the destination of a naming relationship, then the repository engine returns a null name.
When the IRepositoryltem::put_Name method is invoked for a repository object, the repository engine will perform these steps to set the name:
1. The repository engine sets the value of the Name property of all naming relationships for which the object is the destination.
2. If the object exposes the INamedObject interface, the repository engine also sets the value of the Name property attached to that intertace.
Jr Appendix3 : Metadata 3.8 IPropertyDef Interface A property definition object specifies the characteristics of a particular type of property. These characteristics are defined by the properties of the property definition object.
To create a new property definition:
1. Use the CreatePropertyDef method of the IlnterfaceDef interface.
2. Define any non-default characteristics of your new property definition by manipulating the properties of the property definition object.
3. Commit your changes to the repository database.
When to Use Use the IPropertyDef interface to retrieve or modify the characteristics of a property definition.
Properties Property Description APIType The C data type of the property.

ColumnNameThe name of the column in the SQL table for this property.

Flags Specifies details about the property.

SQLScale The number of digits to the right of the decimal point for a numeric property.

SQLSize The size in bytes of the property.

SQLType The SQL data type of the property.

Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IReaositoryDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.

Appendix3 : Metadata 3.9 (Relationship Interface A relationship connects two repository objects in the repository database. A
relationship has an ori4in repository object, a destination repository object, and a set of properties. Each relationship conforms to a particular relationship type.
When to Use Use the (Relationship Interface to manipulate a relationship, or to retrieve the source, target, origin, or destination object for a relationship.
Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IReuositoryDis~atch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
IRenositoryltem Method Description Delete Deletes a repository item.
get Interface Retrieves an interface pointer to the specified item interface.
get Name Retrieves the name associated with an item.
get Repository Retrieves the (Repository interface pointer for an item's open repository instance.
get Type Retrieves the type of an item.
Lock Locks the item.
put Name Sets the name associated with an item.
Refresh Refreshes the cached image of the item.
IRelationshio Method Description get Destination Retrieves an interface pointer to the destination object.
get Origin Retrieves an interface pointer to the origin object.
E

Appendix3 : Metadata get Source Retrieves an interface pointer to the source object.
get Target Retrieves an interface pointer to the target object.
3.10 IRepositoryObject Interface The IRepositoryObject interface provides methods to manage repository objects.
When to Use Use the IRepositoryObject Interface to:
~ Retrieve the object identifier or the internal identifier for a repository object.
~ Retrieve a repository object's type or name.
~ Obtain a lock on a repository object.
~ Change the name of a repository object.
~ Refresh the cached image of a repository object.
~ Delete a repository object.
~ Get a pointer to an alternate interface that the object exposes.
~ Get the open repository instance through which the object is accessed.
Methods (Unknown Method Descri~~tion Querylntertace Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Descrit~tion GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositoryDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
IRepositoryltem Method Description Delete Deletes a repository item.
get Interface Retrieves an interface pointer to the specified item interface.
get Name Retrieves the name associated with an item.
EJ ~

Appendix3 : Metadata get Repository Retrieves the (Repository interface pointer for an item's open repository instance.
get Type Retrieves the type of an item.
Lock Locks the item.
put_Name Sets the name associated with an item.
Refresh Refreshes the cached image of the item.
IRepositoryObiect Method Descriation get InternaIID Retrieves the internal identifier for a repository object.
get ObjectlD Retrieves the object identifier for a repository object.
3.11 IReposRoot Interface The IReposRoot interface is a placeholder interface; it contains no properties, methods, or collections beyond Automation dispatch methods. It is provided as a convenient connection point to the root object. When you create a tool information model, you can attach a relationship collection to this interface that provides a navigational connection to the primary objects of your tool information model.
When to Use Use the IReposRoot interface as a starting point to navigate to other objects in the repository.
Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IReaositoryDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
~2 Appendix3 : Metadata 3.12 IReposTypelnfo Interface This interface relates class, interface, and relationship definition objects to repository type libraries.
When to Use Use the IReposTypelnfo interface to:
~ Determine which repository type libraries contain a particular class, interface, or relationship type.
~ Determine what collection types are associated with a particular relationship type.
Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositoyDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Collections Collection Description ItemInCollections The origin and destination collection types that are connected to a relationship definition object.
ReposTypeLibScopes The collection of repository type libraries that contain a particular class, interface, or relationship type.
3.13 IReposTypeLib Interface There is one repository type library for every tool information model contained in the repository.
Each tool information model provides a logical grouping of all of the type definitions related to a particular tool (or tool set).
To add a new repository type library to the repository, use the IManageReposTypeLib interface.

Appendix3 : Metadata When to Use Use the IReposTypeLib interface to:
~ Define new classes, relationship types, and interfaces for a tool information model.
~ Retrieve or modify the global identifier associated with a repository type library.
~ Determine which type definitions are associated with a particular repository type library.
Properties Property Description Typel_iblD The global identifier for the repository type library.
Methods (Unknown Description Method QuerylnterfaceReturns pointers to supported interfaces.

AddRef Increments the reference count.

Release Decrements the reference count.

(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositoryDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
IReposTypeLib Method Description CreateCIassDef Creates a new class definition object.
CreatelnterfaceDef Creates a new interface definition object.
CreateRelationshipDef Creates a new relationship definition object.
Collections Collection Description ReposTypelnfos The collection of all classes, interfaces, and relationship types that are defined in the repository type library.
~ !y°

Appendix3 : Metadata ReposTypeLibContexts The collection of one repository root object that is the context for the repository type library.
3.14 ISummarylnformation Interface The ISummarylnformation interface maintains Comments and ShortDescription properties for objects that expose this interface.
When to Use Use the ISummarylnformation interface to access the Comments and ShortDescription properties of a repository object.
Properties Property Description Comments General comments about the object.
ShortDescription Brief description of the object.
Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositoryDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the properties exposed by the ISummarylnformation interface.
4. Repository Relationship Definitions This chapter describes the relationships contained within the Repository's Type Information Model (TIM).
4.1 IlnterfaceDef Relationships The Class_hnplements_Inte~face relationship connects the IClassDef and IInterfaceDef interfaces. This relationship is used to define the interfaces that a class implements.

Appendix3 : Metadata The Interface InheritsFrom-Interface relationship is used to identify interfaces that inherit (are subclassed) from other interfaces.
The Interface_Has Members relationship is used to house the interface members (methods, properties, collections) that are pan of an interface.
Interface InheritsFrom Interface Ancestor IlnterfaceDef ICIassDef Class Implements Interface Interfaces ~InterfacelD
>CIassID Classes - -~TabIeNami >PropDescs Flags Interface Interface Has Members Members IlnterfaceMember $~Dis~atchlD
s 4.1.1 Interfaces Collection The collection of all interfaces that are implemented by this class.

Collection DescriptorDescriptor Value Relationship TypeClass-Implements-Interface Source Is Orioin Yes Minimum CollectionZero Size Maximum CollectionMany Size Sequenced CollectionNo Deletes ProoaoatedNo Destinations NamedNo Case Sensitive Not applicable Names Unique Names Not applicable Syntax Set variable = object.lnterfaces( index ) The Interfaces collection syntax has these parts:
Part Description variable A variable declared as an InterfaceDef object. Receives the specified interface.
object An object expression that evaluates to a CIassDef object.

Appendix3 : Metadata index An integer index that identifies which element in the collection is to be addressed. me valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object.Interfaces.Count.
4.1.2 Classes Collection This collection specifies which classes implement the interface Collection DescriptorDescriptor Value Relationship TypeClass-Implements-Interface Source Is Origin No Minimum CollectionZero Size Maximum CollectionMany Size Secbuenced CollectionNo Deletes PropagatedNo Destinations NamedNo Case Sensitive Not Applicable Names Unioue Names Not Applicable Syntax Set variable = object.Classes( index ) The Classes collection syntax has these parts:
Part Description variable A variable declared as a CIassDef object. Receives the specified class definition.
object An object expression that evaluates to an InterfaceDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object.Classes.Count.
4.1.3 Members Collection This collection specifies which members are attached to the interface Collection DescriptorDescriptor Value Relationship TypeInterface-Has-Members Source Is Orioin Yes Minimum CollectionZero Size Maximum CollectionMany Size Se4uenced CollectionYes Deletes ProoagatedYes Destinations NamedYes Case Sensitive No Names Unicl~ue Names Yes E~

Appendix3 : Metadata Syntax Set variable = object. Members( index ) The Members collection syntax has these parts:
Part Description variable A variable declared as an object. Receives the specified property definition, method definition, or collection definition.
object An object expression that evaluates to an InterfaceDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object.Members.Count.
4.1.4 Interface Collection For a particular property, method, or collection definition, the Interface collection specifies which interface exposes a member of this type.
Dispatch Identifier: DISPID_Iface (37) Collection DescriptorDescriptor Value Relationship TypeInterface-Has-Members Source Is Origin No Minimum CollectionOne Size Maximum CollectionOne Size Seauenced CollectionYes Deletes ProoaoatedYes Destinations NamedYes Case Sensitive No Names Unique Names Yes 4.1.5 Ancestor Collection This collection specifies the one base interface from which this interface derives Collection DescriptorDescriptor Value Relationship Ty~~eInterface-InheritsFrom-Interface Source Is Origin Yes Minimum CollectionOne Size Maximum CollectionOne Size Sequenced CollectionNo Deletes Propa4atedNo Destinations NamedNo Case Sensitive Not applicable Names Appendix3 : Metadata Unique Names Not applicable Syntax Set variable = object.Ancestor( index ) The Ancestor collection syntax has these parts:
Part Description variable A variable declared as an InterfaceDef object. Receives the specified base interface definition.
object An object expression that evaluates to an InterfaceDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object.Ancestor.Count.
4.1.6 Descendants Collection This collection specifies other interfaces that derive from this interface.
Collection DescrilotorDescriptor Value Relationship TypeInterface-Inherits From-Interface Source Is Orioin No Minimum CollectionZero Size Maximum CollectionMany Size Seouenced CollectionNo Deletes Propa4atedNo Destinations NamedNo Case Sensitive Not applicable Names Unioue Names Not applicable Syntax Set variable = object.Descendants( index ) The Descendants collection syntax has these parts:
Part Description variable A variable declared as an InterfaceDef object. Receives the specified interface definition.
object An object expression that evaluates to an InterfaceDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object.Descendants.Count.

Appendix3 : Metadata 4.2 Type Library Relationships The Container_ContextFor_ReposTvpeLi6s relationship connects the IManageReposTypeLib and IReposTypeLib interfaces and identifies the type libraries contained within a type library manager and the type library managers for a particular type library.
The ReposTypeLib_ScopeFor ReposTypelnfo relationship identifies the type infos (clases, interfaces and relationship types) that are defined within a.Repository type library.
The Collection-Contains Items relationship identifies the two collections that are associated with a given relationship type.
Container ContextFor ReposTypeLibs IReposTypeLib IManageReposTypeLib --~TypeLibID
ReposTypeLibContexts ReposTypeLibs ReposTypeLibScopes ReposTypeLib ScopeFor ReposTypelnfo I ICoIlectionDef I
t ReposTypelnfos Collection_Confains Items IReposTvpelnfo ItemInCollections Collectionltem 4.2.1 ReposTypeLibs Collection The collection of repository type libraries that are currently stored in the repository. Each repository type library represents a tool information model.
Collection DescriptorDescriptor Value Relationship TypeTIbManager-ContextFor-ReposTypeLibs Source Is Orioin Yes Minimum CollectionZero Size Maximum CollectionMany Size Seauenced CollectionNo Deletes PropaoatedYes Destinations NamedYes Case Sensitive No Names Uni4ue Names Yes Syntax Set variable = object.ReposTypeLibs( index ) The ReposTypeLibs collection syntax has these parts:

Appendix3 : Metadata Part Description variable A variable declared as a ReposTypeLib object. Receives the specified repository type library.
object An object expression that evaluates to a ReposRoot object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object.ReposTypeLibs.Count.
4.2.2 ReposTypeLibContexts Collection The collection of one repository root that is the context for a repository type library.
Collection DescriptorDescriptor Value Relationship TvoeTIbManager-ContextFor-ReposTypeLibs Source Is Ori4in No Minimum CollectionOne Size Maximum CollectionMany Size Seouenced CollectionNo Deletes Prooa4atedYes Destinations NamedYes Case Sensitive No Names Unique Names Yes Syntax Set variable = object.ReposTypeLibContexts( index ) The ReposTypeLibContexts collection syntax has these parts:
Part Description variable A variable declared as a ReposRoot object. Receives the repository root object.
object An object expression that evaluates to a ReposTypeLib object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object.ReposTypeLibContexts.Count.
4.2.3 ReposTypelnfos Collection The collection of all classes, interfaces, and relationship types that are associated with a repository type library. The repository engine uses this collection to enforce the unique naming of all classes, interfaces, and relationship types for a repository type library.
Collection Descriptor Descriptor Value Relationship Type ReposTypeLib-ScopeFor-ReposTypelnfo Source Is Ori4in Yes Minimum Collection Size Zero Appendix3 : Metadata Maximum CollectionMany Size Seouenced CollectionNo Deletes PropagatedYes Destinations NamedYes Case Sensitive No Names Unioue Names Yes Syntax Set variable = object.ReposTypelnfos( index ) The ReposTypelnfos collection syntax has these parts:
Part Description variable A variable declared as an Object. Receives the specified class definition, interface definition, or relationship definition.
object An object expression that evaluates to a ReposTypeLib object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object.ReposTypelnfos.Count.
4.2.4 ReposTypeLibScopes Collection The collection type libraries that contain of repository this definition.

Collection DescriptorDescriptor Value Relationship TvpeReposTypeLib-ScopeFor-ReposTypelnfo Source Is OrictinNo Minimum CollectionOne Size Maximum CollectionMany Size Sequenced CollectionNo Deletes PropagatedYes Destinations NamedYes Case Sensitive No Names Unioue Names Yes Syntax Set variable = object.ReposTypeLibScopes( index ) The ReposTypeLibScopes collection syntax has these parts:
Part Description variable A variable declared as a ReposTypeLib object. Receives the specified repository type library object.
~2 Appendix3 : Metadata object An object expression that evaluates to an InterfaceDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object.TypeLibScopes.Count.
4.2.5 ItemInCollection Collection A relationship type is associated with two collection types. Origin collections conform to one collection type (the origin collection type), and destination collections conform to the other collection type (the destination collection type). The ItemInCollections collection contains the two collection definition objects that represent the origin and destination collection types.
Collection DescriptorDescriptor Value Relationship TvpeCollection-Contains-Items Source Is Ori4in No Minimum CollectionZero Size Maximum CollectionTwo Size Sequenced CollectionNo Deletes Prooa9atedNo Destinations NamedNo Case Sensitive Not applicable Names Uni4ue Names Not applicable Syntax Set variable = object.ItemInCollections( index ) The ItemInCollections collection syntax has these parts:
Part Description variable A variable declared as a CollectionDef object. Receives the specified collection definition.
object An object expression that evaluates to a RelationshipDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object.ItemInCoIlections.Count.
Remarks If the relationship type has not yet been connected to its origin and destination collection types, then this collection can contain less than two collection types.
4.2.6 Collectionltem Collection The collection of one relationship type that defines the relationship between target objects of this type of collection and a single source object.
Collection Descriptor Descriptor Value '~3 Appendix3 : Metadata Relationship TypeCollection-Contains-Items Source Is Origin Yes Minimum CollectionZero Size Maximum CollectionOne Size Sequenced CollectionNo Deletes Propa4atedNo Destinations NamedNo Case Sensitive Not applicable Names Unique Names Not applicable Syntax Set variable = object.Collectionltem( index The Collectionltem collection syntax has these parts:
Part Description variable A variable declared as a RelationshipDef object. Receives the specified relationship definition object.
object An object expression that evaluates to a CollectionDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object.Collectionltem.Count.
5. Base-TIM Information Model A new type information model Base-TIM has been added to the Microsoft Repository to handle the additional metadata definitions that the Type Information Model as defined by Microsoft and described in the previous chapters does not handle.
The following chapters describe the various classes, interfaces and relationships that have been defined for the Base-TIM model.
6. Added Classes The following classes have been defined for the Base-TIM information model in the Repository:
~ ArgumentDef ~ SemanticDef ~ UnitsOfMeasureDef 6.1 ArgumentDef Class The ArgumentDef class is used to define the arguments for a semantic. The arguments for a semantic are the interfaces that are needed by the semantic for its processing.

Appendix3 : Metadata The interfaces for a semantic are identified by a relationship/collection on the active entity. When a semantic is processed, these interfaces are loaded into an array of structures which is passed as an argument to the appropriate semantic method (e.g. Evaluate). The cardinality of the collection on the active entity determines the number of entries that a particular "argument" consumes in this array. For example a to-one relationship (which has a collection with a cardinality of one) will consume one spot in this array whereas a to-many relationship will consume n slots where n is the number of connected interfaces for that relationship.
When to Use Use the ArgumentDef class to add arguments to or delete arguments from a semantic.
I HaveArguments implements ArgumentDef I
6.2 SemanticDef Class The SemanticDef class is used to define the existence of a compute, copy or delete semantic and to identify the active entity for that semantic and the arguments to that semantic. The SemanticDef class implements the ISemanticDef interface which is tied to the IHoIdSemantic interface for the active entity. The ISemanticDef interface is also tied to the IHaveArguments interface which is used to identify the arguments to the semantic.
When to Use Use the SemanticDef class to access or modify semantic definitions.
(Semantic implements SemanticDef 6.3 UnitsOfMeasureDef Class The UnitsOfMeasureDef class is used to define the units of measure domains that can be applied to properties with units of measure.
When to Use Use the UnitsOfMeasureDef class to access or modify units of measure domain definitions.
~5 Appendix3 : Metadata IJUOMDomain~
implements UnitsOfMeasureDef 7. Added Interfaces The following interfaces have been defined for the BASE-TIM model:
~ IHaveArguments ~ IHoldSemantic ~ IJAggregate ~ IJCodeSet ~ IJCodeSetInterface ~ IJImply ~ IJInterfaceInfos ~ IJPropetty2 ~ IJRelationshipType ~ IManageDelete ~ IUserType ~ IJUOMDomain ~ ISemantic All of these interfaces are Repository-supported interfaces with only properties and/or collections that are inherently supported by the Repository machine.
7.1 IHaveArguments Interface The IHaveArguments interface is used to add an argument to a semantic.
When to Use Use the IHaveArguments interface to add an argument to a semantic or delete an argument from a semantic.
Properties Property Description the type of the argument The type of the argument (input, output, constrained) the type of the_Relship The GUID for the relationship Indirect Argument In case the interface that is argument of the semantic is not the destination of the relationship, this property contains the IID of the argument interface Appendix3 : Metadata Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Descriation GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRenositoryDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperfies interface provides access to the Properties collection.
Collections Collection Descriation SemanticForArg The collection of the one semantic to which this argument is tied 7.2 IHoIdSemantic Interface The IHoldSemantic interface is used to identify the interface that is the active entity for a semantic.
When to Use Use the IHoIdSemantic interface to define the interface that is the active entity for a semantic.
Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
IDis~atch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.

Appendix3 : Metadata GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypelnfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositoryDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Collections Collection Description Semantics The collection of semantics for which this interface is the active entity The IHoldSemantic interface is added to the InterfaceDef class to indicate that any interface can potentially be the active entity for a semantic.
IAnnotationalProps IRepositoryObject i / ~ New - Use to store I i I Ulnterfacetnfos ~ -I additional info about th / ~ - - -/ ~ ~ a interface i I i / ~ / ' IJlmply ' NEw - connects to ~, - - - - - IJlmply InterfaceDef IJCodesetlnterface New - connects to '=-- - IJCodeSet I

I
v I v IHoIdSemantic I _ New - Connects to I ~ - -1 ~ (Semantic 1 r~~
Ilnte~' IReposTypehfo ~~
7.3 IJAggregate Interface The IJAggregate interface is used to establish an a~~regation relationship between classes.

Appendix3 : Metadata When to Use Use the IJAggregate interface to define that a class aggegates another class.
Properties Property Description AggregationType The type of aggregation (Aggregation, Containment) Methods (Unknown Description Method QuerylnterfaceReturns pointers to supported interfaces.

AddRef Increments the reference count.

Release Decrements the reference count.

IDisg_atch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.

GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.

GetTypeInfoCountRetrieves the number of type information interfaces that an object provides (either 0 or 1 ).

Invoke Provides access to properties and methods exposed by an Automation object.

IRepositorvDis~oatch Method Description get_Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Collections Collection Description Aggregates The collection of classes that this class aggregates AggregatedBy The collection of classes that that aggregate this class The IJAggregate interface has been added to the CIassDef class. This allows any class to aggregate other classes or be aggregated by other classes.

Appendix3 : Metadata (Class Def I
IA
rnot ational Props ~

IJUs~ i New - Define _ _ implements j implements ~ a User Type , I
~
, /

implements i CIassDef -im I New - connects w plements tw -j IJAggregate \ - - o IJAggregate --i \

I
implements implements a i IRepositoryObject i ' I

IReposTypelnfo 7.4 IJCodeSet Interface The IJCodeSet interface is used to identify properties whose values are defined by entries in another class/interface. A code set property is differentiated from a relationship between two interfaces by the fact that the pointer is one directional (from the property in the one class to the other interface) and there are no semantics associated with the pointer.
When to Use Use the IJCodeSet interface to define or modify the code set characteristics of a property.
Properties Property Description Name The name of the property in the related interface that is to be displayed as the value for this property FiIterCriteria The filter criteria to be applied to the instances to come up with the set of possible values for the property Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description Appendix3 : Metadata GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositoryDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Collections Collection Description CodeSetlnterface The collection of one interface that identifies the type of objects in the code set The IJCodeSet interface has been added to the Microsoft-defined PropertyDef class definition. This allows any property definition to use a code set definition.
IAnnotationalProps IRepositoryObject I
I
implements I implements I ~ ~ ' IJCodeSet New - connects to ~ - - ~,~. - - - IJCodeSetlnterface PropertyDef - - -~mPlements-I w \ implements I ~ ~ IJProperty2 ' implements implements w j i I
I w 1 IPropertyDef I
IlnterfaceMember j 7.5 IJCodeSetlnterface Interface The IJCodeSetInterface interface is used to identify an interface definition as containing the set of possible values (code set) for a property definition(s). Normally, the manipulation of the relationship between an interface definition used as a code set and a propem~ is done from the PropertyDef object using the IJCodeSet interface.
~'i Appendix3 : Metadata Methods (Unknown MethodDescription QuerylnterfaceReturns pointers to supported interfaces.

AddRef Increments the reference count.

Release Decrements the reference count.

(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositoyDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Collections Collection Description PropertiesForCodeSet The collection of properties using this interface as a code set The IJCodeSet interface has been added to the Microsoft-defined InterfaceDef class definition. This allows any interface definition to be used as a code set.
~z Appendix3 : Metadata IAnnotationalProps (Repository ' b / ~ New i -Use to store I i -I additional i - info about Ulnterfaceln - th s -~

/ ~ a interface ~

/
i /
/

/ IJI~ I
~ mp NE
/ ' onnects I ~ to ~i ~~- _--~ IJl l mp y InterfaceDef - New IJCodeSetlnterFace -connects to I - IJCodeSet \ -w \
W

\

I

I
\

I IHoIdSemantic New \ ' -Connects to I
\ \ (Semantic ~ I, J

1 \

Il t rf D
f n e ace e 9~eposTypehfo I

7.6 IJlmply Interface The IJImply interface is used for identifying interfaces that are implied by other interfaces.
When to Use Use the IJlmply interface to define that an interface implies another intertace.
Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.

Appendix3 : Metadata IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Collections Collection Description Implies The collection of interfaces that this interface implies ImpIiedBy The collection of interfaces that imply this interface The IJImply interface has been added to the InterfaceDef class to indicate that any interface can imply another interface or be implied by another interface.
IAnnotationalProps ~_ IRepositoryObject j I i I ~ I New - Use to store ' i ~ U~acelnfos - - - -~ additional info about th I ~ I a interface i I i I
I ~ / ~ / ' IJI p NEw - connects to I ~ ' - - - -i ~ ~ - >';--~ IJlmply InterfaceDef i I New - connects toy -~ IJCodeSetlnterface I ~ IJCodeSet I \ , ~ __ v I
I \
I \
I \ ~ IHoIdSemantic ! New - Connects to I \ r- - -I \ , ~IISemantic I
IlnterfaceDef ~~, ReposTypelnfo ' 7.7 IJlnterfacelnfos Interface The is used to store informations about interfaces in the context of user attributes.
When to Use Use when an interface is a collection of attributes.
~ ~f-Appendix3 : Metadata Properties Property Description UserName Display name for a collection of attributes Jflag (not used) Methods (Unknown MethodDescription QuerylnterfaceReturns pointers to supported interfaces.

AddRef Increments the reference count.

Release Decrements the reference count.

(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRenositoryrDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Collections Collection Description Appendix3 : Metadata IAnnotationalProps IRepositoryObject New - Use to store / i i Ulrterfacelnfos I - additional info about th - - -a interface i IJlmply I NEw - connects to / ~ / - - - - - IJlmply i InterfaceDef IJCodeSetlnterface '~ -- ~~deSetnects to I ~ ~ ' I
I
v I v IHoIdSemantic New - Connects to .=
I ~ _ -I ~ J (Semantic IlnterfaceDef ReposTypehfo 7.8 IJProperty Interface The IJProperty2 interface contains additional amibute metadata beyond what is supported by the IPropertyDef interface.
When to Use Use the IJProperty2 interface to do the following:
~ define or modify any of the metadata properties accessible through this interface ~ identify that an attribute uses a particular units of measure ~ identify that an attribute is the same as another attribute. This can only be set if an attribute is not persistent.
Properties Property Description OnPropertyPage Indicates whether the attribute will appear on a property page SpecificUnitsOfMeasure Indicates whether an attribute has a specific units of measure (e.g. ft).
This value should only be set if the attribute is also tied to a units of measure type (not used) UserName Display name of the attribute UnitsType Type of units for this property PrimaryUnits Default primary display units for this property PecondaryUnitsDefault secondary display units for this property TertiaryUnits Default tertiary display units for this property CodeList Table number for code listed attributes (-1 if not) Appendix3 : Metadata ReadOnly Indicate if the value of this attribute can be set Methods (Unknown MethodDescription QuerylnterfaceReturns pointers to supported interfaces.

AddRef Increments the reference count.

Release Decrements the reference count.

IDisaatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypelnfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IReoositoryDisnatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Collections Collection Description UnitsOfMeasure The collection of at most one unit of measure that applies to this attribute SameAs The collection of at most one property for which this attribute is the same attribute AreSame The collection of properties that are the same as this one The IJProperty2 interface has been added to the PropertyDef class to allow the definition of the additional metadata for any attributeiproperty.

Appendix3 : Metadata IAnnotationalProps IRepositoryObject i / I
implements / implements / ~ ~ IJCodeSet PropertyDef / - -implements implements II implements IJProperty2 New implements I
I
IPropertyDef I
IlnterfaceMember I
7.9 IJRelationshipType Interface IJRelationshiptype interface is used to store the GUID associated to an interfce type.
When to Use Properties Property Description RelationshipTypeGUID GUID
Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypelnfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).

Appendix3 : Metadata Invoke Provides access to properties and methods exposed by an Automation object.
IRe~ositoryDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Collections Collection Description ICIassDef IAnnotationalProps i, I i ~ New - Used for GSCAD
I ~ delete behavior I
I IManageDelete ',-I
i RelationshipDef - - - - - IJRelationshipType i New - Used to store th - - - a GUID associated to a 1 ~ ~ type of relationship 1 w IRepositoryObject IReposTypelnfo I
I
7.10 IManageDelete Interface The IManageDelete interface contains additional information about the propagation of the delete associated to a relarionship.
When to Use Use the IManageDelete interface to define a delete behavior of a relationship.
Properties Pro a Description Delete_Forward Flag for the forward delete behavior. The possible values are PROPAGATE, NO PROPAGATE or PROPAGATE CONDITIONAL.
Delete_Backward Flag for the forward delete behavior.
DisconnectionProgID ProgID of a semantic to fire when a relationship of this type is deleted.
Methods Appendix3 : Metadata (Unknown Method Description Querylntertace Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositoryDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Collections Collection Description ICIassDef ' IA rnot ati onal P cops _.__ I i j New - Used for GSCAD ' - ~ delete behavior I ~ ~I IManageDelete -I
i RelationshipDef ~ -- - - - - ]IJRelationshipType New - Used to store th ' - - - a G UID associated to a 1 ~ ~ I type of relationship IRepositoryObject IReposTypelnfo I i 7.11 IUserType Interface The IJUserType to modify the definition of a class and create a user defined class.
When to Use ~0 Appendix3 : Metadata Use the IJIJserType interface to define a semantic a user type.
Properties Property Description RootCLSID CLSID of the class that is used as a server for this codeless class.
Methods (Unknown MethodDescription QuerylnterfaceReturns pointers to supported interfaces.

AddRef Increments the reference count.

Release Decrements the reference count.

(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.
GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IReaositoryDispatch Method Description get Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Collections Collection Description .9~

Appendix3 : Metadata ICIassD

IA nnotational Props I ' Ne D a IJUserType _ _ implements J a User T a ~ yP
implements a~, , \
~
/

\
~
~
implements CIassDef -implements ~ New - connects tw _~ - -'~ o IJAggregate IJA
re ate gg g --I
~

I
impleme_ nts implements I

I
;
IRepositoryObject IReposTypelnfo 7.12 (Semantic Interface The ISemantic interface is used to define a semantic and tie it to its active entity and its arguments.
When to Use Use the (Semantic interface to define a semantic and to relate that semantic to its active entity and to its arguments (i.e. the interfaces that are input, output and/or constrained by the semantic) Properties Property Description Type Type of the semantic (Compute, Copy, Delete) SticProgID ProgID of the class that implements the semantic SoIverProgID ProgID of the class that implements the solver Methods (Unknown Method Description Querylnterface Returns pointers to supported interfaces.
AddRef Increments the reference count.
Release Decrements the reference count.
(Dispatch Method Description GetIDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers.
GetTypelnfo Retrieves a type information object, which can be used to get the type information for an interface.

Appendix3 : Metadata GetTypeInfoCount Retrieves the number of type information interfaces that an object provides (either 0 or 1 ).
Invoke Provides access to properties and methods exposed by an Automation object.
IRepositoryDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection.
Collections Collection Description Arguments The collection of arguments to the semantic ActiveEntity The collection of one interface that is the active entity for the semantic 8. Added Relationships 8.1 Semantic Relationships The Interface_IsActiveEntityFor_Semantics relationship has been added to the metadata model to identify the "active entity" for a semantic (the InterfaceDef corresponding to the IHoldSemantic) and to connect that active entity to its semantic definition.
The Semantic Has Arguments relationship is used to cormect a semantic with the definition of its input, output and constraint arguments (i.e. the connected interfaces that play a role in the semantic).
(Semantic Interface IsActiveEntityFor Semantics ! i~my name IHoIdSemantic - - i ~my_type ActiveEntity Semantics ~mY_CLSID
SemanticForArg Semantic Has Arguments Arguments IHaveArguments the type of_the_argument~
the type of the_Relship 8.1.1 Semantics Collection This collection specifies which semantics use this interface as the active entity.
Collection Descriptor Descriptor Value Relationship Type Interface-IsActiveEntityFor-Semantics Appendix3 : Metadata Source Is Orioin Yes Minimum CollectionZero Size Maximum CollectionMany Size Seouenced CollectionNo?

Deletes PropagatedNo Destinations NamedNo Case Sensitive Not Applicable Names Unioue Names Not Applicable Syntax Set variable = object.Semantics( index ) The Semantics collection syntax has these parts:
Part Description variable A variable declared as a SemanticDef object. Receives the specified semantic definition.
object An object expression that evaluates to an InterfaceDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object.Semantics.Count.
8.1.2 ActiveEntity Collection This collection of one interface which is the active entity for the semantic.

Collection DescriptorDescriptor Value Relationship TypeInterface-IsActiveEntityFor-Semantics Source Is Origin No Minimum CollectionOne Size Maximum CollectionOne Size Seauenced CollectionNo Deletes Pro~ag~atedNo Destinations NamedNo Case Sensitive Not Applicable Names Uniaue Names Not Applicable Syntax Set variable = object.ActiveEntity( index ) The ActiveEntity collection syntax has these parts:
Part Description Appendix3 : Metadata variable A variable declared as an InterfaceDef object. Receives the specified interface definition.
object An object expression that evaluates to an SemanticDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is one.
8.1.3 Arguments Collection This collection arguments to the specifies the semantic.

Collection DescriptorDescriptor Value Relationship TypeSemantic-Has-Arguments Source Is Oriain Yes Minimum CollectionOne Size Maximum CollectionMany Size Seauenced CollectionYes Deletes Propa4atedNo Destinations NamedNo Case Sensitive Not Applicable Names Unique Names Not Applicable Syntax Set variable = object.Arguments( index ) The Arguments collection syntax has these parts:
Part Description variable A variable declared as a InterfaceDef object. Receives the specified interface definition.
object An object expression that evaluates to an SemanticDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object.Arguments.Count.
8.1.4 SemanticForArg Collection This collection of one semantic for which this interface argument is an argument.
Collection DescriptorDescriptor Value Relationship TvoeSemantic-Has-Arguments Source Is Oriain No Minimum CollectionOne Size Maximum CollectionOne Size Seguenced CollectionNo Appendix3 : Metadata Deletes Propa a~ No Destinations Named No Case Sensitive Names Not Applicable Unioue Names Not Applicable Syntax Set variable = object.SemanticForArg( index ) The SemanticForArg collection syntax has these parts:
Part Description variable A variable declared as a SemanticDef object. Receives the specified semantic definition.
object An object expression that evaluates to an ArgumentDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is one.
8.2 Aggregation Relationship To support aggregation a Class Aggregates-Classes relationship has been created Class Aggregates Classes i +Aggregates I
IJAggregate I I +AggregatedBy and its IJAggregate interface added to the Microsoft-defined ClassDef class.
8.2.1 Aggregates Collection This collection classes that this specifies the class aggregates.

Collection DescriptorDescriptor Value Relationship TypeClass-Aggregates-Classes Source Is Ori4in Yes Minimum CollectionZero Size Maximum CollectionMany Size Seouenced CollectionYes Deletes Propa No aq ted Destinations NamedNo Case Sensitive Not Applicable Names Appendix3 : Metadata Unioue Names Not Applicable Syntax Set variable = object.Aggregates( index ) The Aggregates collection syntax has these parts:
Par Description variable A variable declared as a CIassDef object. Receives the specified class definition.
object An object expression that evaluates to a CIassDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is defined by object.Aggregates.Count.
8.2.2 AggregatedBy Collection This collection of one semantic for which this interface argument is an argument.
Collection DescriptorDescriptor Value Relationship TypeClass-Aggregates-Classes Source Is Origin No Minimum CollectionZero Size Maximum CollectionMany Size Seauenced CollectionNo Deletes Propa No aq ted Destinations NamedNo Case Sensitive Not Applicable Names Unique Names Not Applicable Syntax Set variable = object.AggregatedBy( index ) The AggregatedBy collection syntax has these parts:
Part Descrption variable A variable declared as a CIassDef object. Receives the specified class definition.
object An object expression that evaluates to a CIassDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is object.AggregatedBy.Count.

Appendix3 : Metadata 8.3 Imply Relationship To support an interface implying other interfaces an Interface Implies-Interfaces relationship has been created and Inten'aceImplies Interfaces +Implies +ImpIiedBy its IJImply interface added to the InterfaceDef class defined by Microsoft.
8.3.1 Implies Collection This collection erfaces that this specifies the interface implies.
int Collection DescriptorDescriptor Value Relationship Tvpe interface-Implies-Interfaces Source Is Origin Yes Minimum CollectionZero Size Maximum CollectionMany Size Seouenced CollectionNo Deletes PropagatedNo Destinations NamedNo Case Sensitive Not Applicable Names Unique Names Not Applicable Syntax Set variable = object.lmplies( index ) The Implies collection syntax has these parts:
Part Description variable A variable declared as an InterfaceDef object. Receives the specified interface definition.
object An object expression that evaluates to an InterfaceDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is object.Implies.Count.
8.3.2 ImpIiedBy Collection This collection specifies the interfaces that imply this interface.
Collection Descriptor Descriptor Value Appendix3 : Metadata Relationship TypeInterface-Implies-Interfaces Source Is Ori4in No Minimum CollectionZero Size Maximum CollectionMany Size Sequenced CollectionNo Deletes PropagatedNo Destinations NamedNo Case Sensitive Not Applicable Names Unique Names Not Applicable Syntax Set variable = object.ImpIiedBy( index ) The ImpIiedBy collection syntax has these parts:
Part Description variable A variable declared as an InterfaceDef object. Receives the specified interface definition.
object An object expression that evaluates to an InterfaceDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is object.ImpIiedBy.Count.
8.4 Property Relationships The UnitsOJMeasure ApplyTo Properties relationship is used to define the units of measure for properties that have units of measure.
The Property-IsBasisFor_Properties relationship allows a non-persistent property to be defined as being the same as another property. This is particularly useful for properties with units of measure where the property defined as being the same as another property is defined to have specific units of measure (e.g. property diameter ft is same as property diameter and has specific units of ft).
Property_IsBasisFor Properties SameAs IJProperty2 ~GetPut ~IsPersistent ~IsHidden ~SpecificUnitsOfMeasure ~UnitsType AreSame t~primaryUnits ~SecondaryUnits ~TertiaryUnits Appendix3 : Metadata 8.4.1 SameAs Collection This collection of at most one specifies the property for which this property is the same.
Collection DescriptorDescriptor Value Relationship TyoeProperty-IsBasisFor-Properties Source Is Ori4in No Minimum CollectionZero Size Maximum CollectionOne Size Seouenced CollectionNo Deletes Prooa4atedNo Destinations NamedNo Case Sensitive Not Applicable Names Unioue Names Not Applicable Syntax Set variable = object.SameAs( index ) The SameAs collection syntax has these parts:
Part Description variable A variable declared as a PropertyDef object. Receives the specified property definition.
object An object expression that evaluates to a PropertyDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is object.SameAs.Count.
8.4.2 AreSame Collection This collection specifies the properties that are the same as this property.
Collection DescriatorDescriptor Value Relationship TypeProperty-IsBasisFor-Properties Source Is Orioin Yes Minimum CollectionZero Size Maximum CollectionMany Size Sequenced CollectionNo Deletes PropaoatedNo Destinations NamedNo Case Sensitive Not Applicable Names Unigue Names Not Applicable Appendix3 : Metadata Syntax Set variable = object.AreSame( index ) The AreSame collection syntax has these parts:
Part Description variable A variable declared as a PropertyDef object. Receives the specified property definition.
object An object expression that evaluates to a PropertyDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is object.AreSame.Count.
8.5 Code Set Relationships The Interface IsCodeSetFor_Properties relationship couples a property definition to an interface containing possible values for that property. This allows a property to be code-listed.
Interface IsCodeSetFor Properties IJCodeSet ~ ~ IJCodeSetlntertace PropertiesForCodeSet CodeSetlnterface I
8.5.1 CodeSetlnterface Collection This collection of one identifies the interface that a property definition uses.

Collection DescriptorDescriptor Value Relationship TvoeInterface_IsCodeSetFor Properties Source Is Ori4in No Minimum CollectionZero Size Maximum CollectionOne Size Sequenced CollectionNo Deletes Prooa4atedNo Destinations NamedNo Case Sensitive Not Applicable Names Unioue Names Not Applicable Syntax Set variable = object.CodeSetlntertace( index ) The CodeSetlnterface collection syntax has these parts:
Part Descriation variable A variable declared as an InterfaceDef object. Receives the specified class definition.
object An object expression that evaluates to a PropertyDef object.
~(C~~1 Appendix3 : Metadata index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is object.CodeSetlnterface.Count.
8.5.2 PropertiesForCodeSet Collection This collectionthe properties that use specifies a code set interface.

Collection DescriptorDescriptor Value Relationship Interface_IsCodeSetFor_Properties Type Source Is Ori4inYes Minimum CollectionZero Size Maximum CollectionMany Size Sequenced CollectionNo Deletes PropagatedNo Destinations No Named Case Sensitive Not Applicable Names Uniaue Names Not Applicable Syntax Set variable = object.PropertiesForCodeSet( index ) The PropertiesForCodeSet collection syntax has these parts:
Part Description variable A variable declared as a PropertyDef object. Receives the specified property definition.
object An object expression that evaluates to an InterfaceDef object.
index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is object.PropertiesForCodeSet.Count.
~1G ~.

1. Introduction This Appendix discloses additions to the Unified Modelling Language (UML) needed to describe the metadata used to decribe one embodiment of the present invention.
2. Class properties (Geometry i Below are specific properties defined for UML classes.
TypeInRepository - Possible values of "", Interface, Class, or Semantic. A
null string represents the default value of unassigned. From here on this property will be referred to as TIR. This property indicates that the UML class represents a repository class, interface or semantic. The export tool will attempt to set the unassigned TIR based on the name of the class. A class starting with "I"
will have its TIR set to Interface; a class starting with "C" will have its TIR set to Class, and a class starting with "S" will have its TIR set to Semantic. The export tool will issue a warning when it sets the TIR
based on these starting letters.
~ IsDualInterface - True or False, True by default. If TIR is interface, a true value indicates the interface is dual and, therefore, inherits from IDispatch. If TIR is not interface, this property is not applicable.
~ IsExtensible - True or False, True by default. If TIR is interface, a true value sets the IsExtensible flag to true for the interface definition in the repository. It is currently unclear what this flag means in the repository. Microsoft has been asked to clarify.
~ IsHidden - True or False, False by default. If TIR is interface, a true value sets the IsHidden flags to true for the interface definition in the repository. The repository may use this flag to keep the interface hidden from view by automation viewers (e.g. VB object browser) ~ DefaultInterface - Null string by default. If T1R is class, this string property holds the name of the default interface for the class. The export tool will attempt to set this value by comparing implemented interface names against the class name. An implemented interface with the same name as the class but starting with "I" will automatically be used.
~ SemanticType - Possible values of "", Compute, or Copy. A null string represents the default value of unassigned. If TIR is semantic, this string property indicates if the semantic is for compute or copy. The export tool attempts no automatic assignment.
~ SemanticProgID - Null string by default. If TIR is semantic, this string property holds the ProgID of the COM object called by the associativity subsystem to compute or copy objects in a relationship. The export tool attempts no automatic assignment.
~ SolverProgID - Null string by default. If TIR is semantic, this string property holds the ProgID of the COM object called by the associativity subsystem to compute objects in a constraint relationship.
~ GUID - Null string by default. If TIR is class, this string property holds the ClassID of the COM class. If TIR is interface, this string property holds the InterfaceID of the COM
interface. The format of the string must match the fotrttat "{00000000-0000-0000-0000-000000000000}" as specified by the StringToCLSID
win32 function. The export tool will automatically generate a unique value for this string.
~ ObjectID - Null string by default. If TIR is class or interface, this string property holds the ObjectID of the repository classdef or interfacedef represented by the UML class. The format of the string must match the format "{ {00000000-0000-0000-0000-000000000000},00000000}" as specified by the repository documentation. The export tool will automatically generate a unique value for this string.
~ TableName - Null string by default. If TIR is interface, this string property holds the Access or SQLServer table name used to store instances of properties on the interface.
The export tool will automatically generate a table name based on the interface name.
~ UserName - Null string by default. If TIR is interface or class, this a display name used by the attribute helper.
~IG~

~ IsHardCoded - If TIR is interface, true by default, it means that this interface has a real implementation by opposition to a virtual interface just used for relationship connections or codeledd amibutes.
~ RootCLSID - If TIR is class, default is NULL. it means that this class is a user type i.e. a specialization of the class Root class.
3.3 Association and Role properties ProfileForBeam IP a (Beam +ProfilePro~ider +ProfiteRequester~
Below are the GSCAD specific properties defined for UML associations. These properties are accessed under the GSCAD tab from the association specification dialog.
~ DeleteForward, DeleteBackward - Possible values of Propagate, DontPropagate, or ConditionalPropagate. The default value is DontPropagate for both properties.
These properties indicate the delete propagation rules when deleting a COM object that has relationships to other objects. See GSCAD assoc documentation for more information.
~ DisconnectionProgID - Null string by default. This string property holds the ProgID of a COM object called by the associativity subsystem when a COM object is deleted. The function called is analogous to a destructor function on a c++ object. The export tool allows a null string value and attempts no automatic assignment.
~ RelationshipTypeGUID - Null string by default. This string property holds the type of the repository relationship corresponding to the UML association. The GUID used to represent the type is the same GUID used in the IJAssocRelation::GetCollectionOfRelationsByType method.
Previously, the GUID used for the relationship type was extracted from the GUID part of the relationship object id in the repository.
This property is now used instead of the GUID part of the object id. The format of the string must match the format "{00000000-0000-0000-0000-000000000000}" as specified by the StringToCLSID win32 function. The export tool will automatically generate a unique value for this string.
~ ObjectID - Null string by default. This string property holds the ObjectID
of the repository classdef or interfacedef represented by the UML class. The format of the string must match the format "{ {00000000-0000-0000-0000-000000000000},00000000}" as specified by the repository documentation. The export tool will automatically generate a unique value for this string.
Below are the GSCAD specific properties defined for UML roles. These properties are under the GSCAD A
and GSCAD B tabs from the association specification dialog.
~ Min - Possible values of 0 to infinity (represented by -1 ). The default value is 0. This string property defines the cardinality of one side the relationship represented by the UML
associatation. The export tool attempts no automatic assignment.
~ Max - Possible values of 0 to infinity (represented by -1 ). The default value is -1. This string property defines the cardinality of one side the relationship represented by the UML
associatation. The export tool attempts no automatic assignment.
~ IsOrigin - True or False, False by default. A true value defines the role as the origin side of the relationship. Only relationship origins may be named or indexed. The export tool attempts no automatic assignment.
~ IsNaming - True or False, False by default. A true value indicates the origin side of the relationship supports naming. A true value is only valid if IsOrigin is true. The export tool attempts no automatic assignment.
~ IsUniqueNaming - True or False, False by default. A true value indicates the origin side of the relationship requires only unique names can be given when adding to the relationship. A true value is only valid if IsOrigin and IsNaming are both true. The export tool attempts no automatic assignment.
~ IsCaseSensitive - True or False, False by default. A true value indicates the origin side of the relationship supports case sensitive names. A true value is only valid if IsOrigin and IsNaming are both true. The export tool attempts no automatic assignment.
~~ 11-~ PropagateDelete - True or False, False by default. A true value sets the corresponding repository relationshipdef to true. At this time, no GSCAD sub-system uses this flag. The export tool attempts no automatic assignment.
~ IsSequenced - True or False, False by default. A true value indicates the origin side of the relationship supports integer indexing. The export tool attempts no automatic assignment.
~ IsHidden - True or False, False by default. A true value sets the IsHidden flag to true for the relationship definition in the repository. The repository may use this flag to keep the interface hidden from view by automation viewers (e.g. VB object browser). The export tool attempts no automatic assignment.
~ DispID - Null string by default. This string property holds the Dispatch id of the repository collection represented by the UML role. The string must be in the form of a unique integer number. The export tool will automatically generate a unique value for this string.
~ ObjectID - Currently unused.
5.4 Property properties (Beam Length : double Type : BYTE
Below are the properties defined for UML class properties. These properties are accessed first by opening the class specification dialog, selecting a property and view its property specification dialog.
~ OnPropertyPage - True or False, True by default. If true, this property must be diplayed by the attribute controle..
~ UnitsOfMeasure - 0 by default. It contains the unit type of the attribute.
~ PrimaryUnitsOfMeasure, SecondaryUnitsOfIVIeasure, TertiaryUnitsOtMeasure - 0 by default. It contains the code for the display units.
~ ColumnName - Null string by default. This string property holds the Dispatch id of the repository collection represented by the UML role. The string must be in the form of a unique integer number. The export tool will automatically generate a unique value for this string.
~ DispID - Null string by default. This string property holds the Dispatch id of the repository property represented by the UML property. The string must be in the form of a unique integer number. The export tool will automatically generate a unique value for this string. This value must match the one defined in the idl if this property has to be displayed by the attribute helper.
~ ObjectID - Currently unused.
~ APIType, SQLType, SQLSize, SQLScale - These properties are automatically set by the tool from the type of the property. The export tool hard codes these properties to SQL C
STINYINT, SQL TINYINT, 1, and 0, respectively.
~ InRepository - True or False, False by default. Indicate whether or not this property must be exported in the meta data.
~ CodeList - NULL by default, give the name of the codelist table if this property is codelisted.
~ ReadOnly - True or False. False by default, indicate if this property can be modified using the amibute control.
~ UserName - NULL by default, this is Display name used by the attribute control.
~ OnPropertyPage - True or False, True by default. Indicate if this property must be displayed by the attribute control.
~~5 5.5 Generalize property IProlle Length : double ~
IProfile2D I
Below is the property defined for UML generalization (inherit) element.
~ AggregateeClass - Null string by default. This string propem~ can contain a UML class name used to disambiguate COM aggregation when a COM class has more than one aggregatee and each aggregatee implements the same interface. The string must contain a valid UML class name.
The export tool attempts no automatic assignment.
6. GSCAD interpretation of UML diagrams Using UML diagrams in conjunction with GSCAD property settings on UML elements allows the export tool to define the following repository metadata:
~ Interfaces definitions.
~ Interface inheritance.
~ Interface implies interface relationship.
~ Interface scoping rules for associativity.
~ Relationships definitions.
~ Semantics on interfaces.
~ Arguments on semantics and their type.
~ Indirect interfaces as arguments on semantics.
~ COM classes.
~ Interfaces implemented on COM classes.
~ Aggregation and containment between COM classes.
Use of the export tool completely supersedes .rlp files and makerepos.exe as the means of populating GSCAD
metadata in the repository.
6.1 Interface definitions The applications use interface definitions in the repository to determine existence of semantics and user defined attributes. An interface is defined in .rlp using the following syntax.
define OBJID IJDGeometry Oxa1732cbf 0x5136 0x1 ldl 0x97 0x70 0x08 0x00 0x36 0x75 0x42 0x03 0x0 define IID IJDGeometry Oxal732cbf 0x5136 Oxl ldl 0x97 0x70 0x08 0x00 0x36 0x75 0x42 0x03 createINTERFACE IJDGeometry objid IJDGeometry iid IJDGeometry A repository Interface definition can be specified using UML and GSCAD
properties. Placing a UML class, assigning an interface name, and setting GSCAD property TypeInRepository to Interface is all that is necessary for the export tool to define the interface definition in the repository.

«In>erface»
IJDGeom etry (from SymboIlnterfaceDependency) However, if this interface has already been defined in an application. it is important for the GSCAD GUID
property to be properly set. This property defines the Interface IID that must match up with the defined IID in the application. Looking at the above .rlp text, the GSCAD GUID property should be defined as {a1732cbf 5136-lldl-9770-080036754203}.
6.2 Interface inheritance GSCAD applications may use inheritance information for query and user defined type support. No .rlp syntax exists for describing interface inheritance. It is defined in UML as follows.
For interface inheritance, the inherits (also called generalization) Li~IL
relationship requires no GSCAD
property settings.
6.3 Interface implies relationships GSCAD applications use implies information for query support. \o .rlp syntax exists for describing interface implies relationships. It is defined in UML as follows.
«Interface» i IJDGeometry I
«Implies»
I
«Interface»
IJDLine The UML dependency relationship is used with the "Implies" stereotype name.
The export tool will generate an implies relationship in the repository between IJDGeometry and IJDLine.
'I 0 ~

6.4 Interface scoping for associativity GSCAD applications use interface scoping rules via the associativity subsystem to determine interface dependency during associativity graph compute. See assoc documentation for more information. Interface scoping is defined in .rlp using the following syntax. A scoping relation can be global to an application or only valid within the context of a class.
setSCOPE
Interface IJDOccurrence Scope IJOccurrence The same is defined in UML as follows.
«Interface» ~ «g~pedBy» «Interface»
IJDOccurrence - - _ _ - _ IJOccurrence i Two interfaces can be considered equivalent by the associativity. It is defined in UML as follows.
«Interface» «IsEquiValent» «Interface»
IJA ~--------~ IJB
f One interface can be the origin of at most one scoping relation (ScopedBy or IsEquivalent) in a given context.
An interface that is equivalent to another cannot be a scoping and cannot be scoped.
~ CIassName - NULL by default, indicate in which context this scoping relation apply. The context must be the name of an exported class. If no class name is given the context is global (default scoping rule) and the IsGlobal property must be true.
~ GUID - CLSID of the context class. Set by Export to Repos tool if the scoping relation must be applied within the context of a class.
IsGlobal - True by default, indicate if this scoping relation is applied within the context of a class. True if ClassNAme is NULL, False otherwise.
For interface scoping, the dependency relationship is used with the "ScopedBy"
or "IsEquivalent" stereotype name. The export tool will add the scoping information to the interface definition in the repository.
6.5 Relationship definition GSCAD applications connect physical objects together based on relationship definitions stored in the repository.
See assoc documentation for more information. A relationship is defined in .rlp using the following syntax.
define OBJID XFormModel Ox 1 0x2 0x3 Ox 1 0x2 0x3 Ox 1 0x2 0x3 Ox 1 0x3 0x0 createRELATIONXformModel Origin IJCopyXFormXformModelOrigin Destination IJDLine XformModelDestination Type COLLECTION
NAMING

setPROPERTY XFormModelIManageDelete Delete Forward type char index 1 value NO PROPAGATE

setPROPERTY XFornuModelIManageDelete Delete Backward type char index 2 value PROPAGATE

~~8 setPROPERTY XFormModel IManageDelete ConnectionProgID
type char index 3 value XFormCompStic.XFormCompStic. l The same is defined in UML as follows.
«Interface» ; 0..* ~~~el 0..* ~ «InterFace»
IJDLine ~ ~ IJCopyXForm +~orrnNbdelOrigin +~NbdeIDestination I
The UML association is used to define the repository relationship definition.
The GSCAD properties added to the association allow setting of propagation rules and disconnection fiznctions to call (See section 4.3 Association and Role properties). It is extremely important to understand that UML roles and repository collections are exactly opposite. In the repository, a relationship has two collections, the origin collection on the origin interface and the destination collection on the destination interface. In UML, an association exists between interfaces based on the roles each element plays in the association.
For example:
«Interface» image «Interface»
INfan ~ IWoman +Husband +Wife Here IMan is playing the Husband role and IWoman is playing the Wife role in UML. When this relationship is mapped to the repository, the relationship will be called Marriage and the IMan will get an origin collection named Wife and the IWoman will get a destination collection named Husband.
That is, IMan has a collection of Wife objects and IWoman has a collection of Husband objects (cardinality of the relationship will be left as an exercise for the reader).
Therefore UML association roles reverse when mapped to the repository. Looking at the above XFormModel example, this explains why the XformModelOrigin origin collection on IJCopyXForm defined in .rlp syntax became the role on IJDLine in UML.
The IsOrigin GSCAD property on a UML role is defined in terms the repository NOT UML. Therefore, in the above XFormModel example, the XFormModelOrigin role on IJDLine has IsOrigin set to true because it is desired to have the IJCopyXForm relationship collection called XFormModelOrigin be the origin collection.
As will be seen later, the setting of the IsOrigin GSCAD property plays an important role in defining semantic arguments.
6.6 Semantics on an interface GSCAD applications use semantics on interfaces via the associativity subsystem to compute or copy objects in relationships. See assoc documentation for more information. A semantic is defined using .rlp syntax as follows.
//Define semantic define OBJID SMakeBeam Ox22d718be Ox9cef Oxl ldl Oxa6 0x77 0x0 OxaO Oxc9 OxBd Ox9d Oxbl 0x10 createINSTANCE SemanticDef SMakeBeam ConnectTo IMakeBeam IHoldSemantic Semantics setPROPERTY SMakeBeam ISemantic noname type char index 1 value Compute setPROPERTY SMakeBeam ISemantic noname type char Index 2 value Beams.MakeBeam.ProfileVector. l //Add profile input argument define OBJID ProfileArg Ox22d718c2 Ox9cef Oxl ldl Oxa6 0x77 0x0 OxaO Oxc9 OxBd Ox9d Oxbl 0x0 insertINSTANCEArgumentDef ProfileArg connectto SMakeBeam ISemantic Arguments 1 setPROPERTY ProfileArg IHaveArguments noname type char Index 1 value INPUT
setPROPERTY ProfileArg IHaveArguments noname type GUID
Index 2 value ProfileForBeam //Add vector input argument define OBJID VectorArg Ox22d718c4 Ox9cef Oxl ldl Oxa6 0x77 0x0 OxaO Oxc9 Ox8d Ox9d Oxbl 0x0 insertINSTANCEArgumentDef VectorArg connectto SMakeBeam ISemantic Arguments 2 setPROPERTY VectorArg IHaveArguments noname type char Index 1 value INPUT
setPROPERTY VectorArg IHaveArguments noname type GUID
Index 2 value VectorForBeam //Add beam output argument define OBJID ResultingBeamArg Ox22d718c5 Ox9cef Oxl ldl Oxa6 0x77 0x0 OxaO
Oxc9 Ox8d Ox9d Oxbl 0x0 insertINSTANCEArgumentDef ResultingBeamArg connectto SMakeBeam ISemantic Arguments 3 setPROPERTY ResultingBeamArg IHaveArguments noname type char Index 1 value OUTPUT
setPROPERTY ResultingBeamArg IHaveArguments noname type GUID
Index 2 value ResultingBeam The same is defined in UML as follows.
~~l ?O

SMakeBeam ~iProfileProuder : String = Input '~ ~VectorProvider : String = Input '', ~BeamRequester : String = Output «Interface» i 0..* ProfileForBeam Profile +ProfileProvider +ProfifeRequester TieToSMakeBeam 0..
i «Interface» 0..* ResultingBeam i BeamMaker +BeamP rovider LO"* +BeamRequester «Interface» 0_.* VectorForBeam 0..*
IVector ' «Interface»
+VectorPro~ider +VectaRequester Ig~m This is an example of an associative system with Passive Entities IProfile, IVector, and IBeam and Active Entity IBeamMaker (again see assoc documentation for a complete description Active and Passive Entities). The semantic SMakeBeam is anchored to the Active Entity IBeam:Vlake interface via a special association named TieToSMakeBeam. The UML class elements IProfile, IVector, IBeamMaker, and IBeam are all UML interface definitions. Each has the GSCAD TypeInRepository property set to Interface.
SMakeBeam is different because its GSCAD TypeInRepository property is set to Semantic. In fact, looking at the GSCAD properties of SMakeBeam we see the following settings:
~ TypeInRepository = Semantic ~ SemanticType = Compute ~ SemanticProgID = Beams.MakeBeam.ProfileVector.l Since TypeInRepository is set to Semantic, the export tool treats SMakeBeam differently that the other UML
elements. It interprets properties on the semantic as argument definitions.
Each property must be of type String and each property must have an initial value of Input, Output, Constraint, Self_input, Self_output, Self_constraint. The Rose98 property specification for the ProfileProvider property on SMakeBeam is shown below:

General Lpetail ~
GSCD' Name: [' Class:
. S
-' M
. akeB
. eam -ape: r' String Show ~ classes Stereotype:

Initial Input value:

on . E_xport C
trol-~" P_ubGc ~' ~' Implementation Protected i <' Private D ocumentation:

OK AGGw Browse Help Cancel ~

The actual name of the property must exactly match a role of an association on the IBeamMaker interface.
Since IBeamMaker is an Active Entity only and is not a Passive Entity, the role names supplied must be roles on the other side of the association. Specifying other-side role names goes hand in hand with defining the initial value (semantic argument type). Because IBeamMaker is an Active Entity and not a Passive Entity, no initial value should be marked as Self_input, Self_output or Self_constraint.
That is, it is illegal to specify ProfileProvider, VectorProvider, or BeamRequester as semantic arguments AND
list their types as Self *.
Suppose we wish to not have the intermediate IBeamMaker Active Entity and instead have IBeam be both the Active Entity and Passive Entity.
SMakeBeam '; ~ProfilePro~ider : String = Input i ~VectorProvider : String = Input I $jProfileRequester : String = Self output «Interface»,~ 0..* ProfileForBeam (Profile I I
+ProfilePro~ider lieToSMakeBeam i +ProfileRequester i I
* , 0.. i «Interface»
(Beam i i 0..*
«Interface» 0_.* V~torFor$eam (Vector +VectorPro~ider +VectaRequester -~ 1 ~.

Now IBeam is both the Active Entity and Passive Entity. How can we tell?
Simply by noticing SMakeBeam has an argument of type Self_output. Notice the property name ProfileRequester listed on SMakeBeam. When a semantic wishes to take a Self_input, Self_output, or Self_constraint argument, ANY role name on the IBeam can be listed. Therefore, we could have specified VectorRequester: String =
Self_output and gotten the same result.
Another important piece of information related to role name arguments to semantics is the setting of the IsOrigin GSCAD property on the role. For all semantic arguments that are not of Self_* type, the IsOrigin property must be set to true. Therefore, in the above example, ProfileProvider and VectorProvider must have IsOrigin set to true. If the semantic argument is of type Self_*, the IsOrigin property must be set to false on the role.
Rules for constraint type arguments match exactly with non-constraint type arguments. Self_constraint roles can only be listed as arguments if they exist on the Active Entity interface.
Non-Self_constraint roles must exist on the other side of the association. All non-Self_constraint roles must have IsOrigin set to true and all Self constraint roles must have IsOrigin set to false.
When the export tool fords a semantic, it automatically labels the association between the semantic and interface TieTo<semantic name>.
6.7 Indirect interfaces as arguments to semantics GSCAD applications can define indirect interfaces as semantic arguments rather than having to create an entirely new See assoc documentation for more information.
relationship.An indirect interface argument to a semantic is .rlp syntax as follows.
defined using //Define a semantic to compute the length of the beam define OBJID uteBeamLength 0x3 Ox 1 Ox 1 0x2 0x3 0x4 0x5 SComp 0x6 0x7 0x8 0x9 Ox 10 createINSTANCESemanticDef SComputeBeamLength ConnectTo IAnalyzeBeam IHoldSemantic Semantics setPROPERTY SComputeBeamLength ISemantic noname type char index 1 value Compute setPROPERTY SComputeBeamLength ISemantic noname type char Index 2 value Analysis.BeamLength. l //IBeam as argument define OBJID 0x334 0x1 0x1 0x2 OW 0x4 0x5 0x6 0x7 0x8 0x9 BeamArg 0x0 insertINSTANCEArgumentDef BeamArg connectto SComputeBeamLength ISemantic Arguments 1 setPROPERTY BeamArg IHaveArguments noname type char Index 1 value INPUT

setPROPERTY BeamArg IHaveArguments noname type GUID

Index 2 value BeamToAnalyze //The actual argument to the semantic is not IBeam but rather IJGeometry setPROPERTY BeamArg IHaveArguments noname type IID

Index 3 value IJGeometry The same is defined in UML as follows.

SComputeBeamLength ~BeamPro~iderIJGeometry : String = Input TieToSComputeBeamLength «Interface» ~ * BeamToAnalyze ~_.* «Inteiface»
IAnalyzeBeam ~ g'. +BeamPro~ider (Beam +BeamRequester In this example, the argument to the semantic is in the form <RoleName:InterfaceName> with BeamProvider being the role name and IJGeometry being the interface name. The export tool detects the semicolon and generates metadata indicating the semantics actual argument is the indirect interface specified.
6.8 Take an argument tied by a relationship to another interface than the active entity If the Export to Repos tool does not fmd the argument role directly tied to the active entity, it will try to find it on any interface implied by the active entity. This allows to have a generic connection pattern used by different semantics tied to different active entities.
Semantic Origin : String = input TieToSemantic «Interface>' «Implies» I «Interface»
IActiveEntity - - - - - - IOtherlnterface +Desti nation SampIeRelation +Origin --«Interface»
Ilnterface i This pattern is not "correct" in the sense that no relationship argument of semantic is origin on the active entity.
This semantic will never be triggered (see assoc doc for details) but the model can be exported.
~ ~f-6.9 COM classes GSCAD applications currently do not make use of COM class metadata in the repository. Possible future uses include automatic property page display, query, and associativity scoping rules on COM classes that override interface level scoping rules. No .rlp syntax exists for describin~~ COM
classes. It is defined in UML as follows.
«Interface» ' «Interface»
(Beam I IGecmetry i «Implements» «Implements»
The UML generalization (inherits) relationship is used with the "Implements"
stereotype name. The export tool will generate a repository class definition for CBeam. The class definition will have a relationship to all interfaces implemented on the class. In order for the export tool to recognize the CBeam UML element as a COM class, the TypeInRepository GSCAD property must be set to Class.
It is important to note the export tool will only define interfaces implemented on a class that have a direct generalization relationship. Classes that implement interfaces who have implies relationships do not automatically get the implied interface implemented. Instead, the class must have a direct relationship to the implied interface.
Interface ~' IEngineeringEntity - - - - - -C Implies --Implements il Interface Interface ' (Beam (Geometry V

Implements>' Implements CBeam ~!
6.10 Aggregation and containment on COM classes GSCAD applications currently do not make use of COM class aggregation or containment metadata in the repository. Possible future uses include automatic property page display, query, and associativity scoping rules on COM classes that override interface level scoping rules. :v'o .rlp syntax exists for describing aggregation or containment. It is defined in UML as follows.

«Interfacv>
ILine3D , ', «Interface» «hterfac~> !
IBeam IEngineeringEntity «Aggregates»
«Imptements>' I , «hiplements» «ImPlements»
i i i I
Beam ~ ! ~~m The UML aggregation relationship is used to show CSpecialBeam aggregating CBeam. Additionally, the generalization relationship from CSpecialBeam to IBeam with stereotype name "Aggregates" indicates CSpecialBeam is aggregating the IBeam interface on CBeam. The export tool will generate a repository class definition for CSpecialBeam and will add an aggregation relationship to CBeam.
The export tool adds metadata about the aggregation of the IBeam interface.
Containment is shown in a similar fashion to aggregation.
«Interface>>
ILine3D ' «Interface» «hterfacv>~
(Beam IEngineaingEntity i «Implements»
I /;:,.v «Implements» i a i «tnplements» «ImPlements»
Here CSpecialBeam contains the IBeam interface on CBeam. The UML
generalization relationship is used as with aggregation but with the Implements stereotype name. Note an ambiguity exists in the following case.

«Mplements»
«Interface»
ILine3D I «In~terface» i~ ; «hterface»
(Beam ~ IEngineeringEntity «Implements»
-', «hiplements»
«hiplements» «Implements»
CSpecialBeam j,_, CBeam CBoxBeam Here, it is unclear if CSpecialBeam is containing the IBeam interface on CBeam or CBoxBeam. To disambiguate this case, the generalization relationship has a GSCAD property AggregateeClass. In the above case, setting this property on the CSpecialBeam to IBeam specialization relationship to either CBeam or CBoxBeam will disambiguate the containment relationship. Note this same case can occur for multiple aggregated objects. By default, the export tool will set this property to the first aggregatee found. The tool issues a warning noting the assumption.
'712

Claims (17)

WHAT IS CLAIMED IS:

1. A method for maintaining consistency between objects in a computer system, the method comprising:
providing a first relationship between a first entity and a second entity;
providing a semantic object comprising an action to be performed in response to a change in the first entity;
associating the semantic object with the second entity; and making a change in the first entity thereby invoking the action.

2. The method of claim 1 wherein the second entity has an active entity.

3. The method of claim 2 wherein the active entity has an associated stub object.

4. The method of claim 2 wherein the first entity has a passive entity.

5. The method of claim 1 wherein the objects are persistent objects.

6. The method of claim 1 further comprising:
determining a relationship pattern comprising the first entity, the second entity, and the semantic object;
determining one or more arguments of the semantic object;
invoking a change in the first entity;
using information from the relationship pattern and one or more arguments of the semantic object, determining the location of an output; and evaluating the action to produce the output.

7. The method of claim 1 wherein the semantic object is accessed from a DLL file.

8. The method of claim 1 further comprising:
providing a second relationship between a third entity and the second entity; and after the action is invoked, performing the action on the third entity.

9. The method of claim 1 wherein the action is selected from a group consisting of copy, delete, and modify.

10. A method of maintaining the integrity of objects in a database, the method comprising:
determining a relationship pattern, comprising a binary relation between a first entity and a second entity;
providing a semantic object comprising an action to be performed in response to a change in the first entity;
associating the semantic object with the second entity;
determining metadata comprising information from the relationship pattern and arguments of the semantic object; and storing the metadata and the semantic object.

11. The method of 10 wherein the metadata is stored in a COM or CORBA repository.

12. The method of 10 wherein the semantic object is stored in a DLL
file.

13. A method for updating information in a database, comprising a first relation between a first entity and a second entity and a second relation between a second entity and a third entity, the method comprising:
changing a first object of the first entity;
identifying the first relation as being associated with the first object;
using the first relation and repository metadata, identifying the second entity as an active entity;
identifying a semantic object associated with the active entity, wherein the semantic object comprises an action to be performed in response to a change in the first entity;
using arguments of the semantic object, identifying the third entity; and evaluating the action to change the third entity.

14. A computer system for maintaining consistency between objects, comprising:

a processor; and a memory coupled to the processor, the memory storing a relationship pattern information and modules for execution by the processor;
wherein the relationship pattern information includes:
information defining a first relationship between a first entity and a second entity;
information defining a second relationship between a third entity and the second entity; and information defining a semantic object with an action to be performed for changing the third entity in response to changes in the first entity; and wherein the modules include:
a module for associating the semantic object with the second entity;
and a module for invoking the action when the first entity is changed.

15. A computer program product for a computer system including a processor and a memory for maintaining consistency between objects, the computer program product comprising:
code for directing the processor to provide a first relationship between a first entity and a second entity;
code for directing the processor to provide a semantic object with at least one action to be performed.
code for directing the processor to associate the semantic object with the second entity;
code for directing the processor to invoke at least one action when the first entity is changed; and a computer-readable medium for storing the codes.

16. A method for providing consistency among persistent objects in a computer system, comprising:
using the metadata in a repository, constructing a graph, comprising entities and relations;
associating with each active entity a semantic object;

changing one passive entity, comprising a persistent object, in the graph;
and traversing the graph to update the entities using the semantic objects.

17. A method in a computer system for displaying relationship pattern information in a browser comprising:
displaying a entity as a node on a hierarchical browser folder tree;
If the node is an active entity, displaying the associated semantic object;
and for each argument of the semantic object, displaying a related role.