Using ViewTypes for accessing instance data structured by a base model

Disclosed is a technique for manipulating instance data of a base model. A ViewType, a root object representing an object of the base model, and an operation are received. Whether the ViewType and the root object are compatible is determined. When the ViewType and the root object are compatible, the operation is applied to the instance data of the base model while using the ViewType to traverse the instance data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to the following commonly assigned and co-pending, United States Patent Applications:

U.S. patent application Ser. No. 11/021,730, entitled “DEFINING AND GENERATING A VIEWTYPE FOR A BASE MODEL,” by S. Conn, et al.; and

U.S. patent application Ser. No. 11/021,796, entitled “GENERATING A RELATIONAL VIEW FOR A BASE MODEL SCHEMA,” by P. Boyer et al.,

each of which is filed on the same date herewith, and which is incorporated by reference herein in its entirety.

BACKGROUND

The present invention is related to using ViewTypes for accessing and operating on instance data structured by a base model.

2. Description of the Related Art

An Essential Meta-Object Facility (EMOF) specification describes a framework for describing and representing metadata (i.e., data describing other data). The EMOF specification provides EMOF model constructs that enable creation of metadata models. A metadata model includes objects described by EMOF classes (defined by the EMOF model), links that connect objects described by EMOF associations, and data values. An EMOF class may include a class name, attributes, operations, association references, and other elements. An association reference enables an EMOF object to be “aware” of being in a relationship with other objects via an association, and the relationship links may be navigated or traversed to get to other data in the model (e.g., to perform operations on objects in a metadata model). An EMOF class may inherit characteristics (e.g., attributes, operations, etc.) from other EMOF classes.

Unified Modeling Language (UML) is a notational language for specifying and visualizing software, (e.g., object-oriented projects) and was developed by the Object Management Group (OMG). An EMOF metadata model may be represented using a UML model. For more information regarding EMOF and UML, see the World Wide Web, omg.org.

When defining an EMOF-based model in a relational database, the resulting relational database schema needed for representing the EMOF-based model may be substantially complex. Consequently, dealing with instance data for classes of the model can also be very complicated.

Thus, there is a need in the art for more simply defining and using an EMOF-based model.

SUMMARY OF THE INVENTION

Provided are a method, system, and program for manipulating instance data of a base model. The manipulation may include reading, updating, saving or deleting, instance data within the scope of the ViewYype definition. A ViewType, a root object representing an object of the base model, and an operation are received. Whether the ViewType and the root object are compatible is determined. When the ViewType and the root object are compatible, the operation is applied to the instance data of the base model while using the ViewType to traverse the instance data.

DETAILED DESCRIPTION

In the following description, reference is made to the accompanying drawings which form a part hereof and which illustrate several implementations of the invention. It is understood that other implementations may be utilized and structural and operational changes may be made without departing from the scope of implementations of the invention.

FIG. 1illustrates, in a block diagram, a computing environment in accordance with certain implementations of the invention. A client computer100is connected via a network190to a server computer120. The client computer100includes system memory104, which may be implemented in volatile and/or non-volatile devices. One or more client applications110may execute in the system memory104.

The server computer120includes system memory122, which may be implemented in volatile and/or non-volatile devices. System memory122may store base models142, a ViewType model144, and ViewTypes146. A ViewType146uses a base model (i.e., a subset of the base model or the base model in its entirety). For example, a ViewType146that uses the base model in its entirety may be referred to as a comprehensive ViewType. A ViewType146references classes, attributes, and associations of a base model142(i.e., either a subset or in its entirety) as ViewType objects. For example, a ViewType146uses parts of a base model142by naming classes from the base model. ViewType objects of a ViewType146may be defined by a ViewType model144.

A ViewType generator130executes in the system memory122and generates a ViewType146from a base model142. The ViewType146is built using the ViewType model144. The base model142and the ViewType146may be represented with respective XML Metadata Interchange (XMI) files148. In certain implementations of the invention, the ViewType generator130includes two subcomponents: a ViewType writer132and a ViewType user interface134. The ViewType generator130, XMI files148, ViewType writer132, and ViewType user interface134are described in further detail in the above cross-referenced patent application with U.S. patent application Ser. No. 11/021,730, entitled “DEFINING AND GENERATING A VIEWTYPE FOR A BASE MODEL,” by S. Conn, et al.

XML Metadata Interchange (XMI) was proposed by the Object Management Group (OMG) and uses Extensible Markup Language (XML) to exchange information about metadata. XMI helps programmers using the Unified Modeling Language (UML) with different languages and development tools to exchange their data models with each other. The XMI format standardizes how any set of metadata is described and enables users across many industries and operating environments to see data the same way.

The ViewType writer132is used to create ViewType146objects based on a base model142designated by the user. The ViewType writer132validates ViewType objects against the classes, attributes, and associations declared in an EMOF-based model. The ViewType writer132writes the correctly formatted and validated ViewType to an XMI file148. The ViewType writer132can also build a comprehensive ViewType of a base model142starting at a user-specified root class and recursively including all attributes, associations, and related classes.

The ViewType user interface134allows a user to graphically build and maintain a valid ViewType146based on classes defined in a user-specified base model142(e.g., EMOF-based models) and/or from an existing ViewType. From the ViewType user interface134, a user is also provided with facilities for nesting ViewTypes, which avoids redundant definitions of ViewType branches, and for referring to “proxy” classes, which may define instance data, at runtime, that is manipulated by other ViewTypes. One or more server applications140execute in system memory122A ViewType user interface134is a type of Graphical User Interface (GUI) and may be displayed at the client computer100by the ViewType generator130.

A ViewType Walker system150executes in the system memory212and allows an application (e.g., a client application110) to traverse instance data of a base model, visiting the objects of the base model in a traversal path designated by the structure of a ViewType. A ViewType may be referred to as a “map” that is used to traverse the objects of the base model.

The server computer120provides the client computer100with access to data in a relational data store170An operator console180executes one or more applications182and is used to access the server computer120

The client computer100may comprise any computing device known in the art, such as a server, mainframe, workstation, personal computer, hand held computer, laptop telephony device, network appliance, etc. The network190may comprise any type of network, such as, for example, a Storage Area Network (SAN), a Local Area Network (LAN), Wide Area Network (WAN), the Internet, an Intranet, etc. The relational data store170may comprise an array of storage devices, such as Direct Access Storage Devices (DASDs), Just a Bunch of Disks (JBOD), Redundant Array of Independent Disks (RAID), virtualization device, etc.

FIG. 2illustrates a ViewType model200in accordance with certain implementations of the invention. The ViewType model200includes a ViewType class210, a ViewList class230and a ViewElem class250, along with the attributes and associations of the classes. An instance of the ViewType class210(also referred to as a “ViewType object”) describes the main attributes of a ViewType and includes, for example, a viewName attribute for the name of the ViewType, a model attribute for the name of the base model on which the ViewType is based, a package name attribute, and an optional reference attribute for the name of the tool that owns (i.e., “created”) the ViewType. The root ViewType instance has one association to a root ViewList instance. A package may be described in the UML/EMOF notation used for scoping data in an XMI file. A package may have associated attributes (e.g., definitions of special tags used in the XMI file, definitions of transformation rules, etc.).

A ViewList instance is also referred to as a “ViewList object.” The root ViewList instance and all other instances of the ViewList class contain information about classes found in the base model. The ViewList class230includes an attribute called className that names the base model class that the ViewList represents. The ViewList class230also has a delete flag, which is used to indicate to a delete function whether or not base model objects should be deleted within the scope of the ViewType. A ViewList class230also may include a proxyViewName and proxyAttribs attributes. Presence of a value in the proxyViewName attribute indicates that the base model class represented by the ViewList class is a placeholder, and the details of the base model class are described by another ViewType class' ViewList class. The set of attribute names listed in the ViewList's proxyAttribs attribute specify which of the proxied class' attributes are to be processed with a ViewType instance. The proxyViewName attribute and the association to a ViewElem in a ViewList instance are mutually exclusive; if a ViewList instance does not refer to a proxy, the ViewList instance may alternatively have an association to a ViewElem. A ViewList instance may also have no association or proxy.

The ViewList instance has an association to a ViewElem instance for each attribute and association in the base model class that needs to be defined in this ViewType for the unit of work for which the ViewType will be used.

Each instance of the ViewElem class250has an attribute called attribName whose value matches the name of the attribute or association the ViewElem class represents in the base model class. A ViewElem instance of a ViewElem class250may have a value in its attribAltName attribute to specify an alternate name for the represented attribute. The attribAltName might be used to ensure uniqueness of the attribute name within the set of ViewElem instances for a ViewType instance. If a ViewElem instance represents an atomic type of attribute, such as an integer type or a string type, then the ViewElem instance will not have a nested ViewList instance or ViewName instance. If, on the other hand, a ViewElem instance represents an attribute that is a complex type represented by a base model class or represents a base model association, then the ViewElem instance will either be connected to a nested ViewList instance through a hasViewList association or have a value in its nestedViewName attribute. A hasViewList association connects the ViewElem instance to a ViewList instance for the base model's associated class and that ViewList instance defines the associated base model class' attributes, associations, etc. For the hasViewList relationship, the ViewList instance has a containing ViewElem instance. A value in the nestedViewName attribute names a ViewType instance whose root ViewList instance represents the base model's associated class, and the rest of that ViewType is used to define the associated base model class' structure.

When defining the ViewType, a recursive type of model is used that works its way down to the leaf-most nodes that should be traversed. At the point in the ViewType definition where the leaf-most nodes are described, there is a ViewElem. At the intermediate points in the ViewType definition where the tree continues to be defined, a ViewElem would be the source of a hasViewList relationship to another ViewList rooted on a ViewElem, and so this continues until the hasViewList relationship is not used (i.e., at the leaf-most node).

In certain implementations of the invention, a ViewElem instance representing an attribute or association may be used by one ViewList instance representing a class. To allow for reducing ViewType size, a ViewList instance may be nested by multiple ViewElem instances. Also a ViewType instance may be named as a nestedViewName by multiple ViewElem instances.

In certain implementations of the invention, a ViewType146is defined using an EMOF-based model (i.e., a type of base model142). The ViewType146is described in an XMI format based on the ViewType Document Type Definition (DTD). A ViewType DTD may be described as a definition for a ViewType model, which contains the ViewType, ViewList, and ViewElem classes and associations.

Non-automated processes for creating ViewTypes146in the XMI format have proven to be very time consuming and error-prone. Implementations of the invention enable quickly and easily defining model-validated ViewTypes146. For example, the ViewType generator130allows the user to create and maintain valid ViewType XMI based on a user-specified EMOF-based model. The ViewType XMI describes a subset of base model classes, along with attributes and associations, as ViewType objects. ViewType objects are defined by the ViewType.

In order to define and process a subset of a base model required for a logical unit of work, implementations of the invention enable defining of ViewTypes146. A ViewType146may be described as a user-defmed scope or grouping of interrelated objects that can be used to access and manipulate instance data for a base model142. A ViewType146references classes from the base model142, starting from a root class, and identifies any attributes and/or associations to the base model classes. The ViewType146branches out in a tree type of structure, describing each of the associated classes needed by a logical unit of work. ViewTypes146are used to programmatically manipulate instances of the base model142at a less granular level than the class or object.

The purpose of a base model142is to represent a set of objects and their relationships. For example, the base model142may be an EMOF-based model.FIG. 3illustrates an example of a Department-Employee base model300that is an EMOF-based model in accordance with certain implementations of the invention. For example, the Department-Employee base model300describes a set of classes, attributes of the classes, and the associations from each class to other classes. In certain implementations of the invention, a graphical tool may be used to define the classes (e.g., Rational Rose Realtime available from International Business Machines, Corporation). Also, tools may be used to export the model as an XML Metadata Interchange (XMI) document describing the EMOF-based model. That is, certain tools (e.g., Rational Rose Realtime) output a model output file that can be transformed into XMI format, which is provided as input to certain implementations of the invention. The Department-Employee base model300includes a NamedObject class310, which includes a “name” of string type. A Department class320includes a department number (labeled “deptNo”) of integer type and inherits the characteristics of the NamedObject class310. An Employee class330includes an employee number (labeled “empNo”) of integer type and inherits the characteristics of the NamedObject class310. A Computer class340includes a serial number (labeled “serialNumber”) of string type. Also, all classes310,320,330,340inherit the characteristics (i.e., the OID) of an object class305that is the top level class in a base model142. In addition, an Employee is in one Department, a Department has 0-m (where m may be any integer value) Employees, and an Employee may have a Computer or may not have a Computer (i.e., a 0. . 1 relationship).

Both the Department class320and the Employee class330inherit from the NamedObject class310. Because the Department class320inherits from the NamedObject class310, the Department class320logically has two attributes: deptNo and name. Likewise, each instance of the Employee class may be thought to have two attributes: empNo and name. In addition, instances of the Department class310can be related to instances of the Employee class330via the Dept_Has_Emps association. Instances of the Employee class330may be related to instances of the Computer class340via the Uses association.

FIG. 4illustrates an example of a ViewType based on a Department-Employee model in accordance with certain implementations of the invention.FIG. 5illustrates instance data for a Department-Employee model in accordance with certain implementations of the invention. The example ofFIGS. 4 and 5will be used to illustrate how the ViewWalker system150traverses instance data500for a base model using the ViewType400. In this example, the ViewWalker system150initially determines that the ViewType's410root ViewList's420className attribute specifies the class, or a superclass, type of the instance data's root object, “Department”. In this case, the root ViewList's420className is “Department”, and the root object502is a Department so data traversal and operation application commences.

In the root-to-leaf order, an operation, such as read or update, is first applied to the root “Department” object502. Then the ViewList for the “Department” class420is processed. Each of the ViewList's ViewElems422,424,426, and440, are processed to determine if their corresponding attributes or associations are present in the “Department” object502. The ViewWalker system150applies the operation to the “Department” object502attributes that are not associated with another class (deptNo, name, oid) where applicable. The ViewWalker system150then processes attributes that are associated with another class (i.e., by processing ViewElems that have a nestedViewList or a nestedViewName and their associated instance object), and traversal continues. In this example, the ViewList for the “Department” class420has one ViewElem, “employee”440, that represents an association by way of its nestedViewList. This ViewElem for “employee”440represents the association between the “Department” object502and its target “Employee” object504. Since there is instance data for this association between the “Department” and “Employee” objects, the ViewWalker proceeds to process the “Employee” object504.

In the root-to-leaf order, the operation is applied to the “Employee” object504. Then the ViewList for the “Employee” class442is processed. Each of the ViewList's ViewElems444,446,448, are processed to determine if their corresponding attributes or associations are present in the “Employee” object504The ViewWalker applies the operation to the “Employee” object504attributes that are not associated with another class (empNo, name, and oid) where applicable. The ViewWalker system150then processes attributes that are associated with another class and ViewType traversal continues. In this example, the ViewList for the “Employee” class442has no ViewElems that represent any association and traversal stops. The association between the “Employee” object504and the “Computer” object506is not described in the ViewType400, therefore it is not traversed and the operation is not applied to the “Computer” object506.

If a leaf-to-root order operation (e.g., delete) is specified for the walk, then the operation is applied to the “Employee” object504Processing is now done with the ViewList for the “Employee” class442. Processing returns the ViewList for the “Department” class420. If a leaf-to-root order is specified for the walk, the operation is applied to the “Department” object502. Processing is now done with the ViewList for the “Department” class420. Since the ViewList for the “Department” class420is the root ViewList, the ViewWalker system150processing returns to the ViewType “Dept—Empl” and is complete.

To further illustrate implementations of the invention, examples of an update operation and a delete operation are discussed with reference toFIGS. 4 and 5.

For example, an update operation is applied in the root-to-leaf order. In this example, the ViewWalker system150initially checks that the ViewType's410root ViewList's420className attribute specifies the class type of the instance data's root object502, which it does: “Department”. In the root-to-leaf order, the update operation is applied to the “Department” object502and the object's502attributes first. Then the “Department” object502“deptNo”, “name”, and “oid” attributes are checked. Since these attributes map to ViewElem422,424, and426in the ViewType410, but none of the ViewElem has a nested ViewList, the attributes are not used for traversal.

Next, the “Department” object502“employee” association is checked. The name of the “employee” association matches the “Department” ViewList's ViewElem440for “employee” and the association's target object, an “Employee” object504with empNo=116 and className=“Employee”, matches the “employee” ViewElem's nestedViewList442for the “Employee” class. Therefore, the “Employee” object504is traversed next. Since the update operation is being applied in the root-to-leaf order, the update operation for the “Employee” object504is performed.

Next, the “Employee” object504attributes for “empNo”, “name”, and “oid” are checked, but they are not traversed because the ViewElems444,446, and448to which they map do not have nested ViewLists.

Additionally, the “Employee” object504“computer” association is examined. Since the ViewList442for the “Employee” class does not include a ViewElem for “computer”, the association is not traversed, the “Computer” object506in the instance data500is effectively ignored, and the update operation is not applied to the “Computer” object506. Because the “Employee” object504has no additional associations, the ViewWalker system150ends its traversal of this branch and recursively returns back to the processing of the “Department” object502. The “Department” object502has no additional associations, so its processing returns too, and the root-to-leaf traversal for the update operation and processing of the Dept-Empl ViewType is finished.

A delete operation is applied in the leaf-to-root order. Again, the ViewWalker system150checks that the ViewType's410root ViewList's420className attribute specifies the class type of the instance data's root object502, which it does: “Department”. In the leaf-to-root order, the delete operation is not yet performed on the “Department” object502. The “Department” object502“deptNo”, “name”, and “oid” attributes are checked. Since none of these attributes is an connects to another object (i.e., the ViewElem422,424, and426to which the attributes map do not have nested ViewLists), the attributes are ignored.

Then the “Department” object502“employee” association is checked. The name of the “employee” association matches the “Department” ViewList's420ViewElem440for “employee” and the association's target object, an “Employee” object504with empNo=116 and className=“Employee”, matches the “employee” ViewElem's nestedViewList for the “Employee” class. Therefore, the “Employee” object504is traversed next. The “Employee” object attributes for “empNo”, “name”, and “oid” are checked for object-attribute definition, but they are ignored because the ViewElem444,446, and448to which they map do not have nested ViewLists.

Then the “Employee” object504“computer” association is examined. Since the ViewList442for the “Employee” class does not include a ViewElem for “computer”, the association is not traversed, and the “Computer” object506in the instance data500is ignored. Because the “Employee” object504has no additional associations, and because a leaf-to-root order for “delete” was specified for the walk, the delete operation is now performed on the “Employee” object504The ViewWalker system150ends its traversal of this branch and recursively returns back to the processing of the “Department” object502. The “Department” object502has no additional associations, so the “delete” operation is now performed on the “Department” object502. The leaf-to-root “delete” processing of the Dept—Empl ViewType is finished with the traversal.

FIG. 6illustrates logic implemented in the ViewWalker system150to perform an operation on one or more objects of a base model142in accordance with certain implementation of the invention. When the ViewWalker system150is invoked for an operation, such as create or update that puts data in a relational database, the base model instance data is already loaded in memory from some source (e.g., an XMI file). The ViewWalker system150traverses the in-memory data mapped by the ViewType and performs an operation such as create or update to store information in the relational database. Conversely, an operation such as read may be applied by the ViewWalker150to get data from the relational database. In this case, the ViewWalker system150gets data from the relational database into memory as it traverses a ViewType. In either case, the instance data for the base model142is represented by a set of objects in memory.

Control begins at block600with invocation of the ViewWalker system150. When the ViewWalker system150is invoked (e.g., by a client application110), a ViewType146, a root object, and an operation are specified. The ViewType146is specified for traversal guidance. That is, the instance data for the base model142is traversed or “walked” using the structure of the ViewType146as a guide to identify which objects of the base model142should be processed. The root object identifies an object in the base model142and the corresponding object in the ViewType146serves as the starting point for the traversal of the ViewType146. The operation specified is to be performed on the instance data for the base model142.

In block602, the ViewWalker system150determines whether the root object is compatible with the ViewType146to be traversed. If so, processing continues to block604, otherwise, processing is done. That is, the ViewWalker system150verifies that the specified root object of the base model142is compatible with an object that is specified in the ViewType146(i.e., an object type specified by the ViewType's root ViewList may be a superclass of the base model object instance).

In block604, the specified operation is checked. In particular, the operation specified to the View Walker is validated to ensure that a method or function exists with the given name and that it is possible to invoke that method or function against the object specified. The operation may be one of a set of operations that the ViewWalker system150recognizes or may be the name of a method in one or more of the objects to be traversed. Some examples of operations to be performed on data in the objects of the base model142include, for example, reading data, updating data, deleting data, and adding data.

The objects of the base model are organized in a network. A ViewType defined for a base model provides a root, or starting point, from which zero or more objects emanate. An object from which no other objects emanate is referred to as a “leaf” object. A root can actually be a leaf if no objects emanate from the root.

An operation may be applied to each object in the base model142(i.e., each piece of instance data) when the object in the base model142is initially encountered (producing a root-to-leaf order of application) or after the object's associated objects in the base model142have been processed (producing a leaf-to-root order of application). In certain implementations of the invention, the order of application of the operation (i.e., root-to-leaf or leaf-to-root) is determined based on the type of the operation. For operations performed in the root-to-leaf order, the operation is performed on the root first, then the operation is cascaded out to the leaves. Some operations, however, are performed in the leaf-to-root order so that the operation is performed on the leaves first, and then the operation is performed on other objects, working back to the root. A cascading type of delete function is an example of an operation for which leaf-to-root order may be used. In this case, the delete starts at the leaves of the instance data. If the root instance is deleted before the leaves, then parts of the instance data are deleted before they are traversed. Also, traversal of deleted data may cause unexpected results. An add operation is one that may be performed in the root-to-leaf order.

In block606, if the order of application of the operation has been determined to be root-to-leaf based on checking the operation, processing continues to block608, otherwise, processing continues to block610. Regardless of the order of application of the operation, the ViewWalker system150starts traversal at the root object using the root ViewType's ViewList to determine which associations to traverse first.

In block608, the instance data is traversed using the ViewType146as a guide and the operation is performed on an object when the object is encountered. When the operation is performed, the operation is actually performed on data in the object. In the root-to-leaf order of application, the operation is applied to the root object. Then each of the root object's attributes and associations is examined. An association relates two objects, which may be referred to as a “source” object and a “target” object. For example, the root object may be a source object related to one or more target objects. A ViewElem may be described as an attribute with a data type. When that data type is a class (as opposed to a simple String, Integer, Enum, etc.), the ViewElem represents another object that is the target of a n−1 association. The processing of the ViewWalker system150processes the related objects of the source object when processing the associations of the source object.

If the attribute or association of a source object is specified in the ViewType146as one of the source object's ViewList's ViewElems, then the attribute or association is considered for traversal, otherwise, the attribute or association is skipped. Associations and their target objects are considered for traversal. Attributes are considered for traversal if they are “object attributes”. An object attribute represents a complex type of attribute that is defined by an object. Unlike a complex type of attribute, an atomic attribute is defined by an enumerated type (e.g., integer, string, etc.). When an association or object attribute is considered for traversal, a related target object is examined. If the target object class, or one of its superclasses, matches the corresponding ViewElem's nestedViewList's className, then the target object is compatible and qualifies for traversal. The operation is applied to the target object and the target object is processed in the same manner as the source object (e.g., the attributes and associations of the target object are processed), using the nestedViewList for its traversal qualification. Traversal qualification may be described as the definitions in the ViewType for which associations are traversed. When the target object is processed in this manner, the object may be referred to as a “source” object as the object may be related to other objects (i.e., target objects) by associations. The attributes and associations of the object whose names match those in the ViewType's146corresponding ViewElem are examined. If an attribute's defining object class name, or an association's target object class name or one of its superclass names matches the className of the nestedViewList, then the operation is applied to the related object and processing continues until the instance data has been completely traversed relative to the ViewType146.

In block610, the instance data is traversed using the ViewType146as a guide and the operation is performed on an object after associated objects have been processed. In the leaf-to-root order of application, the operation is not applied to any object until after the object's associated object attributes and associations are traversed and consequently operated on. Because the traversal is recursive, the operation is performed on each object as the traversal returns from walking back to the root from the leaf or leaves. This results in the operation being first applied to the last object traversed. Some operations (e.g., a cascading delete) use this order of application, while other operations use the root-to-leaf order of application.

In either case, traversal of a branch of the tree structure representing the base model142finishes when either an object with no attributes or associations matching those mentioned in the ViewType146at the appropriate ViewList is encountered or when the ViewList for a processed object has no ViewElem with nested ViewLists. In other words, when the instance data runs out of related objects or when the ViewType's146branch reaches a leaf, the ViewWalking system150of a subset of instance data completes and returns back up the path of traversal. The traversal is complete when all related instance data mapped by the ViewType146definition has been visited and traversed.

Following Pseudocode A lists pseudocode for processing performed by the ViewWalker system150in accordance with certain implementations of the invention, and slashes (//) precede comments.

The portion of Pseudocode A for applying an operation to an object with the ViewWalker system150is as follows:

The above portion of Pseudocode A for applying an operation to an object with the ViewWalker system150shows the possibility that the operation may be performed in one of two ways. If the implementation of the ViewWalker system150understands the operation itself and implements its own function/method for performing the operation, then the ViewWalker system150function/method for the operation is invoked. On the other hand, if the ViewWalker system150does not explicitly understand the operation, then the instance data's own method can be invoked to perform the operation.

In certain implementations of the invention, ViewType generator130function for creating a comprehensive ViewType for a data model may be invoked as the ViewWalker system150is initialized. This allows for more dynamic view handling of instance data. A comprehensive ViewType does not include redundant declarations of classes that might be required in more than one branch of the ViewType. Instead, the comprehensive ViewType uses existing declarations to form a networked ViewType. The comprehensive ViewType makes use of recursive structures to allow the comprehensive ViewType to be used with any configuration of instance data that adheres to the base model. Because most base models are actually networks as opposed to hierarchies, ViewTypes also can be networks in support of base models.

An example for the use of this idea is an “add” operation. A chunk of instance data is submitted to the ViewWalker system150with a root object indicated, dynamic view generation flagged, and the name of the base model142that describes the data and its relationships. Instead of looking for an existing ViewType146, the ViewWalker system150creates a comprehensive view, using the ViewType generator130, based on the root object and the indicated base model142. Then, using this dynamically created ViewType146, the ViewWalker system150processes the instance data, applies an operation, such as adding data to the database, as the instance data is traversed. This allows the instance data passed to the ViewWalker system150to be processed, regardless of what is defined by a statically defined ViewType146that might be incomplete or might have become obsolete.

In certain implementations of the invention, Pseudocode A for the ViewWalker system150may be modified so that the main function of Pseudocode A is replaced by

Pseudocode BMain:if ViewType not specifiedInvoke View Type Builder to create a comprehensiveViewType based onthe object type of aRootObject and the modelInitialize theViewWalker for the ViewTypeUse theViewWalker to walk instance data rooted onaRootObject, applyingsomeOperationend

Because all the ViewType objects are complete, having all the attribute and association representations from the model class, they can be reused. The advantages of comprehensive ViewTypes are twofold. First, they can be much smaller than a fully expanded ViewType with the same information. Second, comprehensive ViewTypes are complete. If the user does not know exactly what subset of the model a unit of work will deal with, then a comprehensive ViewType, may be used to process any configuration of instance data that adheres to the same model on which the ViewType is based. The ViewType generator130processes ViewTypes in such a way as to avoid infinite looping, although recursion is used.

Thus, implementations of the invention provide a new type, referred to as a “ViewType” that simplifies the process of manipulating data by specifying those parts of the EMOF-based model needed for a logical unit of work. Implementations of the invention also enable using ViewTypes to traverse instance data described by an EMOF-based model and applying an operation as the data is traversed (i.e., “walked”).

Additional Implementation Details

The described implementations may be implemented as a method, apparatus or article of manufacture using programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The term “article of manufacture” and “circuitry” as used herein refers to a state machine, code or logic implemented in hardware logic (e.g., an integrated circuit chip, Programmable Gate Array (PGA), Application Specific Integrated Circuit (ASIC), etc.) or a computer readable medium, such as magnetic storage medium (e.g., hard disk drives, floppy disks, tape, etc.), optical storage (CD-ROMs, optical disks, etc.), volatile and non-volatile memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs, DRAMs, SRAMs, firmware, programmable logic, etc.). Code in the computer readable medium is accessed and executed by a processor. When the code or logic is executed by a processor, the circuitry may include the medium including the code or logic as well as the processor that executes the code loaded from the medium. The code in which preferred implementations are implemented may further be accessible through a transmission media or from a file server over a network. In such cases, the article of manufacture in which the code is implemented may comprise a transmission media, such as a network transmission line, wireless transmission media, signals propagating through space, radio waves, infrared signals, etc. Thus, the “article of manufacture” may comprise the medium in which the code is embodied. Additionally, the “article of manufacture” may comprise a combination of hardware and software components in which the code is embodied, processed, and executed. Of course, those skilled in the art will recognize that many modifications may be made to this configuration, and that the article of manufacture may comprise any information bearing medium known in the art. Additionally, the devices, adapters, etc., may be implemented in one or more integrated circuits on the adapter or on the motherboard.

The logic ofFIG. 6describes specific operations occurring in a particular order. In alternative implementations, certain of the logic operations may be performed in a different order, modified or removed. Moreover, operations may be added to the above described logic and still conform to the described implementations. Further, operations described herein may occur sequentially or certain operations may be processed in parallel, or operations described as performed by a single process may be performed by distributed processes.

The illustrated logic ofFIG. 6may be implemented in software, hardware, programmable and non-programmable gate array logic or in some combination of hardware, software, or gate array logic.

FIG. 7illustrates an architecture of a computer system that may be used in accordance with certain implementations of the invention. Client computer100, server computer120, and/or operation console180may implement computer architecture700. The computer architecture700may implement a processor702(e.g., a microprocessor), a memory704(e.g., a volatile memory device), and storage710(e.g., a non-volatile storage area, such as magnetic disk drives, optical disk drives, a tape drive, etc.). An operating system705may execute in memory704. The storage710may comprise an internal storage device or an attached or network accessible storage. Computer programs706in storage710may be loaded into the memory704and executed by the processor702in a manner known in the art. The architecture further includes a network card708to enable communication with a network. An input device712is used to provide user input to the processor702, and may include a keyboard, mouse, pen-stylus, microphone, touch sensitive display screen, or any other activation or input mechanism known in the art. An output device714is capable of rendering information transmitted from the processor702, or other component, such as a display monitor, printer, storage, etc. The computer architecture700of the computer systems may include fewer components than illustrated, additional components not illustrated herein, or some combination of the components illustrated and additional components.

The computer architecture700may comprise any computing device known in the art, such as a mainframe, server, personal computer, workstation, laptop, handheld computer, telephony device, network appliance, virtualization device, storage controller, etc. Any processor702and operating system705known in the art may be used.

The foregoing description of implementations of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the implementations of the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the implementations of the invention be limited not by this detailed description, but rather by the claims appended hereto. The above specification, examples and data provide a complete description of the manufacture and use of the composition of the implementations of the invention. Since many implementations of the invention can be made without departing from the spirit and scope of the implementations of the invention, the implementations of the invention reside in the claims hereinafter appended or any subsequently-filed claims, and their equivalents.