JPH1115655A - Application shifting method not based on model and its system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To shift legacy system application not based on a model to a system based on a model on various platform by analyzing application not based on a model so as to generate a rationalized physical model and generating a platform depending physical model to input to a modeling system from the physical model. SOLUTION: A model extracting tool 20 generates the physical model 22 of legacy system application in the middle of conversion. A rationalizing module 24 rationalizes an object exported from the tool 20 through the use of information repository depending information 26 and generates a rationalizing physical model 28. After then, a model exporting module 30 is executed to generate a platform depending physical model 32 from the model 28. This model 32 is an inspection file and a composer model populating a modeling system 34 is prepared by a composer.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

FIELD OF THE INVENTION The present invention relates generally to model-based application systems, and more particularly to non-model-based (non-model-based) legacy systems.
gacy) Generating model-based applications from system applications.

[0002]

BACKGROUND OF THE INVENTION As they become obsolete or businesses point to the need, legacy systems, which are generally implemented on non-relational databases, are systems based on the latest models. ,
Or it has been redeveloped to run on an information repository. Systems based on these models provide greater flexibility and efficiency in maintaining and upgrading application systems. However, creating new systems raises the problem that business rules and other information integrated in these legacy systems must be extracted and used as efficiently as possible. Extracting these business rules and implementing them on different models and on different platforms is essential to making the transition with minimal disruption and without disrupting normal business activities. is there.

There is a need for a method and system for migrating non-model based legacy system applications to model based systems on a variety of platforms.

[0004]

SUMMARY OF THE INVENTION The present invention has been implemented on a computer for transitioning a non-model based application to a model based application operable to run on a particular modeling system on a particular platform. Including system. The present invention includes a first module for analyzing a non-model based application to generate a physical model of the non-model based application. This physical model is
Includes objects, entities, relationships, and properties from data and information in non-model based applications.
The second module rationalizes objects, entities, relationships, and properties in the physical model.
ize) to generate a streamlined physical model. The third module generates a platform-dependent physical model for input into the modeling system from the streamlined physical model. A modeling system data file that provides information about the particular modeling system to the second module is also included.

[0005]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention operates on a general purpose computer as shown at 10 in FIG. The computer 10 includes a data input device 12, a central processing unit (CPU) 1
4, including a display device 16 and a memory 18. A block diagram of the preferred embodiment of the present invention is shown in FIG. A model extraction tool 20, such as VIASOFT, is used to generate a physical model 22 of the legacy system application being transformed. The physical model 22 consists of files containing information about legacy system objects such as, for example, object types (fields, segments, etc.) and object identification, detailing the association between one "Composer" object and another. Finally, it details the characteristics (eg, name) of the Composer object. Various parameters can be set to run the model extraction tool 20 and specify the amount of detail to be extracted. The amount of specifications to be extracted can include basic specifications, basic specifications plus tolerances, or basic specifications plus batch interaction flow specifications.

[0006] The rationalization module 24 uses the information repository dependency information 26 to rationalize objects exported from the model extraction tool 20 and generate a rationalized physical model 28. The streamlined physical model 28 is then processed by the model exporting module 30 and the exporting model 32 (Texas Instrum)
(populated in a modeling system 34 such as Composer, a product of ents Incorporated). The rationalization module 24 also uses a bridge database 26 that contains information about the modeling system 34 that rationalizes the physical model 22. The rationalization module 24 includes several modules as shown in the block diagram of FIG. These modules include an initialization module 40, an appearance denormalization module 42, a "deletion is a buffer" module 44, a single field redefinition deletion module 46, a database entity processing module 48, and a duplicate file removal module 5.
0, target area cleanup module 52, duplicate object removal module 54, special character replacement module 56, and object description population module 5
8 inclusive. The details of each module constituting the rationalization module 24 will be described below.

[0007] The initialization module 40 clears the logging table and re-enables program options. The logging table is used by the object description population module 58 to create a description.
The initialization module 40 should be executed before other modules are executed. The physical model 22 includes a number of emergent entities. A separate entity is created for each occurrence clause found in the program in the legacy system application. These appearing entities contain only one attribute. Therefore, the physical model 22
A single entity within can be related to multiple appearing entities. The large number of these entities can make it difficult to operate the physical model 22 with them. Further, these appearing entities essentially do not add much value to the physical model 22. Accordingly, the rationalization module 24 includes an appearance denormalization module 42 for denormalizing these appearing entities back to the parent entity.
As a result, the attributes of the appearing entity are transferred to the parent entity. This also reduces the number of entities in the physical model 22.

In operation, the appearance denormalization module 42
Finds all related entities using the "... is an occurrence" relationship. FIG. 4 shows an entity relationship diagram including the entities “customer” 60 and “customer address” 62. Table 1 below shows the related attributes of the entity shown in FIG. As shown in FIG. 4, both entities are related through a "... is an occurrence" / "... has an occurrence" relationship. When the appearance normalization cancellation module 42 operates, “... is an appearance”
The attributes contained in the entity, ie, “customer address” 62, are forwarded to the entity “... Has occurrence”, ie, “customer” 60. These attribute names are then updated as follows. new attribute First name = "appearance ｜｜｜ Age attribute Name This "... is an occurrence" entity, "Customer Address" 62, is deleted with any relationship to it,
An entity relationship diagram as shown in the lower part of FIG. 4 is generated. The attributes obtained in “Customer” 60 are shown in Table 2 below. Table 1. Before execution entity attributes customers customers living plant customers Number customer Street address Line customer Name customer Phone Table 2. Entity attribute customer after execution Customer Number customer Name customer Phone appearance client Street address The line physical model 22 can also include multiple buffered entities, as shown in FIG. These tend to include 132 bytes of print lines or print areas. They provide little or no added value in the physical model 22, and therefore the "deletion is a buffer" module 4
4 can be eliminated as part of the streamlining module 24 that processes. This can greatly reduce the number of entities in the physical model 22.

In operation, the "delete is a buffer" module 44 detects all related entities using the "... is an occurrence" relationship. The “... is a buffer” entity, ie, the “print area” 64
Deleted with any relationship to it. Since there is no expected effect for the "... is a buffer" entity, the operation of the "delete is a buffer" module 44 results in the entity relationship diagram shown in the lower part of FIG. Physical model 22 may include a number of redefined entities. One for each redefinition clause found in the program in the legacy system application
Two separate entities are created. Most of these redefined entities contain only one attribute. The large number of these entities can make it difficult to operate the physical model 22 with them. Essentially, these appearing entities add little value to the model. Accordingly, the rationalization module 24 defines a single field redefinition and deletion module 46 that detects and deletes these single field redefinitions. The operation of the single-field redefinition deletion module 46 is based on the physical model 2
Significantly reduce the number of entities in 2.

[0010] Single field redefinition deletion module 46
Finds all related entities using the "... is a redefinition" relationship as shown in the example entity relationship diagram shown in FIG. If "... is a redefinition" entity, i.e. "5D-redefinition-is output-
If "was" 70 has only one attribute, it is deleted. Then the subsequent line was "... has a redefinition" entity, i.e. "... was -output-record-" 72, and "5D-redefine-output was-" Is "redefined". Then the "... is a redefinition" entity, i.e. "5D-redefinition-was an output-" 70 is deleted with any relation to it, and the entity shown in the lower part of FIG. -A relation diagram is obtained. "... is a redefinition" entity, ie "5
For D-redefined-is output- "70, there is no other expected effect.

The database processing entity module 48 detects all entities associated with a "database entity" (segment) through a "... uses a database entity" relationship. Then, the database processing entity module 48 selects “... Uses a database entity” having the maximum number of attributes. Each attribute in the selected entity is checked for each other "... uses a database entity" attribute and whether it exists in another "... uses a database entity" Check whether or not. For each “... Uses a database entity” where one of the attributes of the selected entity is present, the overall match percentage is stored.

[0012] Then, if the selected "... uses a database entity" is: 1) If the number of attributes in the selected "... uses a database entity" is less than 10, Is less or equal and if 100% of the attributes match the attributes in the other "... uses a database entity", or 2) if the selected "... is a database entity" The number of attributes in "use a database entity" is greater than 10 and if 95% or more of the attributes are consistent with the other attributes in "... use database entity". If any of the criteria are met, it is deleted. If one "... uses a database entity" is deleted, or if there is only one "... uses a database entity", then a designated database management system ( If the type of the DBMS is not DB2, the attributes of the selected entity are transferred to "... is a database entity". The expected effect for "... uses a database entity" is transferred to "... is a database entity" before deletion. The lower part of FIG. 7 shows an entity relation diagram obtained after the operation of the database entity processing module 48 of the entity relation diagram shown in the upper part of FIG. The attributes associated with the entities in the entity relationship diagram shown at the top of FIG. 7 are shown in Table 3 below. FIG.
The resulting attributes associated with the entities in the entity relationship diagram shown below are shown in Table 4 below.

When executing the database entity processing module 48, the user can set the "number of starting characters to ignore" parameter prior to execution. This causes the database entity processing module 48 to ignore the first X character from each attribute name while matching attributes across entities. For example, if the "number of starting characters to ignore" parameter is set to 4, the database entity processing module 48 considers the following attribute names to be the same. D409-customer-name D220-customer-name or D1-customer-number D9-customer-number Table 3. Entity attribute customer D9-customer-record D1-customer- record customer-identification D9-customer-number D1-customer-number D1-customer-name D1-customer-name D9-customer-telephone-number D1-customer -Phone-Number D9-Customer-Address-1 D1-Customer-Address-1 D9-Customer-Address-2 D1-Customer-Address-2 D9-Customer-Address-3 D1-Customer-Address-3 Table 4. Entity attribute customer D9-customer-number D9-customer-name D9-customer-telephone-number D9-customer-address-1 D9-customer-address-2 D9-customer-address-3 after execution The example shown in FIG. In the entity relationship diagram, the database entity processing module 48 selects “D9-Customer-Record” 76 as the selected entity. The reason is that even though "D9-Customer-Record 76" and "D1-Customer-Record" 78 have the same number of attributes, the database entity processing module 4
8 first finds the "D9-Customer-Record" 76 entity. The database entity processing module 48 then determines that each attribute in the selected entity (D9-customer-record 76) is another "... uses a database entity", i.e., "D1-customer-record" 78. Determine if it exists. The database entity processing module 48 then calculates the percentage of matches for each selected entity for each "... uses a database entity" (100% in the example above). "... uses a database entity" (D1-customer-record 78) is deleted because it meets the first criterion described above.

The expected effects from the two records in entity D1-customer-record 78 are then passed to entity customer segment 74. The description of "D9-Customer-Record" 76 is updated as follows (assuming that "D1-Customer-Record" 78 is referenced in a program named PFTP001). Deleted record: PFTP001 D1-customer-record In this case, the parameter "number of first characters to ignore" is set to 3. Thus, when examining the attribute name, the database entity processing module 48 ignores “D9-” in the entity “D9-customer-record” 76, and ignores “D9-” in the entity “D1-customer-record” 78.
1- "is ignored. Duplicate file removal module 50
Examines duplicate entities in the region of interest. At the beginning,
The duplicate file elimination module 50 selects the entity having the maximum number of attributes. The attributes of the selected entity are then checked against the attributes of each of the other entities in the area of interest. The overall matching percentage for each entity is stored.

If the entity is: 1) If the number of attributes in the selected "... uses a database entity" is less than or equal to 10, and if 100% of the attributes are If they match, or 2) if the number of attributes in "... uses a database entity" is greater than 10 and 95% or more of the attributes are consistent If it meets any of the two criteria, it is deleted. Duplicate file removal module 50 does not transfer attributes between entities. The expected effect for the deleted entity is transferred to the selected entity. Also, all relationships from the deleted record are transferred to the selected record.

When all the entities in the target area have been examined for the selected entity, the newly selected entity is selected based on the number of attributes. The attribute matching and entity deletion process
This is repeated until all entities have been selected. As described above, the user can specify some parameters to control attribute matching across entities. The "number of starting characters to ignore" parameter, the "number of ending characters to ignore" parameter, and the "ignore number" parameter can also be used. For example, if the "number of last characters to ignore" parameter is set to 4, then the next attribute is considered to be the same. Customer-name-D409 Customer-name-D220 For example, if the "ignore numbers" parameter is set to 1, then the following attributes are considered to be the same: Input-Record-Data Input-Record-Data 1 If the "ignore numbers" parameter is set to 1, then the following attributes are also assumed to be the same. In other words, being set to 1 means that one digit is ignored. Input 1-Record-Data Input-Record-Data Table 5. Entity Attribute Heading Before Execution- Record 1 Heading-Record 2 End Part-Record 1 End Part-Record 2 Customer-Number Customer-Number Filling Character-1 Filling Character-1 Customer-Name Customer-Name Total Bill Amt total Bill Amt customer-telephone-number customer-telephone-number customer-address-1 customer-address-1 customer-address-2 customer-address-2 customer-address-3 customer-address-3 filling-character-1 filling-character-1 , Entities “heading-record 1”, “heading-record 2”, and “terminal-
“Record 1” and “Terminal-Record 2” are the physical models 22 currently being processed by the duplicate file removal module 50.
Shall be included in It is also assumed that the duplicate file removal module 50 selects the entity “heading-record 1” as the selected entity. The reason is that the entity "heading-record 1" is detected first, even if "heading-record 1" and "heading-record 2" have the same number of attributes. The duplicate file elimination module 50 then determines whether each attribute in the selected entity (“heading-record 1”) is equal to each other entity (“heading-record 2”,
("Terminal part-Record 1" and "Terminal part-Record 2"). The duplicate file removal module 50 then calculates, for each other entity, the percentage of matches with the selected entity (in the example, 100%, 14%, and 14%). Then in this example:
The duplicate file removal module 50 deletes the entity “Header-Record 2” that passes the first criterion described above. The expected effect for "Header-Record 2" is transferred to "Header-Record 1" and the description of "Header-Record 1" is updated as follows. Deleted record: PFTP002 Heading-Record 2 Next, the entity "Heading-Record 1" is marked as processed so that it is not examined again.
The duplicate file removal module 50 then selects "Terminal-Record 1" as the next selected entity,
It is determined whether the selected entity (“end-record 1”) exists in another unmarked entity (“end-record 2”) in the target area. Next, the duplicate file removal module 50 calculates the percentage of “end-record 2” matches for the selected entity (100% in this example). This entity "Terminal-Record 2" is then deleted because it passes the first criterion described above. `` Terminal-
The expected effect for "Record 2" is transferred to "End-Record 1". Next, the description of “end-record 1” is updated as follows. Deleted record: end-record 2 The above parameter "number of first characters to ignore" is set to 3 in this case, and duplicate file removal module 50 ignores the first three characters when examining the attribute name. .
The entities and their associated attributes obtained after processing by the duplicate file removal module 50 are shown in Table 6 below. Table 6. Entity Attribute Heading After Execution- Record 1 End- Record 1 Customer-Number Filling Character-1 Customer-Name Total-Bill-Amt Customer-Phone-Number Customer-Address-1 Customer-Address-2 Customer-Address-3 Fill Character-1 The target area cleanup module 52 performs two functions. First, the target area cleanup module 52 deletes a target area that does not include an entity type. Second, if an area of interest contains a single entity type, rename this entity type using the area of interest name and transfer that entity type to the next highest area of interest. Then, the target area is deleted.
If the next highest target area is the root target area level,
The entity type is transferred to a target area called a system file. The description of the entity type is updated to record the name before updating.

The following "Data Model List" example shows before being processed by the target area cleanup module 52. The example "Data Model List" is
A root level target area named “customer model” and target areas “new customer file”, “customer empty area”, and “old customer file” are included. Before execution-Data model list "Customer model" (Root level target area) "New customer file" (Target area) "... was input-record" (Single entity type) "Customer empty area" ( (Target area) "Customer database" (Target area) "Customer" (Single entity type) "Customer address" (Single entity type) "Old customer" (Target area) "... was -output-record" (Single Entity Type) After the execution of the target area cleanup module 52, an example “data model list” is as follows. After execution-Data model list “Customer model” (Root level target area) “System file” (New target area) “New client File "(single entity type)" old client "File" (single entity type) "customer database" (target area) "customer" (single entity type) "customer address" (single entity type) -Input-Record was: Renamed from "
To "New client File "entity type. The entity type "old client File "
Corrected in the same way.

The duplicate object removal module 54 performs the following functions. First, it ensures that all object names are unique throughout the physical model 22. Second, it removes overlapping relationships. Third
Next, the duplicate object removal module 54 removes the duplicate "allowable value". Fourth, the duplicate object removal module 54 optionally removes all attributes including a given column (string). Fifth, the duplicate object removal module 54 optionally removes all characters in the attribute name that match the given editing pattern up to the first hyphen or underscore. Finally, the duplicate object removal module 54 optionally changes all parent-child relationships to one-to-many. Each of these functions is examined in turn. The duplicate object removal module 54 examines each object name and ensures that it is unique through the physical model 22. It checks the "target area", "entity type", "function", and "attribute name" for uniqueness. If duplicate object removal module 54 detects two objects with the same name in physical model 22, it adds a six digit number before one of those names. If the entity contains two attributes with the same name, eg, “fill character”, “fill character”, the duplicate object removal module 54 appends a two digit number to the end of the attribute name, eg, “fill character”. First occurrence of " 0
1 ”and the second occurrence of“ fill character ”is“ fill character ”.
01 ". Table 7. Operation Example of Duplicate Object Removal Module 54 for Duplicate Object Name Object Type Object Name / Before Object Name / Post Entity Type Customer Customer Customer 011223 Customer customer 006234 Customer Function PFTP001 PFTP001 PFTP001 233231 PFTP001 Attribute E5-fill-character-1 (customer E5-fill-character-1 entity type) E5-fill-character-1 (customer E5-fill-character-1 (01 entity type) The physical model 22 can include a plurality of overlapping relationships. This means that the two entity types are related through the same relationship twice, as shown in the upper part of FIG. 8 (in the upper part of FIG. 8, the entity “customer” 80
But the relationship "... is accessible via ..." /
Entity "customer" by "contact for ..." Contact "82 twice). These overlapping relations are stored in the duplicate object removal module 54.
To obtain the entity relationship diagram shown in the lower part of FIG. 8 (in the lower part of FIG. 8, the entity "customer"
80 is "... is accessible via ..." /
Entity "customer" through "contact for ..." Is only associated once with "contact").

The duplicate object removal module 54 includes:
As in the example shown below, a value allowed for uniqueness is also checked for each attribute in the physical model 22. Previous attribute "Customer Type Code "is the allowed value 'A',
It has 'B', 'B' and 'C'. After attribute "customer Type Code "is the allowed value 'A',
It has 'B' and 'C'. The duplicate object removal module 54 allows a user to remove all attributes from the physical model 22 including a column. For example,
If the user specifies the column as "fill character",
All attributes whose names include "fill character" are deleted. The description of the parent entity type is updated to reflect the deletion of that attribute.

Further, a duplicate object removing module 5
4 provides the user with an option to change all parent-child relationships in the physical model 22 from one-to-one density (cardinality) to one-to-many density. In addition, the duplicate object removal module 54 includes a first hyphen (or underline).
Option to remove all characters up to from all attribute names in the physical model 22. The user can specify an editing pattern, and the duplicate object removal module 54 causes each character to follow the specified pattern. If any character fails to match the edit pattern, the attribute name does not change. Tables 8 and 9 below show examples of having no specified edit pattern and having the specified edit pattern, respectively. Table 8. Example-No edit pattern specified Attribute name before execution Attribute name after execution Customer-First name D9-Customer-Number Customer-Number Phone-Number Number D509-EFT-Bank-Identification-Number EFT-Bank-Identification-Number Edit pattern Running this option without specifying is not recommended. Table 9. Example- Attribute name before designating and executing edit pattern A999 Attribute name after execution Customer-Name Customer-Name D9-Customer-No. Customer-No. Phone-No. Phone-No. D509-EFT-Bank-Identification-No. EFT-Bank- Identification-number 9D-fill-character-1 9D-fill-character-1 As described above, duplicate object removal module 54
Examines each character up to the first hyphen for the corresponding character in the edit pattern. The exemplary editing pattern A999 used in the example shown in Table 9 above requires that the first character be a (alphabet) character and that the second, third and fourth characters be numeric. Is specified. Duplicate object removal module 54
Examines only the characters up to the first hyphen in the attribute name. In the example shown in Table 9, both D509 and D9 have disappeared in the inspection for the edit pattern.

Returning to FIG. 3, the rationalization module 24 also includes a special character replacement module 56 that replaces all occurrences of one character (eg, a hyphen) in the object name with another character (eg, a hyphen). For example,
(Underline). Table 10 below shows example designations provided to the special character substitution module 56. Table 10
Describes which characters are replaced and what. Table 11 below describes the operation of the special character replacement module 56 using the designations given in Table 10. Table 10. Special character Examples character substitution character hyphen '-' underlined ' 'Brackets'('underscore' 'Close parenthesis') 'underline' 'Plus sign' + 'underline' 'Dot'.'Underline' 'Ampersand'&'row' Tmp 'Double ampersand'&&'row' Prm '' Table 11. Example Before name replacement After name replacement "customer-name""customer "&& ZCFT.File name""PRM ZCFT "File name""& ZCFT.File name""TMP ZCFT File name "Customer (name) +)" Customer Name Note that only the object name is affected, and that none of the characters that appear as allowed values have changed.

The object description population module 58 populates the description for the model objects of "region of interest", "entity type", "attribute", and "function". The general description layout is as follows. Legacy name: Description: The legacy name is the same as the object name. The reason for populating the legacy name is that here, during the analysis phase of the project, the object name will probably have to be renamed, and thus this name will provide a traceback to the existing system.

Some additional lines can be added to the description of some entity types. For example, if the entity type ("input record") has been renamed to the target area name, the following line is added to the description of the entity type. "Rename from ...": "Input record" Also, if an entity type is related to another entity type by a "... is a database entity" relationship, and "... is a database entity"("D4-Customer-Record") has been deleted under the "Database Entity Processing" option, the following line is added to the entity type description: "Deleted record": PROG0001 D4-customer-
Record The program name referring to "D4-Customer-Record" is also "・
Is a database entity ".

Finally, after the rationalized physical model 28 is generated, the model exporting module 30 is executed, and the platform-dependent physical model 32 is generated from the rationalized physical model 28 generated by the rationalized module 24. In the current embodiment of the invention, the platform dependent physical model 32 generated by the model exporting module 30 is an inspection file, which is used by Composer to create a "composer model" that populates the modeling system 34. You.

In connection with the above description, the following items are disclosed. 1. A computer-implemented system for translating a non-model based application to a model based application and enabling it to operate on a particular modeling system on a particular platform, comprising: A first module for analyzing the non-based application and generating a physical model including objects, entities, relationships, and properties from data and information within the non-model based application, each having an object name;
A second module responsive to the first module for rationalizing the objects, the entities, the relationships, and the properties in the physical model to generate a rationalized physical model; Respond,
A third module for generating a platform-dependent physical model to be input to the modeling system from the streamlined physical model. 2. The system of claim 1, further comprising an information repository database that supplies information related to the particular modeling system performing the model-based application to the second module. 3. 3. The system of any of clauses 1-2, wherein the second module includes an initialization module that initializes a plurality of user-defined parameters. 4. Clause 1-3, wherein the second module further comprises: a denormalization module that denormalizes the appearing entity back to the associated parent entity and reduces the number of the objects in the physical model. A system according to any of the preceding claims. 5. 5. The method of any of claims 1-4, wherein the second module further comprises a "deletion is a buffer" module that deletes buffered entities to reduce the number of objects in the physical model. system. 6. The second module further includes a single-field redefinition deletion module that deletes redefined entities that include only one attribute from the physical model to reduce the number of the entities in the physical model. −
A system according to any one of claims 5 to 13. 7. The second module uses some of the relationships to detect entities including database entities, matches attributes contained within each entity according to predetermined matching criteria, and if the match is a predetermined threshold value. 7. The system according to any one of the above items 1-6, further comprising a database entity processing module for deleting each of the entities. 8. The system of any of the preceding claims, wherein the second module further comprises a duplicate file elimination module that eliminates duplicate entities having one of a plurality of regions of interest. 9. The second module removes the one of the target areas if the one of the target areas is blank;
Any of the preceding claims, further comprising a target area cleanup module that merges the one of the target areas into a higher target area if the one of the target areas includes a single entity type. The system described in Crab. 10. The second module guarantees the unique name of the object through the physical model, removes duplicates in the relationship, removes duplicate tolerances, modifies the attributes according to predetermined criteria, and The system of any of clauses 1-9, further comprising a duplicate object removal module that changes some of the relationships from many-to-many to one-to-one. 11. 11. Any of the above items 1-10, wherein the second module further includes a special character replacement module that replaces all occurrences of a first predetermined character string in the object name with a second predetermined character string. The system described in Crab. 12. The system according to any of claims 1-11, wherein said second module further comprises an object description populate module for inserting information describing said objects. 13. A computer-implemented method for migrating a non-model based application to a model based application and enabling it to operate on a particular modeling system on a particular platform, comprising: Analyzing the non-based application; generating a physical model of the non-model based application including objects, entities, relationships, and properties from data and information in the non-model based application; Generating a streamlined physical model by rationalizing the objects, the entities, the relationships, and the properties in the model, and generating a platform-dependent physical model to be input to the modeling system from the streamlined physical model Performing the method. 14． The present invention is a computer-implemented system for transitioning a non-model based application to a model based application and enabling it to run on a particular modeling system (34) on a particular platform. including. The present invention analyzes non-model based applications and analyzes the physical model (2
2) generating a first module (20). The physical model contains properties from data and information in objects, entities, relationships, and non-model based applications. The second module (24) contains the physical model (2
2) rationalize the objects, entities, relationships and properties in to generate a streamlined physical model (28). A third module (30) generates a platform dependent physical model (32) that is input from the streamlined physical model (28) to the modeling system (34). Also included is a modeling system data file (26) that provides information about the particular modeling system (34) to the second module (24).

[Brief description of the drawings]

FIG. 1 is a block diagram of an exemplary computer system on which the present invention operates.

FIG. 2 is a block diagram of the present invention.

FIG. 3 is a diagram showing the rationalization module included in the present invention in more detail.

FIG. 4 is an entity relationship diagram used to illustrate one of the features of the present invention.

FIG. 5 is an entity relationship diagram used to illustrate another feature of the present invention.

FIG. 6 is an entity relationship diagram used to illustrate another feature of the present invention.

FIG. 7 is an entity relationship diagram used to illustrate another feature of the present invention.

FIG. 8 is an entity relationship diagram used to illustrate yet another feature of the present invention.

[Explanation of symbols]

 10 Computer 12 Data Input Device 14 CPU 16 Display Device 18 Memory 20 Model Extraction Tool 22 Physical Model 24 Rationalization Module 26 Information Repository Dependent Information 28 Rationalization Physical Model 30 Model Exporting Module 32 Exporting Model 34 Modeling System 40 Initialization Module 42 Appearance Denormalization module 44 Deletion is buffer module 46 Single field redefinition deletion module 48 Database entity processing module 50 Duplicate file elimination module 52 Target area cleanup module 54 Duplicate object elimination module 56 Special character substitution module 58 Object description population module

Claims (2)

[Claims] 1. A computer-implemented system for transitioning a non-model based application to a model based application and enabling it to operate on a particular modeling system on a particular platform. Analyzing a non-model based application and generating a physical model including properties from objects and entities, each having an object name, and data and information within the non-model based application; A second module responsive to the first module for rationalizing the objects, entities, relationships, and properties in the physical model to generate a rationalized physical model; and To the modeling system from the streamlined physical model A third module for generating a platform-dependent physical model to be applied. 2. A computer-implemented method for migrating a non-model based application to a model based application and enabling it to run on a particular modeling system on a particular platform. Analyzing the non-model-based application and generating a physical model of the non-model-based application including objects, entities, relationships, and properties from data and information in the non-model-based application; Generating a rationalized physical model by rationalizing the objects, the entities, the relationships, and the characteristics in the physical model; and a platform input from the rationalized physical model to the modeling system. Generating a dependent physical model. How to.