Method of Transforming Graphical Object Diagrams to Product Data Manager Schema

The present invention relates generally to computer database structures, and more particularly to a method of transforming conceptual database models into actual database implementations, and that detects and corrects conversion errors during the conversion process.

Object oriented models have become a powerful mechanism for abstracting, documenting and communicating system concepts during information system development. The object oriented models, which are highly conceptual, allows a programmer to focus on database objects and the relationships between the objects without the need to focus on implementation of the database. For example, object oriented models are extremely useful in modeling classes, such as entities and associated attributes of the entities, and association and inheritance relationships among the classes in the development of product data manager (PDM) applications.

While object oriented models are useful for the design and development of databases as described above, the models must be transformed into detailed PDM schemas for actual implementation. Conventional software packages, such as Rational Software Corporation's Rational Rose object oriented modeling product, and Adra Systems Inc.'s Matrix product data manager, are two commercially available software packages that address the graphical object model conceptualization and PDM system respectively. This invention addresses specifically the transformation of the graphical object oriented model into PDM schemes. Specifically, because of the contrasting nature of the object oriented models and PDM schemas, i.e., conceptual models versus actual implementation, the transformation from conceptual object oriented models to PDM schemas is error prone and is dependent on the target PDM platform.

This invention details a method of maintaining consistency between object oriented models and PDM schemas and that detects both actual and potential errors during the conversion process. There is also a need for a method of further enhancing the usefulness of the transformation methodology to provide a user with further design options.

Accordingly, the present invention provides a method, an associated system, for converting object oriented models into an actual operable database. The method and system automatically converts object oriented models into inputs that are compatible with the target product data manager. As a result, many errors can be detected during the conversion process, thereby allowing the PDM designer to correct the errors before actual PDM implementation. Further, the method and system of the present invention generates ancillary outputs that further enhance the usefulness of the method and system. Errors and inconsistencies between the object oriented model and the PDM database can thus more easily be tracked, thereby enhancing the integrity of the resulting PDM database.

More particularly, the present invention provides a method of constructing a database from the graphical object model, including extracting and repairing the logical model from the graphical object modular output; detecting actual and potential errors in the model; repairing the detected errors; compiling and transforming the logical model to a target PDM database platform.

According to another embodiment, the present invention provides a database constructor. The constructor includes a data input through which data indicative of relationships among database objects is input. An object modeler generates an object model of the database from the data. A compiler transforms the object model database into a hierarchial database model. An error detection and warning file is generated, indicative of actual and potential errors in the database detected during the conversion process. The output also outputs ancillary files that further operate to maintain consistency between the object model and the hierarchial model. The data output also outputs the actual database scripts necessary for implementation.

FIG. 1 is a block schematic diagram of the database construction system of the present invention;

FIG. 2 is a block schematic diagram of the object oriented model product data manager compiler shown in FIG. 1;

FIG. 3 is a flow diagram illustrating the methodology associated with the database constructor FIG. 1;

FIG. 4 is a block schematic diagram of the database construction system shown in FIGS. 1-3;

FIG. 5 is a sample relationship diagram of an object model to be converted into a product data manager data base by the methodology of the present invention;

FIG. 6 is a partial display extract of a logical portion of the object model of FIG. 5;

FIG. 7 is a class file for the object diagram of FIG. 5;

FIG. 8 is an attribute file for the object diagram of FIG. 5;

FIG. 9 is an association file for the object diagram of FIG. 5;

FIG. 10 is a role file for the object diagram of FIG. 5;

FIG. 11 is an attribute script file for the target product data manager;

FIG. 12 is a type script file for the target product data manager platform;

FIG. 13 is a relationship script file for the target product data manager platform; and

FIG. 14 is an error file created during the transformation of the object diagram to the product data manager platform in accordance with the methodology of the present invention.

Referring to the drawings, FIG. 1 illustrates a database generator system 10 incorporating the methodology of the present invention. The system 10 is preferably implemented in an environment 12, which could be, for example a UNIX environment or in a personal computer that is a Windows '95 or higher based machine having an Intel Pentium processor. The system 10 bridges the gap between graphical object oriented (OO) models, which are highly conceptual in nature, and product data manager (PDM) schemas, which are implementation specific. The system converts (OO) models into inputs that are compatible with the target PDM platform in a manner that detects errors that would go otherwise undetected by conventional transformation processes. The system also allows ancillary outputs to be generated to further enhance the usefulness of the transformation process.

Still referring to FIG. 1, the system 10 implemented within the environment 12 receives data indicative of identified relationships among database objects from data input 14 such as a computer drawing program. The drawing program generates a file that is subsequently input and processed by a graphic object modeler 16. The graphic object modeler 16 is preferably a commercially available modeling product, such as Rational Software Corporation's Rational Rose (OO) modeling product. The graphic object modeler in turn is linked to a compiler 20 that implements the transformation methodology in accordance with a preferred embodiment of the present invention. The compiler 20 processes object model files 22 generated by the graphic object modeler 16 to convert the files into a database platform files for use in a database platform, such as a product data manager (PDM) platform 24, in the form of product data manager schema scripting files 26. In addition, the compiler 20 generates error and warning files 27 that indicate inconsistencies detected during the conversion process, and outputs additional ancillary files 28, discussed in more detail below, that further aid the system user in developing the database platform.

Referring to FIG. 2, the (OO)/PDM compiler 20 of FIG. 1 is shown in more detail. The compiler 20 receives object model files at 30, and is programmed to include a model extractor, which extracts a logical (OO) model, as indicated at 32. The model extractor 32 outputs the extracted logical model to a logical model compiler 34. The logical model compiler 34 compiles the logical model into recognizable entities and relationships that are amenable for further processing, as will be described below in more detail. Once the compiler has compiled the logical model, it outputs the logical model to a generator 36. The generator 36 takes the logical model files and transforms files to PDM schema files 26 for use in a target PDM platform. In addition, the generator also detects errors in the compiled logical model, and correspondingly generates error/warning files, as indicated at 27. In addition, the generator generates ancillary files, as indicated at 28, to further assist PDM downline processing. The ancillary files may include revision information that assist in maintaining version control and consistency. For example, as the object oriented model is revised in response to changing needs, t,e incremental changes from the previous version, both at the object model and PDM database schema levels can be outputted to the ancillary files. This information can be used to incrementally update the PDM schema to the latest release. Conversely, this information can be used to roll back the current version of the PDM schema to the previous release.

FIG. 3 is a block schematic diagram 40 showing the database construction system, and particularly the system compiler 20, of the present invention in more detail. As shown, the object modeler 16 receives input from the data input 14 and generates an original (OO) model 22. Files from the (OO) model are then input into the compiler 20, which is programmed to generate a logical model 42 from the (OO) model 22. The compiler 20 generates the logical model 42 by filtering/repairing the peculiarities detected in the logical model as being generated via software generated filter/repair block 44. The software block 44 filters the presentation layer associated with the input data and the original (OO) model, as the system of the present invention only requires relational data information, i.e., that one object is related to other input data in a hierarchial manner. After the presentation layer is stripped from the (OO) model, the logical model extractor 32 then extracts the logical model 42. Both the filter/repair block 44 and the logical model extractor 32 are software implemented. A pseudo code representing the logic used to implement the block 44 and the extractor 32 is shown in the pseudo code attached as Appendix A.

The resulting logical model 42 is then input into a software utility block 44 compiler. The software utility, which is preferably commercially available software utilities such as Lex (Lexical Analyzer) and/or Yacc (yet another compiler compiler), uses context free grammar to parse the logic contained in the logical model to generate files, such as class filed, association files, attribute files and roll files, as indicated generally in the file block 46. After the software utility block 44 generates the file block 46, the files from the block 46 are input into a compiler target mapping engine 48. The target mapping engine 48 then maps the general class files 46 into more specific application schema files, as indicated at 26. Particularly, these schema files are PDM schema files, which are ultimately output to target PDM system for use in the PDM platform. Target mapping engine 48 also generates error and ancillary files 27, 28 from the general class files, that will enable the system operator to detect database errors before implementation of the PDM system. As with the compiler software block 41, the target mapping engine 48 is software implemented through logic, such as that illustrated in the computer pseudo code attached in Appendix A.

Referring to FIG. 4, a flow diagram summarizing the methodology of the system of the present invention is shown at 50. At 52, data indicative of relationships among various objects to be related in the database schema is input through the input 14. At 54, the object modeler 16 generates an object oriented model, and outputs object model files to the compiler 20. At 56, the model extractor 32 extracts the logical model from the object model files input at the input 30. The logical model is defined as only those entities, including associated attributes and methods, and relationships defined among the entities contained in the output from the object modeler. At 56, two tasks are performed. First, the software addresses any peculiarities encountered in the (OO) model outputs. For example, the (OO) modeler generates different outputs based on how the system is used, and repairs the output of the logical model. Second, this step identifies and extracts elements of the logical model. Because the output from the (OO) model often contains information that is not essential to the logical model, this step filters out all non-essential information, such as, for example, font and screen positional information. Preferably, this step is accomplished with a stand-alone Tcl application. As indicated at 60, if peculiarities exist in the (OO) model output, methodology advances to step 62, and the logical model is repaired in response to the noted peculiarities of step 60.

After the logical (OO) model is extracted from the object model output files, the methodology compiles the logical model at step 64. Step 64 is accomplished in two parts. First, because the logical model has a predefined structure and grammar, software utilities, which are preferably Lex (Lexical Analyzer) and Yacc (yet another compiler compiler), which are both commercially available, are initially used to define the logical model grammar. The output of the above software utilities, which conforms to C programming language, is compiled into a stand-alone software module that is used by the compiler 20. The resulting output identifies and tags all entities, relationships among the entities, and associated information, such as object identifiers, names, and multiplicity of associations. Second, step 64 splits the output into several files, such as class and association files, in a form conducive to subsequent processing. The second part of step 64 preferably is implemented in Tcl.

The logical model is subsequently transformed to a PDM schema file at step 66. The software maps the target PDM requirements to logical model data, and detects errors and other inconsistencies. Errors, and warnings of potential errors, are reported to the system user through an error file 27 in FIG. 2. Simultaneously, the PDM schema file is generated for use by the target PDM platform, as shown at 26 in FIG. 2. Further, ancillary target PDM related files such as the files at 28 in FIG. 2, may also be generated in the step to assist in building the PDS platform. For instance, such ancillary files may include revision and incremental PDM schema update information. As with step 64, the software module implementing this step is preferably realized in TCL programming language. The PDM schema file is subsequently output at 68 for use in the target PDM platform.

The above individual processing steps are preferably linked together through a script. Each software module associated with each step is a stand alone application, as the OO/PDM compiler is partitioned into distinct processing steps, thus making troubleshooting and further expansion of the methodology in software development easier.

Referring to FIGS. 5-13, transformation of sample OO models to resulting PDM schema will now be described to further illustrate the system and methodology of the present invention. FIG. 4 illustrates a sample object model file to be transformed into a PDM schema file at 80. In FIG. 4, classes are denoted by square boxes with the class name in the upper section of the box and attributes in the bottom section of the box. There is a generalization relationship among "Product", "Refrigeration", "Valve" and "Actuator" classes as well as among "Actuator", "Pneumatic" and "Electrical" classes. Generalization relationship is also referred as classification relationship in object oriented literature. In this example, super-class "Product" has sub-classes "Refrigeration", "Valve" and "Actuator". "Actuator" is further classified as being either "Pneumatic" or "Electrical". This "Product" class has a "productCode" attribute which characterizes the manufacture code of each product. Similarly, other classes (not shown) have other attributes. The association relationship between the "Valve" and "Actuator" (represented by a line between "Valve" and "Actuator") denotes that a "Valve" can use many "Actuators" and an "Actuator" can be used by many "Valves". The solid balls at the end of the association line further represent the "many" denotation.

Using the object model file 80 in FIG. 4, information contained in the logical portion of the object model is extracted which is referred to as the logical model. The other aspect of the object model deals with the presentation layer, i.e., the display and placement of the classes and relationships on the screen (or paper). Because all the semantics of the model are contained in the logical model, working with the logical model simplifies the down line processing. A portion of the logical model is illustrated at 90 in FIG. 5.

In the next step of processing, a compiler parses the context free grammar associated with the logical model illustrated in FIG. 5 to generate specific files for the classes, attributes, relationships, and roles. The generated class file is shown at 100 in FIG. 6.

In FIG. 6, each row in the class fie describes one class and contains five key fields: ("33B3F64AO164" for "Refrigeration" class), the class name, a description, the reference to the super-class ("33B3F64DO33F" in the "Refrigeration" class) and abstract class indicator, separated with ".vertline." character. If there is no super-class referenced, the fourth field is empty. The last field (abstract class indicator) identifies whether the class can be instantiated. In FIG. 6, no descriptive information is supplied in the original object diagram and no information is supplied as to whether the classes are abstract or not.

The attributes extracted by the OO/PDM compiler are shown in a resulting attribute file at 110 in FIG. 7. Each row of the attribute file has fields separated by ".vertline.". These fields are: a key field for the attribute, the attribute name, a description, the class key which the attribute belongs and the domain for the attribute.

To capture the association relationship, two files are used: one to address the association itself and the other to address the ends of the association, i.e., a multiplicity file and a role file. Since there is only one association in FIG. 4, only one row exists in the association file, as shown at 120 in FIG. 8. The format follows other file formats described previously: a key field, name of the association and a description, separated by ".vertline.". Note that there is no association name supplied, and the Rational Rose software supplies a default name ("$UNNAMED$O").

The role file is shown at 130 in FIG. 9. Because there are two ends to the single association in the object diagram, there are two rows in the role file. Each row includes five fields, with each field being separated by the ".vertline." character: a key that identifies the role, the name of the role, the multiplicity, the class key to which the role is attached, and the key reference to the association. Note that the "many" multiplicity designation is represented as "0 . . n" by Rational Rose.

Transformation of the object diagram to the target PDM schema file is accomplished by taking information contained in the files and generating the appropriate schema information appropriate for the target PDM. The Matrix PDM product from Adra Systems, Inc. is used for the exemplary target PDM. The generated Matrix attribute file is shown at 140 in FIG. 10, which conforms to the Matrix syntax. For example, because Matrix requires a globally unique attribute name, all attribute names are prepended with the class name to insure uniqueness. Furthermore, for those attributes that have unspecified domain, the default domain "string" is used.

The Matrix type (analogous to class) and relation (analogous to association) files are shown at 150 in FIG. 11 and at 160 in FIG. 12, respectively. The proper syntax required by Matrix for super-class, sub-class relationship (DERIVED key word) is supplied. In addition, proper sequencing of super-class and sub-classes, as required by the Matrix product, is also maintained. That is, a super-class type is created before a sub-class type can reference its super-class type. In our example, as shown in FIG. 11, "Actuator" is defined (through the ADD TYPE "Actuator" statement) before either "Electrical" or "Pneumatic" types are defined (again, through the ADD TYPE "Electrical" and ADD TYPE "Pneumatic" statements). For associations, translation of the multiplicity from Rational Rose convention to Matrix notation (CARDINALITY n) is made.

Finally, a log file summarizing all the errors and warnings detected during the compilation from the object diagram to the target PDM schema is created as described above and is shown at 170 in FIG. 13.

As can be appreciated from the foregoing description, the transformation system and method of the present invention allows an object model to be transformed into the database format in the manner that permits the system operator to note, and address, inconsistencies in the object files. Thus, consistency may be maintained between the OO models and the PDM schema, and the transformation process may be further defined through the use of the associated ancillary outputs generated by the system and method of the present invention. The transformation system and method of the present invention also transform an object model to an implementation specific file in an accurate and user-friendly manner that allows a database designer to focus on the conceptual aspects of database design rather than on database implementation.