Title of Invention

A METHOD FOR MAINTAINING CONSISTENCY BETWEEN OBJECTS IN A COMPUTER SYSTEM

Abstract

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.

Full Text

FORM 2 THE PATENTS ACT 1970 [39 OF 1970] & THE PATENTS RULES, 2003 COMPLETE SPECIFICATION [See Section 10; rule 13] 'A METHOD FOR MAINTAINING CONSISTENCY BETWEEN OBJECTS IN A COMPUTER SYSTEM' INTERGRAPH SOFTWARE TECHNOLOGIES COMPANY ("IST"), a corporation organized and existing under the laws of the State of Nevada, 2325-B Renaissance Drive, Las Vegas, Nevada 89119, United States of America, The following specification particularly describes the invention and the manner in which it is to be performed: PATENT Attorney Docket No.: 12172-008610 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 of Yann 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 deygloping 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 lUnknown interface 13 is a COM interface that is typically available to all users of COM objects. The lUnknown 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 arid 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 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 UML representation for line and dimension of Fig. 8 using a specific embodiment of the present invention; Fig. 10A 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 Windows™ 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 of binary 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 object(s) 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 object 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, RelationB 86, and ReIation_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 'TarallelTo" 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 ParallelTo 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 "ParallelTo" 120 relationship, which are "ParallelToDestination: 0..1" 120-a on the destination side and "ParallelToOrigin: 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 MakeParallelComputeSem semantic object 130 is: Class CMakeParallelComputeSem: IJCompute { public: STDMETHODIMP Evaluate( LPENUMJARGDESC pRelatedValues); STDMETHODIMP PreValueModify( LPJARGDESC pPreModifyValue, LPENUMJARGDESC pArgsOfSemantic); } IJCompute is the base class for CMakeParallelComputeSem and is the interface for Class CMakeParallelComputeSem. In one embodiment IJCompute may have the following format: Interface IJCompute: IUnknown { IJCompute: :EnumValues Enumerates the arguments of the semantic and qualifies them as input / output / constraint. A return code of RELATION_S_IMPLICIT_INPUT / OUTPUT indicates that entities enumerating the corresponding relation should be considered as argument of the semantic even if not enumerated by this function UCompute: :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. UCompute: :GetSolver Only used on constraint to find the corresponding constraint solver. UCompute: :PreValueModify Tells the semantic(s) 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. UCompute: :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 (LPENUMJIDREF 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 IK) (Interface Identifier) - OBJID (Object Identifier) pair (step 212). The active entity is then created or located (step 214) using another GUID or UD-OBJTD 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 object(s) 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 HDs 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 LJDLine interface for each of the three relationships 120,122, and 124. Thus we define an OBJID (which is a GUTD appended by a long identifier) and refer to an existing HD. This GUTD should be the same as the interface HD to be used. // Define OBJID and HDs that serve as (Passive) JDLines define UD IJDLine 0x260E0AlF 0x04F18 0x11D1 0x97 0x70 0x08 Ox 00 0x36 0x75 0x42 Ox 03 define OBJID JDLine 0x260E0AlF 0x04F18 0x11D1 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 createlNTERFACE key word is used, followed by the participating OBJID and ED: createlNTERFACE IJDLine objid JDLine iid IJDLine Note that we could have called the OBJID, UD and INTERFACE by any names we chose. It is not the name ("IJDLine") but the actual value of the JJD that marks it as an IJDLine interface. At step 214 an OBJID and UD 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 UD IJMakeParaDistanceHub 0x42D921B7 0x7567 0x11D1 OxBD 0x31 0x08 0x00 0x36 0xF4 0x17 0x03 define OBJID IJMakeParaDistanceHub 0x42D921B7 0x7567 0x11D1 OxBD 0x31 0x08 0x00 0x36 0xF4 0x17 0x03 0x00 createlNTERFACE 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: "ParallelTo", "DistanceFrom" and "MPADResult". The following shows the code for specifying the "ParallelTo" 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: define OBJID ParallelTo 0xE6FAEAE2 0x77BA Oxl ldl OxBD 0x33 0x08 0x00 0x36 0xF4 0x17 0x03 0x00 Having defined a OBJID for "ParallelTo", we use it in the createRELATION declaration and name the relation "ParallelToRelation". We specify the origin as DMakeParaDistanceHub (and name the origin role "ParallelToOrigin"), the destination as IJDLine (and name the destination role "ParallelToDestination"), 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 GUTDs, 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 0xE6FAEAE4 0x77BA 0x1 ldl OxBD 0x33 0x08 0x00 0x36 0xF4 0x17 0x03 0x10 Next an instance of the semantic object is created (using the createlNSTANCE 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: createlNSTANCE SemanticDef MakeParallelComputeSem ConnectTo IJMakeParaDistanceHub IHoldSemantic Semantics 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 MakeParallelComputeSem ISemantic noname type char index 1 value Compute setPROPERTY MakeParallelComputeSem ISemantic noname type char Index 2 value AnchorSemantics.MakeParallelCompute. 1 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 Une 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 ParallelTo_Arg 0xE6FAEAE5 0x77BA 0x1 ldl OxBD 0x33 0x08 0x00 0x36 0xF4 0x17 0x03 0x00 insertINSTANCEArgumentDefParallelTo_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 ParallelTo_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, DXFormPipe (active entity) 410 that has relations 412, 416, 418 to the passive entities, DDPipe 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 DDPipe is first added: In the Typelnrepository "Value" column, change the value to Interface Change the "Value" of GUJD and put in the GUTD of IJDPipe: {E0C4E513-6EBD-11D2-BDEF-080036801C04} There are two ways to find the GUTD 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, DXFormPipe 410, is added: In the Typelnrepository "Value" column, change the value to Interface Change the value of GUID and put in the GUTD of DXFormPipe: {4AC243C0-70F8-11D2-BDEF-080036801C04} 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 Typelnrepository "Value" column, change the value to Semantic Change the "Value" of SemanticType to Compute Change the "Value" of SsemanticProgH) 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 IJXFormPipe : 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 UML 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 DLine 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 550, 590, and 620. Fig. 10A illustrates another UML representation for line 510 and dimension 512 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. UDimension 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 SpecialRelationForThatPattem 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 RelationA 622-a and an instance 624-a of Relation^ 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 object(s) 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) object(s) is updated with the result(s) 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 550 on object xxx 610a). 2. Look at the relations enabled on object xxx 610a and find an instance of Relation A 622-a. 3. Look in the metadata for the definition of relation_A 622 and see that relation_A 622 is attached to DHub 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. RelationZ, 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. "CoCreatelnstance" 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). DDLine 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. IXDLine 810 is also displayed (not shown on Fig. 14) on the same level as ICopyXForm 812. Semantic SCopyXForm 814 has a collection of arguments associated with it including arguments XFormModelOrigin 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. APPENDIX 1 lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll II Add new TIM (type information model)for the purpose of adding a // new relationship pattern, // IJMakeAnchorLineParallelAtDistance. CreateTTM AnchorParallelAtDistance-TIM lltlllllllllllllllllllllllllHIIIIIIIIIHIIIIHIIIIIIIIHIIIIHIIIIIIII II Declare Passives for relationships. // IJMakeAnchorLineParallelAtDistance uses only IJDLines, so here // define IJDLine IE), OBJID and declare Interface/Objid connection // The value of the IJD comes from the IDL file in the project that // creates IJDLine' define UD IJDLine 0x260E0AlF 0x4F18 Oxl IDl 0x97 0x70 0x08 0x00 0x36 0x75 0x42 0x03 define OBJID JDLine 0x260E0AlF 0x4F18 0x1 1Dl 0x97 0x70 0x080x00 0x36 0x75 0x42 0x03 0x00 createlNTERFACE UDLine objid IJDLine iid IJDLine lllllll/llllllllllllllllllllllllllllllllllll/lllllllll/llll/lllllllllll II Declare Active Entity for a relationship pattern. // define DMakeParaDistanceHub IID, OBJID and INTERFACE connection define JJD DMakeParaDistanceHub 0x42D921B7 0x7567 0x1 IDl 0xBD0x31 0x08 0x00 0x36 0xF4 0x17 0x03 define OBJID DMakeParaDistanceHub 0x42D921B7 0x7567 0x1 IDl 0xBD0x31 0x08 0x00 0x36 0xF4 0x17 0x03 createlNTERFACE DMakeParaDistanceHub objid DMakeParaDistanceHub iid DMakeParaDistanceHub lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll II Declare relationships that participate in Pattern. // // Declare Parallel-defining a relationship // ParallelToRelation. Use GuidGen, DEFINE_GUID format, and delete // extraneous stuff, then tack on long "0" define OBJID ParallelToRelation 0xE6FAEAE2 0x77BA 0x1 ldl OxBD 0x33 0x08 0x00 0x36 0xF4 0x17 0x03 0x00 createRELATION ParallelToRelation Origin DMakeParaDistanceHub ParallelToOrigin Destination IJDLine ParallelToDestination Type COLLECTION_NAMING lllllllllltlllllllllllllllllllltllltlllllllllilllllllllllllllllllllllll II Declare Distance-defining Relation DistanceFromRelation. define OBJID DistanceFromRelation 0xE6FAEAE6 0x77BA 0x1 Idl 1 OxBD 0x33 0x08 0x00 0x36 0xF4 0x17 0x03 0x00 createRELATION DistanceFromRelation Origin IJMakeParaDistanceHub DistanceFromOrigin Destination IJDLine DistanceFromDestination Type COLLECTION_NAMTNG lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll II Declare Result-defining Relation MPADResultRelation. define OBJID MPADResultRelation 0xE6FAEAE8 0x77BA 0x1 Idl OxBD Ox3 0x08 0x00 0x36 0xF4 0x17 0x03 0x00 createRELATION MPADResultRelation Origin IJMakeParaDistanceHub MPADResultOrigin Destination IJDLine MPADResultDestination Type COLLECTION_NAMTNG lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll II Declare a compute semantic: ComputeParaDistance. Note that in // this case, the long ID is 0x10 as opposed to our customary 0x00 define OBJID ComputeParaDistance 0xE6FAEAE4 0x77BA 0x1 1dl OxBD 0x33 0x08 0x00 0x36 0xF4 0x17 0x03 0x10 lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll II 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 IIIIIIIIIIIIIIIIIIHIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII II 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. // ArgumentDef & IHaveArguments are defined in IMSCoreRelPats.RLP define OBJTD ParallelTo_Arg 0xE6FAEAE5 0x77BA Oxl Idl OxBD 0x33 0x08 0x00 0x36 0xF4 0x17 0x03 0x00 insertINSTANCE ArgumentDef ParallelTo_Arg ConnectTo ComputeParaDistanceObjid ISemantic Arguments 1 lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll II Each argument has two properties: Property 1 specifies whether // the argument is INPUT or OUTPUT. Property specifies the GUJD of // the Relation (e.g., relationship) to which this argument corresponds setPROPERTY ParallelTo_Arg IHaveArguments noname type char Index 1 value INPUT setPROPERTY ParalleITo_Arg IHaveArguments noname typeGUID Index 2 value ParallelToRelation llllllll/lllllllllllll/llllllllllllllllllll/lllllllllllllllllllllllllll II Declare DistanceFrom argument define OBJID DistanceFrom_Arg 0xE6FAEAE7 0x77BA 0x11dl OxBD 0x33 0x08 0x00 0x36 0xF4 0x17 0x03 insertTNSTANCE ArgumentDef DistanceFrom_Arg ConnectTo ComputeParaDistanceObjid ISemantic Arguments 2 setPROPERTY DistanceFrom_Arg IHaveArguments noname type char Index 1 value INPUT setPROPERTY DistanceFrom_Arg IHaveArguments noname typeGUID Index 2 value DistanceFromRelation lllllillllllllllllllllllllllllllllllllllllllHIIIIIIIIIIIIIIIIIllllllll II Declare MPADResultRelation argument. Note that it is an OUTPUT argument define OBJID MPADResultRelation_Arg 0xE6FAEAE9 0x77BA Oxl ldl 0xBD33 0x08 0x00 0x36 0xF4 0x17 0x03 insertlNSTANCE ArgumentDef MP ADResultRelation_Arg ConnectTo ComputeParaDistanceObjid ISemantic Arguments 3 setPROPERTY MPADResultRelation_A IHaveArguments noname type char Index 1 value OUTPUT setPROPERTY MPADResultRelation_A IHaveArguments noname typeGUID Index 2 value MPADResultRelation lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll 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 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 function that sets the start and end points of a line "LineBy2Pts (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 symmetrical 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: line 1 and line 2. • The end-user can grab Line 1 with the mouse and move it. In response, the system moves line 2 so that it remains parallel to line 1. • The end-user can also move line 2 and the system would move line 1 to remain parallel. In associative terms, 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 may 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 only partially defines a value(s). An external mechanism, called a solver, 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,Pl)". 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 concident 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 IID). This means that a single COM object may become several values in the recompute graph. (The IID 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, IID1), affected by what's posted on (pObject,IID2)? 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 calling IJCompute: :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. 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::IslncrementalEnable). 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: • find 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 certain FROZEN elements. In addition to these constraints, this will introduce some more elements other arguments of these added constraints, that may be in turn 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 bow many more should be added at each re-catch (IJRelationSolver: :GetWidth). Incremental catch of the dependent graph with a salver width of 1 r- Limits of the / explored graph 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 Assoc Interfaces 2.6.4.1 API For Constraint System with Incremental Solving IJRelationSol7ver: :IslncrementalEnable 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: :Get Width 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 in ppAddedValues 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::EvaIuate When an Evaluate function changes the relationships in the dependent graph, it [OBSCURED TEXT] 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. Example : The object PQ, exposes interfaces IJD1 and IID2. It participates by these interfaces relationships Rl and R2. Because of meta data associated to these relationships - (PO, IID1) is output of a semantic SI - (PO, IID2) is input of another semantic S2. Now the problem: How much these 2 values of the recompute graph(P0, nDl) and (PO, ID32) can be seen independent from each other ? • They are totally independent, IJD1 is representing for example the geometry of the entity, and 11D2 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 (PO, DD2). When proceeding the update graph, the semantic S1, outputting to IID 1, 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 Entities 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 anllD • 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 tree structure bellow that IID are considered modified, and the semantics taking them for INPUT should recompute. • Because outputting to an outer IID is affecting the inner, the ordering of the semantic should be such that the semantic outputting to the outer IID is called before the semantic(s) taking the inner for input. 2.7.3 Member Assignment The question is: Do we allow • Semanticl to declare IID1 for input • Semantic2 to declare IID2 for output With IID2 corresponding to an inner atom of EDI? This violates somehow the rule that an entity can be OUPUT of only one semantic at the time, since the recompute of both Semantic 1 and Semantic2 will affect what IID2 represents. We propose to allow that with the following logic: • Semantic 1 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 illustrates an object that exposes following IID IIDJFull_Object. It represents the complete object IID_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 that modifying IID Geometry and HD_Attributes (or what's scoped under it) has no effect on each other. IID_Attrl and IID_Attr2 represents specific user attributes. Their are iling and scoped under IID_Attributes. Relationships to that object, and associated meta data are such that (object, IID_Attributes) is output of semantic S1 (object, IID Attrl) is output of semantic S2 (object, HD Attr2) is input of semantic S3 (object, HD Geometry) is input of semantic S4 (object, IID Full Object) is input of semantic S5 If another entity that is input argument of SI is modified, the sequence of recompute will be: - S1 recomputes first. This may change what is read from IID_Attrl, IID_Attr2 - S2 recomputes after, per "the member assignment rule" - S3 and S5 will then recompute (the order is not defined, S3 may recompute before or after S5) But S4 will not recompute. 2.7.6 Atomicity Defined On Classes The above description of the element atomicity comes from the meta data the application. We may consider 2 possible ways of defining it: • At the interface level. s what we did initially. Meta data of an interface defines in which interface this interface is 'scoped'. This means that all the class sing this interface will present for it the same atomicity model, lat we have a unique scoping tree for all the intf, all the classes of rstem. I This showed non-practical and caused unsolvable conflict in establishing this unique tree. • At the class level. The scoping tree is defined per class: All the entities of the same class expose the same atomicity 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 ED, this IID is considered directly scoped under IDD FULLOBJECT (topmost atom representing the complete object). 2.7.7 API Internal atomicity is described as follow: • A specific IID : HD_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 IID_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 intf. 3. API And Interfaces What's bellow is just an introduction to the API. Please refer to the complete Assoo 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 Purpose 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 associated to that argument by pArgDesc->GetArgumentFlags(&flags) - testing if that flag contains the bit RELATION_MODMED. 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 pRelatedValues Return code S_OK Successful completion E FAIL Failure 3.1.2 IJCompute::PreVahieModify 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 pModifiedValue LPENUMJARGDESC pRelated Values IN Value about to be modified IN Enumerates the complete list of arguments of the semantic 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 persistence at all, not even between the call to PreValueModify 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 (pUnknown) 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 evaluate 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 implemented in latter cycle of the system, not there in 1.0. 3.2 IJRelationSolver: Interface For Solver 3.2.1 IJRelationSolver::Solver Purpose. Solves the constraints system after values or constraints participating it have been modified. Like IJCcmpute::Evaluate; this function should notified the revisi manager of modified elements before 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 ppAdditionalValue values to be "unfrozen", when 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 explored 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 information on the matter. Return code S_OK The solver is incremental enable S FALSE The solver is not incremental enable 3.2.3 IJRelationSolver: :GetWidth Purpose For a solver mcremental enable, indicates how many unfrozen values should be left between any modified 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:: ImplementDeferOrError 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 practical because - more difficult to enable marshalling - not VB compatible - reference count nightmare since the structure would contains intf pointer to be released by the caller. 3.3.1 IJArgDesc "GetArgu men tObject LPUNKNOWN pArgument 0 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 LJArgDesc::GetArgumentIID LPIID pIID 0 ED of the argument 3.3.3 IJArgDesc ::GetArgumentFlags ULONG *flags 0 Flags associated to the argument. When used as argument of Solve or Evaluate, this is made of the binary combination of: RELATIONJNPUT: This is a input arg of the semantic RELATIONJ3UTPUT This is a output arg of the semantic RELATION_CONSTRATNT This is a constraint arg of the semantic RELATION_MODIFIED This arg has been modified 3.3.4 UArgDesc: ;Get4rgunieiirCol}ection LPUNNOWN pCoIlection 0 The object is presented argument of the semantic, because it belongs to a relationship's collection of an active entity. This API lets the semantic retrieve the collection, and from there get more information (type the relationship, identity of the active entity, etc). 3.3.5 UArgDesc: .-GetlndexInCollection Returns the index of the argument in the collection (NB This is I based: The first member of the collection is at the index 1) ULONG*plndex 0 3.3.6 IJArgDesc::GetlndexInSoIverArgument ULONG *plndex 0 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 accumulation 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 0 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 coincidence parallelism, orthogonality, etc. 3.4.2 IJConstraintDesc: :EnumArgOfConstraint LPENUMJARGDESC * 0 Enumerates the arguments of this constraint as ppArgDesc they participate the constraint system : The argument maybe 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 IJRelationGraphlnfo: 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 IJRelationGraphlnfo: :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 commit time of the transaction 3.5.2 IJRelationGraphlnfo:: EnumAddedRelationships 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 LPENUMUNKNOWN ppEnumAddedRel IN OUT Inquired object enumerator of added relationships. The passed-in pObject can be 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 lJRelationGraphlnfo:: EnumRemovedRelationships Purpose This function is for the same purpose as EnumAddedRelationships, to optimize recompute semantic with respect to deleted relationships. Parameters LPUNKNOWN pObject LPENUMUNKNOWN ppEnumAddedRel IN OUT Inquired object enumerator of removed relationships. The passed-in pObject can be 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 Example 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 = c - 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. PATENT Attorney Docket No.: 12172-008610 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. 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 interface. 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_ReposRootOb]. 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. Interfaces Interface IAnnotationalProps IManageReposTypeLib Description Gets and sets annotational properties. Adds tool infonnation models (repository type libraries) to a IRepositaryDispatch IRepositoryltem IRepositoryObject repository. Provides enhanced dispatch support. Manages repository objects and relationships. Retrieves repository object identifiers. IRepositaryObjectStorage Creates 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 infonnation 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. Interfaces Interface IAnnotatianalProps IRepositoryDispatch IRepositoryltem IRepositoryObject Description Gets and sets annotational properties. Provides enhanced dispatch support. Manages repository objects and relationships. Retrieves repository object identifiers. IRepositoryObjectStorage Creates and loads repository objects. IReposTypeLib Creates class, interface, and relationship definitions for a repository type library. 2.3 ClassDef 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 ClassDef class. To insert a new class definition into a tool information model, use the ReposTypeLib class. When to Use Use the ClassDef 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. Interfaces Interface lAnnatationalProps ICIassDef IRepositoryDispatch IRepositaryltem IRepositaryObject Description Gets and sets annotational properties. Manages class definitions. Provides enhanced dispatch support. Manages repository objects and relationships. Retrieves repository object identifiers. IRepository Objects torage 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 InterfaceDefDefinition 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 ClassDef 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. Interfaces Interface IAnnotatianalProps llnterfaceDef IRepositoryDispatch IRepositoryltem IRepositoryObject Description Gets and sets annotational properties. Manages interface definitions. Provides enhanced dispatch support. Manages repository objects and relationships. Retrieves repository object identifiers. IRepository Objects tor age 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. Interfaces Interface lAnnotationalProps IRepositoryDispatch IRepositoryltem IRepositoryObject Description Gets and sets annotational properties. Provides enhanced dispatch support. Manages repository objects and relationships. 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 Method of 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. Interfaces Interface IAnnotationalProps HnterfaceMember IRepositoryDispatch IRepositaryltem IRepositoryObject IRepositoryObj ectstorage Description Gets and sets annotational properties. Relates a member to an interface. Provides enhanced dispatch support. Manages repository objects and relationships. Retrieves repository object identifiers. Creates 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. Interfaces Interface lAnnotationalProps HnterfaceMember IPropertyDef IRepositoryDispatch IRepositoryltem IRepositoryObject IRepositoryObjectStorage Description Gets and sets annotational properties. Relates a member to an interface. Retains property characteristics. Provides enhanced dispatch support. Manages repository objects and relationships Retrieves repository object identifiers. Creates and loads repository objects. 2.8 ColIectionDef 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 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. Interfaces Interface IAnnotatianalProps ICallectionDef IInterfaceMember IRepositoryDispatch IRepositaryltem IRepositoryObject IRepositoryObj ectStorage Description Gets and sets annotational properties. Manages collection definitions. Relates a member to an interface. Provides enhanced dispatch support. Manages repository objects and relationships. Retrieves repository object identifiers. Creates and loads repository objects. 3. Repository Interface Definitions This chapter describes the various interfaces that are part of the type Information 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 lAnnotationalProps 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. If these two requirements are met, then you can attach an annotational property value to an object by using the EReposProperty::put_VaIue 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 IUnknown Method Querylnterface AddRef Release Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. IDispatch Method GetDsOfNames GetTypelnfo GetTypelnfoCount Invoke Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. IRepositoryDispatch Method getProperties Description Retrieves the IReposProperties interface pointer. The IReposPropertiesinterface 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 alt of the interfaces, 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. • Retrieve the global identifier for the class. • Access the collection of interfaces that are part of a class definition.Properties Properties Property ClassID Description The global identifier of the class. Methods lUnknown Method Querylnterface AddRef Release Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. IDispatch Method GetlDsOf Names GetTypelnfo GetTypelnfoCount Invoke Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type Information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. IRepositoryDispatch Method get_Properties Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. IClassDef Method Addlnterface CreatelnterfaceDef Description Adds an existing interface to the class definition. Creates a new interface and adds it to the class definition. Objectlnstances Materializes an lObjectCol 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: • The rninimum 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 CoUectionltem collection. The CoUectionltem collection associates a single relationship type to the collection type. To add a new collection type, use the InterfaceDef interface. When to Use Use the ICollectionDef interface to retrieve or modify the properties of a collection type, or to determine the kind of relationship that the collection implements. Methods IUnknown Method Description Querylnterface Returns pointers to supported interfaces. AddRef Increments the reference count. Release Decrements the reference count. TDispatch Method Description GetlDsOfNames 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. IRepnsitnryDispatch Method getProperties Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. Properties Property Flags IsOrigin MaxCount MinCount Description Flags that determine the behavior of this type of collection. Indicates whether or not collections of this type are origin collections. The maximum number of target objects that can be contained in a collection of this type. The minimum number of target objects that must be contained in a collection of this type. 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 IInterfaceDef 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 IClassDef interface or the IReposTypeLib interface. When to Use Use the HnterfaceDef 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. Table Name The name of the SQL table that is used to store instance information for the properties of the interface. Methods IUnknown Method Querylnterface AddRef Release Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. IDispatch Method GetlDsOfNames GetTypelnfo Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. GetTypelnfoCount Invoke Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. IRepositorvDispatch Method getJProperties Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. HnterfacePef Method Description CreateMethodDef Creates a new method definition, and attaches it to the interface definition. CreatePropertyDef Creates a new property definition, and attaches it to the interface definition. CreateRelationshipColDef Creates 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 n the repository that expose this interface. Collections Collection Ancestor Classes Descendants Members Description The collection of one base interface from which this interface derives. The collection of classes that implement the interface. The collection of other interfaces that derive from this interface. 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 IlnterfaeeMember 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 IlnterfaeeMember 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 Property DispatchID Flags Inscription -the dispatch identifier to use when accessing an instance of this type of member. Flags that specify details about this type of member. Methods lUnknown Method Querylhterlace AddRef Release Description Returns pointrers to suppotteh intefraces. Increments the reference count, Decrements the reference count. IDispatch Method GetlDsOfNames GetTypelnfo GetTypelnfoCount Invoke ascription Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). provides access to properties and methods exposed by an Automation object. IRepositoryDispatch Method getProperties Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. Collections Collection Interface Description. 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 lUnknown Method Description Querylnterface AddRef Release IDispatch Method GetlDsOfNames GetTypelnfo GetTypelnfoCount Invoke Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type inforrmation object, which cm be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. IRePositorvDispatch Method get_Properties Description Retrieves the IReposProperties interface pointer. The rReposProperties interface provides access to the Properties collection. IManapeRepnsTypeLib Method Description CreateTypeLib Creates a repository type library for a new tool information model. Collections Collection Inscription 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 Property Description Name The name of the object. Methods IUnknown Method Description Querylnterface Returns pointers to supported interfaces. AddRef Increments the reference count. Release Decrements the reference count. TDispatch Method Description GetIDsOsOfNam.es 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. IReposiroryDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer. The ReposProperties 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 interface. However, the repository engine does use the INamedObject interface, if it is exposed by a repository object. When the IRepositoryItem::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 IRepositoryItem::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 interface. 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 APIType ColumnName Flags SQLScale SQLSize SQLType Description The C data type of the property. The name of the column in the SQL table for this property. Specifies details about the property. The number of digits to the right of the decimal point for a numeric property. The size in bytes of the property. The SQL data type of the property. Methods TUnknown Method Querylnterface AddRef Release Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. IDispatch Method GetlDsOfNames GetTypelnfo Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. 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. (.9 IRelationship Interface A relationship connects two repository objects in the repository database. A relationship has an origin, repository object, a destination repository object, and a set of properties. Each relationship conforms to a particular relationship type. When to Use Use the IRelationship Interface to manipulate a relationship, or to retrieve the source, target origin, or destination object for a relationship. Methods ITnknown Method Querylnterface AddRef Release Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. IDispatch Method GetlDsOfNames GetTypelnfo GetTypelnfoCount Invoke Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. TRepositorvDispatch Method get_Properties Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. IRepositoryItem 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 getJType Lock putName Refresh Retrieves the Repository interface pointer for an item's open repository instance. Retrieves the type of an item. Locks the item. Sets the name associated with an item. Refreshes the cached image of the item. TRelationship Method getDestination getOrigin Description Retrieves an interface pointer to the destination object. Retrieves an interface pointer to the origin object. get_Source get_Target Retrieves an interface pointer to the source object. 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 IRepositoryabject 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 obj ect. • 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 U In known Method Querylnterface AddRef Release Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. IDispatch Method GetlDsOfNames GetTypeInfo GetTypeInfoCount Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). [nvoke Provides access to properties and methods exposed by an Automation object. TRepositon. Dispatch Method get_Properties Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. TRepositoryltem 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 get_Type Lock put_Name Refresh Retrieves the Repository interface pointer for an item's open repository instance. Retrieves the type of an item. Locks the item. Sets the name associated with an item. Refreshes the cached image of the item. IRepositorvObiect Method getlnternallD get_ObjectID Description Retrieves the internal identifier for a repository object. 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 TTfnknown Method Querylnterface AddRef Release Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. IDispatch Method GetlDsOfNames GetTypelnfo Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. 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. IRepositorvDispatch Method Pescription getJProperties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. 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 lUnknown Method Querylnterface AddRef Release Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. IDispatch Method GetlDsOfNames GetTypelnfo GetTypelnfoCount Invoke Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. IRepositoryDispatch Method get_Properties Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. Collections Collection Description ItemlnCollectians 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. 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 TypeLibID Description The global identifier for the repository type library. Methods IUnknown Method Querylnterface AddRef Release Description Returns pointers to supported interfaces. Increments the reference count Decrements the reference count. IDispatch Method GetlDsOfNames GetTypelnfo GetTypelnfoCount Invoke Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. IRepositoryDispatch Method get_Properties Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. IReposTvpeLib Method CreateClassDef CreatelnterfaceDef CreateRelationshipDef Description Creates a new class definition object. Creates a new interface definition object. Creates a new relationship definition abject. Collections Collection ReposTypelnfos Description The collection of all classes, interfaced and relationship types that are defined in the repository type library. ReposTypeLibContexts The collection of one repository root object that is the context for the repository type library. 3.14 ISummarylnformation Interface The Summaryinformation interface maintains Comments and ShortDescription properties for objects that expose this interface. When to Use Use the ISummaryinformation interface to access the Comments and ShortDescription properties of a repository object. Properties Property Comments ShortDescription Description General comments about the object. Brief description of the object. Methods TUnknown Method Querylnterface AddRef Release Description Returns pointers to supported interfaces, increments the reference count. Decrements the reference count. IDispatch Method GetlDsOfNames GetTypelnfo GetTypelnfoCount Invoke Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1) Provides access to properties and methods exposed by an Automation object. IRepositorvDispatch 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 UnterfaceDef Relationships The Class Implements interface relationship connects the IClassDef and IlnterfaceDef interfaces. This relationship is used to define the interfaces that a class implements. The Interface JnheritsFrom Interface relationship is used to identify interfaces that inherit (are subclassed) from oilier interfaces. The InterfaceJIasMembers relationship is used to house the interface members (methods, properties, collections) that are part of an interface. Interface inherftsFrom_interface 4.1.1 Interfaces Collection The collection of all interfaces that are implemented by this class. Collection Descriptor Relationship Type Source is Origin Minimum Collection Size Maximum Collection Size Sequenced Collection Deletes Propagated Destinations Named Case Sensitive Names Unique Names Descriptor Value Class-Implements-Interface Yes Zero Many No No No Not applicable Not applicable Syntax Set variable = object.Interfaces( index) The Interfaces collection syntax has these pads: Eart Description variable A variable declared as an InterfaceDef object. Receives the specified interface. object An obj ect expression that evaluates to a ClassDef 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.Interfaces.Count. 4.1.2 Classes Collection This collection specifies which classes implement the interface. Collection Descriptor Relationship Type Source Is Origin Minimum Collection Size Maximum Collection Size Sequenced Collection Deletes Propagated Destinations Named Case Sensitive Names Unique Names Descriptor Value Class-Implements-Interface No Zero Many No No No Not Applicable Not Applicable Syntax Set variable = object.Classes( index) The Classes collection syntax has these parts: Earl Description variable _ A variable declared as a ClassDef 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 Descriptor Descriptor Value Relationship Tvpe Interface-Has-Members Source Is Origin Yes Minimum Collection Size Zero Maximum Collection Size Many Sequenced Collection Yes Deletes Propagated Yes Destinations Named Yes Case Sensitive Names No Unique Names Yes Syntax Set variable = object.Members( index) The Members collection syntax has these parts: Part Descrirtiop 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: DISPED Iface (37) Collection Descriptor Descriptor Value Relationship Type Interface-Has-Members Source Is Origin No Minimum Collection Size One Maximum Collection Size One Sequenced Collection Yes Deletes Propagated Yes Destinations Named Yes Case Sensitive Names No Unique Names Yes 4.1.5 Ancestor Collection This collection specifies the one base interface from which this interface derives. Collection Descriptor Relationship Type Source Is Origin Minimum Collection Size Maximum Collection Size Sequenced Collection Deletes Propagated Destinations Named Case Sensitive Names Descriptor Value Interface-lnheritsFrom-Interface Yes One One No No No Not applicable Unique Names Not applicable Syntax Set variable = object Ancestor( index) Eari variable object index The Ancestor collection syntax has these parts: Description A variable declared as an InterfaceDef object. Receives the specified base interface definition. An object expression that evaluates to an InterfaceDef object. 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 Andestor.Count 4.1.6 Descendants Collection This collection specifics other interfaces that derive from this interface. Collection Descriptor Relationship Type Source Ts Origin Minimum Collection Size Maximum Collection Size Sequenced Collection Deletes Propagated Destinations Named Case Sensitive Names Unique Names Descriptor Value Interface-lnheritsFrom-Interface No Zero Many No No No Not applicable Not applicable Syntax Set variable = object.Descendants( index) The Descendants collection syntax has these parts: i 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. 4.2 Type Library Relationships The Container•_ ContextForReposTypeLibs 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_ScopeForReposTypelnfo relationship identifies the type infos (classes, 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. 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 Descriptor Descriptor Value Relationship Tvpe TIbManager-ContextFor-ReposTypeLibs Source Ts Origin Yes Minimum Collection Size Zero Maximum Collection Size Many Sequenced Collection No Deletes Propagated Yes Destinations Named Yes Case Sensitive Names No TInique Names Yes Syntax Set variable = object.ReposTypeLibs( index) The ReposTypeLibs collection syntax has these parts: 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 Descriptor Descriptor Value Relationship Type TIbManager-ContextFor-ReposTypeLibs Source Is Origin No Minimum Collection Size One Maximum Collection Size Many Sequenced Collection No Deletes Propagated Yes Destinations Named Yes Case Sensitive Names No 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 Ubrary. 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 Ts Origin Yes Minimum Collection Size Zero Maximum Collection Size Many Sequenced Col1ection No Deletes Propagated Yes Destinations Named Yes Case Sensitive Names No Unique Names Yes Syntax Set variable = object.ReposTypeInfos( index) The ReposTypelnfos collection syntax has these pads: 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 of repository type libraries that contain this definition. Collection Descriptor Descriptor Value Relationship Type ReposTypeLib-ScopeFor-ReposTypelnfO Source Is Origin No Minimum Collection Size One Maximum Collection Size Many Sequenced Collection No Deletes Propagated Yes Destinations Named Yes Case Sensitive Names No Unique Names Yes Syntax Set variable = object ReposTypeLibScopes( index) The ReposTypeLibScopes collection syntax has these parts: Fart Description variable A variable declared as a ReposTypeLib object. Receives the specified repository type library object. 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 ItemlnCollection 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 ItemlnCoUections collection contains the two collection definition objects that represent the origin and destination collection types. Collection Descriptor Descriptor Value Relationship Type Collection-Contains-Items Source os is Origin No Minimum Collection Size Zero Mavimnm Collection Size Two SequencedCollection No Deletes Propagated No Destinations Named No Case Sensitive Names Not applicable Unique Names Not applicable Syntax Set variable = object ItemlnCollections( index) The ItemlnCoUections 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 obj ect. 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 ItemlnCollectionsCount. 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 Relationship Type Source ig Qrigin Minimum Collection Size Maximum Collection Size Sequenced Collection Deletes Propagated Destinations Named Cage Sensitive Names Unique Names Collection-Contains-Items Yes Zero One No No No Not applicable Not applicable Syntax Set variable *= object.CollectionItem( index) The Collectionitem 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 CollectionItem.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. The interfaces for a semantic are identified by a relationship/collection on the ctive 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. 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. 6.3 UnitsOfMeasureDef Class The UnitsOfMeasureDef class is used to define the units of measure domains that can be apphed to properties with units of measure. When to Use Use the UnitsOfMeasureDef class to access or modify units of measure domain definitions. Added Interfaces The following interfaces have been defined for the BASE-TIM model: IHaveArguments IHoldSemantic IJAggregate IJCodeSet IJCodeSetlnterface IJImply IJInterfacelnfos rfProperty2 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. Methods lUnknown Method Querylnterface AddRef Release Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. IDispatch Method GetlDsOfNames GetTypelnfo GetTypelnfoCount Invoke Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). 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 SemanticForArg Description The collection of the one semantic to which this argument is tied 7.2 IHoldSemantic Interface The IHoldSemantic interface is used to identify the interface that is the active entity for a semantic. When to Use Use the IHoldsemantic interface to define the interface that is the active entity for a semantic. Methods IUnknown Method Querylnterface AddRef Release Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. IDispatch Method GetlDsOfNames Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. GetTypelnfo GetTypelnfoCount Invoke Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. TRepositorvDispatch 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. 7.3 IJAggregate Interface The IJAggregate interface is used to establish an aggregation relationship between classes. When to Use Use the UAggregate interface to define that a class aggregates another class. Properties Property AggregationType Description The type of aggregation (Aggregation, Containment) Methods IUnknown Method Description Querylnterface Returns pointers to supported interfaces. AddRef Increments the reference count. Release Decrements the reference count. IDispatch Method GetlDsOfNames GetTypelnfo GetTypelnfoCount Invoke Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. IRepositoryDispatch Method Description get_Properties Retrieves the IReposF'roperties interface pointer. The IReposProperties interface provides access to the Properties collection - Collections Collection Aggregates AggregatedBy Description The collection of classes that this class aggregates The collection of classes that that aggregate this class The UAggregate interface has been added to the ClassDef class. This allows any class to aggregate other classes or be aggregated by other classes. 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 Name FilterCriteria Description The name of the property in the related interface that is to be displayed as the value for this property The filter criteria to be applied to the instances to come up with the set of possible values for the property Methods IUnknown Method Querylnterface AddRef Description Returns pointers to supported interfaces. Increments the reference count. Release Decrements the reference count. IDispatch Method Description etEDsOfNames GetTypelnfo GetTypelnfoCount Invoke Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1) Provides access to properties and methods exposed by an Automation object. IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer. The ReposProperties interface provides access to the Properties collection. Collections Collection CodeSetlnterface Description 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. 7.5 UCodeSetlnterface Interface The IJCodeSetlnterface interface is used to identify an interface definition as containing the set of possible values (code set) for a property definitions). Normally, the manipulation of the relationship between all interface definition used as a code set and a property is done from the PropertyDef object using the IJCodeSet interface. Methods IUnknown Method Querylnterface AddRef Release Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. IDispatch Method GeODsOfNames GetTypelnfo GetTypelnfoCount Invoke Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. IRepositorvDispatch 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. 7.6 IJImply Interface The IJImply interface is used for identifying interfaces that are implied by other interfaces. When to Use Use the IJImply interface to define that an interface implies another interface. Methods IUnkPOwn Method Queryinterface AddRef Release IDispatch Method GetlDsOfNames GetTypelnfo GetTypeinfoCount Invoke Pescription Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1) Provides access to properties and methods exposed by an Automation object. IRepositorvDispatch Method Description getProperties Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. Collections Collection Implies ImpliedBy Description The collection of interfaces that this interface implies The collection of interfaces that imply this interface The Dimply interface has been added to the InterfaceDef class to indicate that any interface can imply another interface or be implied by another interface. 7.7 IJInterfaceinfos 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. Properties Property UserName Jflag Methods IUnknown Method Querymterface AddRef Release IDispatch Method GetlDsOfNames GetTypelnfo GetTypelnfoCount Invoke IRepositorvDispatch Method get_Properties Description Display name for a collection of attributes (not used) Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. Collections Collection Description 7.8 IJProperty Interface The IJPropery2 interface contains additional attribute 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 OnPropertyPage SpecificUnitsOfMeasure UserName UnitsType Description Indicates whether the attribute will appear on a property page 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) Display name of the attribute Type of units for this property PrimaryUnits Default primary display units for this property PecondaryUnits Default secondary display units for this property TertiaryUnits Default tertiary display units for this property deList Table number for code listed attributes (-1 if not) ReadOnly Indicate if the value of this attribute can be set Methods IUnknown Method Querylnterface AddRef Release IDispatch Method GetlDsOfNames GetTypelnfo information for an interface. GetTypelnfoCount Invoke IRepositoryDispatch Method get_Properties Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference, count. Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type infonnation object, which can be used to get the type Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. Collections Collection UnitsOfMeasure Same As AreSame Description The collection of at most one unit of measure that applies to this attribute The collection of at most one property for which this attribute is the same attribute 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 attribute/property. 7.9 IJRelationshipType Interface IJRelationshiptype interface is used to store the QUID associated to an interface type. When to Use Properties Property RelationshipTypeGUlD Methods IUnknown Method Querylnterface AddRef Release IDispatch Method GetlDsOfNames GetTypelnfo GetTypelnfoCount Description GUID Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. 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. get_Properties Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. Collections Collection Description 7.10 IManageDelete Interface The IManageDelete interface contains additional information about the propagation of the delete associated to a relationship. When to Use Use the IManageDelete interface to define a delete behavior of a relationship. Properties Property Delete Forward DeleteJBackward DisconnectionProgID Description Flag for the forward delete behavior. The possible values are PROPAGATE, NO_PROPAGATE or PROPAGATE_CONDITIONAL. Flag for the forward delete behavior. ProgID of a semantic to fire when a relationship of this type is deleted. Methods ITInknown Method Querylnterface AddRef Release IDispatch Method GetlDsOfNames GetTypelnfo GetTypelnfoCount Invoke IRepositorvDispfltch Method get_Properties Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. Collections Collection Description 7,11 IUserType Interface The IJUserType to modify the definition of a class and create a user defined class. When to Use Use the UUserType interface to define a semantic a user type. Properties Property RootCLSID Description OLSID of the class that is used as a server for this codeless class. Methods Illnknown Method Querylnterface AddRef Release IPispatch Method GetlDsOfNames GetTypelnfo GetTypelttfoCount Invoke IRepositoryDisoatch Method get_Properties Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. Retrieves the number of type information interfaces that an object provides (either 0 or 1). Provides access to properties and methods exposed by an Automation object. Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. Collections Collection Description 7.12 ISemantiC 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 Type SticProglfl SolverPraglD Methods Description Type of the semantic (Compute, Copy, Delete) ProgiD of the class that implements the semantic ProgID of the class that implements the solver IUnknown Method Querylntefface AddRef Release IDispatch Method GetlDsOfNames GetTypelnfo Description Returns pointers to supported interfaces. Increments the reference count. Decrements the reference count. Description Maps a single member and a set of argument names to a corresponding set of dispatch identifiers. Retrieves a type information object, which can be used to get the type information for an interface. elnfbCount invoice IRepositorvDispatch Method get_Properties Retrieves the number of type information interfaces that an object provides (eitherOor 1). Provides access to properties and methods exposed by an Automation object. Description Retrieves the IReposProperties interface pointer. The IReposProperties interface provides access to the Properties collection. Collections Collection Arguments ActiveEntity Description The collection of arguments to the semantic 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 InrerfaceDef corresponding to the IHoldSemantic) and to connect that active entity to its semantic definition. The Semantic Has_Arguments relationship is used to connect a semantic with the definition of its input, output and constraint arguments (i.e. the connected interfaces that play a role in the semantic). 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 Source Is Origin Yes Minimum Collection Size Zero Maximum Collection Size Many Sequenced Collection No? Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable Unique Names Not Applicable Syntax Set varible = 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 pne to the number of elements in the collection. The number 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 Descriptor Descriptor Value Relationship Type Interface-IsActiveEntityFor-Semantics Source Is Origin No Minimum Collection Size One Maximum Collection Size One Sequenced Collection No Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable Unique Names Not Applicable Syntax Set variable = object. ActiveEntity (index) The ActiveEntity 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 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 specifies the arguments to the semantic. Collection Descriptor Descriptor Value Relationship Type Semantic-Has-Arguments Source Ts Origin Yes Minimum Collection Size One Maximum Collection Size Many Sequenced Collection Yes Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable Unique Names Not Applicable Syntax Set variable - object.Argumtntsf 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 Descriptor Descriptor Value Relationship Type Semantic-Has-Arguments Source is Origin No Minimum Collection Size One Maximum Collection Size One Sequenced Collection No Deletes Propagated Destinations Named Case Sensitive Names Unique Names Syntax No No Not Applicable Not Applicable 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 obj ect 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 Cfass_Aggregates_ Classes +Aggregates IJAggregate +AggregatedBy and its IJAggregate interface added to the Microsoft-defined ClassDef class. 8.2.1 Aggregates Collection This collection specifies the classes that this class aggregates. Collection Descriptor Relationship Type Source Is Origin Minimum Collection Size Maximum Collection Size Sequenced Collection Deletes Propagated Destinations Named Case Sensitive Names Descriptor Value Class-Aggregates-Classes Yes Zero Many Yes No No Not Applicable Unique Names Not Applicable Syntax Set variable = object. Aggregates^ index) The Aggregates collection syntax has these parts: Earl Description variable A. variable declared as a ClassDef object. Receives the specified class definition. object An object expression that evaluates to a ClassDef 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 Descriptor Descriptor Value Relationship Type Class-Aggregates-Classes Source Is Origin No Minimum Collection Size Zero Maximum Collection Size Many Sequenced Collection No Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable Uniqvte Names Not Applicable Syntax Set variable = object. AggregatedBy( index) The AggregatedBy collection syntax has these parts: Part Descriptiop variable A variable declared as a ClassDef object. Receives the specified class definition. object An object expression that evaluates to a ClassDef 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 obj ectAggregatedEyCount. 8.3 Imply Relationship To support an interface implying other interfaces an Interface Implies Interfaces relationship has been created and its Ulmply interface added to the InterfaceDef class defined by Microsoft. 8.3.1 Implies Collection This collection specifies the interfaces that this interface implies. Collection Descriptor Relationship Type Source Is Origin Minimum Collection Size Maximum Collection Size Sequenced Collection Deletes Propagated Destinations Named Case Sensitive Names Unique Names Syntax Descriptor Value Interface-Implies-Interfaces Yes Zero Many No No No Not Applicable Not Applicable Set variable = object Amplies (index) The Implies collection syntax has these parts: fart 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 Relationship Type Source Is Origin Minimmn Collection Size Maximum Collection Size Seguencgd Collection Deletes Propagated Destinations Named Case Sensitive Names Unique Names Ihterface-Implies-Interfaces No Zero Many No No No Not Applicable Not Applicable Syntax Set variable = object ImpIiedBy (index) The ImpliedBy collection syntax has these parts: variable object index Description A variable declared as an Interfaceflef object. Receives the specified interface definition. An object expression that evaluates to an InterfaceDef object. 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.ImpliedBy.Count. 8.4 Property Relationships The UnitsOfMeasure_ApplyTo_properties relationship is used to define the units of measure for properties that have units of measure. The PropertyJsBasisForproperties 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). 8.4.1 SameAs Collection This collection of at most one specifies the property for which this property is the same. Collection Descriptor Relationship Type Source Is Origin Minimum Collection Size Maximum Collection.Size Seguenced Collection Deletes Propagated Destinations Named Case Sensitive Names Unique Names Syntax Descriptor Value Property-IsBasisFor-Properties No Zero One No No No Not Applicable Not Applicable Set variable = object.SameAs( index) The SameAs collection syntax has these parts: fart 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 Descriptor Relationship Type Source Is Origin Minimum Collection Size Maximum Collection Size Sequenced Collection Deletes Propagated Destinations Named Case Sensitive Names Unique Names Descriptor Value Property-IsBasisFor-Properties Yes Zero Many No No No Not Applicable Not Applicable Syntax Set variable = object.AreSame( index) The AreSame collection syntax has these parts: Part variable object index Description A variable declared as a PropertyDef object. Receives the specified property definition. An object expression that evaluates to a PropertyDef object. An integer index that identifies which element in tbe 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 obj ect. AreSame.Count. 8.5 Code Set Relationships The interface_jsCodeSetFor_Properties relationship couples a property definition to an interface containing possible values for that property. This allows a property to be code-listed. 8.5.1 CodeSetlnterface Collection This collection of one identifies the interface that a property definition uses. Collection Descriptor Relationship Type Source Is Origin Minimum Collection Size Maximum Collection Size Sequenced Collection Deletes Propagated Destinations Named Case Sensitive Names Unique Names Descriptor Value Interface_IsCodeSetFor Properties No Zero One No No No Not Applicable Not Applicable Syntax Set variable = object.CodeSetlnterface (index) The CodeSetlnterface collection syntax has these parts: Part Description variable A variable declared as an InterfaceDef obj ect. Receives the specified class 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. CodeSetlnterface.Count. 8.5.2 PropertiesForCodeSet Collection This collection specifies the properties that use a code set interface. Collection Descriptor Descriptor Value Relationship Type Interface_IsCodeSetFor Properties Source Is Origin Yes Minimum Collection Size Zero Maximum Collection Size Many Sequenced Collection No Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable Unique Names Not Applicable Syntax Set variable = object.PropertiesForCodeSetf index,) The PropertiesForCodeSet collection syntax has these parts Part Description variable A variable declared as a PropertyDef obj ect. Receives the specified property definition. object An object expression that evaluates to an InterfaceDef obj ect. 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 obj ectPropertiesForCodeSetCount. 1. Introduction This Appendix discloses additions to the Unified Modelling Language (UML) needed to describe the metadata used to describe one embodiment of the present invention. 2. Class properties IGeometry Below are specific properties defined for UML classes. • TypelnRepository — 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 "F 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. • IsDuallnterface — 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 falgs 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. VP object browser) • Defaultlnterface — Null string by default. If TIR 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 T' 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. • SemantieProgID — 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 InterfacelD of the COM interface. 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. If TIR is class or interface, this string property holds the ObjectID of the repository classdef or interfacedef represented by the DML. 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. • 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 artributes. • 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 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 QUID used to represent the type is the same QUID used in the IJAssocRelation::QetCollectionOfRelationsByType method. Previously, the QUID used for the relationship type was extracted from the QUID part of the relationship object id in the repository, this property is now used instead of the QUID 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. • ObjectlD — 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 association. The export tool attempts no automatic assignment. • Max — Possible values of 0 to infinity (represented by —I). The default value is -I. This string property defines the cardinality of one side the relationship represented by the UML association. 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, [he 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. • 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 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 displayed by the attribute control.. • UnitsOfMeasure —0 by default. It contains the unit type of the attribute. • PrimaryUnitsOfMeasure, SecondaryUnitsOfNleasure, TertiaryUnitsOfMeasure —0 by default. It contains the code for the display units. • CoIumnName — 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_STINYrNTJ SQLJTINYINT, I, 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 attribute 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 Generalize property Below is the property defined for UML generalization (inherit) element. • AggregateeClass — Null string by default. This string property 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 rip 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 .rip using the following syntax. define OBJTD IJDGeometry 0xal732cbf0x51360xl ldl 0x97 0x70 0x08 0x00 0x36 0x75 0x42 0x03 0x0 define ITD IJDGeometry 0xal732cbf 0x5136 0x11 dl 0x97 0x70 0x08 0x00 0x36 0x75 0x42 0x03 create INTERFACE IJDGeometry objid IJDGeometry iid IJDGeometry A repository Interface definition can be specified using UML and GSCA[) properties. Placing a UML class, assigning an interface name, and setting GSCAD property TypelnRepository to Interface is all that is necessary for the export tool to define the interface definition in the repository. However, if this interface has already been defined in an application, it is mportant for he GSCAD GUID property to be properly set. This property defines the [nterface IID that must match up with the defined LID in the application. Looking at the above rip text, the USCAD GUID property should be defined as {al732cbf-5136-1 ldl-9770-080036754203}. 6.2 Interface inheritance GSCAD applications may use inheritance information for query and user defined type support. No rip syntax exists for describing interface inheritance. It is defined in DML as follows. For interface inheritance, the inherits (also called generalization) UML relationship requires no GSCAD property settings. 6 3 Interface implies relationships OSCAD applications use implies infomiation for query support. No rip syntax exists for describing interface implies relationships. It is defined in UML as follows. 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. 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 mote information. Interface scoping is defined in rip 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 IIOccurrence The same is defined in UML as follows. Two interfaces can be considered equivalent by the associativity. It is defined in UML as follows. 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. • ClassName - 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 IsGIobal 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, IsOIobal — 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 rip using the following syntax. define OBJID XFormModel Oxl 0x2 0x3 0x1 0x2 0x3 0x1 0x2 0x3 0x10x3 0x0 createRELATION XformModel Origin UCopyXEorm XformModelOrigin Destination IJDLine XformModelDestination Type COLLECTION_NAMING setPROPERTY XFormModel IManageDelete DeleteForward type char index 1 value NO_PROPAGATE setPROPERTY XFormModel IManageDelete Delete_Backward type char index 2 value PROPAGATE -setPROPFRTY XFormModel IManageDelete ConnectionProgID type char index 3 value XFormCompSticXFormCompStic. 1 The same is defined in UML as follows. 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 functions 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: 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 XforrnModelOrigin origin collection on IJCopyXForm defined in rip syntax became the role on IJDLine in UML. The IsOrigin GSCAD property on a IJML 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 OSCAX) 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 rip syntax as follows. //Define semantic define OBJID SMakeBeam 0x22d718be 0x9cef Oxlldl 0xa6 0x77 0x0 OxaO 0xc9 0x8d 0x9d Oxbl Ox 10 createlNSTANCE SemanticDef SMakefleam ConnectTo IMakeBeam IHoldSemantic Semantics setPROPERTY SMakeBeam ISemantic nonanie type char index 1 value Compute setPROPERTY SMakeBeam ISemantic noname type char Index 2 value Beams MakeBeam.ProfileVector.l //Add profile input argument define OB JID ProfileArg insertlNSTANCEArgumentDef connectto setPROPFRTY type Index value setPROPERTY type Index value //Add vector input argument define OBJID VectorArg 0x22d718c2 0x9cef Oxlldl 0xa6 0x77 0x0 OxaO 0xc9 0x8d 0x9d Oxbl 0x0 ProfileArg SMakefleam ISemantic Arguments ProfileArg IHaveArguments noname char 1 INPUT ProfileArg IHaveArguments noname QUID 2 ProfileForBeam 0x22d718c4 0x9cef Oxlldl 0xa6 0x77 0x0 OxaO 0xc9 0x8d 0x9d Oxbl 0x0 insertlNSTANCEArgumentDef VectorArg connectto 2 setPROPFRTY SMakeBeam ISemantic Arguments VectorArg IHaveArguments noname type char Index value INPUT setPROPERTY VectorArg IHaveArguments noname type GUTD Index 2 value VectorForBeam //Add beam output argument define OBJID 0x22d718c5 0x9cef Oxlldl 0xa6 0x77 0x0 OxaO 0xc9 ResultingBeamArg 0x8d 0x9d Oxbl 0x0 insertlNSTANCEArgumentDef ResultingBeamArg connectto SMakeBeam ISemantic Arguments 3 setROPERTY ResultingBeamArg IHaveArguments noname type char Index 1 value OUTPUT setPROPFRTY ResultingBeamArg IHaveArguments noname type GUID Index 2 value ResultingBeam The same is defined in UML as follows. 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 IBeamMake 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 TypelnRepository property set to Interface. SMakeBeam is different because its QSCAD TypelnRepository property is set to Semantic. In fact, looking at the OSCAD properties of SMakeBeam we see the following settings: • TypelnRepository = Semantic • SemanticType = Compute • SemantieProgID = Beams,MakeBeam,ProfileVector.l Since TypelnRepository is set to Semantic, the export tool treats SMakefleam 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, Selfjnput, Self_output, Self_constraint The Rose98 property specification for the ProfileProvider property on SMakeBeam is shown below: 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 IB earn be both the Active Entity and Passive Entity. Now IBAeam is both the Active Entity and Passive Entity. How call 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 Selfjnput, Self_output or Self_constraint argument, ANY role name on the IBeam can be listed. Therefore, we could have specified VectorRequester: String = Selfoutput 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 Selfconstraint roles must have IsOrigin set to false, When the export tool finds a semantic, it automatically labels the association between the semantic and interface Tie To. 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 relationship. See assoc documentation for more information. An indirect interface argument to a semantic is defined using rip syntax as follows. //Define a semantic to compute the length of the beam define OBJID SComputeBeamLength 0x3 0x1 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0x10 createlNSTANCE SemanticDef SComputeBeamLength ConnectTo LAnalyzeBeam IHoldSemantic Semantics setPROPERTY SComputeBeamLength ISemantic noname type char index 1 value Compute setPROPERTY SComputeBeamLength ISemantic noname type char Index 2 value Analysis.BeamLength. 1 //IBeam as argument define OB JID BeamArg insertlNSTANCE connectto setPROPERTY type Index value setPROPERTY type Index value 0x334 0x1 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0x0 ArgumentDef BeantArg SCompuiel3eamLength ISemantic Arguments . BeamArg IHaveArguments noname char 1 INPUT BeamArg IHaveArgunients noname GUID 2 BeamTo Analyze //The actual argument to the semantic is not IBeam but rather UGeometry setPROPFRTY BeamArg II laveArguments noname type IK) Index 3 value UGeometry The same is defined in LJML as follows. In this example, the argument to the semantic is in the form with BeamProvider being the role name and IJGeometry being the interface name. The export tool detects the semicolon and generates metadata indicating the semantic's 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 find the argument role directly tied to the active-ferity, 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. 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. 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 rip syntax exists for describing COM classes. It is defined in UML as follows. The UML generalization (inherits) relationship is used with the "Implements" stereotype name. The export tool will generate a repository class defimtion 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 TypelnRepository 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. 6.10 Aggregation and containment on COM classes GSCAD applications currently do not make use of CONI 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. No rIp syntax exists for describing aggregation or containment. It is defined in UML as follows. 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. Here CSpecialBean contains the IBeam interface on CBeam. The UML generalization relationship is used as with aggregation but with the Implements stereltype name. Note an ambiguity exists in the following case. 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 EBeam 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. WE CLAIM: 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 as claimed in claim 1, wherein the second entity has an active entity. 3. The method as claimed in claim 2, wherein the active entity has an associated stub object. 4. The method as claimed in claim 2, wherein the first entity has passive entity. 5. The method as claimed in claim 1, wherein the objects are persistent objects. 6. The method as claimed in claim 1, 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 as claimed in claim 1, wherein the semantic object is accessed from a DLL file. 8. The method as claimed in claim 1, 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 as claimed in 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 as claimed in claim 10, wherein the metadata is stored in a COM or CORBA repository. 12. The method as claimed in claim 10, wherein the semantic object is stored in a DLL file. 13. A method of 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 us 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 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. Dated this 30th day of October, 2001 [JAYANTA PAL] OF MREMFRY & SAGAR ATTORNEY FOR THE APPLICANTS

Documents:

abstract1.jpg

IN-PCT-2001-01336-MUM-ABSTRACT(30-10-2001).pdf

IN-PCT-2001-01336-MUM-ABSTRACT(AMENDED)-(28-6-2005).pdf

IN-PCT-2001-01336-MUM-ABSTRACT(GRANTED)-(18-7-2007).pdf

in-pct-2001-01336-mum-cancelled pages(28-06-2005).pdf

IN-PCT-2001-01336-MUM-CANCELLED PAGES(28-6-2005).pdf

IN-PCT-2001-01336-MUM-CLAIMS(30-10-2001).pdf

IN-PCT-2001-01336-MUM-CLAIMS(GRANTED)-(18-7-2007).pdf

in-pct-2001-01336-mum-claims(granted)-(28-06-2005).doc

in-pct-2001-01336-mum-claims(granted)-(28-06-2005).pdf

in-pct-2001-01336-mum-correspondence(28-06-2005).pdf

in-pct-2001-01336-mum-correspondence(ipo)-(18-07-2007).pdf

IN-PCT-2001-01336-MUM-CORRESPONDENCE(IPO)-(31-8-2007).pdf

IN-PCT-2001-01336-MUM-DEED OF ASSIGNMENT(14-10-2003).pdf

in-pct-2001-01336-mum-deed of assingment(17-09-2003).pdf

IN-PCT-2001-01336-MUM-DESCRIPTION(COMPLETE)-(30-10-2001).pdf

IN-PCT-2001-01336-MUM-DESCRIPTION(GRANTED)-(18-7-2007).pdf

in-pct-2001-01336-mum-drawing(28-06-2005).pdf

IN-PCT-2001-01336-MUM-DRAWING(30-10-2001).pdf

IN-PCT-2001-01336-MUM-DRAWING(AMENDED)-(28-6-2005).pdf

IN-PCT-2001-01336-MUM-DRAWING(GRANTED)-(18-7-2007).pdf

IN-PCT-2001-01336-MUM-FORM 1(14-10-2003).pdf

IN-PCT-2001-01336-MUM-FORM 1(25-7-2005).pdf

in-pct-2001-01336-mum-form 1(28-06-2005).pdf

IN-PCT-2001-01336-MUM-FORM 1(30-10-2001).pdf

in-pct-2001-01336-mum-form 13(19-11-2001).pdf

in-pct-2001-01336-mum-form 19(27-04-2004).pdf

IN-PCT-2001-01336-MUM-FORM 2(COMPLETE)-(30-10-2001).pdf

IN-PCT-2001-01336-MUM-FORM 2(GRANTED)-(18-7-2007).pdf

in-pct-2001-01336-mum-form 2(granted)-(28-06-2005).doc

in-pct-2001-01336-mum-form 2(granted)-(28-06-2005).pdf

IN-PCT-2001-01336-MUM-FORM 2(TITLE PAGE)-(30-10-2001).pdf

IN-PCT-2001-01336-MUM-FORM 2(TITLE PAGE)-(GRANTED)-(18-7-2007).pdf

in-pct-2001-01336-mum-form 3(30-10-2001).pdf

in-pct-2001-01336-mum-form 5(30-10-2001).pdf

in-pct-2001-01336-mum-form 6(14-10-2003).pdf

IN-PCT-2001-01336-MUM-POWER OF AUTHORITY(14-10-2003).pdf

in-pct-2001-01336-mum-power of authority(17-09-2003).pdf

in-pct-2001-01336-mum-power of authority(28-06-2005).pdf

IN-PCT-2001-01336-MUM-POWER OF AUTHORITY(6-5-2002).pdf

IN-PCT-2001-01336-MUM-SPECIFICATION(AMENDED)-(28-6-2005).pdf

IN-PCT-2001-01336-MUM-WO INTERNATIONAL PUBLICATION REPORT(30-10-2001).pdf