Apparatus and method for gathering and entering data requirements from multiple users in the building of process models and data models5590360Abstract A computer-based apparatus and method for gathering Information for data model and Process model development includes a plurality of terminals on a local area network at which multiple users enter Information in a structured manner in response to an ordered sequence of screens displayed for a given project; a centralized database for receiving the Information from the multiple users; and a bridge program for transforming the group-entered Information stored in the database into a format that a computer-based information engineering tool can create into a model. An analyst workstation is included to enable only an analyst to edit gathered Information in response to comments from users and provide certain consensus inputs. Claims I claim: Description FIELD OF THE INVENTION
______________________________________
OBJECT TYPE CODE
______________________________________
CRITICAL ASSUMPTION
10039
FUNCTION 10058
INFORMATION NEED 10041
PROBLEM 10031
______________________________________
It is noted that each Object type begins with the numeral "1". An Association File record defines relationships or associations between Objects defined in the Object File and/or associations between associations defined in the Association File. The Association File record includes 41 characters: characters 1-11 are integers (beginning with a "2") that represent the token or identifier for the particular association; 13-17 are integers (starting with "2") that represent the Association Type; 19-29 are integers that represent a unique FROM Token identifying the Object or association that is the source of the relationship or association; and 31-41 are integers that represent a unique TO Token identifying the Object or association to which the relationship or association is directed. The FROM Tokens and TO Tokens can be defined in the Object File or Association File--in the former case, the token begins with a "1" and in the latter it begins with a "2". An example of an Association File record for a "relationship type" of association corresponding to "Class is taught by Instructor" follows: 20000000022,20044,10000000004,10000000003 In this example, 20044 indicates that the association is of the "relationship type"; 20000000022 is the token identifying the specific relationship type, for example the relationship between two specific Objects; 10000000004 is the token representing "CLASS"; and 10000000003 is the token representing "INSTRUCTOR." It is noted that the INSTRUCTOR token and CLASS token are the same as set forth in the Object File record described above. The third type of file, the Property File, includes records that describe properties for Objects and relationship types. Each Property File record contains 58 characters and associates a property type and a value with tokens in the Object File or Association File. The first eleven characters (1-11) are integers that identify a token for an Object or association; characters 13-17 correspond to the property type code which must begin with a "3"; 19-23 which are all zeroes; and 26-57 which describes in text or numbers the property. Reference is again made to the foregoing example of "Class Is Taught by an Instructor." Suppose it is intended that the class be taught by no more nor less than 1 instructor. These maximum and minimum values are properties of the relationship between the Instructor and the class. Suppose that 30034 is the property type representing a "FROM-TO" property, that is a property extending from one item to another. Suppose that 30035 represents "FROM-TO MINIMUM CARDINALITY" whereas 30036 represents "FROM-TO MAXIMUM CARDINALITY". The following Property File records correspond to "Class is taught by a minimum of 1 instructor and a maximum of 1 instructor":
______________________________________
20000000022,30034,00000,"IS TAUGHT BY
"
20000000022,30035,00000,"1 "
20000000022,30036,00000,"1 "
______________________________________
Similarly, to express the notion that the "Instructor teaches a minimum of one class and a maximum of many classes" the following property records would be stored:
______________________________________
20000000022,30034,00000,"TEACHES
"
20000000022,30035,00000,"1 "
20000000022,30036,00000,"M "
where "M" stands for "many".
______________________________________
The last file in the ADW encyclopedia is the Textual Property File, TIEXP, which defines comments and definitions for Objects and relationship types. Records in this file associate a property type and value with tokens defined in the Object File or Association File. Each record includes 98 characters. The first 11 are integers corresponding to an identified token for an Object in the Object File or a relationship type defined in the Association file. The five characters 13-17 are integers corresponding to 30076 for a definition or 30077 for comments. Repetition Number characters 19-23 can have a value from 1 to 5. The remaining characters 26-97 contain a long textual property value. If more than 72 characters are needed for a definition or comments, it can flow to the next record by using a next Repetition Number. The first line of comments may have a 00001 Repetition Number, while the second line of comments may have a Repetition Number of 00002. By way of example, the definition for the token 10000000004 (i.e., identifier for CLASS) as a "Group of Students . . . meeting to participate . . . " would be represented by:
______________________________________
100000000004,30076,00001,"Group of . . .
"
100000000004,30076,00002,"meeting to . . .
"
______________________________________
The above four files, referred to as flat files, are required by Knowledgeware's ADW to generate process models and data models. Typically, the computer-based information engineering tool prompts the user to enter the Information needed to generate the four files. However, only one user enters the Information. Moreover, the inputs are highly formatted and require the user to have experience and expertise in Knowledgeware ADW in order to enter the information. Hence, the user entering data must be versed in both the project to be performed and in the tool being used or must acquire the Information from others. 3. Description of Inventive Front End to Computer-based Information Engineering Tool A. Hardware Configuration and Operation Referring to FIG. 1, a local area network (LAN) 100 is shown having terminals 102 through 110 connected thereto. Each terminal 102 through 110 is preferably an IBM* 8590-OL9 PS/2* Model 90 XP486. Each terminal 102 through 110 has a respective display 112 through 120. Each display is preferably an IBM PS/2 8515 color display. The LAN 100 is preferably a token ring network 16/4. The terminals 102 through 110 are connected to the LAN 100 with an appropriate cable (not shown) and preferably are installed with a PS/2 4 MB memory modification kit and a 3990 Enhanced KBRD English (US). A mouse (not shown) is provided with each terminal and operates in the standard manner. Terminal 102 is an "analyst" terminal which has a unique configuration and is allowed to perform operations unavailable to the other terminals 104 through 110. For example, the analyst terminal 102 is used to identify users that can attend a specific project. Other special features of the analyst terminal 102 are discussed below. Also connected to the LAN 100 is a server 130. The server 130 is preferably an IBM 8590-OLF PS/2 Model 90 XP 486 equipt similar to the terminals 102 through 110, except that it includes a server adapter (not shown) which is preferably a 4041 Token Ring Network Adapter 16/4 IBM Server ADP/A and is not provided with a mouse. The server 130 has a centralized database 132 and is connected to a printer 134. Reports, based on data stored in the database 132, can be printed at printer 134 with an appropriate input command from terminal 102 (or, in some instances, other of the terminals). The analyst terminal 102 has a number of tools installed that other terminals 104 through 110 do not. The analyst terminal 102 includes a a decomposition diagrammer, dataflow diagrammer, entity relationship diagrammer, entity type diagrammer, and minispec action diagrammer. (It is noted that a dataflow describes an overall flow of data that is made up of elements referred to as Data Flows.) These tools are typically available in a computer-based information engineering tool 136 which is accessed through a bridge program 138. The bridge program 138 converts table data stored in database 132 into a format strictly dictated by a computer-based information engineering tool 138, such as ADW. That is, data stored in the database 132 is exportable through the bridge program 138 into the computer-based information engineering tool 136. Connected to the analyst terminal 102 is a projector 140 with a projector screen 142 for displaying to all users the contents of the analyst's display 112. A preferred projector model is the BARCO projector which projects onto a screen the display of a terminal. B. Operation Referring to FIG. 2, the general operation of the invention is illustrated. In step 202, users at terminals 102 through 110 (of FIG. 1) enter data onto the LAN 100 (of FIG. 1) in response to menu screens. Depending on the screen input to which the user is entering input, at step 204, the data or Requirement is transferred to an appropriate location in a table in the database 132 (of FIG. 1). These Requirements can then be printed and/or categorized. For example, suppose the user is at a screen with a box in which the user can add a new Component. When the user enters the name of the Component in the box, the data is transferred to a table of Components that pre-exists in the database 132 (of FIG. 1). In this regard, each time a project is set up, a Component table for the project is set up in the database 132 (of FIG. 1). By way of further example, suppose the analyst has a screen that asks whether the Component is an Entity or Attribute, and the analyst, based on user comments, enters "Entity" at terminal 102 (of FIG. 1). That Information is conveyed to the database 132 (of FIG. 1) and is stored in a pre-existing "Entity" table stored for the project. The gathered Information may be printed out in step 206 as a report. Also, the gathered Information may be directed in step 208 through the bridge program (138 of FIG. 1) to convert the gathered Information into a format that the computer-based information engineering tool (136 of FIG. 1) can recognize. In step 210, the computer-based information engineering tool generates a desired model, such as a decomposition diagram, data flow diagram, or the like. Steps 202, 204 and 208 can be viewed as a novel front-end 212 of the present invention; that is, a front-end 212 for gathering natural language input from a plurality of users at respective terminals on a network and converting it into a format that existing computer-based information engineering modelling tools can import. It is noted that for different information engineering tools, different bridge programs may be required. However, the input to all bridge programs are the same Requirements and data gathered and stored in the centralized database (132 of FIG. 1) and the exportable output must be in terms of Entities, Attributes, External agents, Cardinalities, Data Flows, Data Stores, and Parent Process group hierarchies, which are typically required by computer-based information engineering tools. A specific bridge program is described below. Referring to FIG. 3, a decomposition diagram shows successive levels of detail involved in accumulating Information according to the present invention. Gathering Information 302 is the highest level of Process and is a parent to three constituent offspring Processes: gathering Requirements 304, gathering Information for building a Process model 306, and gathering Information for building a data model 308. Requirements define what the participants expect the final result of their project to achieve. Modelling a Process involves defining the various Processes relating to the project in terms of data flowing into and from the Process, relationships between Processes, and relationships with agents external to but employed in the Process being modelled. The modelling of dataflow involves the tracking of incoming and outgoing data as it flows between Processes themselves or between Processes and external Data Stores. Processes that compose the Process of "gathering Requirements" 304 are shown in FIG. 4. Process 400 involves "reviewing Requirements" in which users are displayed a list of previously entered Requirements. The users discuss and propose editing changes, which can modify or delete Requirements on the list. The changes can be entered only at the analyst machine (102 of FIG. 1). This helps ensure that a common set of data understood by all users is stored in the database 132 (of FIG. 1). Process 402 involves "entering known Requirements" that may have previously been defined or imposed on the group. In Process 404, certain categories are defined into which Requirements may be grouped. In Process 406, users discuss and propose which requirements fit within which defined categories. Categories need not be exclusive; one Requirement can fit into more than one category as the users may determine. In Process 408, new requirements can be entered by the users. Requirements and category Information, as entered by users or modified by analyst input, is stored in a project database using the services of a database manager (in the preferred embodiment the OS/2 Database Manager). Each Process is accomplished by users responding to appropriate menus displayed at their displays (114 through 120, respectively, of FIG. 1). For example, a user screen 500 is shown in FIG. 5. In FIG. 5, three decisions have been entered. It is first noted that the three major activities that can be performed are shown in the lower half of the screen 500: gathering Information for Requirements 502, Processes 504, and Data 506. The Requirements option 502 (obscured in the figure) has been selected. The screen 500 also includes a horizontal menu bar 508 that lists FILE, SPECIFY, REVIEW, ASSIGN, TOOLS, HELP choices. The TOOLS choice is hatched and hence not available to the user's machine at this time. The SPECIFY choice is darkened to indicate that it has been selected. A pull-down window 510 is shown under the SPECIFY selection. Although six items are readable in the window 510, only the top two REQUIREMENTS and CATEGORIES are available for selection, given the earlier choices. It is noted that PROCESSES and FUNCTIONAL GROUPS (i.e., Parent Process Groups), are choices available when Process modelling is being performed; and that DATA FLOWS and DATA COMPONENTS are available when dataflow modelling is performed. Screen 500 is representative of screens used in the present invention. Such screens are preferably generated in accordance with the IBM operating system OS/2.* The creation of menus, menu bars, pull-down windows, and the like are described in the Programming Guide for the operating system "IBM Operating System/2* Programming Tools and Information Version 1.2" at chapters 11, 14, 15, and 16. Specific programming routines for achieving such screens are provided in the Guide. *Operating System/2 and OS/2 are registered trademarks of the IBM Corporation. Referring again to FIG. 3, the layers of Processes related to the gathering Information used in modelling Processes are shown. The second layer includes ENTER DATA 310 and REVIEW DATA 312. The more detailed Processes of ENTER DATA 310 include ENTER PROCESS INFO (such as the Process name and Process description) 314, ENTER DATA FLOW INFORMATION 316, ENTER DATA STORE INFORMATION 318, ENTER EXTERNAL AGENT INFORMATION 320, and ENTER PARENT PROCESS GROUP INFORMATION 322. Under the Process of building a DATA Model 308, there is a next lower level of two Processes ENTER NEW COMPONENTS 324 and REVIEW COMPONENTS 326, with REVIEW COMPONENTS 326 having two offspring Processes DESCRIBE AND ASSIGN TYPE 328 and ASSOCIATE ATTRIBUTES TO ENTITIES 330. Looking first at the Processes involved in gathering Information for modelling data, it is noted that some Components may be previously imposed while others may be entered by users in Process 324. The entering of Components (like the entering of Requirements described above) is accomplished by multiple users at terminals 102 through 110 (of FIG. 1) entering the data. The REVIEW Process 326, while relying on user discussion and consensus, permits input from only the analyst terminal 102 (of FIG. 1). That is, only the analyst terminal 102 (of FIG. 1) is programmed and configured to enter such data as is known in the programming field. Under Process 328, Components are described and defined as an Entity or Attribute. While users may discuss which type applies to a given Component, only the analyst terminal 102 (of FIG. 1) can make the assignment. Similarly, while users discuss and form consensus on the matching of Attributes with Entities, the entry of such matching in Process 330 is permitted at only the analyst terminal 102 (of FIG. 1). The Entities and Attributes are stored in a database corresponding to the project being performed, and the association therebetween is also stored in the database. The database is preferably a relational database in which data is stored in tables. Sample Components for a Process, relating to business personnel, are listed below in Table 1: TABLE 1. SAMPLE COMPONENT LIST EMPLOYEE Employee First Name Employee Last Name Employee Middle Initial Employee Address Line 1 Employee Address Line 2 Employee Address Line 3 Employee City Employee State Employee Zipcode Employee Department Employee Division Employee Internal Zip Employee Serial Number Employee Tie-line Employee Nodeid Employee Start Date Employee Information Employee End Date Employment Status MANAGEMENT Manager Name Manager Tie-line Manager Nodeid Manager Outside Line Serial Number Social Security Number Spouse SALARY Salary Rate Staff type DEPARTMENT Department Name PROJECTS In Table 1, the Components in all capital letters represent Entities. The remaining Components are Attributes listed under associated Entities. Data entered by users or analyst at terminals 102 through 110 (of FIG. 1) is directed to respective tables in the database (132 of FIG. 1). The tables, based on the user and analyst entries, indicate whether a data item is an Entity or Attribute, a Data Flow, a Parent Process, or the like. A sample table stored in database 132 follows:
TABLE 2
______________________________________
Employee name
Address Serial No.
Tel. no.
______________________________________
Employee 1
] ] ]
Employee 2
] ] ]
Employee 3
] ] ]
______________________________________
In the above Table 2, it is assumed that input from the analyst terminal (102 of FIG. 1) identifies "employee" as an Entity and "employee name", "address", "serial number" and "telephone number" as Attributes. Processes stored in the database, as previously noted, are identified as Parent Processes, and offspring Processes thereof are noted as well. The hierarchy of Processes is stored in a linked list in the database 132. A sample linked list looks as follows in Table 3:
TABLE 3
______________________________________
.sctn.
/**********************************************************/
/* A component may be EITHER an attribute or
*/
/* an entity but not both! */
/**********************************************************/
typedef struct .sub.-- COMPONENT
CHAR dbmErrCodeDesc
[DBMSGLENGTH];
CHAR szCompDef [257];
CHAR szCompName [32];
CHAR szDFTypeName [32];
CHAR szCompDisp ;
sptrATTRIBTYPE sptrCOLNAME;
sptrENTITYTYPE sptrTABLENAME;
struct .sub.-- COMPONENT *B4Comp:
struct .sub.-- COMPONENT *NextComp:
}COMPONENT, FAR *sptrCOMPONENT;
______________________________________
Referring again to FIG. 1, once the Information is stored in the database 132, the analyst terminal 102 can perform a number of functions. A simple print-out of the entered data can be requested from the printer 134. If DATA FLOW or PROCESS Information was entered, the analyst terminal 102 can also request to format the data to be exported to the computer-based information engineering tool 136 through the bridge program 138. The bridge program 138 for ADW is shown in Appendix 1. A more detailed chart for preparing data gathered according to this invention for export to ADW or a similar tool is shown in Appendix 2. As noted in the program, the desired directory for the project is obtained and a parent link list, representing Process hierarchy, is obtained. The parent Process is assigned a "dummy" (or arbitrary) token which identifies it in terms that ADW recognizes for tokens. As noted previously, a 1000000000x corresponds to a token for an Object in ADW parlance, where "x" is a selectable digit. The parent token and name are then written to an OI.EXP file (10000) and the token plus description are written to a text file TI.EXP (30076). The file type designation corresponds to ADW conventions for providing file types. Associations between a Parent Process and another Process are assigned a token which is stored in an AI.EXP file (20034). The bridge program 138 then looks to Data Flows. An Object token is assigned to a Data Flow (if one is not already assigned) and the newly assigned token is written to an OI.EXP file (10008). The token and description are written to the text file. A "to or from" token is then assigned if not already done so, based on the input relating to destination or source provided by the users (see steps 1114 and 1124 of FIG. 9). "To" and "from" correspond to source and destination data entered at the analyst terminal 102. If the Object was identified as an External Agent or Data Store, it is given an Object type (10012). Otherwise, it is assumed to be a Process and is given an Object type (10000). The Association between the directional "to" or "from" Object and a Parent Process is assigned a token (if there is none) in a format recognizable by ADW; namely 2000000000x. If the Object was identified during data entry as an External Agent, the Association is given a type 20001; if a Data Store, then type 20006; and if a Process, then type 20034. New Association tokens are written to an Association export file AI.EXP. Tokens for various other Associations are assigned and written to the Association file with appropriate types. In the data gathering described above, components are identified as Entities and Attributes. The bridge program 138 gets Entities associated with a Data Flow and then assigns a token to each Entity that is not previously identified with a token. The token is of the form 1000000000x and is written into OI.EXP file (10007), with the description being entered into TI.EXP (30076). A token is assigned to the Association between the Entity and Data flow (2000000000x) and written into AI.EXP with a type 20041. Attributes are treated similarly. A token is provided for each Association between an Entity and an Attribute, and each Association between an Attribute and a Data flow. Maximum and minimum values, which were provided during data entry, are also written to the file. Further Information relating to data type is also written into the file. Data type includes a description of an Attribute. The bridge program 138, by assigning tokens and types to the data, generates files ADW can recognize. The generated files can be transferred, or exported, to ADW which can provide any of various diagrams that it is designed to prepare. Upon request from the analyst terminal 102, ADW can import files generated by the bridge program 138 to produce a decomposition diagram (such as FIG. 1) or a data flow diagram as is shown in FIG. 6. In FIG. 6, for Processes are shown, by way of example, for the present invention. In particular, Processes include: SET UP FRONT END FOR PROJECT, PRODUCE REPORTS, GATHER INFO, and FORMAT INFORMATION FOR ADW IMPORT. The data inputs to each Process are also identified. Another diagram relating to Entity relationships can also be generated. Such diagrams are known in the art. While the bridge program 138 described herein is directed to the ADW information engineering tool, other bridge programs may be implemented for other similar tools. The identification of types and the number of files in the encyclopedia may vary, but the required Information should remain substantially the same; namely, Entities, Attributes, External Agents, Data Flows, Parent Process groups, and Data Stores. Accordingly, while the bridge program 138 may differ for different tools, the Information gathering part of the invention and screens used in gathering Information should remain unchanged. In FIG. 7, a flowchart 700 is shown which follows steps performed when a project has been set up 702 and before the data generated and stored in the database 132 (of FIG. 1) is passed to the bridge program 138 (of FIG. 1). FIG. 7 shows one way in which the invention can be practiced. In the set-up step 702, the analyst at terminal 102 (of FIG. 1) identifies the project to be performed; identifies users than can participate in the project; and performs administrative tasks. Users log in and provide data concerning themselves and the project to be undertaken. Following the set-up, Information relating to REQUIREMENTS 704, PROCESS MODEL 706, or DATA MODEL 708 can be selected. The analyst terminal 102 enables one of the three options so that all users are entering data for the same data items. If REQUIREMENTS 704 is chosen, the users determine if they should be GATHERING REQUIREMENTS 710 or CATEGORIZE REQUIREMENTS 712. If the former, the user at each terminal 102 through 110 (of FIG. 1) can ENTER REQUIREMENTS 714. The users see a screen at their displays 112 through 120 (of FIG. 1) like that illustrated in FIG. 8. In entering requirements, users specify their needs for a software application being developed, a procedure being established, or other project. After all requirements have been entered, a review of the Requirements entered by all users can be selected by entering REQUIREMENTS, then REVIEW, then REQUIREMENTS on the screen shown in FIG. 5 or the users can CATEGORIZE them at step 712 by entering REQUIREMENTS, then SPECIFY, then CATEGORIES on the screen shown in FIG. 5. In the former case, during the review, the list of Requirements as it is updated is preferably displayed on the projector screen 142 (of FIG. 1) and can also be brought up on each user display 114 through 120 (of FIG. 1) by entering a REFRESH command shown on the screen of each user display 114 through 120 (of FIG. 1). In response to user proposals and consensus, changes to the Requirements can be entered at the analyst terminal 102 (of FIG. 1) as illustrated in step 716. The analyst terminal 102 (of FIG. 1) will have a screen including an option to request one of a variety of reports. Reports can include a listing of all Requirements and a listing of meeting participants. If there is to be a report (718), it is selected (720) and printed (722) by printer 134 (of FIG. 1). The session may terminate 726 or continue on to modelling a process and/or modelling data. In categorizing Requirements at step 712, a category type is entered (step 728) and described (step 730). Requirements are assigned to categories in step 732 by the analyst (as suggested by the notation (A)) based on user input. Once entered the categories may be reviewed starting at step 716. Referring to FIG. 9, the steps in modelling data are outlined. At step 902, Components are entered and described. An option is available to review the entered Components (step 904). In any event, the analyst, based on user comments, specifies Component type (step 906)--that is, whether the Component is an Entity (step 908) or Attribute (step 910). The users, prior to the data entry, are instructed as to the meaning of these terms if the terms are unfamiliar. If styled an Attribute, minimum and maximums and a maximum value are entered at steps 912, 914, and 916, respectively. These items indicate how often an item is expected to be seen or used in the task. If values are not entered, defaults are provided. All Components are defined as Entity or Attribute if they are to be exported to the computer-based information engineering tool 136 (of FIG. 1). After all Components have been selected (step 918), there is assignment of Attributes to Entities at the analyst terminal 102 in response to user comments (step 920). The results of specifying the Component types and of assigning Attributes to Entities are (at step 922) stored, for the project, in the database 132. If a report is desired (step 924), the appropriate report is selected (step 926) and printed (step 928). Activity may stop at that point, a new project may be entered into, or entered data can be revised by going back to the first step of FIG. 7. Referring again to FIG. 7, performing Process modelling at step 708 may be selected whether no data modelling was performed or after data modelling. To make that selection, the user enters PROCESSES, then SPECIFY, then PROCESSES at the screen FIG. 5 (which features the main menus). The screen in FIG. 10 then appears with boxes for name, description, and Data Flows of a new Process. Referring to FIG. 11, the user enters name and process description in steps 1102 and 1104, and then identifies data flow out (step 1106). For a Data Flow-out entry, screen FIG. 12 is displayed. A name is entered by the user onto screen FIG. 12 where a separate box for the name is included (step 1108). Components stored in the database are displayed on the user displays at step 1110 and, as users deem appropriate, additional Components are added (step 1112). A destination name and destination type are entered (step 1114) to define where the Data Flow is to go. In FIG. 12, for the data flow named "Vendor Record", there is a Component entitled "Vendor Region". The destination could be a Process, External Agent, or Data Store. Components associated with the Data Flow out should all be entered and specified, together with the above data (step 1115). At step 1116, a Parent Process group is selected for review. An appropriate screen is displayed when the user activates the ADD command on screen FIG. 10 after all Data Flow and Component Information is entered. A confirmation screen asks if the information is correct. The results are saved at step 1117 by entering an appropriate command at the analyst terminal 102 (of FIG. 1) The Data Flow-in procedure is similar to Data Flow-out and is shown in steps 1118 through 1128, except that the source rather than the destination of the Data Flow is sought. Associated Components then go through steps 1116 and 1117 enroute to step 1130. At step 1130, the entered Process model data can be reviewed. The review enables the users to propose modifications to the data entered. The entered data is preferably displayed on the projector screen 142 (of FIG. 1) and, upon user request, at the user terminal displays. Changes can only be entered at the analyst terminal 102. Starting at a screen FIG. 13, the users can propose changes based on Parent Process group. Referring to the sample data in FIG. 13, the Parent Process group "Order Equipment" includes a Process "Prepare Equipment Order". Other Processes in the group are shown as "Determine Inventory Needs" and "Get Vendor Information". By entering the command DETAILS, screen FIG. 14 is displayed which depict a Process in greater detail. Associated Data Flows, Data Flow types (that is, destination type or source type), and available Components are displayed. Based on user input, the displayed data may be modified or deleted at the analyst terminal 102 (of FIG. 1). By clicking a mouse (not shown) when pointing at the Data Flow named "Equipment Order" in FIG. 14, the screen of FIG. 15 is displayed. Modifications to the Data Flow can be effected at the analyst terminal 102 (of FIG. 1). If the DESCRIPTION button is entered at the screen of FIG. 15, the screen of FIG. 16 will appear to show whether a Component selected from either the Associated Component List or the Available Component List is an Entity, Attribute, or yet Unassigned. Referring again to FIG. 11, after editing Processes and Components thereof in step 1132, the results can be readied for export (step 1134). The analyst terminal 102 (of FIG. 1). The analyst terminal 102 (of FIG. 1) enters an input that directs the gathered data to the bridge program 138, which performs the appropriate conversion. If there is no Data flow-in (step 1118), the data already generated can be saved (step 1140). Step 1142 corresponds to returning to the initial step (and menu) of FIG. 7. Alternatively, if a report is desired (step 1144), the appropriate report is selected (step 1146) and printed (step 1148). Activity may stop at that point, a new project may be entered into, or entered data can be revised by going back to the first step of FIG. 7. The invention further includes a reverse bridge program (not shown) which can be used to take Information from a computer-based information engineering tool 138 and re-format it to be processed by the front-end of the present invention. In particular, Information would be transferred to appropriate tables in the centralized database 132 so that multiple users can enter further Information or be involved in the editing of the Information entered from the computer-based information engineering tool 138. The revised Information can then follow the steps set forth in the flow chart outlined in the above-discussed figures. While the invention has been described in terms of a preferred embodiment in a specific environment, those skilled in the art would recognize that the invention can be practiced, equivalently or with modification, within the spirit and scope of the appended claims. ##SPC1##
|
Same subclass Same class Consider this |
||||||||||