US5233513A: Business Modeling, Software Engineering and Prototyping Method and Apparatus

The present invention relates to modeling of businesses through the application of cognitive linguistic fundamentals and a microprocessor based engine for manipulating the data to create variable business models which are converted to application software for the business.

Programming engineering has evolved concurrently with hardware development in the computer industry. Unfortunately, the maturation process has not been equal and hardware sophistication has outpaced program engineering creating an ever increasing disparity where hardware is available to do the most sophisticated processes but the software is lagging or non-existent. To solve this dilemma, numerous attempts have been made to utilize a computer to create software. The prior art approach to computer generated software engineering has been a two pronged approach, that is, data flow modeling is created and then an entity relationship is developed based on that model. The entity relationship in the form of data is used to drive the design, that is, in the prior systems, the deduced data and only the data requirements or end result of the program are used to drive the code generator. This creates numerous problems with the detail processes and results in an unacceptable number of false starts through the trial and error process inherent in such systems.

The multitude of shortcomings inherent in the prior art are overcome by a merger of linguistic and cognitive science which have evolved to a system known as Metavision under the guidance of the patentee. The Metavision system presented herein encompasses the concept of cognitive modeling which creates a business model using a linguistic approach to create algorithms that generate programs in conjunction with expert systems. This is achieved through computational linguistic applications which create a four dimensional cognitive model. The dimensions are process, control, data and support (agents or instruments).

Three general principles underlie this system. They are, first the models need to be cognitive intuitive, that is they must be visualizations of thoughts. Second, the models must be complete, including all four dimensions, process, control, data and support. Finally, the models must have transformability.

The simplest model springs from a single sentence which according to linguistic principles includes a subject, verb and object. In cognitive modeling for computational linguistics applications, the subject is considered the source, the verb the path and the object the target. Thus from a simple sentence, a model and program may be developed. The source is the world knowledge. The path is the various avenues with which the data of the world knowledge flows and is manipulated to create the merged data or end result, the target.

The Metavision system with the aid of an analyst creates models based on world knowledge. These models are then converted to software designs via algorithms that include feedback to the models. Once the software design and models have satisfied all the feedback requirements to stabilize the software design, program code is generated to produce the desire application software based on the design.

The feedback process is enhanced by expert systems that perform diagnostics on the feedback to ensure that the input equals the reference or the end result is met with all of the required inputs modeled or accounted for.

A primary objective of the invention is to provide a method to establish project management controls.

Another objective is to provide a method to determine the scope, objectives and benefits for a business model of management controls.

Another objective is to provide a method to quantify scope limits for a business model of management controls.

Another objective is to provide a method to establish quality indicators for objectives for a business model of management controls.

Another objective is to provide a method to quantify benefits for a business model of management controls.

Another objective is to provide a method to develop a deliverables list for a business model of management controls.

Another objective is to provide a method develop a deliverables list for each phase for a business model of management controls.

Another objective is to provide a method to establish project reviews for a business model of management controls.

Another objective is to provide a method to establish the review and acceptance cycle for a business model of management controls.

Another objective is to provide a method to establish progress reporting for a business model of management controls.

Another objective is to provide a method to establish a change control procedure for a business model of management controls.

Another objective is to provide a method to develop a plan for a business model of management controls.

Another objective is to provide a method to develop a detailed plan for first phase of project for a business model of management controls.

Another objective is to provide a method to develop projects tasks for a business model of management controls.

Another objective is to provide a method to develop manpower loading for a business model of management controls.

Another objective is to provide a method to develop deliverable milestones for a business model of management controls.

Another objective is to provide a method to develop review and acceptance dates for a business model of management controls.

Another objective is to provide a method to develop hardware availability dates for a business model of management controls.

Another objective is to provide a method to develop resource budgets for a business model of management controls.

Another objective is to provide a method to develop a personnel budget for a business model of management controls.

Another objective is to provide a method to develop a facilities budget for a business model of management controls.

Another objective is to provide a method to develop a hardware budget for a business model of management controls.

Another objective is to provide a method to develop a software packages and tools budget for a business model of management controls.

Another objective is to provide a method to develop a money budget.

Another objective is to provide a method to develop interview lists and schedules for a business model of management controls.

Another objective is to provide a method to model current business practices for a business model of management controls.

Another objective is to provide a method to conduct interviews to build process models for a business model of management controls.

Another objective is to provide a method to create process models of line management and reporting job roles by function for a business model of management controls.

Another objective is to provide a method to create process models of higher management levels that line management reports to.

Another objective is to provide a method to create process models of automated computer or mechanical systems for a business of management controls.

A still further objective is to provide a method for creating a business model including process models containing the following information:

process transformations, process sequence and process descriptions;

supporting agents performing process and supporting instruments (tools) used in process;

people or organizational units (group, department, division etc.);

software program module or entire automated software system; computer hardware;

tools: manual tools or automated machines;

support quantification (agents and/or instruments used to perform process);

location of supporting resource and facilities information;

size of supporting resource: quantity of people/computers/tools performing process;

commitment of supporting resource: person/computer/tool hours spent on process per unit of calendar time;

cost of supporting resource: total of (person/computer/tool, unit cost).times.(resource commitment);

process efficiency: support time to perform job per 1 unit of output;

process throughput: calendar time to produce 1 unit of output;

process capacity: units of output=(resource commitment).times.(throughput);

RFP data consumed and produced by each process;

RFP transfer rules controlling transfers between processes: branching, start, stope and sequence;

RFP goals and objectives or policies and procedures controlling a process;

RFP quality standard (quality indicators) for controlling input data quality: edit rules and tables;

RFP quantification;

name, description and form or report number;

collect DBA information: sizing, volume, security, retention and source database names.

Another objective is to model interviewees' organization with an organization chart showing formal control structure for a business model.

Another objective is to collect example RFP's produced, consumed or controlling processes (reports, forms, databases, policies, procedures, goals and other packets of information) during interviews for a business model.

Another objective is to collect user issues and problems about a current business process model.

Another objective is to model automated systems database schemas (within project scope) for a business model.

Another objective is to load existing system database schemas as business information external schemas for a business model.

Another objective is to enter user supplied definitions and descriptions for database fields and record relationships for a business model.

Collect DBA information: sizing, volume, security, retention and source database names for a business model.

Another objective is to summarize and integrate process models, summarize RFPs and summarize supports for a business model.

Another objective is to summarize first line management and worker process models up into a complete functional processes (including both mgt. control and worker execution) by using 7+/-2 rule for each functional area interviewed. Balance summarized levels RFPs for a business model.

Another objective is to integrate summarized process models from different functional areas by summarizing them into larger complete functional processes with their controlling higher management control processes included. Observe the 7+/-2 rule if actual business follows the rule for a business model.

Another objective is to summarize input/output RFP's on higher level process diagrams by creating part-whole relationships, i.e. create summary data class RFPs on high level process diagrams that own detail RFPs on lower level process diagrams for a business model.

Another objective is to summarize controls RPFs: link high level management goal RFPs with their decomposition into sub-goal RFPs i.e., high level goals own the tactical sub-goals of lower level management for a business model.

Another objective is to summarize supports: higher organizational units own their parts, software systems own their programs, computers own their processors and machines own their parts for a business model.

Another objective is to review models with business units and modify for correctness.

A further objective is to determine changes necessary to optimize current business practice: measure process model.

Another objective is to review issues and problems lists to determine if indicated changes are desirable in a business model.

Another objective is to use models of good industry practice to measure difference with a current business model.

Another objective is to verify control RFPs exist and function for regulatory compliance within a business model.

Another objective is to verify data RFPs exist to feed any proposed increases in information systems within a business model.

Another objective is to verify corporate control stack works: high level goal RFPs own low level objective RFPs and feedback loops exist within a business model.

Another objective is to locate information bottlenecks using process throughput measures.

Another objective is to calculate differences between formal organizational controls (formal organization chart) and actual process control RFPs for a business model.

Another objective is to verify quality indicator RFPs exist for goals and objectives of a business model.

Another objective is to create proposed changes to a current business model.

Another objective is to identify specific changes required to improve deficiencies within a business model including changes and additions to information systems or manual processes.

Another objective is to quantify organizational impact (job function changes etc.) and political cost of a business model.

Another objective is to estimate development cost and development time for changes of a business model.

Another objective is to quantify benefits of changes to a business model.

Another objective is to review proposed changes, modify and obtain user concurrence of a business model.

Another objective is to develop information system architecture plan for proposed changes to a business model.

Another objective is to list new information required to implement changes in a business model.

Another objective is to list new sources and owners of information.

Another objective is to list information integration changes: organizational changes, database changes, software changes, communications changes and computer changes.

Another objective is to list known data quality problems.

Another objective is to develop migration plan to implement proposed changes and estimated schedule.

Another objective is to refine estimated development costs and development time for changes.

Another objective is to review proposed changes, modify and obtain user concurrence.

Another objective is to review a proposed desired business practices model, modify and obtain functional management concurrence.

Another objective is to prepare a desired business practices model presentation.

Another objective is to modify models based on executive management priorities.

Another objective is to prioritize approved projects within a business model of management controls.

Another objective is to develop technical designs to implement information system architecture plan within a business model.

another objective is to choose the best implementation design based on relational projects selection methodology; project phase duration less than nine months; cost effectiveness; availability of resources; people, hardware and software; hardware technology; flexibility: open or closed architecture.

Another objective is to develop implementation schedules for each project within a business model.

Another objective is to transform a business model into a software engineering model.

Another objective is to increase detail of business process model in the area to be improved, i.e. compose more detailed levels.

Another objective is to choose single function business processes in improvement area to automate

information creation, read (retrieval), update and delete;

information reporting;

information tracking;

information sharing or transmission;

scheduling;

decision making;

procedures within a business model of management controls.

Another objective is to add computer system specific processes, to a business model.

Another objective is to provide menus of system functions (these will select automatable manual processes and computer specific processes) to programs developed form a business model.

Another objective is to provide automated interfaces to other systems to programs developed from a business model.

Another objective is to provide system error reporting and error recovery to programs developed from a business model.

Another objective is to provide system security to programs developed from a business model.

Another objective is to provide audit log of system transactions to programs developed from a business model.

Another objective is to provide database archival and restoration to programs developed from a business model.

Another objective is to provide database maintenance reports to programs developed from a business model.

Another objective is to provide database optimization to programs developed from a business model.

Another objective is to provide database integrity rule enforcement to programs developed from a business model.

Another objective is to add system function selection transfer rules to menu processes to select all system functions within a business model.

Another objective is to specify transfer rules for all function selections of a business model.

Another objective is to model program logic as necessary for design of a business model.

A further objective is to create a question map to model business data relationships.

Another objective is to create a question map to model business data relationships from created simple sentences identifying the questions the user needs to answer.

Another objective is to create a question map to model business data relationships from grouped like sentences combining all similar information gathered from different sources.

Another objective is to create a question map to model business data relationships from developed population tables identifying role names and set up tables of instances.

Another objective is to create a question map to model business data relationships from uniqueness constraints which eliminate duplicates from tables and ensure the proper level of specificity.

Another objective is to create a question map to model business data relationships from multiple reference roles which determine the unique way to identify roles.

Another objective is to create a question map to model business data relationships from integrity constraints to keep logical consistency between statements about a system and reflect how the enterprise works.

Another objective is to group the question map into a conceptual schema to create the optimal database design.

Another objective is to model menus, screens and reports for use by programs developed from a business model.

Another objective is to specify fields for menu function selection for use by programs developed from a business model.

Another objective is to specify detailed hardware and packaged software requirements selection for use by programs developed from a business model.

Another objective is to produce database design documentation for use by programs developed from a business model.

Another objective is to generate application software system from SE models for use by programs developed from a business model.

A unique merger of linguistic and cognitive science has lead to a revolutionary realization integrating business management planing, business execution and management/operational software development. This is achieved through a microprocessor manipulated program which extracts the data inherent in the cognitive process leading to the spoken or written word and converts that data into business models capable of defining the interrelationship and functions of every member of a business from the director to the shipping clerks and floor sweepers. The thoroughness with which the program models the business and its operations is capitalised on by the program which uses the data it generated to produce application software program code capable of controlling and/or performing any and all functions of the business. A dynamic relationship is created between the business model and developed programs which allows prototyping of all business activities and the investigation of any eventuality followed by generation of new code and programs as needed to follow business growth or change. The system springs from The Connected Development Process of Four Dimensional Cognitive Modeling using the four basic linguistic entities of PROCESS and its attendant adjuncts of DATA, CONTROL and SUPPORT. To simplify the detailed description of this revolutionary approach, the forgoing concepts are embodied in the newly coined word "MetaVision", which shall be used through out this patent to convey the notion of the entity of the applicants invention.

The Metavision program embodies a general knowledge modeling system incorporating four Dimensional Cognitive Modeling and a built-in process for creating the models and automatically generating application software systems from them. The process is the Connected Development Process which requires the execution of the following nine basic steps:

Step 1. "WHAT-IS" Business users create a Metavision Process Model of their job or the jobs of a work group by providing Metavision with the individual workers job steps for each job, the information each worker needs to know to do the job and the information produced by doing the job. The goals and objectives of each job are also provided to the Metavision modeler. An organizational model is created by having users enter the names and titles of the individuals they report to. To enter job process and organization informations, a user will select Metavision prototype job processes and then respond to the Metavision dialogue that follows about the particulars of their job. This results in a Metavision "what-is" model of how the business currently operates.

Step 2. "WHAT-SHOULD-BE" The business user or the work group measure problems in the Metavision "what-is" process model of their jobs by running a variety of Metavision analysis reports that identify job problems like poor management control, lack of information needed to a job and information bottlenecks that slow job performance. For example, the formal organization chart created in the preceding step is matched against the actual organizational controls on the process models. The users improve their job process by changing the "what-is" model based on problems identified. These changes may include both improvements in the jobs performed by the workers and computer automation of some job steps. New reports, forms or packets of information may be required. They will be added together with the new processes that create them, during this step. If a job step is to be automated then it is tagged for further attention. This results in a Metavision "what-should-be" model.

As a result of a "what-should-be" model, a list of the new information in the proposed automated systems together with its sources and relationships to other information is automatically generated by Metavision. This is called and Information Systems Architecture and it will be used to help prioritize projects.

Step 3. "WHAT-TO-DO" the "what-to-do" model is approved or modified by management. In the case of automated systems, management will either decide to automate or not by removing or adding the automated process tags attached in the preceding step. The information systems architecture developed in the previous step is used to prioritize projects since it shows which automated systems must be done first to feed information to later systems. This produces a Metavision "what-to-do" model of specific projects (some of which will be automated systems) and project priorities that the organization has validated.

Step 4. "HOW-TO-DO-IT" In this step, the users will choose "how-to-do-it" by picking the kind of computer, computer language and database system that the automated system will be generated into. This is done by making the appropriate selections from the Metavision menus.

Step 5. "SHOULD-BE-SOFTWARE-PROCESS-MODEL" The next project from "what-to-do" list is selected and the job steps to be automated are composed into greater detail until each job step is at a single function level of detail. Examples of single function job steps are report preparation or creation of new information. A business user does this by selecting Metavision prototype single function job processes and then responding to the Metavision dialogue that follows about the particulars of their job.

The user next adds the extra processes required by a well designed computer system, but that would not otherwise be a part of the business users job such as database reorganization and password security. Menu selections processes are not added at this stage, but in the next step. These, like prototypical job processes, can be selected from a list. However, the Metavision product will provide suggested selections if asked.

Step 6. "SHOULD-BE-CONTROL-LOGIC-MODEL" All the single function processes that will be automated must now be linked to menus that enable a system user to select them. The Metavision product can generate a default menu selection system or the business user can create new selection processes by selecting prototype menu selection processes from the Metavision product process option list. These processes are interconnected with control RFP arrows that contain the transfer of control rules.

Step 7. QUESTION MAP USER RFPs During this step a complete three schema data model for all programs, screens, menus, reports, databases and inter-programs transfers of data is automatically generated from the set of questions that a business user requires the information system to answer. These questions are transformed into declarative sentences and entered, in English, into the Metavision product. They are then parsed into a fifth normal form data model.

More sentences instances of the central question sentences are now collected from a business user. These instances are used by the Metavision product to develop a model of permissible value ranges for the subjects and objects in sentences. The Metavision product also uses them to automatically generate test data sets, record population control files, table validations and update edit rules.

another dialogue with the business user now takes place about how the user uniquely identifies the subjects and objects in the central question sentences. The business user must also engage in a dialogue about references to information shared between two or more question sentences. The answers to these questions are used by the Metavision product to calculate database relations, indexes, keys, navigational paths and referential integrity constraints. The product also uses them to calculate report or screen root files and relational updaters.

After these calculations are complete the Metavision product automatically generates a third normal form logical database design and corresponding third normal for external (Physical) database structure.

Step 8. MODEL, MENUS, SCREENS AND REPORT RFPs Select and interface standard and the hardware and software configurations to support the selected interface. Based on the specified interface standard, the screen is painted by selecting the database fields from a picture of the database.

Step 9. GENERATE SYSTEM Select processes to be automated from the list and the code will be automatically generated.

The nine steps outlined above are preformed by individuals under the direction of a master plan provided by a book of directions or a MetaVision modeler and entails the running of the MetaVision program to process inputs from the individuals. To simplify the detailed explanation of MetaVision, the steps are expanded first as the detailed steps preformed to produce the input to the program and then as the steps and routines performed by the program.

The standards of legibility require that some diagrams be divided into a plurality of sheets. To maintain continuity, all of the sheets which comprise a single diagram are given the same figure number with a letter suffix to identify individual sheets. Key letters are provided on individual sheets to assist in joining the sheets that comprise a single diagram. In the "Brief Description Of The Drawings" which follows, only the basic figure number, without letter suffixes, is provided to indicate substance of the diagram. Continuity is maintained between the plural sheets for a single diagram by "Joins Figure" notations where applicable.

FIGS. 1A, 1B and 1C make up for FIG. 1 which is a functional diagram of the Building Management Systems.

FIGS. 2A, 2B, 2C, 2D and 2E make up for FIG. 2 which is a functional diagram of Business Modeling steps.

FIGS. 3A, 3B, 3C and 3D make up for FIG. 3 which is a functional diagram of the Establish Project Management Controls steps.

FIGS. 4A and 4B make up for FIG. 4 which is a functional diagram of the Model Business What Is steps.

FIGS. 5A and 5B make up for FIG. 5 which is a functional diagram of the Model Business What Should Be steps.

FIG. 6 is a functional diagram of the Decide What to Do steps.

FIG. 7 is a functional diagram of the Develop How To Do It steps.

FIG. 8 is a functional diagram of the Develop Software SHOULD-BE Process Model steps.

FIGS. 9A and 9B make up for FIG. 9 which is a functional diagram of the Model Current Business Practices steps.

FIGS. 10A and 10B make up for FIG. 10 which is a functional diagram of the Prototyping steps.

FIG. 11 is a functional diagram of the Develop File Design steps.

FIGS. 12A and 12B make up for FIG. 12 which is a functional diagram of the Model Control Logic steps.

FIG. 13 is a functional diagram of the Design Screens & Reports steps.

FIGS. 14A and 14B make up for FIG. 14 which is a functional diagram of the Question Map RFP's steps.

FIG. 15 is a functional diagram of the Create External Schema.

FIG. 16 is a functional diagram of the Input screen report layout steps.

FIG. 17 is a functional diagram of the Create Simple Sentences steps.

FIG. 18 is a functional diagram of the Group Like Sentences Together steps.

FIGS. 19A and 19B make up for FIG. 19 which is a functional diagram of the Develop Population Tables steps.

FIGS. 20A and 20B make up for FIG. 20 which is a functional diagram of the Add Uniqueness Constraints steps.

FIG. 21 is a functional diagram of the Identify Multiple Reference Roles steps.

FIG. 22 is a functional diagram of the Add Integrity Constraints steps.

FIG. 23 is a functional diagram of the Write/Edit Sentences from RFP's steps.

FIG. 24 is the Add Project data flow diagram.

FIGS. 25A, 25B and 25C make up for FIG. 25 which is the Control Diagram DIAGRAM data flow diagram.

FIG. 26 is the Control Diagram CREATE data flow diagram.

FIGS. 27A, 27B and 27C make up for FIG. 27 which is the Conceptual Scheme DIAGRAM data flow diagram.

FIGS. 28A, 28B and 28C make up for FIG. 28 which is the Conceptual Schema CREATE data flow diagram.

FIGS. 29A, 29B and 29C make up for FIG. 29 which is the External Schema DIAGRAM data flow diagram.

FIGS. 30A, 30B and 30C make up for FIG. 30 which is the External Schema CREATE data flow diagram.

FIGS. 31A, 31B and 31C make up for FIG. 31 which is the Organization Chart DIAGRAM data flow diagram.

FIGS. 32A and 32B make up for FIG. 32 which is the Organization Chart CREATE data flow diagram.

FIGS. 33A, 33B and 33C make up for FIG. 33 which is the Process Diagram DIAGRAM data flow diagram.

FIGS. 34A and 34B make up for FIG. 34 which is the Process Diagram CREATE data flow diagram.

FIGS. 35A, 35B and 35C make up for FIG. 35 which is the Question Map DIAGRAM data flow diagram.

FIGS. 36A, 36B and 36C make up for FIG. 36 which is the Question Map CREATE data flow diagram.

FIGS. 37A, 37B and 37C make up for FIG. 37 which is the Report Design DIAGRAM data flow diagram.

FIGS. 38A and 38B make up for FIG. 38 which is the Report Design CREATE data flow diagram.

FIGS. 39A, 39B and 39C make up for FIG. 39 which is the Screen Design DIAGRAM data flow diagram.

FIG. 40 is the Screen Design CREATE data flow diagram.

FIG. 41 is the Move UP A Level data flow diagram.

FIGS. 42A and 42B make up for FIG. 42 which is the Move DOWN A Level data flow diagram.

FIGS. 43A and 43B make up for FIG. 43 which is the Create Process Box data flow diagram.

FIGS. 44A and 44B make up for FIG. 44 which is the Create Data Source/Sink data flow diagram.

FIGS. 45A and 45B make up for FIG. 45 which is the Create RFP (Arrow) data flow diagram.

FIGS. 46A and 46B make up for FIG. 46 which is the Create Fan data flow diagram.

FIG. 47 is the Create Free Text data flow diagram.

FIG. 48 is the Create Support Data data flow diagram.

FIGS. 49A, 49B and 49C make up for FIG. 49 which is the Open NEW Report data flow diagram.

FIGS. 50A, 50B and 50C make up for FIG. 50 which is the Open NEW Screen data flow diagram.

FIG. 51 is the Enter RFP Data data flow diagram.

FIGS. 52A and 52B make up for FIG. 52 which is the Control What If data flow diagram.

FIGS. 53A and 53B make up for FIG. 53 which is the Data What If data flow diagram.

FIG. 54 is the Process What If data flow diagram.

FIGS. 55A and 55B make up for FIG. 55 which is the Support What If data flow diagram.

FIG. 56 is the Grouping data flow diagram.

FIG. 57 is the Hypertext Processing data flow diagram.

FIGS. 58A, 58B, 58C, 58D, 58E, 58F, 58G and 58H make up for FIG. 58 which illustrates the Merge processes for two copies of a file, one in the source directory and one in the destination directory.

FIGS. 59A and 59B make up for FIG. 59 which is the Constraint Validation data flow diagram.

FIG. 60 is the Process Diagram Hypertext data flow diagram

FIG. 61 is the Organization Chart Hypertext data flow diagram.

FIG. 62 is the Question Map Hypertext data flow diagram

FIG. 63 is the Conceptual Schema Hypertext data flow diagram

FIG. 64 is the data flow diagram.

FIG. 65 is the Report Hypertext data flow diagram

FIG. 66 is the Screen Hypertext data flow diagram

FIG. 67 is the Matrix Diagrams data flow diagram

FIG. 68 is the Process/RFP Matrix Diagram data flow diagram.

FIG. 69 is the DSS/RFP Matrix Diagram data flow diagram.

FIG. 70 is the Process/Control RFP Matrix Diagram data flow diagram.

FIG. 71 is the Process/Support Matrix Diagram data flow diagram.

FIG. 72 is the Support/RFP Matrix Diagram data flow diagram.

FIG. 73 is the COBOL FD Documentation data flow diagram.

FIG. 74 is the Trangen Documentation data flow diagram.

A unique merger of linguistic and cognitive science has lead to a revolutionary realization integrating business management planing, business execution and management/operational software development. This is achieved through a microprocessor manipulated program which extracts the data inherent in the cognitive process leading to the spoken or written word and converts that data into business models capable of defining the interrelationship and functions of every member of a business from the director to the shipping clerks and floor sweepers. The thoroughness with which the program models the business and its operations is capitalized on by the program which uses the data it generated to produce application software program code capable of controlling and/or performing any and all functions of the business. A dynamic relationship is created between the business model and developed programs which allows prototyping of all business activities and the investigation of any eventuality followed by generation of new code and programs as needed to follow business growth or change. The system springs from The Connected Development Process of Four Dimensional Cognitive Modeling using the four basic linguistic entities of PROCESS and its attendant adjuncts of DATA, CONTROL and SUPPORT. To simplify the detailed description of this revolutionary approach, the forgoing concepts are embodied in the newly coined word "MetaVision", which shall be used through out this patent to convey the notion of the entity of the applicants invention.