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

Abstract

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

Description

MANAGING OBJECT RELATIONSHIPS USING AN OBJECT

REPOSITORY

CROSS-REFERENCES TO RELATED APPLICATIONS This application claims priority from the following provisional patent application, the disclosure of which is herein incorporated by reference for all purposes: U.S. Provisional Patent Application No. 60/131,970 in the names 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 developing applications using object-oriented frameworks and repository technology. Repositories enable sharing and reuse of information by providing a common hub for storing metadata which describes the structure and meaning of software components. Metadata enables heterogeneous applications to manipulate software components without knowing the implementations of the components. To promote sharing and reuse of metadata information among heterogeneous applications, information models are defined to standardize the structure and semantics of the metadata. A repository, using a standardized information model, provides a global and consistent mechanism for accessing metadata for application development. An example of a repository is the Microsoft Repository developed by

Microsoft Corporation of Redmond, Washington. The Microsoft Repository uses the Open Information Model (OLM) for describing metadata specifications and provides an environment for sharing, reuse, and integration of metadata for application development. Information stored in the Microsoft Repository is exposed using Microsoft's Common Object Model (COM) which forms the basis for the Object Linking and Embedding (OLE) technology which allows objects to share data and capabilities. COM defines a binary standard for object implementation that is independent of the implementation programming language. COM objects are in-memory representations of the information stored in the repository. A repository may include a object-oriented or relational or mixed database.

The repository information model defines the classes of the objects, types of relationships that can exist between the objects, and various properties that are attached to the object classes and the relationship types. A "class" may contain properties, methods, and collections which are grouped into functionally related groups which are implemented as COM "interfaces." In COM, a class may have multiple interfaces which are publicly accessible to users of the object-oriented framework and enable communication between applications.

A repository object is defined in terms of the interfaces that it exposes. The set of interfaces that an object exposes describes the object's state, the manner in which the object can be manipulated, and the associations the object can have with other objects. Relationships may also be defined between interfaces of different objects or of the same object. Further information and details about COM and OLE may be obtained from "Inside OLE 2" by Kraig Brockschmidt, 1994, Microsoft Press, and "Inside COM, Microsoft's Component Object Model," by Dale Rogerson, 1997, Microsoft press, both of which are hereby incorporated by reference for all purposes.

Fig. 1 depicts a convention representation of a COM interface 10, for an object 11 (another term for object 11 is component) and a user 12 of the object. Object 11 is said to have an "interface implementation", including interfaces 13 and 14, that are analogous to an object oriented programming "class." Interfaces 13 and 14 include member functions 15 and 16, respectively. User 12 can manipulate object 11 by calling functions 15, and 16 of interfaces 13 and/or interface 14, respectively. In response to the function calls, object 11 may return specific data about itself to user 12. Object 11, however maintains exclusive control of its own data 17. In some cases user 12 may only be aware of one of several interfaces available in object 12. The available interface may then be queried for additional interfaces. A pointer to the queried interface is returned if the queried interface is supported by the object. For example, the IUnknown interface 13 is a COM interface that is typically available to all users of COM objects. The IUnknown interface may then be queried to obtain pointers to other interfaces supported by the object, such as interface 14. After obtaining a pointer to interface 14, user 12 can call member functions 16 belonging to interface 14.

As previously stated, relationships may be established between interfaces of one or more objects or between interfaces of the same object. A relationship describes the way in which one object refers to another object, as exposed through their interfaces. The participants in a relationship are usually referred to as "entities" participating in the relationship. Relationships are usually binary, for example relationships in Microsoft Repository, may be directed or bi-directional. A relationship typically includes an origin of the relationship, referred to as the "origin" entity, and a destination of the relationship, referred to as the "destination" entity. In Microsoft Repository, each relationship conforms to a particular relationship type and is associated with an object of the class RelationshipDef. This object contains the metadata associated with the relationship.

Several actions have to be preformed when entities involved in a relationship are changed, for example, modified, copied, or deleted. These operations are important for maintaining referential and data integrity of the object system.

2> Accordingly, an important aspect of any object-oriented framework system is the manner in which referential and data integrity of the system is maintained when entities involved in a relationship are changed.

Several techniques have been developed for maintaining integrity of the object system when entities participating in relationships are changed. In conventional systems, the actions be performed upon a change operation are usually associated with each occurrence of the relationship. In addition, the code implementing the actions is typically spread through out the object implementation and thus is difficult to understand and maintain. The increased complexity of the implementation also makes it unsuitable for modification or customization.

Thus, there is a need for a relationship management system which allows generalized relationships to be defined between objects and which provides a simplified technique for maintaining referential and data integrity of the object system when objects involved in a relationship are changed.

SUMMARY OF THE INVENTION One embodiment of the present invention provides a method of maintaining consistency between objects in a computer system. The method includes providing a first relationship between a first entity and a second entity. A semantic is also provided, including an action to be performed in response to a change in the first entity. A semantic object is associated with the second entity and making a change in the first entity invokes the action. In a second embodiment, the method may also include providing a second relationship between a third entity and the second entity. And after the action is invoked, performing the action on the third entity. The action may be selected from a group consisting of copy, delete, and modify.

In another embodiment a computer system for maintaining consistency between objects is provided. The computer system includes a processor; and a memory coupled to the processor. The memory stores relationship pattern information and modules for execution by the processor. The pattern information includes information defining a first relationship between a first entity and a second entity, information defining a second relationship between a third entity and the second entity, and information defining a semantic object with actions to be performed for changing the third entity in response to changes in the first entity. The modules include a module for associating the semantic object with the second entity and a module for invoking the actions when the first entity is changed.

In yet another embodiment a method of assembling information in order to maintain integrity of objects in a database is provided. The method includes establishing 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, Relation_B 86, and Relation_C 88. Relation_A 81 shows a dependency relationship with a Origin 82 and a Destination 84, where Origin 84 and Destination 86 are two roles of Relation_A. A semantic object 80 is associated with active entity C 76 and controls the processing to be triggered, in the context of an active entity, when an entity belonging to the relationship pattern is change, for example, modified, copied, or deleted.

Fig. 4 depicts an example of a relationship pattern 100 including active entity IJMakeParaAtDistance 102 and three passive entities 104, 106, and 108 defined as IJDLine interfaces. Entities 104 and 106 are the input entities while entity 108 is the output entity for relationship pattern 100. According to the relationship pattern of Fig. 4, output entity 108 is drawn parallel to input entity 104 and at a predetermined distance from input entity 106. Passive entity 104 is in a relationship "ParallelTo" 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_LMPLICIT_INPUT / OUTPUT indicates that entities enumerating the corresponding relation should be considered as argument of the semantic even if not enumerated by this function

IJCompute : : Evaluate

Asks the semantic(s) to update its output after a change of one or more of its inputs. This function is called only if arguments of the semantics have been actually been modified.

IJCompute: :GetSolver

Only used on constraint to find the corresponding constraint solver.

IJCompute: :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.

IJCompute: :ImplementDeferOrError Indicates if the semantic is defer / error aware.

}

The code implementing the Evaluate method may be, for example, the following (stub format): STDMETHODIMP CMakeParallelComputeSem: Evaluate

(LPENUMJLDREF 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=LNPUT 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 LTD (Interface Identifier) - OBJ D (Object Identifier) pair (step 212). The active entity is then created or located (step 214) using another GULD or IID-OBJID pair. In step 216 the relationships between the active entity and one or more passive entities are added. These binary relationships may have a cardinality and/or a direction. The relationships may have roles, for example, a dependency relationship has an "Origin" role and a "Destination" role. The semantic 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 IIDs for passive entities are declared. A relationship pattern uses objects via their interfaces. Thus the object-interface pairs for all passive contributors to each relationship in the pattern need to be specified. In our example, we have the same JDLine accessed via its IJDLine interface for each of the three relationships 120, 122, and 124. Thus we define an OBJID (which is a GUID appended by a long identifier) and refer to an existing IID. This GUID should be the same as the interface IID to be used.

// Define OBJTD and IIDs that serve as (Passive) JDLines define IID 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 IID:

createLNTERFACE IJDLine objid JDLine iid IJDLine

Note that we could have called the OBJTD, ILD and INTERFACE by any names we chose. It is not the name ("IJDLine") but the actual value of the IID that marks it as an

IJDLine interface.

At step 214 an OBJID and LTD for the active entity is declared. In our example, the active entity is a stand-alone. That is, it exists for the sole reason of tying the passive entities of the relationship pattern together, and does not have serve as an independent business object. The name of the active object is: MakeParaAtDistanceHub and its corresponding interface: IJMakeParaAtDistanceHub. The process in step 214 is similar to step 212. define IID IJMakeParaDistanceHub 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:

ϊ-z. define OBJID ParallelTo 0xE6FAEAE2 0x77BA 0x1 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 IJMakeParaDistanceHub (and name the origin role "ParallelToOrigin"), the destination as IJDLine (and name the destination role "ParallelToDestination"), and the type as COLLECTION_NAMLNG: createRELATION ParallelToRelation Origin IJMakeParaDistanceHub ParallelToOrigin

Destination IJDLine ParallelToDestination Type COLLECTION_NAMING

The other two relationships are declared similarly (with different GULDs, 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 OBJTD, in this case the identifier of our semantic instance: define OBJTD MakeParallelComputeSem 0xE6FAEAE4 0x77BA Ox 11 d 1 OxBD 0x33 0x08 0x00 0x36 0xF4 Ox 17 0x03 Ox 10

Next an instance of the semantic object is created (using the createTNSTANCE 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: createTNSTANCE 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 AnchorS emantics.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 line and the distance line. The third argument is the output line. The declaration of the parallel input line is shown below. The other two are similar (see Appendix 1).

We begin declarations by creating OBJID' s. Each argument has a corresponding OBJID. We name each argument according to the relation that it represents. We then connect each argument to the semantic. Note that the use of the ConnectTo keyword in this situation employs an additional argument following the collection name (Arguments): the index (1, 2, or 3) of the argument. This determines the order of arguments evaluated by the Evaluate method.

define OBJTD ParallelTo_Arg 0xE6FAEAE5 0x77BA 0x1 ldl OxBD 0x33 0x08 0x00 0x36 0xF4 Ox 17 0x03 0x00 insertLNSTANCE ArgumentDef ParallelTo_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^ 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, IJXFormPipe (active entity) 410 that has relations 412, 416, 418 to the passive entities, IJDPipe 422 and IJLine 424, and is tied to the compute semantic SXFormPipe 450. The descriptions of various metadata of one embodiment of the present invention that can be stored in a Repository are given in Appendix 3. The extensions to UML for one embodiment of the present invention are given in Appendix 4. Both Appendices 3 and 4 are incorporated herein.

In order to create metadata to be stored in the Repository for this embodiment using the example UML diagram of Fig. 7, the steps in Fig. 6 are followed, although not necessarily in the same order. Step 210 describes the relationship pattern in the UML diagram of Fig. 7. In step 212 the passive entities 422, 424 need to be added. A class IJDPipe is first added:

In the Typelnrepository "Value" column, change the value to Interface

Change the "Value" of GUID and put in the GUID of IJDPipe: {E0C4E513-6EBD- 11 D2-BDEF-080036801 C04}

There are two ways to find the GUID of an interface: (1) look at the corresponding .idl file where the interface has been defined, or (2) use the registry (regedit) and do a search for the interface name such as IJDPipe 422. Next the IJLine 424 interface is added. For this example it is assumed the IJLine interface already exists. In step 214 the active entity, IJXFormPipe 410, is added:

In the Typelnrepository "Value" column, change the value to Interface

Change the value of GUID and put in the GUID of IJXFormPipe: {4AC243C0-70F8-11D2-BDEF-080036801C04}

vs 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 SsemanticProgID to

SXFormGSCADPipe.SXFormPipe.l. (It is the ProgID of the compute semantic.)

Next an association, TieToSXFormPipe, is created between IJXFormPipe 410 and SXFormPipe 450.

At step 216 binary relationships are added:

Create an association between IJDPipe and IJXFormPipe: Name: InputPipe 412 Role A (IJXFormPipe side): InputPipeDst 420

Role B (IJDPipe side): InputPipeOrg 422 GSCD B Tab, change IsOrign: True

Create an association between IJDPipe and 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

XG propagated consistently through the system by using the metadata and the semantic object(s). Use of the information in the relation objects and/or the active entities, i.e., at the business model level, is not needed, as opposed to prior art which needed to access to one and/or the other. An example will show the differences. Fig. 8 illustrates two objects: a dimension 512 and a line 510 and is described in Fig. 8 of Patent No. 5,692,184. In this example, the dimension 512 depends on the line 510 such that whenever the geometry of the line 510 changes the dimension 512 is re-calculated.

Fig. 9 illustrates a graphic representation of the COM interfaces for line 510 and dimension 512 of Fig. 8 and is described in Fig. 9 of Patent No. 5,692,184 (col. 63, line 49 to col. 64, line 37). The three nodes in the associative graph are a value node 530 representing the line's geometry (identified by line 540, and interface IJLine 550), a function node 560 representing the evaluation function, "ComputeCFun," (identified by interface IJCompute 520), and a value node 570 representing the line's dimension (identified by dimension 580, and interface IJDimension 590).

The evaluation function of function node 560 is called every time the IJLine interface 550 is changed. The evaluation function determines how the output entity, in this case IJDimension 590, is modified due to the change in input entity, IJLine 550. The evaluation function is accessed through its interface IJCompute 520, which is in turn accessed through IJRelation 515. Thus the evaluate function is accessed through a relation interface (IJRelation 515) and its interface, IJCompute 520 is part of the dimension object 570, 580.

Fig. 10 illustrates a UML representation for line 510 and dimension 512 of Fig. 8 using a specific embodiment of the present invention. Besides the IJLine Interface 550 (input passive entity) of Line object 610 and IJDimension interface 590 (output passive entity)of Dimension object 612, there is a IJHub interface 620 (active entity)for the hub object 614. IJHub 620 has no method or properties and serves solely as a hub between the two passive entities 550 and 590. There are two binary relationships, Relation_A 622 and Relation_B 624. The relationships 622 and 624 are different than those of Fig. 9, IJRelationValue 517 and IRelation 515 above, in that 622 and 624 do not point to a function. In one embodiment the evaluation function is in the semantic object 630 and is accessed through the IJCompute interface (not shown). The semantic has two arguments: Relation_A: IJLine = INPUT 632 and Relation_B: IJDimension = OUTPUT 634. Thus the semantic object 630 is separate from the entities 550, 590, and 620. X 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. IJDimension 640 is both a passive entity, as it receives the output of the semantic object 656, as well as active entity, as it tied to the semantic object 656. Note that more than one semantic may be associated with one active entity. The relationship between IJLine 550 and IJDimension 640 is SpecialRelationForThatPattern 650 and it has an origin role 652 and a destination role 654. Fig. 11 shows a relationship pattern of Fig. 10 at the business model level.

Fig. 11 has instances of the classes given in Fig. 10 and has no semantic object 630. "xxx" 610-a is an instance of class Line 610. "yyy" 612-a is an instance of class Dimension 612. "Instance of Hub" 614-a is an instance of class Hub 614. There is also an instance 622-a of Relation_A 622-a and an instance 624-a of Relation_B 624-a. Thus a change on "xxx" 610-a may cause a change in "yyy" 612-a. However, how the change is accomplished is not part of the business level, but is part of the metadata and semantic object (see Fig. 10).

Fig. 12 gives a flowchart illustrating the updating process for one embodiment of the present invention. At step 710 the value of an object is changed for example, modified (or the object may be deleted or copied). Next at step 712 the relations associated with the changed object are identified. At step 714 the metadata is examined to find the active entity that has a relation to the changed object. A semantic 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 IJHub 620.

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

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

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

Library) file containing the semantic object 630.

8. Cocreate the object having CLSID found in step 7 and query its IJCompute interface. "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). IJDLine 810 is a passive entity. IJCopyXForm 812 is an active entity. SCopyXForm 814 is the semantic object tied to the active entity 812.

Fig. 14 depicts relationship pattern information for Fig. 13 as seen using a repository browser of one embodiment of the present invention. The active entity ICopyXForm 812 is displayed in a tree format. IJDLine 810 is also displayed (not shown on Fig. 14) on the same level as 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.

lo APPENDIX 1

II Add new TIM (type information model)for the purpose of adding a

// new relationship pattern, // IJMakeAnchorLineParallelAtDistance.

CreateTTM AnchorParallelAtDistance-TTM

II Declare Passives for relationships.

// IJMakeAnchorLineParallelAtDistance uses only LTDLines, so here // define IJDLine IID, OBJID and declare Interface/Objid connection

// The value of the IID comes from the IDL file in the project that

// creates IJDLine define IID IJDLine 0x260E0AlF 0x4F18 0x1 IDl 0x97 0x70 0x08 0x00 0x36 0x75 0x42 0x03 define OBJID JDLine 0x260E0AlF 0x4F18 0x1 ID 1 0x97 0x70 0x08 0x00 0x36

0x75 0x42 0x03 0x00 createlNTERFACE IJDLine objid IJDLine iid IJDLine

II Declare Active Entity for a relationship pattern.

// define IJMakeParaDistanceHub IID, OBJID and INTERFACE connection define IID IJMakeParaDistanceHub 0x42D921B7 0x7567 0x1 IDl 0xBD0x31 0x08 0x00 0x36 0xF4 0x17 0x03 define OBJID IJMakeParaDistanceHub

0x42D921B7 0x7567 0x1 IDl 0xBD0x31 0x08 0x00 0x36 0xF4 0x17 0x03 createlNTERFACE IJMakeParaDistanceHub objid IJMakeParaDistanceHub iid IJMakeParaDistanceHub

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

lτ Origin IJMakeParaDistanceHub ParallelToOrigin Destination IJDLine ParallelToDestination Type COLLECTION_NAMING

// Declare Distance-defining Relation DistanceFromRelation. define OBJID DistanceFromRelation 0xE6FAEAE6 0x77BA 0x1 ldl 1 OxBD 0x33 0x08 0x00 0x36 0xF4 0x17 0x03 0x00 createRELATION DistanceFromRelation

Origin IJMakeParaDistanceHub DistanceFromOrigin Destination IJDLine DistanceFromDestination

Type COLLECTION_NAMING

II Declare Result-defining Relation MPADResultRelation. define OBJTD MPADResultRelation 0xE6FAEAE8 0x77BA 0x1 ldl OxBD 0x33 0x08 0x00 0x36 0xF4 Ox 17 0x03 0x00 createRELATION MPADResultRelation

Origin IJMakeParaDistanceHub MPADResultOrigin

Destination IJDLine MPADResultDestination

Type COLLECTION_NAMING

II Declare a compute semantic: ComputeParaDistance. Note that in

// this case, the long ID is 0x10 as opposed to our customary 0x00 define OBJTD ComputeParaDistance

0xE6FAEAE4 0x77BA 0x1 ldl OxBD 0x33 0x08 0x00 0x36 0xF4 0x17 0x03 0x10

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 TMSCoreRelPats.RLP createTNSTANCE 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.1

// Declare semantic arguments. Each argument has a corresponding

// OBJTD. 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 TMSCoreRelPats.RLP define OBJTD ParallelTo_Arg 0xE6FAEAE5 0x77BA 0x1 ldl OxBD 0x33 0x08 0x00 0x36 0xF4 0x17 0x03 0x00 insertlNSTANCE ArgumentDef ParallelTo_Arg ConnectTo ComputeParaDistanceObjid ISemantic Arguments 1

II Each argument has two properties: Property 1 specifies whether

// the argument is INPUT or OUTPUT. Property specifies the GUID of

// the Relation (e.g., relationship) to which this argument corresponds setPROPERTY ParallelTo_Arg LHaveAiguments noname type char

Index 1 value INPUT setPROPERTY ParallelTo_Arg IHaveArguments noname type GUID

Index 2 value ParallelToRelation

II Declare DistanceFrom argument define OBJTD DistanceFrom_Arg 0xE6FAEAE7 0x77BA 0x11 dl OxBD 0x33 0x08

0x00 0x36 0xF4 0x17 0x03 insertlNSTANCE ArgumentDef DistanceFrom_Arg

ConnectTo ComputeParaDistanceObjid ISemantic Arguments 2 setPROPERTY DistanceFrom_Arg IHaveArguments noname type char

Index 1 value INPUT setPROPERTY DistanceFrom_Arg IHaveArguments noname type GUTD

Index 2 value DistanceFromRelation

II Declare MPADResultRelation argument. Note that it is an OUTPUT argument define OBJID MPADResultRelation_Arg 0xE6FAEAE9 0x77BA 0x1 ldl 0xBD33 0x08 0x00 0x36 0xF4 0x17 0x03 insertlNSTANCE ArgumentDef MPADResultRelation_Arg ConnectTo ComputeParaDistanceObjid ISemantic Arguments 3 setPROPERTY MPADResultRelation_A IHaveArguments noname type char

Index 1 value OUTPUT setPROPERTY MP ADResultRelation_A IHaveArguments noname type GUTD

Index 2 value MPADResultRelation

Ik-

2.3 Semantics In A Recompute Graph

Assoc recognizes two kinds of semantics: associative functions and constraints. This paragraph will describe them. It will also introduce solvers and interface dependencies, that play also an active role during the update process.

2.3.1 Associative Functions

Consider a cell in a spreadsheet that calculates the sum of a row of numbers. Whenever a number in the row is modified, the sum is updated. In associative terms, this would be the result of an associative function which

• takes for input the row of numbers

• produces the relevant sum for output.

We say that the sum depends on the numbers in the row. Notice that you cannot directly edit the sum. The sum only exists as the output of the dependency relation. To change the sum you must change one or more of the values it depends on or make the sum depend on a new set of values. You can only affect the output of a recompute semantic by changing its input.

Now, consider another cell that calculates an average by dividing the sum. When a number in the row is changed: the sum would be updated first then the average would be updated, associative functions imply an ordering of evaluation

When an associative function is evaluated, itentirely 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.

S For example, suppose α lαnction that sets the start and end points of a line "Lιnt. /2Pts(Lιne, 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 PI, 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 mput point, the evaluation function LιneBy2Pts function is re-evaluated, and post back to the lme 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 m relationship

Consider a graphics system that can create a parallel constraint between two lines hnel and hne2

• The end-user can grab lmel with the mouse and move it In response, the system moves hne2 so that it remains parallel to lmel

• The end-user can also move lme2 and the system would move lmel to remain parallel

In associative terms, the lmes 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, m an equivalence relation any of the entmes 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 asolver , is used to modify value respectmg 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 begm point of a lme to match a given point "IsBegιnPoιnt(LO,Pl)" The lme geometry is only partially defined by this predicate If L0 or PI changes, the predicate, L0 and PI are passed to a solver The solver would modify L0 or PI to make LO's begm pomt comcident with PI If any other values were related by predicates to L0 and PI, those values along with their predicates would be passed to the solver at the same rime

2.3.3 Solvers

Constraints end up being quite inactive durmg the update process They

• enumerate their arguments and qualifies them mput / 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 mput 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 (pObjectllD) This means that a single COM object may become several values m 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 mdependent 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 addmg additional recompute semantics when a COM object plays the role of several value m 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 (IJRevιsion::Update, IJRevιsιon::Add)

• Search and sort of the dependent graph to obtam 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 calhngIJCompute::Evaluate

- A solver is evaluated by calling IJConstraιntSolver::Solve Constraints and related values are passed m 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 usmg 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 certam situations, a recompute semantic may need to modify somethmg not declare output. The modified entities are then kept in a look aside list At completion of the recompute process m 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 processmg That's why Assoc asserts if a semantic modifies a non output argument, without turning ON the "reentry mode" by calling IJRevisionrBatchReentry. 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 gomg to be modified. This means that the call is performed before the modificanon 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 m its initial state before its value gets affected.

2.6 Incremental Re-catch Of the Dependent Graph

When a dependent graph updates, an mcremental 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 "mcremental enable" (API

I RelationSolver::IsIncrementalEnable) It becomes extremely expensive when the constraint systems grows m size, example a the floor plan of an hospital, or a P&ID schema

The idea of mcremental 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 mcremental re-catch of the graph that adds all the constraints on

12 certam FROZE. < elements. In addition to these constrains, this will mtro αce 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 descπption here bellow to see how the solver could mdicate how many elements should be mtroduced in the initial constraint system, and how many more should be added at each re-catch (IJRelationSolver : :Get Width).

Incremental catch of the dependent graph with a solver width of 1

how many values on a constraint path between a modified value and a frozen value

2.6.2 Edition Of the Graph By the Evaluate Function Of a Recompute Semantic

As part of its processing, an evaluate function may modified certain relations of the dependent in the sense of

- semantic that the relation contams

- 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 descnbed m earlier paragraphs the different steps of an update operation are

1. Fmd the set of mterested 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 mput

3. Call m 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 domam of mterest (mcremental 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

IJRelationSolver::IsIncrementalEnable

This API is called by Assoc to figure out if the solver is mcremental enable or not. If mcremental enable, a partial catch of the constraint svstem can be performed. The system to can be later on complete at the request of the solver per the mcremental solvmg technique descnbed here above

A solver that is mcremental enable should return S_OK

IJRelationSolver::GefWidth

This API is called by Assoc to controls how many elements are retained initially m a mcremental constraint system, and to extend the constraint system when the solver asks for mcremental 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 mppAddedValues and return the status RELATION_S_INCREMENTAL_SEARCH to ask the recompute machine for a more complete graph.

All the semantics acting on these values and all the values that are values related to these semantics are then added to the graph After the graph is re-ordered, the evaluation functions with the added values for output are called before the constraint solver is called again with the extended system

An alternate solution is to ask for a complete search of the constraint system by returning RELATION_S_FULL_CONSTRAINT

2.6.4.2 API For Edition Of the Graph During IJCompute::Evaluate

When an Evaluate function changes the relationships m the dependent graph, it should return __iJATION_S_SEARCH to notify the update engme th ^e current graph is no longer valid, and ask for the mcremental graph.

2.7 Internal Atomicity Of Elements That Participate Recompute

2.7.1 Description Of the Problem

The overview of the associative subsystem descπbes how relanonship types are defined to interfaces, and how an element by exposmg several mterfaces 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 mterfaces of the element.

Example The object P0, exposes mterfaces LTDl and HD2. It participates by these mterfaces relationships Rl and R2. Because of meta data associated to these relationships

- (P0, IIDl) IS output of a semantic SI

- (P0, IID2) is mput of another semantic S2

Now the problem: How much these 2 values of the recompute graph(P0, IIDl) and (P0, IID2) can be seen mdependent from each other ?

• They are totally mdependent, HDl is representing for example the geometry of the entity, and IID2 its user properties. That's then irrelevant to the associative subsystem that the 2 entities of the recompute graph are coming from the same COM objet.

• They are not so mdependent from each other Posting new data to(P0, IIDl) changes the data obtained from the other (P0, UD2) When proceeding the update graph, the semantic SI, outputting to IIDl, should then be proceeded before S2 In that configuration, certam restπctions may also apply to guarantee consistency of the data model after all the recompute are performed. That's what will be developed m the rest of the paragraph.

2.7.2 Entities Seen As a Structure

An entity is seen as a structure, contaming fields or nested sub structures. This organises the internal data of the COM object mto a tree, and it defines its internal atomicity.

Interface IID used to connect relationships are paired to the atoms of the tree (fields, intermediate sub-structure, top most structure).

As a result of this tree like structure, when an element is modified through an IID

• All the atoms nested (or scoped) m 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 takmg them for argument

• If a semantic declares an IID for mput, 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 semandcs taking them for INPUT should recompute

3τ • Because outputnng to an outer IID is affecting the inner, the ordering ot ie semantic should be such that the semantic outputnng to the outer IID is called before the semantιc(s) taking the inner for mput

2.7.3 Member Assignment

The question is Do we allow

• Semantic 1 to declare IIDl for mput

• Semantιc2 to declare IID2 for output

With HD2 corresponding to an inner atom of HD1⁹

This violates somehow the rule that an entity can be OUPUT of only one semantic at the time, smce the recompute of both Semantic 1 and Semanϋc2 will affect what IID2 represents We propose to allow that with the following logic

• Semantic 1 affects globally the structure corresponding to HDl

• Semantιc2 is evaluated after, and ovemdes 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 mput 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 llustrates an object that exposes following IID πD_Full_Object It represents the complete object

HD_Geometry It represents the geometπc part of the objectand it's scoped mto IID_Full_Object

ITD_Attπbutes It represents the user attribution on the object It's scoped under IID_Full_Object It's a siblmg of IID_Geometry, which means thay modifymg IID_Geometry and IID_Attπbutes (or what's scoped under it) has no effect on each other

IID_Attrl and IID_Attr2 represents specific user attπbutes Their are sibling and scoped under HD_Attnbutes

Relationships to that object, and associated meta data are such that

(object, IID_Attπbutes) is output of semantic SI

(object, IID_Attrl) is output of semantic S2

(object, IID_Attr2) is mput of semantic S3

(object, IID_Geometry) is mput of semantic S4 (object, IID_Full_Object) is mput of semantic S5

If another entity that is mput argument of SI is modified, the sequence of recompute will be

- SI recomputes first This may change what is read from IID_Attrl, IID_Attr2

- S2 recomputes after, per "the member assignement 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 descπption of the element atomicity comes from the meta data of the application We may consider 2 possible ways of defining it

• At the interface level.

That's what we did uiitialy Meta data of an interface defines m which other interface this interface is 'scoped' This means that all the class exposmg this interface will present for it the same atomicity model, and that we have a unique scoping tree for all the intf, all the classes of the system This showed non pratical and caused unsolvable conflict in establishing

unique tree • At the class level.

The scopmg 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 scopmg information is explicitly defined for a given IID, this IID is considered directly scoped under IID_FULL_OBJECT (topmost atom representing the complete object)

2.7.7 API

Internal atomicity is descnbed as follow

• A specific IID IID_FULL_OBJECT is associated to the complete object

• HRESULT IJRelationMetaData GetScopιng( const GUTD Atom, GUID* ContaimngAtom), with Atom IN, Inquired atoms ContaimngAtom OUT Contaming atom Remarks

- Dependmg from IID_FULL_OBJECT should be the prefeπed way to depend on the complete object

- GetScopιng(IιD_FULL_OBJECT) should be the only call that returns S_FALSE, and no scopmg

3. API And Interfaces

What's bellow is just an introduction to the API Please refer to the complete Assoc API documentation for much more mformation 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 associatiated to that argument by pArgDesc->GetArgumentFlags(&flags)

- testing if that flag contamts the bit RELATION_MODIFIED

This function should notify the revision manager of the output argument about to be modified by calling IJRevιsιon->Update(pObject,ιιd) This should be done before the output is assigned a new value

Parameters LPENUMJARGDESC IN Enumerates the arguments of the semantic pRelatedValues

Return code

S_OK Successfull completion E FAIL Failure

3.1.2 IJCompute: -.PreValueModify

Purpose

Tells the semantics that a related entity is about to be modified This occurs before the modification actually happens The modification could come from a command / a recompute semantic or a solver.

Parameters

LPJARGDESC IN Value about to be modified pModifiedValue

LPENUMJARGDESC IN Enumerates the complete list of arguments of the semantic pRelatedValues

Precaution of use

• For performance reasons, PreValueModify of a semantic may be called for a value that is not actually argument of the semantic This is up to the semantic to control.

• The semantic has no persistance at all, not even between the call to PreValueModify and to Evaluate This means, that if the semantics has something to persist (example initial value for a constraint solver m order to find the solution the closest to the initial state), the semantics needs to return to persistent entity, by the mean of the pModιfiedValue->GetCollectιon

The "initial state" can the be stored for example m the active entity, or m 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 / eπor aware, its evuluate function will be called even if some of its arguments are m error / out of date.

If not, the associative system will propagate automatically the out of date / eπor stams 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

26 3.2.1 IJRelationSolver::SoIve

Purpose

Solves the constramts system after values or constramts participatmg it have been modified Like IJCcmpute Evaluate, this function should notified the revision manager of modified elementsbefore the modifications are performed

Parameters

LPENUMJARGDESC IN Values m the constraint system pRelatedValues

LPENUMCONSTRAINTDESC IN Constraint in the constraint system pRelatedConstraints

LPENUMJARGDESC* OUT Used by incremantal solver only, to ask values to be "unfrozen", when ppAdditionalValue an acceptable solution can not be found

A value is presented FROZEN to the solver can not be modified by the solver, when all the relationships that it participates have not been expored yet

3.2.2 IJRelationSolver::IsIncrementalEnable

Purpose

Indicates if the solver is "mcremental enable", and how many elements away from modified values should be presented "not frozen" to the solver Please refer to the paragraph about mcremental solving techniques for more information on the matter

Return code

s_oκ The solver is mcremental enable

S FALSE The solver is not mcremental enable

3.2.3 IJRelationSoIver::CetWidth

Purpose

For a solver incremental enable, mdicates how many unfrozen values should be left between any modifed value, and the first frozen value

Parameters

ULONG *wιtdh OUT Width, between 0 and 7 A value of 1 or 2 is recommended

% 3.2.4 IJRelationSoiver::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 altemate implementation could have been to pass for argument / enumerate directly a structure containing the corresponding fields. This is not pratical because

- more difficult to enable marshalling

- not VB compatible

- reference count nightmare since the stucture would containt intf pointer to be released by the caller.

3.3.1 IJArgDesc::GetArgumentObject

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 IJArgDesc: :GetArgumentIID

LPIID pIID O IID 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 : RELATION NPUT: This is a input arg of the semantic RELATIONJDUTPUT This is a output arg of the semantic RELATION_CONSTRAINT This is a constraint arg of the semantic RELATION_MODIFIED This arg has been modified

3.3.4 IJArgDesc::GetArgumentCollection

LPUNNOWN pCollection O The object is presented argument of the semantic, because it belongs to a relationships'collection of an active entity. This API lets the semantic retrieve the collection, and from there get more information (type of the relationship, identity of the active entity, etc).

3.3.5 IJArgDesc::GetIndexInCoIlection

ULONG *ρlndex 0 Returns the index of the argument in the collection

(NB This is 1 based: The first member of the collection is at the index 1)

3.3.6 IJArgDesc::GetIndexInSolverArgument

3τ ULONG *plndex O Only of use when the pointer IJArgDesc is obtained from the enumerator returned by IJConstraιntDesc::EnumConstraintArgs.

A solver is given for arguments the list of values and the list of constraint m the system The list of values is the accumlation of all the constramt arguments

For a given constramt argument, this function returns the mdex 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 m to constraint solver to descnbe the constramt participating the constramt system currently solved

3.4.1 IJConstraintDesc: :GetConstraint

LPUNKNOWN *pConstramt O Return the constramt That participates the constramt system The constramt solver may need then to Query and use other mterfaces 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 constramt is concidence, parallehsme, orthogonality, etc

3.4.2 IJConstraintDesc: :EnumArgOfConstraint

LPENUMJARGDESC * O Enumerates the arguments of this constramt as they participate the constramt ppArgDesc system The argument may be RELATION_MODIFIED or not It could be

INPUT only m the solver, while presented CONSTRAINT m the meta data, because of the presence of other semantics outputt g to it.

3.5 IJRelationGraphlnfo: Additional Information About the Graph That Recomputes

Recompute semantics m IJCompute Evaluate and solvers m IJRelationSolver Solve can query the first passed in argument (enumerator of related values) for this mterface, and obtam such additional information about the graph that recomputes.

3.5.1 IJHelationGraphInfo::IsCommitted No Parameters

Returned Value

S_OK The cuπent recompute corresponds to a modification about to be committed, hence to a call to ITransaction Commit

S_FALSE The current recompute coπesponds to an intermediate evaluation durmg the transaction, asked for by a call to IJRevision Flush Not to the final evaluation done at commut time of the transaction

3.5.2 IJRelationGraphlnfo:: EnumAddedRelationships

35 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 bemg marked RELATION_MODIFIED. This function allows identifying such configuration to implement optimized recompute by

- enumerating relationship added to the active entity

- by the mterface IJDRelationship on the enumerated relationship controls the impact that the added relationship may have (or may not have) on the current semantic.

Parameters

LPUNKNOWN pObject IN Inquired object

LPENUMUNKNOWN OUT enumerator of added relationships. The passed-m pObject can be ppEnumAddedRel ongm or destination of the relationship.

If no relationship has been added on pObject, a NULL enumerator is returned

Returned Value

s_oκ

E OUTOFMEMORY

3.5.3 IJRelationGraphlnfo:: EnumRemovedRelationships

Purpose

This function is for the same purpose as EnumAddedRelationships, to optimize recompute semantic with respect to deleted relationships

Parameters

LPUNKNOWN pObject IN Inquired object

LPENUMUNKNOWN OUT enumerator of removed relationships. The passed-m pObject can be ppEnumAddedRel ongm or destination of the relationship.

If no relationship has been removed on pObject, a NULL enumerator is returned

Returned Value

s_oκ

E OUTOFMEMORY

4. Symbolic Example a,4 Z,*K: == 12 c,8

Y, b = 2*a

b,8

*o X,b+d+-e==12 e,4

LEGEND:

V Associative constraint function

Each node contams 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 descπption 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 ordermg can be expressed as: a = Z^'= c < Y < b < X = d

- 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". Smce "a" now has a value of 2, the new value of "b" would be 4 w 3. "d", "X" and "e" would be passed to a solver to satisfy the predicate "X" Smce "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

\ Appendιx3 Metadata

1. Introduction

This Appendix describes the changes made to the Microsoft Repository needed to contain the additional metadata for an embodiment of the present invention

2. Repository Class Definitions

2.1 ReposRoot Class Definition

There is one root object in each repository The root object is the starting point for navigating to other objects in the repository The root object serves as the starting point for both type and instance data navigations

• Type data navigation:

When you create a tool information model the corresponding repository type library is attached to the root object via the ReposTypeLibs collection This collection can be used to enumerate all of the tool information models (type data) that are contained in the repository

• Instance data navigation:

Once a tool information model is defined the repository can be populated with instance data This instance data consists of objects and relationships that conform to the classes and relationship types of the tool information model

Because the objects are connected via relationships, you can navigate through this data However, to enable general purpose repository browsers to navigate this data, the first navigational step must be from the root object of the repository through a root relationship collection to the primary objects of your tool information model Primary objects are objects that make a good starting point for navigating to other objects of your tool information model

Because this root relationship collection is different for each tool information model, it must be defined by the tool information model There are two options for attaching this relationship collection to the root object

1. The ReposRoot class implements the IReposRoot interface This interface is provided to tool information model creators as a connection point You can add your connecting relationship collection to this 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 identήer is OBJID ReposRootObj

When to Use

Use the ReposRoot class to

• Obtain a starting point for navigating to objects in the repository

• Create a new tool information model

• Attach a relationship collection to the root object of the repository that connects to the primary objects of your tool information model

w Appendιx3 : Metadata

implements IRepositoryObject

/

/ ~X implements

ReposRoot

\

\ imple

Interfaces Interface Description lAnnotationalProps Gets and sets annotational properties

IManageReposTypeLib Adds tool information models (repository type libraries) to a repository

IRepositoryDispatch Provides enhanced dispatch support IRepositoryltem Manages repository objects and relationships. IRepositoryObject Retrieves repository object identifiers IRepositoryObjectStorage 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 information model contained in the repository database. Each tool information model provides a logical grouping of all of the type definitions related to a particular tool (or tool set) Repository type libraries are instances of the ReposTypeLib class.

To insert a new tool information model into the repository database, use the ReposRoot class

When to Use

Use the ReposTypeLib class to

• Define new classes, relationship types, and interfaces for a tool information model

• Retrieve or modify the global identifier associated with a repository type library

• Determine which type definitions are associated with a particular repository type library Appendιx3 : Metadata

implements

ReposTypeLib IRepositoryObject

-implements- -

implements

Interfaces Interface Description lAnnotationalProps Gets and sets annotational properties IRepositoryDispatch Provides enhanced dispatch support IRepositoryltem Manages repository objects and relationships IRepositoryObject Retrieves repository object identifiers IRepositoryObjectStorage Creates and loads repository objects

IReposTypeLib Creates class, interface, and relationship definitions for a repository type library

2.3 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

M Appendιx3 Metadata

\

IReposTypelnfo

Interfaces

Interface Description lAnnotationalProps Gets and sets annotational properties

ICIassDef Manages class definitions

IRepositoryDispatch Provides enhanced dispatch support

IRepositoryltem Manages repository objects and relationships

IRepositoryObject Retrieves repository object identifiers

IRepositoryObjectStorage Creates and loads repository objects

IReposTypelnfo Contains the collection of definition objects that are associated with a tool information model's repository type library

2.4 InterfaceDef Definition

The properties methods, and collections that a class implements are organized into functionally related groups Each group is implemented as a COM interface The properties, methods, and collections of each interface are members of the interface An interface definition is the template to which an interface conforms Interface definitions are instances of the InterfaceDef class

To create a new interface definition, use the 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 Appendιx3 : Metadata

implements

/ /

InterfaceDefU

implements

\

\ x^ I InterfaceDef implements

\ \

IRepo.sTypelnfo

Interfaces Interface Description lAnnotationalProps Gets and sets annotational properties HnterfaceDef Manages interface definitions IRepositoryDispatch Provides enhanced dispatch support IRepositoryltem Manages repository objects and relationships IRepositoryObject Retrieves repository object identifiers IRepositoryObjectStorage Creates and loads repository objects

IReposTypelnfo Contains the collection of definition objects that are associated with a tool information model's repository type library

2.5 RelationshipDef Definition

When you define a tool information model in the repository, you define classes of objects, types of relationships that can exist between objects, and various properties that are attached to these object classes and relationship types The relationship types that you define in your tool information model are represented by instances of the RelationshipDef class

When to Use

Use the RelationshipDef Class to access the properties of a relationship definition (also referred to as a relationship type)

To insert a new relationship type into a tool information model, use the ReposTypeLib class

-6 Appendιx3 : Metadata

ICIassDef

lAnnotationalProps

RelationshipDef

— — _j IRepositoryObject

Interfaces Interface Description lAnnotationalProps Gets and sets annotational properties IRepositoryDispatch Provides enhanced dispatch support IRepositoryltem Manages repository objects and relationships IRepositoryObject Retrieves repository object identifiers IRepositoryObjectStorage Creates and loads repository objects

IReposTypelnfo Contains the collection of definition objects that are associated with a tool information model's repository type library

2.6 Method Def 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

ft Appendιx3 : Metadata

implements

/ /

/

MethodDef IRepositoryObject implements- -54

\

\ implements

\

Interfaces Interface Description lAnnotationalProps Gets and sets annotational properties llnterfaceMember Relates a member to an interface IRepositoryDispatch Provides enhanced dispatch support IRepositoryltem Manages repository objects and relationships IRepositoryObject Retrieves repository object identifiers IRepositoryObjectStorage Creates and loads repository objects

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

M Appendιx3 : Metadata

Interfaces Interface Description lAnnotationalProps Gets and sets annotational properties llnterfaceMember Relates a member to an interface IPropertyDef Retains property characteristics IRepositoryDispatch Provides enhanced dispatch support IRepositoryltem Manages repository objects and relationships IRepositoryObject Retrieves repository object identifiers IRepositoryObjectStorage Creates and loads repository objects

2.8 CollectionDef Class Definition

Repository objects are related to each other via relationships The set of relationships, all of the same type, that relate one object to zero or more other objects, is a relationship collection

A collection type (also referred to as a collection definition) defines how instances of a particular collection type will behave The characteristics of the collection type determine

• The minimum and maximum number of items in a collection

• Whether or not the collection type is an origin collection type

• Whether or not the collection type permits the naming of destination objects, and if so, whether those names are case sensitive, and required to be unique

• Whether or not the collection type permits the explicit sequencing of items in the collection

• What happens to related objects when objects or relationships in the collection are deleted

• The kind of relationship that a particular collection type uses to relate objects to each other

A collection is attached to an interface as a member of the interface To add a new collection type to an interface definition, use the InterfaceDef class

When to Use

*#3 Appendix3 : Metadata

Use the CollectionDef class to retrieve or modify the properties of a collection type, or to determine the kind of relationship that the collection implements.

\ \ llnterfaceMember

Interfaces Interface Description lAnnotationalProps Gets and sets annotational properties. ICollectionDef Manages collection definitions. llnterfaceMember Relates a member to an interface. IRepositoryDispatch Provides enhanced dispatch support IRepositoryltem Manages repository objects and relationships. IRepositoryObject Retrieves repository object identifiers. IRepositoryObjectStorage Creates and loads repository objects.

3. Repository Interface Definitions

This chapter descnbes the various interfaces that are part of the type Infromation Model defined by Microsoft and exposed through the Repository Browser. As for the pre\ IOUS 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 lAnnotationalProps interface.

2. A property definition object must exist for an lAnnotationalProps interface property with a name that matches the name of your annotational property

so Appendιx3 Metadata

If these two requirements are met, then you can attach an annotational property value to an object by using the IReposProperty::put_Value method to set the value of the annotational property for that particular object

When to Use

Use the lAnnotationalProps interface to access the annotational properties of a repository object or relationship

Methods IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

Remarks

Annotational properties are maintained by the repository as string data The creator and users of the annotational property must get and set the property value using the appropriate data type via the VARIANT structure If a data type other than string is used, the repository will perform the appropriate data conversion

Since all annotational properties in the repository must be defined as interface members of the lAnnotationalProps interface, all annotational property names share the same name space When you choose a name for an annotational property, make the name as specific and unique as possible.

3.2 ICIassDef Interface

The ICIassDef interface helps you create tool information models, by adding interfaces to a class To insert a new class definition into a tool information model, use the IReposTypeLib interface

To complete a class definition, once you have added all of the 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 Appendix3 : Metadata

Retrieve the global identifier for the class

Access the collection of interfaces that are part of a class definition

Properties

Property Description

ClasslD The global identifier of the class

Methods

IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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.

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection.

ICIassDef Method Description

Addlnterface Adds an existing interface to the class definition

CreatelnterfaceDef Creates a new interface and adds it to the class definition

Objectlnstances Materializes an 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

5Z Appendιx3 : Metadata

The minimum and maximum number of items in a collection

Whether or not the collection type is an origin collection type

Whether or not the collection type permits the naming of destination objects, and if so, whether those names are case sensitive, and required to be unique

Whether or not the collection type permits the explicit sequencing of items in the collection

What happens to related objects when objects or relationships in the collection are deleted

The kind of relationship that a particular collection type uses to relate objects to each other is determined by its Collectionltem collection The Collectionltem collection associates a single relationship type to the collection type

To add a new collection type, use the llnterfaceDef 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

IDispatch 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

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

Properties Property Description

Flags Flags that determine the behavior of this type of collection IsOrigin Indicates whether or not collections of this type are origin collections

MaxCount The maximum number of target objects that can be contained in a collection of this type.

MinCount The minimum number of target objects that must be contained in a collection of this type

55 Appendιx3 ° Metadata

Collections

Collection Description

Collectionltem The collection of one relationship type that defines the relationship between target objects of this type of collection and a single source object

3.4 HnterfaceDef Interface

The properties, methods, and collections that a class implements are organized into functionally related groups Each group is implemented as a COM interface The properties, methods, and collections of each interface are members of the interface An interface definition is the template to which an interface conforms

To add a new interface to the repository, use the ICIassDef interface or the IReposTypeLib interface

When to Use

Use the 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

TableName The name of the SQL table that is used to store instance information for the properties of the interface

Methods

IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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 Appendιx3 : Metadata

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 Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

HnterfaceDef 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 lObjectCol interface pointer for the collection of all objects in the repository that expose this interface

Collections

Collection Description

Ancestor The collection of one base interface from which this interface derives

Classes The collection of classes that implement the interface

Descendants The collection of other interfaces that derive from this interface Members The collection of members that are attached to the interface definition

3.5 llnterfaceMember 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 llnterfaceMember 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 llnterfaceMember 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 Appendix3 : Metadata

Property Description

DispatchlD The dispatch identifier to use when accessing an instance of this type of member

Flags Flags that specify details about this type of member

Methods IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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.

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer. The

IReposProperties interface provides access to the Properties collection.

Collections

Collection Description

Interface The collection of one interface that exposes this type of member

3.6 IManageReposTypeLib Interface

Each tool information model that is stored in the repository is represented by a repository type library.

When to Use

Use the IManageReposTypeLib interface to

• Create a repository type library for a new tool information model

• Determine what tool information models are currently stored in the repository

Methods

IUnknown Method Description

SG Appendιx3 ^• Metadata

Querylnterface Returns pointers to supported interfaces

AddRef Increments the reference count

Release Decrements the reference count

IDispatch 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

IRepositorvDispatch Method Description get_Propertιes Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

IManageReposTypeLib Method Description

CreateTypeLib Creates a repository type library for a new tool information model

Collections Collection Description

ReposTypeLibs The collection of repository type libraries that are currently stored in the repository

3.7 INamedObject Interface

Normally, a name is associated with a repository object via a naming relationship The collection for such a relationship provides the scope for the name, and can require that all names in the collection be unique This is the preferred method for naming objects, when a given object will be the destination of only one naming relationship

If your tool information model contains a class that is not the destination of a naming relationship type, or is the destination of multiple relationship types, but no single relationship type is the obvious choice to be the naming relationship type, then you can attach the name property to the class This is accomplished by defining your class to implement the INamedObject interface If your class implements the INamedObject interface, the repository engine will use that interface when asked to retrieve or set an object name

When to Use

Use the INamedObject interface to access the Name property of a repository object that exposes this interface

Properties

5* Appendιx3 . Metadata

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

IDispatch 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.

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the persistent members exposed by the INamedObject interface

Remarks

None of the standard repository engine or Type Information Model classes implement the INamedObject interface However, the repository engine does use the INamedObject interface, if it is exposed by a repository object

When the IRepositoryltem::get_Name method is invoked for a repository object, the repository engine will perform these steps to retrieve the name

1. If the object exposes the INamedObject interface, the repository engine returns the value of the Name property

2. Otherwise, the repository engine searches for a naming relationship for which the current object is the destination object

3. If such a relationship is found, the repository engine returns the name associated with that relationship.

4. If the object is not the destination of a naming relationship, then the repository engine returns a null name

When the IRepositoryltem::put_Name method is invoked for a repository object, the repository engine will perform these steps to set the name

1. The repository engine sets the value of the Name property of all naming relationships for which the object is the destination

2. If the object exposes the INamedObject interface, the repository engine also sets the value of the Name property attached to that interface

5$ Appendιx3 : Metadata

3.8 IPropertyDef Interface

A property definition object specifies the characteristics of a particular type of property These characteristics are defined by the properties of the property definition object

To create a new property definition

1. Use the CreatePropertyDef method of the HnterfaceDef interface

2. Define any non-default characteristics of your new property definition by manipulating the properties of the property definition object

3. Commit your changes to the repository database

When to Use

Use the IPropertyDef interface to retrieve or modify the characteristics of a property definition

Properties

Property Description

APIType The C data type of the property

ColumnName The name of the column in the SQL table for this property

Flags Specifies details about the property

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

SQLSize The size in bytes of the property

SQLType The SQL data type of the property

Methods IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count.

IDispatch 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.

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection. Appendιx3 : Metadata

3.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 IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

IRepositoryltem Method Description

Delete Deletes a repository item getjnterface Retrieves an interface pointer to the specified item interface get_Name Retrieves the name associated with an item get_Repository Retrieves the IRepository interface pointer for an item's open repository instance get_Type Retrieves the type of an item Lock Locks the item put_Name Sets the name associated with an item Refresh Refreshes the cached image of the item

IRelationship Method Description get_Destination Retrieves an interface pointer to the destination object get_Origin Retrieves an interface pointer to the origin object

€0 Append ιx3 : Metadata

get_Source Retrieves an interface pointer to the source object get_Target Retrieves an interface pointer to the target object

3.10 IRepositoryObject Interface

The IRepositoryObject interface provides methods to manage repository objects

When to Use

Use the IRepositoryObject Interface to

• Retrieve the object identifier or the internal identifier for a repository object

• Retrieve a repository object's type or name

• Obtain a lock on a repository object

• Change the name of a repository object

• Refresh the cached image of a repository object

• Delete a repository object

• Get a pointer to an alternate interface that the object exposes

• Get the open repository instance through which the object is accessed

Methods

IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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.

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

IRepositoryltem Method Description

Delete Deletes a repository item get lnterface Retrieves an interface pointer to the specified item interface get_Name Retrieves the name associated with an item

1 Appendιx3 : Metadata

get_Reposιtory Retrieves the IRepository interface pointer for an item's open repository instance get_Type Retrieves the type of an item Lock Locks the item put_Name Sets the name associated with an item Refresh Refreshes the cached image of the item

IRepositoryObject Method Description getJntemallD Retrieves the internal identifier for a repository object get_ObjectlD Retrieves the object identifier for a repository object

3.11 IReposRoot Interface

The IReposRoot interface is a placeholder interface, it contains no properties, methods, or collections beyond Automation dispatch methods It is provided as a convenient connection point to the root object When you create a tool information model, you can attach a relationship collection to this interface that provides a navigational connection to the primary objects of your tool information model

When to Use

Use the IReposRoot interface as a starting point to navigate to other objects in the repository

Methods

IUnknown Method Description

Querylnterface Returns pointers to supported interfaces

AddRef Increments the reference count

Release Decrements the reference count

IDispatch 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

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

GZ Appendix3 : Metadata

3.12 IReposTypelnfo Interface

This interface relates class, interface, and relationship definition objects to repository type libraries

When to Use

Use the IReposTypelnfo interface to

• Determine which repository type libraries contain a particular class, interface, or relationship type

• Determine what collection types are associated with a particular relationship type

Methods IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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.

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection.

Collections

Collection Description ItemlnCollections 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

€ > Appendιx3 . Metadata

When to Use

Use the IReposTypeLib interface to

• Define new classes, relationship types, and interfaces for a tool information model

• Retrieve or modify the global identifier associated with a repository type library

• Determine which type definitions are associated with a particular repository type library

Properties

Property Description

TypeLiblD The global identifier for the repository type library

Methods

IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

IReposTypeLib Method Description CreateClassDef Creates a new class definition object CreatelnterfaceDef Creates a new interface definition object CreateRelationshipDef Creates a new relationship definition object

Collections Collection Description ReposTypelnfos The collection of all classes, interfaces, and relationship types that are defined in the repository type library

G Appendιx3 : Metadata

ReposTypeLibContexts The collection of one repository root object that is the context for the repository type library

3.14 ISummarylnformation Interface

The ISummarylnformation interface maintains Comments and ShortDescription properties for objects that expose this interface

When to Use

Use the ISummarylnformation interface to access the Comments and ShortDescription properties of a repository object

Properties Property Description Comments General comments about the object ShortDescription Brief description of the object

Methods IUnknown Method Description Querylnterface Returns pointers to supported interfaces. AddRef Increments the reference count Release Decrements the reference count

IDispatch 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.

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 w ithin the Repository's Type Information Model (TIM)

4.1 HnterfaceDef Relationships

The Class Jmplementsjntei face relationship connects the ICIassDef and HnterfaceDef interfaces This relationship is used to define the interfaces that a class implements

SB Appendix3 : Metadata

The Interface Jnherits From Jnterface relationship is used to identify interfaces that inherit (are subclassed) from other interfaces

The Interface _Has_Members relationship is used to house the mterface members (methods, properties, collections) that are part of an interface.

Interface InhentsFrom Interface

Interface Has Members

Members llnterfaceMember

^>DispatchlD ^>Flags

4.1.1 Interfaces Collection

The collection of all interfaces that are implemented by this class.

Collection Descriptor Descriptor Value

Relationship Type Class-lmplements-lnterface 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 - oό/ecf.lnterfaces( index ) The Interfaces collection syntax has these parts: Part Description variable A variable declared as an InterfaceDef object Receives the specified interface. object An object expression that evaluates to a ClassDef object.

ce Appendιx3 Metadata

index An integer index that identifies which element in the collection is to be addressed The valid range is from one to the number of elements in the collection The number of elements in the collection is specified by object Interfaces Count

4.1.2 Classes Collection

This collection specifies which classes implement the interface

Collection Descriptor Descriptor Value

Relationship Type Class-lmplements-lnterface Source Is Origin No Minimum Collection Size Zero Maximum Collection Size Many Seouenced Collection No Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable Unigue Names Not Applicable

Syntax

Set variable = object.C\asses( index )

The Classes collection syntax has these parts

Part 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 Oπαin Yes

Minimum Collection Size Zero

Maximum Collection Size Many

Seαuenced Collection Yes

Deletes Propagated Yes

Destinations Named Yes

Case Sensitive Names No

Unigue Names Yes

6 Appendιx3 ^• Metadata

Syntax

Set variable ob/ecf.Members( index )

The Members collection syntax has these parts

Part Description variable A variable declared as an object Receives the specified property definition, method definition, or collection definition object An object expression that evaluates to an InterfaceDef object index An integer index that identifies which element in the collection is to be addressed The valid range is from one to the number of elements in the collection The number of elements in the collection is specified by object Members Count.

4.1.4 Interface Collection

For a particular property, method, or collection definition, the Interface collection specifies which interface exposes a member of this type

Dispatch Identifier: DISPIDJface (37)

Collection Descriptor Descriptor Value

Relationship Tvoe Interface-Has-Members

Source Is Origin No

Minimum Collection Size One

Maximum Collection Size One

Seouenced Collection Yes

Deletes Prooaαated 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 Descriptor Value

Relationship Type Interface-lnheritsFrom-lnterface Source Is Origin Yes Minimum Collection Size One Maximum Collection Size One Sequenced Collection No Deletes Propagated No Destinations Named No Case Sensitive Names Not applicable Appendιx3 Metadata

Unique Names Not applicable

Syntax

Set variable =

index )

The Ancestor collection syntax has these parts

Part Description variable A variable declared as an InterfaceDef object Receives the specified base interface definition object An object expression that evaluates to an InterfaceDef object index An integer index that identifies which element in the collection is to be addressed The valid range is from one to the number of elements in the collection The number of elements in the collection is specified by object Ancestor Count

4.1.6 Descendants Collection

This collection specifies other interfaces that derive from this interface

Collection Descriptor Descriptor Value

Relationship Type Interface-lnheritsFrom-lnterface Source Is Origin No Minimum Collection Size Zero Maximum Collection Size Many Seouenced Collection No Deletes Propagated No Destinations Named No Case Sensitive Names Not applicable Unigue Names Not applicable

Syntax

Set variable oϋ/ecf.Descendants( index ]

The Descendants collection syntax has these parts

Part Description variable A variable declared as an InterfaceDef object Receives the specified interface definition object An object expression that evaluates to an InterfaceDef object index An integer index that identifies which element in the collection is to be addressed The valid range is from one to the number of elements in the collection The number of elements in the collection is specified by object Descendants Count Appendιx3 : Metadata

4.2 Type Library Relationships

The Container ontextF ^'or _ReposT\peLιbs 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 ScopeFoi _ReposTypeInfo relationship identifies the type infos (clases, interfaces and relationship types) that are defined withm a Repository type library

The Collection Zontains tems 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 Type TlbManager-ContextFor-ReposTypeLibs Source Is Origin Yes Minimum Collection Size Zero Maximum Collection Size Many Seouenced Collection No Deletes Propagated Yes Destinations Named Yes Case Sensitive Names No Unigue Names Yes

Syntax

Set variable - ooyecf.ReposTypeLibs( index )

The ReposTypeLibs collection syntax has these parts

To Appendix3 : Metadata

Part Description variable A variable declared as a ReposTypeLib object. Receives the specified repository type library. object An object expression that evaluates to a ReposRoot object. index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by ob/ecf.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 TlbManager-ContextFor-ReposTypeLibs Source Is Origin No Minimum Collection Size One Maximum Collection Size Many Seouenced Collection No Deletes Propagated Yes Destinations Named Yes Case Sensitive Names No Unigue Names Yes

Syntax

Set variable ofa/ecf.ReposTypeLibContexts( index ]

The ReposTypeLibContexts collection syntax has these parts:

Part Description variable A variable declared as a ReposRoot object. Receives the repository root object. object An object expression that evaluates to a ReposTypeLib object. index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by object. ReposTypeLibContexts. Count.

4.2.3 ReposTypelnfos Collection

The collection of all classes, interfaces, and relationship types that are associated with a repository type library. The repository engine uses this collection to enforce the unique naming of all classes, interfaces, and relationship types for a repository type library.

Collection Descriptor Descriptor Value

Relationship Type ReposTypeLib-ScopeFor-ReposTypelnfo Source Is Origin Yes Minimum Collection Size Zero

Ύ Appendιx3 - Metadata

Maximum Collection Size Many

Seouenced Collection No

Deletes Propagated Yes

Destinations Named Yes

Case Sensitive Names No

Unigue Names Yes

Syntax

Set variable obyecf.ReposTypelnfos( index )

The ReposTypelnfos collection syntax has these parts

Part Description variable A variable declared as an Object Receives the specified class definition, interface definition, or relationship definition object An object expression that evaluates to a ReposTypeLib object index An integer index that identifies which element in the collection is to be addressed The valid range is from one to the number of elements in the collection The number of elements in the collection is specified by object ReposTypelnfos Count

4.2.4 ReposTypeLibScopes Collection

The collection 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 Unigue Names Yes

Syntax

Set variable = o£>yecf.ReposTypeLibScopes( index )

The ReposTypeLibScopes collection syntax has these parts

Part Description variable A variable declared as a ReposTypeLib object Receives the specified repository type library object

1-2. Appendιx3 : Metadata

object An object expression that evaluates to an InterfaceDef object index An integer index that identifies which element in the collection is to be addressed The valid range is from one to the number of elements in the collection The number of elements in the collection is specified by object TypeLibScopes Count

4.2.5 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 ItemlnCollections collection contains the two collection definition objects that represent the origin and destination collection types

Collection Descriptor Descriptor Value

Relationship Type Collection-Contains-ltems Source Is Origin No Minimum Collection Size Zero Maximum Collection Size Two Seguenced Collection No Deletes Propagated No Destinations Named No Case Sensitive Names Not applicable Unigue Names Not applicable

Syntax

Set variable ob/ecf.ltemlnCollections( index )

The ItemlnCollections collection syntax has these parts

Part Description variable A variable declared as a CollectionDef object Receives the specified collection definition object An object expression that evaluates to a RelationshipDef object index An integer index that identifies which element in the collection is to be addressed The valid range is from one to the number of elements in the collection The number of elements in the collection is specified by object ItemlnCollections Count

Remarks

If the relationship type has not yet been connected to its origin and destination collection types, then this collection can contain less than two collection types

4.2.6 Collectionltem Collection

The collection of one relationship type that defines the relationship between target objects of this type of collection and a single source object

Collection Descriptor Descriptor Value

?> Appendix3 : Metadata

Relationship Type Collection-Contains-ltems Source Is Origin Yes Minimum Collection Size Zero 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 obyecf.Collectionltem( index )

The Collectionltem collection syntax has these parts

Part Description variable A variable declared as a RelationshipDef object. Receives the specified relationship definition object. object An object expression that evaluates to a CollectionDef object index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is specified by ob ecf.Collectionltem. Count.

5. Base-TIM Information Model

A new type information model Base-TIM has been added to the Microsoft Repository to handle the additional metadata definitions that the Type Information Model as defined b 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

Ψt- Appendιx3 : Metadata

The interfaces for a semantic are identified by a relationship/collection on the active entity When a semantic is processed, these interfaces are loaded into an anay 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 determmes 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 m this anay 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

implements

ArgumentDef

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 IHoldSemantic 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

ISemantic

implements

SemanticDef

6.3 UmtsOfMeasureDef Class

The UmtsOfMeasureDef class is used to define the units of measure domains that can be applied to properties with units of measure

When to Use

Use the UmtsOfMeasureDef class to access or modify units of measure domain definitions

T Appendιx3 : Metadata

implements

UmtsOfMeasureDef

7. Added Interfaces

The following interfaces have been defined for the BASE-TIM model

IHaveArguments

IHoldSemantic

IJAggregate

IJCodeSet

IJCodeSetlnterface

IJImply

IJInterfacelnfos

IJProperty2

IJRelationshipType

IManageDelete

IUserType

IJUOMDomain

ISemantic

All of these interfaces are Repository-supported interfaces w ith onlv 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_Relshιp 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

l€ Appendix3 : Metadata

Methods

IUnknown Method Description Querylnterface Returns pointers to supported interfaces. AddRef Increments the reference count Release Decrements the reference count

IDispatch 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.

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer. The

IReposProperties interface provides access to the Properties collection.

Collections

Collection Description SemanticForArg The collection of the one semantic to which this argument is tied

7.2 IHoldSemantic Interface

The IHoldSemantic interface is used to identify the mterface 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 Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count. Release Decrements the reference count

IDispatch Method Description

GetlDsOfNames Maps a single member and a set of argument names to a corresponding set of dispatch identifiers

Ή- Appendix3 : Metadata

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

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

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

IRepositorvDispatch 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.

lAnnotationalProps

IRepositoryObject

^"7T

/ yr New - Use to store X i U lr erfacelnfos additional info about t

I e interface f i

/ / Ulmply NEw - connects toX

XX- , - - Ulmply

_J

InterfaceDef

New - connects to

~-> IJCodeSetlnterface IJCodeSet

\ \ \

-≥-_

IHoldSemantic New - Connects to X ISemantic

7.3 IJAggregate Interface

The IJAggregate interface is used to establish an aggregation relationship between classes.

Ϊ8 Appendιx3 : Metadata

When to Use

Use the IJAggregate interface to define that a class aggegates another class

Properties

Property Description

AggregationType The type of aggregation (Aggregation, Containment)

Methods IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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.

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

Collections Collection Description Aggregates The collection of classes that this class aggregates AggregatedBy The collection of classes that that aggregate this class

The IJAggregate interface has been added to the ClassDef class This allows any class to aggregate other classes or be aggregated by other classes

T* Appendιx3 ' Metadata

7.4 IJCodeSet Interface

The IJCodeSet interface is used to identify properties whose values are defined by entries in another class/mterface A code set property is differentiated from a relationship between two interfaces by the fact that the pomter is one directional (from the property in the one class to the other interface) and there are no semantics associated with the pointer

When to Use

Use the IJCodeSet interface to define or modify the code set characteristics of a property

Properties

Property Description

Name The name of the property in the related interface that is to be displayed as the value for this property

FilterCriteria The filter criteria to be applied to the instances to come up with the set of possible values for the property

Methods

IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch Method Description Appendιx3 : Metadata

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

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

Collections Collection Description

CodeSetlnterface The collection of one interface that identifies the type of objects in the code set

The IJCodeSet interface has been added to the Microsoft-defined PropertyDef class definition This allows any property definition to use a code set definition

New - connects to IJCodeSetlnterface

7.5 IJCodeSetlnterface Interface

The IJCodeSetlnterface interface is used to identifv an interface definition as containing the set of possible values (code set) for a property definιtιon(s) Normalh the manipulation of the relationship between an interface definition used as a code set and a property is done from the PropertyDef object using the IJCodeSet interface

fl Appendix3 : Metadata

Methods IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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.

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

91 Appendιx3 ^■ Metadata

7.6 Ulmply Interface

The Ulmply interface is used for identifying interfaces that are implied by other mterfaces

When to Use

Use the Ulmply interface to define that an interface implies another interface

Methods

IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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

§3 Appendix3 : Metadata

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer. The

IReposProperties interface provides access to the Properties collection.

Collections

Collection Description

Implies The collection of interfaces that this interface implies

ImpliedBy The collection of interfaces that imply this interface

The Ulmply 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 Ulnterfacelnfos 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.

S4- Appendix3 : Metadata

Properties

Property Description

UserName Display name for a collection of attributes Jflag (not used)

Methods IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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.

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

Collections

Collection Description

$S Appendix3 : Metadata

7.8 IJProperty Interface

The IJProperty2 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 Description OnPropertyPage Indicates whether the attribute will appear on a property page SpecificUnitsOfMeasure Indicates whether an attribute has a specific units of measure (e.g. ft). This value should only be set if the attribute is also tied to a units of measure type (not used)

UserName Display name of the attribute

UnitsType Type of units for this property

PrimaryUnits Default primary display units for this property

PecondaryUnits Default secondary display units for this property

TertiaryUnits Default tertiary display units for this property

CodeList Table number for code listed attributes (-1 if not)

§ Append ιx3 : Metadata

Readonly Indicate if the value of this attribute can be set

Methods

IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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.

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

Collections Collection Description UnitsOfMeasure The collection of at most one unit of measure that applies to this attribute

SameAs The collection of at most one property for which this attribute is the same attribute

AreSame The collection of properties that are the same as this one

The IJProperty2 interface has been added to the PropertyDef class to allow the definition of the additional metadata for any attribute/property

8 Appendιx3 : Metadata

New A

7.9 IJRelationshipType Interface

IJRelationshiptype mterface is used to store the GUID associated to an mterfce type

When to Use

Properties

Property Description RelationshipTypeGUID GUID

Methods

IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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 ) Appendix3 : Metadata

Invoke 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

7.10 IManageDelete Interface

The IManageDelete mterface 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 Description

Delete Forward Flag for the forward delete behavior. The possible values are

PROPAGATE, NO_PROPAGATE or PROPAGATE CONDITIONAL.

Delete Backward Flag for the forward delete behavior.

DisconnectionProglD ProglD of a semantic to fire when a relationship of this type is deleted.

Methods Appendix3 : Metadata

IUnknown Method Description Querylnterface Returns pointers to supported interfaces AddRef Increments the reference count Release Decrements the reference count

IDispatch 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

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection.

Collections

Collection Description

7.11 lUserType Interface

The IJUserType to modify the definition of a class and create a user defined class

When to Use Appendιx3 : Metadata

Use the IJUserType interface to define a semantic a user type

Properties

Property Description RootCLSID CLSID of the class that is used as a server for this codeless class.

Methods IUnknown Method Description Querylnterface Returns pointers to supported interfaces. AddRef Increments the reference count Release Decrements the reference count

IDispatch 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.

IRepositorvDispatch Method Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

Collections Collection Description

Appendix3 : Metadata

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 ISemantic interface to define a semantic and to relate that semantic to its active entity and to its arguments (i.e. the interfaces that are input, output and/or constrained by the semantic)

Properties Property Description Type Type of the semantic (Compute, Copy, Delete)

SticProglD ProglD of the class that implements the semantic SolverProglD ProglD of the class that implements the solver

Methods IUnknown Method Description Querylnterface Returns pointers to supported interfaces. AddRef Increments the reference count. Release Decrements the reference count.

IDispatch 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.

94. Appendιx3 : Metadata

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 Description get_Properties Retrieves the IReposProperties interface pointer The

IReposProperties interface provides access to the Properties collection

Collections Collection Description Arguments The collection of arguments to the semantic ActiveEntity The collection of one interface that is the active entity for the semantic

8. Added Relationships 8.1 Semantic Relationships

The Interface lsActiveEntityFor Semantics relationship has been added to the metadata model to identify the "active entity" for a semantic (the InterfaceDef conesponding 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 mput, output and constramt 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-lsActiveEntityFor-Semantics

^<8 Appendιx3 : Metadata

Source Is Origin Yes Minimum Collection Size Zero Maximum Collection Size Many Seαuenced Collection No? Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable Unioue Names Not Applicable

Syntax

Set variable = oϋ/ecr.Semantics( index )

The Semantics collection syntax has these parts

Part Description variable A variable declared as a SemanticDef object Receives the specified semantic definition object An object expression that evaluates to an InterfaceDef object index An integer index that identifies which element in the collection is to be addressed The valid range is from one to the number of elements in the collection The number of elements in the collection is specified by object Semantics Count

8.1.2 ActiveEntity Collection

This collection of one interface which is the active entity for the semantic

Collection Descriptor Descriptor Value

Relationship Type Interface-lsActiveEntityFor-Semantics Source Is Origin No Minimum Collection Size One Maximum Collection Size One Seαuenced Collection No Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable Unique Names Not Applicable

Syntax

Set variable = o£>/ecf.ActιveEntity( index )

The ActiveEntity collection syntax has these parts Part Description Appendix3 : Metadata

variable A variable declared as an InterfaceDef object Receives the specified interface definition object An object expression that evaluates to an SemanticDef object index An integer index that identifies which element in the collection is to be addressed The valid range is from one to the number of elements in the collection The number of elements in the collection is one

8.1.3 Arguments Collection

This collection specifies the arguments to the semantic

Collection Descriptor Descriptor Value

Relationship Type Semantic-Has-Arguments Source Is Oπαin Yes Minimum Collection Size One Maximum Collection Size Many Seαuenced Collection Yes Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable Unique Names Not Applicable

Syntax

Set variable = o_yecf.Arguments( index )

The Arguments collection syntax has these parts

Part Description variable A variable declared as a InterfaceDef object Receives the specified interface definition. object An object expression that evaluates to an SemanticDef object index An integer index that identifies which element in the collection is to be addressed The valid range is from one to the number of elements in the collection The number of elements in the collection is specified by object Arguments Count.

8.1.4 SemanticForArg Collection

This collection of one semantic for which this interface argument is an argument

Collection Descriptor Descriptor Value

Relationship Type Semantic-Has-Arguments Source Is Origin No Minimum Collection Size One Maximum Collection Size One Sequenced Collection No

65 Appendιx3 : Metadata

Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable Unique Names Not Applicable

Syntax

Set variable oj /ecf.SemanticForArg( index )

The SemanticForArg collection syntax has these parts

Part Description variable A variable declared as a SemanticDef object Receives the specified semantic definition object An object expression that evaluates to an ArgumentDef object index An integer index that identifies which element in the collection is to be addressed The valid range is from one to the number of elements in the collection The number of elements in the collection is one

8.2 Aggregation Relationship

To support aggregation a Clαss_Aggregαtes_Clαsses relationship has been created

Class_Aggregates_Classes

jates !

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 Descriptor Value

Relationship Type Class-Aggregates-Classes Source Is Origin Yes Minimum Collection Size Zero Maximum Collection Size Many Seouenced Collection Yes Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable

36 Appendix3 : Metadata

Unigue Names Not Applicable

Syntax

Set variable oϋ/ecf.Aggregates( inde )

The Aggregates collection syntax has these parts: Part 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 Unique Names Not Applicable

Syntax

Set variable = o/b/ect.AggregatedBy( index )

The AggregatedBy collection syntax has these parts:

Part 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 object.AggregatedBy. Count.

3f Appendιx3 : Metadata

8.3 Imply Relationship

To support an interface implying other interfaces an Interface Jmphesjnterfaces relationship has been created and

Interface Implies Interfaces

+lmplιes

Ulmply

+lmplιedBy

its Ulmply mterface added to the InterfaceDef class defined by Microsoft

8.3.1 Implies Collection

This collection specifies the interfaces that this interface implies

Collection Descriptor Descriptor Value

Relationship Type Interface-lmplies-lnterfaces Source Is Origin Yes Minimum Collection Size Zero Maximum Collection Size Many Seouenced Collection No Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable Unique Names Not Applicable

Syntax

Set variable ojb/ecf.lmplies( index )

The Implies collection syntax has these parts

Part Description variable A variable declared as an InterfaceDef object Receives the specified interface definition object An object expression that evaluates to an InterfaceDef object. index An integer index that identifies which element in the collection is to be addressed The valid range is from one to the number of elements in the collection The number of elements in the collection is object Implies Count

8.3.2 ImpliedBy Collection

This collection specifies the interfaces that imply this interface Collection Descriptor Descriptor Value Appendix3 : Metadata

Relationship Type Interface-lmplies-lnterfaces 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 Unigue Names Not Applicable

Syntax

Set variable oύ/ecf.lmpliedBy( index )

The ImpliedBy collection syntax has these parts:

Part Description variable A variable declared as an InterfaceDef object. Receives the specified interface definition. object An object expression that evaluates to an InterfaceDef object. index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is object.lmpliedBy.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 Property JsBasisFor Properties relationship allows a non-persistent property to be defined as being the same as another property. This is particularly useful for properties with units of measure where the property defined as being the same as another property is defined to have specific units of measure (e.g. property diameter_ft is same as property diameter and has specific units of ft).

Property sBasisFor_Properties

Appendix3 : Metadata

8.4.1 SameAs Collection

This collection of at most one specifies the property for which this property is the same.

Collection Descriptor Descriptor Value

Relationship Type Property-lsBasisFor-Properties Source Is Origin No Minimum Collection Size Zero Maximum Collection Size One Seouenced Collection No Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable Unique Names Not Applicable

Syntax

Set variable = object.SameAs( inde )

The SameAs collection syntax has these parts:

Part Description variable A variable declared as a PropertyDef object. Receives the specified property definition. object An object expression that evaluates to a PropertyDef object. index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is object.SameAs.Count.

8.4.2 AreSame Collection

This collection specifies the properties that are the same as this property.

Collection Descriptor Descriptor Value

Relationship Type Property-lsBasisFor-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 Unigue Names Not Applicable

ΛOO Appendιx3 : Metadata

Syntax

Set variable = ofo/ecf.AreSame( index )

The AreSame collection syntax has these parts

Part Description vanable A variable declared as a PropertyDef object Receives the specified property definition object An object expression that evaluates to a PropertyDef object index An integer index that identifies which element in the collection is to be addressed The valid range is from one to the number of elements in the collection The number of elements in the collection is object AreSame Count

8.5 Code Set Relationships

The Interface JsCodeSetFor Properties relationship couples a property definition to an mterface contammg 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 Descriptor Value

Relationship Type lnterface_lsCodeSetFor_Propertιes Source Is Origin No Minimum Collection Size Zero Maximum Collection Size One Sequenced Collection No Deletes Propagated No Destinations Named No Case Sensitive Names Not Applicable Unioue Names Not Applicable

Syntax

Set variable oώ/ecf.CodeSetlnterface( index )

The CodeSetlnterface collection syntax has these parts Part Description variable A variable declared as an InterfaceDef object Receives the specified class definition ooyecf An object expression that evaluates to a PropertyDef object

Λ Λ Appendix3 : Metadata

index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is object. CodeSetlnterface. Count.

8.5.2 PropertiesForCodeSet Collection

This collection specifies the properties that use a code set interface.

Collection Descriptor Descriptor Value

Relationship Type lnterface_lsCodeSetFor_Propertιes 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 = objecf.PropertiesForCodeSet( index )

The PropertiesForCodeSet collection syntax has these parts:

Part Description variable A variable declared as a PropertyDef object Receives the specified property definition. object An object expression that evaluates to an InterfaceDef object index An integer index that identifies which element in the collection is to be addressed. The valid range is from one to the number of elements in the collection. The number of elements in the collection is object. PropertiesForCodeSet. Count.

1ϋZ APPENDIX 4

1. Introduction

This Appendix discloses additions to the Unified Modelling Language (UML) needed to describe the metadata used to decπbe 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 strmg 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 startmg with "I" will have its TIR set to Interface, a class starting with "C" will have its TIR set to Class, and a class starting with "S" will have its TIR set to Semantic The export tool will issue a warning when it sets the TIR based on these starting letters

• 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 m 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 mterface, a true value sets the IsHidden flags to true for the interface definition m the repository The repository may use this flag to keep the interface hidden from view by automation viewers (e g VB object browser)

• Defaultlnterface - Null string by default If TIR is class, this string property holds the name of the default mterface for the class The export tool will attempt to set this value by compaπng implemented interface names agamst the class name An implemented mterface with the same name as the class but starting with "I" will automatically be used

• SemanticType - Possible values of "", Compute, or Copy A null string represents the default value of unassigned If TIR is semantic, this string property indicates if the semantic is for compute or copy The export tool attempts no automatic assignment

• SemanticProgID - Null string by default If TIR is semantic, this string property holds the ProglD 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 ProglD of the COM object called by the associativity subsystem to compute objects in a constraint relationship

• GUID - Null strmg 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 StπngToCLSID Win32 function The export tool will automatically generate a unique value for this string

• ObjectID - Null string by default If TIR is class or interface, this string property holds the ObjectID of the repository classdef or interfacedef represented by the UML class The format of the string must match the format "{ {00000000-0000-0000-0000-000000000000} ,00000000}" as specified by the repository documentation The export tool will automatically generate a unique value for this string

• TableName - Null string by default If TIR is interface, this string property holds the Access or SQLServer table name used to store instances of properties on the interface The export tool will automatically generate a table name based on the interface name

• UserName - Null string by default If TIR is interface or class, this a display name used by the attribute helper

Λθ APPENDIX 4

IsHardCoded - If TIR is mterface, 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 attributes

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, DeleteBackvvard - Possible \ alues of Propagate. DontPropagate, or ConditionalPropagate The default value is DontPropagate for both properties These properties mdicate 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 strmg property holds the ProglD 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 strmg property holds the type of the repository relationship corresponding to the UML association The GUID used to represent the type is the same GUID used in the IJAssocRelation GetCollectionOfRelationsByType method Previously, the GUID used for the relationship type was extracted from the GUID part of the relationship object id in the repository This property is now used instead of the GUID part of the object id The format of the string must match the format "{00000000-0000-0000-0000-000000000000}" as specified by the StringToCLSID Win32 function The export tool will automatically generate a unique value for this string

• ObjectID - Null strmg by default This strmg property holds the ObjectID of the repository classdef or mterfacedef 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 strmg

Below are the GSCAD specific properties defined for UML roles These properties are under the GSCAD A and GSCAD B tabs from the association specification dialog

• Min - Possible values of 0 to infinity (represented by -1 ) The default value is 0 This string property defines the cardinality of one side the relationship represented by the UML associatation The export tool attempts no automatic assignment

• Max - Possible values of 0 to infinity (represented by -1) The default value is - 1 This string property defines the cardinality of one side the relationship represented by the UML associatation The export tool attempts no automatic assignment

• IsOrigin - True or False, False by default A true value defines the role as the origin side of the relationship Only relationship origins may be named or indexed The export tool attempts no automatic assignment

• IsNaming - True or False, False by default A true value indicates the origin side of the relationship supports nammg 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 \ alue indicates the ongm side of the relationship requires only unique names can be

adding to the relationship A true value is only valid if IsOrigin and IsNaming are both true The export tool attempts no automatic assignment

• IsCaseSensitive - True or False, False by default A true value indicates the origin side of the relationship supports case sensitive names A true value is only valid if IsOrigin and IsNaming are both true The export tool attempts no automatic assignment

θ^ APPENDIX 4

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 mteger mdexing 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 strmg 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 strmg

• ObjectID - Currently unused

5.4 Property properties

IBeam

^Length double ^Ty e BYTE

Below are the properties defined for UML class properties These properties are accessed first by opening the class specification dialog, selecting a property and view its property specification dialog

• OnPropertyPage - True or False, True by default If true, this property must be diplayed by the attribute controle.

• UnitsOfMeasure - 0 by default It contams the unit type of the attribute

• PrimaryUnitsOfMeasure, SecondaryUnitsOfMeasure, TertiaryUnitsOfMeasure - 0 by default It contams the code for the display units

• ColumnName - Null strmg by default This string property holds the Dispatch id of the repository collection represented by the UML role The string must be m the form of a unique integer number The export tool will automatically generate a unique value for this string

• DispID - Null strmg by default This string property holds the Dispatch id of the repository property represented by the UML property The strmg 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 ldl if this property has to be displayed by the attribute helper

• ObjectID - Currently unused

• APIType, SQLType, SQLSize, SQLScale - These properties are automatically set by the tool from the type of the property The export tool hard codes these properties to SQL_C_STINYINT, SQL_TINYINT, 1 , and 0, respectively

• InRepository - True or False, False by default Indicate whether or not this property must be exported m the meta data

• CodeList - NULL by default, give the name of the codehst table if this property is codehsted

• ReadOnly - True or False False by default, indicate if this property can be modified using the attribute control

• UserName - NULL by default, this is Displav name used by the attribute control

• OnPropertyPage - True or False, True by default Indicate if this property must be displayed by the attribute control

OS APPENDIX 4

5.5 Generalize property

IProlile

^Lengt : double

IProfile2D

Below is the property defined for UML generalization (inherit) element.

• AggregateeClass - Null string by default. This strmg 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 contam 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 scopmg rules for associativity.

Relationships definitions.

Semantics on mterfaces.

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 populatmg GSCAD metadata m 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 OBJID IJDGeometry Oxal 732cbf 0x5136 0x1 ldl 0x97 0x70 0x08 0x00 0x36 0x75 0x42 0x03

0x0 define IID IJDGeometry 0xal732cbf 0x5136 0x1 ldl 0x97 0x70 0x08 0x00 0x36 0x75 0x42 0x03 createlNTERFACE IJDGeometry objid IJDGeometry lid IJDGeometry

A repository Interface definition can be specified using UML and GSCAD properties Placing a UML class, assigning an interface name, and setting GSCAD property TypelnRepository to Interface is all that is necessary for the export tool to define the interface definition m the repository

10 G APPENDIX 4

«lnterføce» IJDGeometry

(f rom SymbollnterfaceDependency )

However, if this mterface has already been defined in an application it is important for the GSCAD GUID property to be properly set This property defines the Interface IID that must match up with the defined IID m the application Lookmg at the above rip text, the GSCAD GUID property should be defined as {al732cbf-5136-l 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 UML as follows

For mterface inheritance, the inherits (also called generalization) UML relationship requires no GSCAD property settings

6.3 Interface implies relationships

GSCAD applications use implies information for query support \o rip syntax exists for describing mterface implies relationships It is defined in UML as follows

«lmplιes»

The UML dependency relationship is used with the "Implies stereotype name The export tool will generate an implies relationship in the repository between IJDGeometry and IJDLine

I ^Q Ϊ APPENDIX 4

6.4 Interface scoping for associativity

GSCAD applications use interface scoping rules via the associatn lty subsystem to determine interface dependency durmg associativity graph compute See assoc documentation for more information. Interface scopmg is defined in rip using the following syntax A scopmg relation can be global to an application or only valid withm the context of a class setSCOPE

Interface IJDOccurrence

Scope IJOccurrence

The same is defined in UML as follows

«lnterface» «ScopedBy» «lnterface» IJDOccurrence IJOccurrence

Two interfaces can be considered equivalent by the associatn lty It is defined in UML as follows

<<lnterface>> <<lsEq valent>> <<lnterface>> IJA > IJB

One mterface can be the origin of at most one scoping relation (ScopedBy or IsEquivalent) m a given context An mterface that is equivalent to another cannot be a scoping and cannot be scoped.

• ClassName - NULL by default, mdicate 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 scopmg rule) and the IsGlobal property must be true

• GUID - CLSID of the context class Set by Export to Repos tool if the scoping relation must be applied within the context of a class

• IsGlobal - True by default, indicate if this scoping relation is applied within the context of a class. True if ClassNAme is NULL, False otherwise.

For interface scoping, the dependency relationship is used with the "ScopedBy" or "IsEquivalent" stereotype name. The export tool will add the scoping information to the mterface definition in the repository

6.5 Relationship definition

GSCAD applications connect physical objects together based on relationship definitions stored m the repository See assoc documentation for more information A relationship is defined m rip using the following syntax define OBJID XFormModel Oxl 0x2 0x3 0x1 0x2 0x3 0 1 0x2 0x3 0x1 0x3 0x0 createRELATION XformModel

Ongm IJCopyXForm XformModelOπgm

Destination IJDLine XformModelDestination

Type COLLECTION NAMING setPROPERTY XFormModel IManageDelete Delete_Forward type char index 1 value NO PROPAGATE setPROPERTY XFormModel IManageDelete Delete_Backward type char mdex 2 value PROPAGATE

A0$ APPENDIX 4

setPROPERTY XFormModel IManageDelete ConnectionProgID type char mdex 3 value XFormCompStic XFormCompStic 1

The same is defined m 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 ongm collection on the oπgin mterface and the destmation collection on the destination interface In UML, an association exists between interfaces based on the roles each element plays in the association For example

«lnterface» Mamage «lnterface» IMan IWoman

+Husband +Wife

Here IMan is playing the Husband role and IWoman is playmg the Wife role m UML When this relationship is mapped to the repository, the relationship will be called Marriage and the IMan will get an ongm 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 Lookmg at the above XFormModel example, this explams why the XformModelOπgin origin collection on IJCopyXForm defined m rip syntax became the role on IJDLine in UML

The IsOrigin GSCAD property on a UML role is defined m terms the repository NOT UML Therefore, m 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 ongm collection As will be seen later, the setting of the IsOrigin GSCAD property plays an important role in defmmg semantic arguments

6.6 Semantics on an interface

GSCAD applications use semantics on interfaces \ la the associate ity 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 0x9cef0x1 ldl 0xa60x770x0 OxaO 0xc90x8d 0x9d Oxbl

0x10 createlNSTANCE SemanticDef SMakeBeam ConnectTo IMakeBeam IHoldSemantic Semantics

setPROPERTY SMakeBeam ISemantic noname type char mdex 1 value Compute setPROPERTY SMakeBeam ISemantic noname type char

Index 2 value Beams MakeBeam Profile Vector 1

-i&e APPENDIX 4

//Add profile input argument define OBJID ProfileArg 0x22d718c2 0x9cef 0x1 ldl 0xa6 0x77 0x0 OxaO 0xc9 0x8d 0x9d Oxbl 0x0 lnserflNSTANCEArgumentDef ProfileArg connectto SMakeBeam ISemantic Arguments setPROPERTY ProfileArg IHaveArguments noname type char

Index 1 value INPUT setPROPERTY ProfileArg IHaveArguments noname type GUID

Index 2 value ProfileForBeam

//Add vector input argument define OBJID VectorArg 0x22d718c4 0x9cef 0x1 l dl 0xa6 0x77 0x0 OxaO 0xc9 0x8d 0x9d Oxbl 0x0 msertlNSTANCEArgumentDef VectorArg connectto SMakeBeam ISemantic Arguments setPROPERTY VectorArg IHaveArguments noname type char

Index 1 value INPUT setPROPERTY VectorArg IHaveArguments noname type GUID

Index 2 value VectorForBeam

//Add beam output argument define OBJID ResultingBeamArg 0x22d718c5 0x9cef 0x1 ldl 0xa6 0x77 0x0 OxaO 0xc9 0x8d 0x9d Oxbl 0x0 msertlNSTANCEArgumentDef ResultingBeamArg connectto SMakeBeam ISemantic Arguments 3 setPROPERTY ResultingBeamArg IHaveArguments noname type char

Index 1 value OUTPUT setPROPERTY ResultingBeamArg IHaveArguments noname type GUID

Index 2 value ResultingBeam

The same is defined in UML as follows

APPENDIX 4

! «lnterface» 0. ResultmgBeam Beam Maker

+BeamProvιder

0..^*

+BeamRequester

I «lnteιface» | θ..^*

0.. * VectorForBeam IVector «lnterface»

]+VectorProvιder +VectorRequester IBeam

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 descπption Active and Passive Entities). The semantic SMakeBeam is anchored to the Active Entity IBeamMake mterface via a special association named TieToSMakeBeam The UML class elements IProfile, IVector, IBeamMaker, and IBeam are all UML mterface definitions. Each has the GSCAD TypelnRepository property set to Interface. SMakeBeam is different because its GSCAD TypelnRepository property is set to Semantic In fact, looking at the GSCAD properties of SMakeBeam we see the following settings:

• TypelnRepository = Semantic

• SemanticType = Compute

• SemanticProgID = Beams. MakeBeam.Profile Vector.1

Smce TypelnRepository is set to Semantic, the export tool treats SMakeBeam differently that the other UML elements. It interprets properties on the semantic as argument definitions. Each property must be of type String and each property must have an initial value of Input, Output, Constraint, Self nput, Self output, Self_constraint. The Rose98 property specification for the ProfileProvider property on SMakeBeam is shown below:

APPENDIX 4

Property Specification for ProfileProvider UE1

General j Detail ] GSCD | Name: Class: SMakeBeam

Type: | String H P^" Show classes

Stereotype: initial value: Input

- Export Control Public Protected <• Private f^* Implementation

Documentation:

OK Cancel Apply I Browse ▼ Help

The actual name of the property must exactly match a role of an association on the IBeamMaker interface. Since IBeamMaker is an Active Entity only and is not a Passive Entity, the role names supplied must be roles on the other side of the association. Specifying other-side role names goes hand in hand with defining the initial value (semantic argument type). Because IBeamMaker is an Active Entity and not a Passive Entity, no initial value should be marked as Self input, Self output or Self constraint. That is, it is illegal to specify ProfileProvider, VectorProvider, or BeamRequester as semantic arguments AND list their types as Self_*.

Suppose we wish to not have the intermediate IBeamMaker Active Entity and instead have IBeam be both the Active Entity and Passive Entity.

. «lnterface» o„* VectorForBeam IVector

-.+VectorPiOvider + Vector Requester

^■11 X APPENDIX 4

Now IBeam is both the Active Entity and Passive Entity How can we tell? Simply by noticing SMakeBeam has an argument of type Self output. Notice the property name ProfileRequester listed on SMakeBeam. When a semantic wishes to take a Self_ιnput, Self output, or Self constraint argument, ANY role name on the IBeam can be listed. Therefore, we could have specified VectorRequesteπ String = Self output and gotten the same result.

Another important piece of mformation related to role name arguments to semantics is the settmg 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 constramt type arguments match exactly with non-constraint type arguments. Self constramt roles can only be listed as arguments if they exist on the Active Entity mterface. Non-Self constraint roles must exist on the other side of the association. All non-Self constramt roles must have IsOrigin set to true and all Self constramt roles must have IsOrigin set to false.

When the export tool finds a semantic, it automatically labels the association between the semantic and interface TιeTo<semantιc name>.

6.7 Indirect interfaces as arguments to semantics

GSCAD applications can define indirect mterfaces as semantic arguments rather than havmg to create an entirely new relationship. See assoc documentation for more information. An indirect interface argument to a semantic is defined usmg .rip syntax as follows.

//Define a semantic to compute the length of the beam define OBJID SComputeBeamLength 0x3 0 1 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0x10 createlNSTANCE SemanticDef SComputeBeamLength

ConnectTo IAnalyzeBeam IHoldSemantic Semantics setPROPERTY SComputeBeamLength ISemantic noname type char mdex 1 value Compute setPROPERTY SComputeBeamLength ISemantic noname type char

Index 2 value Analysis. BeamLength 1

//IBeam as argument define OBJID BeamArg 0x334 0x1 0x1 0x2 0\3 0x4 0x5 0x6 0x7 0x8 0x9 0x0 insertlNSTANCE ArgumentDef BeamArg connectto SComputeBeamLength ISemantic Arguments setPROPERTY BeamArg IHaveArguments noname type char

Index 1 value INPUT setPROPERTY BeamArg IHaveArguments noname type GUID

Index 2 value BeamToAnalyze

//The actual argument to the semantic is not IBeam but rather IJGeometry setPROPERTY BeamArg IHa\ eArαuments noname type IID

Index 3 value IJGeometry

The same is defined in UML as follows.

Η3 APPENDIX 4

SComputeBeamLength

^BeamProuder IJGeometry Stnng = Input

ΗeToSComputeBeamLength

«lnterface» BeamTo Analyze OX «lnterface» lAnalyzeBeam 0 ^* IBeam

+BeamRequester +BeamProuderi

In this example, the argument to the semantic is m the form <RoleName InterfaceName> with BeamProvider bemg 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 mdirect mterface 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 entity, it will try to find it on any interface implied by the active entity This allows to have a generic connection pattern used by different semantics tied to different active entities

TieToSemantic

<<lnterface>> «lmplιes» ' «lnterface» lActiwsEntity >, lOtherlnterface

+Destι nation

SampleRelaϋon

i-Oπgin

<< lnterface>> [ llnterfece

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

11 - APPENDIX 4

6.9 COM classes

GSCAD applications currently do not make use of COM class metadata in the repository. Possible fumre 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 definition for CBeam. The class definition will have a relationship to all interfaces implemented on the class. In order for the export tool to recognize the CBeam UML element as a COM class, the 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 COM class aggregation or containment metadata in the repository. Possible fumre 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.

4$ APPENDIX 4

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. Tlie export tool adds metadata about the aggregation of the IBeam interface.

Containment is shown in a similar fashion to aggregation.

«lnteιface» ILine3D «lnterface» «kιterface» χ> IBeam lEngineeringEntity

«lmplements»

«lmplements» Δ

:knplements» «lmplements»

CSpecialBeam CBeam

Here CSpecialBeam contains the IBeam interface on CBeam. The UML generalization relationship is used as with aggregation but with the Implements stereotype name. Note an ambiguity exists in the following case. APPENDIX 4

Here, it is unclear if CSpecialBeam is containing the IBeam interface on CBeam or CBoxBeam. To disambiguate this case, the generalization relationship has a GSCAD property AggregateeClass. In the above case, setting this property on the CSpecialBeam to IBeam specialization relationship to either CBeam or CBoxBeam will disambiguate the containment relationship. Note this same case can occur for multiple aggregated objects. By default, the export tool will set this property to the first aggregatee found. The tool issues a warning noting the assumption.

^•T ^ f

Claims

WHAT IS CLAIMED IS:

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

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

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

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

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

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

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

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

119

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

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

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

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

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

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

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

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

a computer-readable medium for storing the codes.

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

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

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

1ZΛ