WO2001079996A1 - Method for extracting business rules - Google Patents

Abstract

An object-oriented and object-based concept, method and technique for extracting, netting and aggregating business rules from business application system. The source code of the application system components (e.g. programs, screen definitions, table definitions, database definitions) is parsed to populate specific OO-models. These populated models are then evaluated and extended according to a specific inside-out rule-tracing algorithm. This algorithm is based on the de-facto standard and practical definition of a business rule. A business rule is the combination of conditional and imperative source code commands that affect a change on a business data entity. The extracted rule is presented as hyper-graph (with click-able objects / nodes for activating other detailed analysis graphs or reports), as report or as interface to other workbenches. The innovative inside-out tracing algorithm extracts complete business rule chains (imperative and conditional logic) for a given application system. The tracing is performed over program boundaries (call structures).

Description

Method for extracting business rules

The invention relates to a method for extracting business rules from the system- component-sourcecode of business application systems.

Background Domain

This invention relates to methodologies and techniques for reverse engineering of computer based information systems and, more particularly, to a method and technique for extracting business rules out of computer programs in so called 'legacy systems'. Rapidly changing business requirements are increasing the demands on information technology (IT) organisations. Mergers, acquisitions, regulatory changes, globalization and political evolution drive these dynamics and the need to concurrently maintain, improve and evolve information systems. As companies put year 2000-related issues behind them, pent up demand for new technology, e-commerce, functional integration and other changes are now on the agenda.

IT must respond to these demands with new and unique strategies that do not ignore our reliance on the large installed base of legacy data and application systems. One goal is to improve our collective understanding of these systems in order to maintain them more effectively, extract knowledge from them as needed and free subject matter experts for new design tasks. A second goal is to streamline, migrate and ultimately transform critical business knowledge in these systems into new design and delivery paradigms. These new paradigms include deployment of e-commerce solutions and a shift to component-based development and systems management.

Business Rule Extraction

Business rule extraction is the process of identifying implementation independent business logic that comprises the basic essence of a business application. Business logic is typically less than 20% of a given application program or system and is characterized by a combination of conditional and imperative source code commands that affect a change on a business data entity.

One element of business rule identification and extraction is the rationalization of data elements within a repository. This prerequisite to rule extraction reduces redundant data definitions and subordinate data elements down to a working subset. Rationalized data facilitates the rule extraction process because all logic linked to a given business entity can be captured and assimilated as a single business rule. Business rule extraction plays a major role in migration and e-business projects.

Conversion & e-Business Migration

One of the challenges in an e-business initiative is to understand how current functions within the enterprise have been implemented. Once found analysts must either interface with or migrate these functions to into e-business environments. In an e-business project, an input screen may be the starting point for creating a web-based function that performs a credit clearing function. If an analyst can identify a record defining the credit card processing screen in the legacy application, a business rules extraction workbench should be used to trace all of the logic linked to this input record and help isolate credit clearing processing logic. Analysts could then use the workbench to isolate a specific subset of rules linked, for example, to a credit card clearing function, and then reuse this rule in an e-business application. Analysts could apply the business rule analysis capabilities to examine and consolidate redundantly defined business rules linked to this credit card function. The workbench should also identify all of the data elements, records, files and related rules linked to this initial rule by allowing an analyst to trace related data definitions and logic paths leading to or from the logic that defined the initial rule.

There is also a demand for other strategic architecture initiatives. To identify and segregate common or related system functionality, which could then be used to migrate to a new system in a distributed or web-based environment. As part of this process, project teams may begin populating component-based development libraries. This would involve grouping common business rules under a set of high-level functions or framework, consolidating these rules into non-redundant groupings and allowing analysts to use these components as building blocks for future development and migration projects.

Related Technologies System Transformation

Whether driven by redesigned business processes, cost issues or other factors, IS has been chartered with providing organizations a competitive edge through information technology. The objective ofthe majority of these systems "redevelopment" efforts is to replace, integrate or somehow accommodate legacy systems to more effectively meet business goals. As a result of this directive, improved understanding of legacy systems, through business rule capture, is becoming an increasingly common goal.

Many organizations have found that the IS department actually contains a company's functional expertise. But over time, that expertise has been lost. When companies make the decision to move to distributed systems or other technological environments, they need to determine what functions were currently being performed and what functions needed to be added. Business rule extraction is the way to determine what a company has before attempting to move forward."

Many companies are involved with a large number of business process reengineering (BPR) efforts. BPR, in the absence of systems transformation, yields only short term relief. When redesigning business processes, it is critical to realign application system functions at the same time."

Systems transformation normally involves a mix of model driven and code based redesign and reuse along with adding new functions. In some cases packages provide baseline functionality. In other situations in-house development leads the way.

The use of templates, in the form of reusable design models is growing. But while templates, packages and other reusable components streamline design efforts, business rules embedded in legacy systems still provide that "competitive edge".

These rules are "locked up" in legacy systems and efforts to re-specify them in today's high pressure, downsized environments is a costly, time consuming endeavour. Legacy rule capture and reuse has been described as the "missing link" in the systems transformation process.

Slicing of Rules

Rule isolation and extraction is performed by tracing logic paths based on various selection criteria. This includes logic leading to the creation of a given output variable, logic linked to some type of conditional and logic associated with a given input transaction type. Analysts must review a rule after extraction in order to use it as is, extract again based on a different criteria or subset the extracted rule further. These techniques are somewhat tool dependent, but it is important to establish an initial extraction crite- ria regardless ofthe tool being applied.

Required rule extraction tool criteria minimally includes an ability to "slice" out a rule based on a specified selection criteria.

Since business rules do not limit themselves to the confines of a source program, extraction tools must be able to analyze logic across program boundaries. Beyond that, a rule extraction tool should be able to bypass or highlight implementation dependent logic, store an extracted rule, further extract against a previously extracted rule, display a rule in varying formats to promote understandability and transform an extracted rule into a reusable format.

Object ofthe invention The present invention has the object to enable complete and fully automated excavation of conditional and imperative logic for each external defined/known data field in each program of a legacy system (e.g. Cobol, PL/1, RPG, Natural, ADS, etc.). The present invention has the further object to enable linking of these basic rules across program boundaries (call structures).

The present invention has the further object to enable a high degree of automated elimination of implementation logic (e.g. program flow control logic).

The present invention has as other object to enable a powerful interactive elimi- nation or repair of logic flaws and inconsistencies.

The present invention has also the object to enable an effective gathering of all the basic rules for a given business entity attribute by tracing all its synonyms in data stores and in programs.

Definition ofthe invention

The invention provides a method for extracting business rules from the system- component-sourcecode of business application systems comprising the steps of: a) parsing said sourcecode by means of a parser and generating thereby objects representing entities, sub-entities and characteristics of the system and the system-com- ponents ofthe system which_are stored in an object oriented repository, b) applying an algorithm for extracting business rules to be expressed in externally defined or known arguments, which algorithm can be subdivided into: bl ) determination of data-elements which represent business entity attributes, b2) determination of rule-operation objects for the determined external data- element objects, said rule-operation objects representing the imperative logic for the subject business entity attribute b3) creating a special rule-argument object for each relevant argument, the arguments being classified as value access argument, constant field argument, local data argument or external data argument, whereby in case of local data objects the algorithm is applied repetitive until no new local data objects are found b4) evaluating for each determined rule-operation object the existence of a valid constrain, the relevant arguments of a constrain argument object being classified as value access argument, count field argument, constant field argument, local data argument or external data argument, whereby in case of local data objects the algorithm is applied repetitive until no new local data objects are found.

Figures

The invention will be described in more detail with reference to the attached drawings. Figure 1 illustrates three basic operations that are no part, part of 1 or part of 2 constrain blocks.

Figure. 2 illustrates the general architecture necessary for performing the method according to the invention.

Figure 3 shows two windows with information of a part of an implemented and populated model.

Figure 4 illustrates the use of hypergraph technology.

Figure 5 illustrates an overall object model structure.

Figure 6 illustrates the statement object hierarchy.

Figure 7 illustrates the arguments object hierarchy. Figure 8 illustrates the statement block object hierarchy.

Figure 9 illustrates the data element object hierarchy.

Figure 10 illustrates the data record object hierarchy.

Figure 11 shows the major steps, flow and iterations ofthe tracing algorithm. Figure 12 illustrates the determination of data elements. Figure 13 shows special object classes and their relationships. Figure 14 shows an overall flow ofthe business rules extraction algorithm. Figure 15 shows the basic object structure for rule operations and rule constrains. Figure 16 shows special object classes and their relationships.

Figure 17 shows an overall flow ofthe business rules extraction algorithm. Figure 18 illustrates the control block structure.

Figure 19 shows a simplified example of an object structure for a complete business rule. Figure 20 illustrates program to program linking.

Figure 21 illustrates a prototype example of a hypergraph based work branch. Figure 22 shows a prototype implementation of a business rules reporting work branch.

Detailed description with reference to the fi ures

General

The present invention is based on the following concept:

• A business rule for a given business entity attribute is implemented in computer programs by means of conditional and imperative logic and related arguments. • A rule is only meaningful and useful (for further aggregation or evaluation) when all the arguments of this conditional and imperative logic are expressed in terms of (other) business entity attributes (or constant fields and value accesses).

• Arguments in terms of local variables (interim results, work-area, etc.) will be further traced for their imperative and conditional logic until all arguments are ex- pressed in terms of business entity attributes (or constant fields and value accesses).

• Business entity attributes are maintained as persistent data, as fields or columns in file-records, database-records or RDB-table-rows. Other relevant business entity attributes are only present in the system as input or output fields in print- or screen- records or other communication records. • Operations on or with these business entity attributes can be performed directly with the above described fields, or indirectly with their synonyms.

• There are basically two types of field-synonyms in programs: - Re-definitions or re-naming constructs Indirect structure / record definitions, where the input/output record doesn't contain field definitions but where a local defined work-record with field definitions is completely moved into / from that input / output record.

• Determination of these synonyms is key for a complete excavation of the business rules for a given business entity attribute.

• The completeness and feasibility of this rules excavation approach is guaranteed by defining a basic rule as all the imperative and conditional logic that determines the value / content of a business entity attribute field. Tracing of the logic until all arguments are expressed in terms of (other) business entity attribute fields (or con- stant fields and value accesses) results in practical and effective boundaries of this rules excavation.

• Fields / records for inter-program communication (call structure) are to be treated as business entity attribute fields. Rules for this type of fields will later be connected /added to the rules-chain ofthe target business entity attribute field.

Key Definitions Rules

Rules are expressed in imperative and conditional logic where all the arguments are expressed in terms of external defined fields (operands) and local constants or value accesses only

Local fields / results are traced further until they are expressed in additional imperative and conditional logic where all arguments are expressed in terms of external defined fields (operands) and local constants or value accesses only Business entity attribute fields or external defined fields include re-definitions, re-names but also hidden local definitions and synonyms (e.g. move local structure to output-record).

Initially, fields / records for inter-program communication (call structure) are to be treated as business entity attribute fields or external defined fields.

Basic operations (imperative logic)

Basic operations or instructions are the operations that establish the new (create, modify or delete) values for the business entity attributes. These operations are the ba- sic elements of a business rule. Basic operations can be simple and straightforward or complex and compounded with constrain operators (conditional logic).

Basic operations may use arguments. These arguments are constants, local variables, value accesses or external defined variables.

Secondary operations (imperative logic)

Secondary operations or instructions are the operations that establish the values for the local variables (used as arguments in primary or secondary operations or constrain operations). These operations are also part of a business rule. Secondary opera- tions can be simple and straightforward or complex and compounded with constrain operators (conditional logic).

Secondary operations may use arguments. These arguments are constants, local variables, value accesses or external defined variables.

Transfer operations (imperative logic)

Transfer operations or instructions are the operations that directly or indirectly

'place' the new (create, modify or delete) values into the business entity attributes.

There can be a chain of these transfer operations (I/O, move or assign, re-definitions, re-names, etc.) There are two types of transfer operations:

• Assignments as basic or secondary operation of a business rule with or without constrain operators (conditional logic)

• Explicit (move) or implicit (re-defined) transfer of values to business entity attributes. Constrain operators (conditions) for this type of transfer are per definition 'program flow control operators' and therefor not part of a business rule.

Constrain operations (conditional logic)

Constrain operations or instructions are instructions that directly control the execution of basic operations, secondary operations, other constrain operations and as- signment transfer operations. As such, constrain operators are the other basic elements of a business rule. Constrain operations can be simple and straightforward or complex and compounded with basic and secondary operators for their arguments. Constrain operations may use arguments. These arguments are constants, count fields, local variables, value accesses or external defined variables.

Constrain blocks (conditional logic) Constrain blocks are the conditioned branches of constrain operations. An operation / instruction can be part of one block only. If a basic / secondary / assignment- transfer operation is part of a constrain block, then this constrain block is part of the business rule.

A constrain operation can also be part of a constrain block. In that case, the busi- ness rule will contain nested constrain blocks.

Only the constrain block with the operation is relevant for the business rule. Neither the other constrain branches, nor the other statements in all constrain branches are of interest for the business rule.

Figure 1 shows three basic operations that are no part, part of one or part of two constrain blocks. The legends in figure 1 have the following meaning: Stmt = statement

If = if

Constr = constrain BO Stmt = basic operation statement

Control Blocks

Control blocks are distinct parts of a program with controllable execution. Examples are paragraphs in Cobol and procedures in other languages.

Execution of a control block can be conditional. If a business rule operation or constrain is part of a conditional control block, then the constrain block of that condition is also part ofthe business rule.

Key Technology General The implementation of the present invention is based on innovative new technology. This new technology has two major dimensions:

• Specific OO-models for business rules extraction

• Specific extraction algorithms This new technology is combined with and embedded by further non-published technology which for evaluation ofthe present invention.

Embedding Technology

The Architecture as illustrated in figure 2 has evolved in several well-separated components. This has ensured that complexity has become manageable by breaking it down in different components. Any new analysis engine can make use of the same parsers and language models. Components can be re-used and extended without having to change other components. For this purpose Object Oriented concepts are applied.

Language Interface and Language Model

For each programming language a Language Interface and a Language Model have been developed. The Language Interface parses the source code, applying the language recognition rules for that language. During parsing the objects are generated according to the Language Model. The objects are stored in the Object-Oriented Repository.

Although the Language Interfaces and Models differ for each supported language, the various dialects within a language (i.e. for COBOL: COBOL-I, COBOL-

II, IBM-MNS, BULL, Tandem, etc.) share the same Language Interface and Model. Additionally, several plug-in parsers may exist (e.g. for DB2 SQL), to allow parsing of embedded languages.

The Language Models are the 'blue-prints' for populating the Cosmos/ES Repository.

The Language Models are fine grained and represent all the required information about the system components (attributes and behaviour, semantics and syntax).

The Object Models are designed to maximize the ability of, and the flexibility for the applications.

Effective OO-modelling requires professional implementation of generalization / specialization constructs.

Model Objectives

The high level of detail needed by the Applications requires sophisticated storage mechanisms in the Repository. Relational databases provide insufficient mechanisms to efficiently store, retrieve and process complex object structures.

The Repository is an object base that allows the storage of very large collections of interrelated objects. These objects represent entities from the software systems like programs, statements, data definitions, etc.

Model Characteristics

The following statistics show the granularity ofthe Language Models: ^■ COBOL Language Model 40 super object classes - 600 object types 4000 attributes 2500 link-attributes (relationships between object-types)

Model Example Figure 3 shows two windows with information of a part of an implemented and populated model.

The front window shows a part of the object hierarchy for the super-class 'statement'. This selection indicates the types of objects that are specifically designed to enable the required capabilities and flexibility for the applications. The second window shows the attribute values and object-link-references of a particular move statement.

Hyper-graph Interaction

The products apply preferably hyper-graph technology. Hyper-graphs are even more powerful than hypertext applications. A hyper-graph enables a real structured walkthrough of complex systems at an effective aggregation level.

As illustrated in figure 4 the objects contain specific attributes (e.g. link- attributes) for composing powerful graphs. They also contain specific attributes that enable effective hyper-graph applications like member/parent relationships for data- structure graphs and line-no attributes for source-code views. Essential Embedding Technology

The following subjects are regarded as essential embedding technology for the present invention and therefor part of this patent request. Overall Object Model Structure

The total system-model as illustrated in figure 5 consists of an hierarchy of system-component-models. Each system-component-model can be used alone or in rela- tion with other system-component-models. The relationships between the system-component-models are maintained in an overall system-model.

This architecture has several advantages:

• There are no limits to the size ofthe information-system to be analyzed.

• Updates to the system-model are limited to updates of the respective system-com- ponent-models and the link-step to the overall-system-model.

Populated system-component-models consist of an object-model-definition part and a so-called EDT (Extended Descriptor Tree) with all the actual objects and relationships.

For analysis or evaluation of a system-component, the complete EDT, with the accompanying model-description, is placed in internal memory. This approach gives another major performance advantage.

Statement Object Hierarchy

Figure 6 shows an essential part of the applied object hierarchy for program statements. The obtained hierarchy is based on specific generalization / specialization principles to enable precise but fast analysis of large and complex systems / programs.

Essential attributes

The following attributes (for most of the shown object-classes) are regarded as essential for the present invention:

• source_file: for reports and hyper-graphs of business-rules

• lineno: idem

• end lineno: idem

• col: idem • end col: idem

• arguments: relation to data-element-objects, expressions and value-accesses

• block: e.g. for determination of constrain/condition-blocks

• paragraph: e.g. for determination of program-control-blocks Argument Object Hierarchy

Figure 7 shows an essential part of the applied object hierarchy for statement-arguments. Arguments are an artificial/conceptual layer between statements and the data used by these statements. The obtained hierarchy is based on specific generalization / specialization principles to enable precise but fast analysis of large and complex systems / programs.

Essential attributes The following attributes (for most ofthe shown object-classes) are regarded as essential for the present invention:

• source_file: for reports and hyper-graphs of business-rules

• lineno: idem

• end_lineno: idem • col: idem

• end_col: idem

• arguments: e.g. arguments of an expression-argument

• statement: relates to the parent-statement object

For Value- Access Arguments also:

• name: for reports and hyper-graphs of business-rules

• phys_length: for tracing and evaluation of infections

• picture: for tracing and evaluation of infections and for reports and hyper- graphs of business-rules • value: for reports and hyper-graphs of business-rules

Statement_Block Object Hierarchy

Figure 8 shows an essential part of the applied object hierarchy for program- statement-blocks. Execution of a statement-block can be conditional. These conditions may be part of business-rules. The obtained hierarchy is based on specific generalization / specialization principles to enable precise but fast analysis of large and complex systems / programs.

The following attributes (for most of the shown object-classes) are regarded as essential for the present invention:

Essential attributes source_file:for reports and hyper-graphs of business-rules

- lineno: idem

- end_lineno: idem

- col: idem

- end_col: idem

- name: for reports and hyper-graphs of business-rules - statement: relates to the statement-object that controls execution statements: relate to the statements contained in the statement block

Data-Element Object Hierarchy

Figure 9 shows an essential part ofthe applied object hierarchy for data-elements.

The obtained hierarchy is based on specific generalization / specialization principles to enable precise but fast analysis of large and complex systems / programs.

The following attributes (for most of the shown object-classes) are regarded as essential for the present invention:

Essential attributes source file: for reports and hyper-graphs of business-rules lineno: idem end_lineno: idem col: idem end_col: idem name: idem parent: relates to the parent data-element in the structure members: relates to the component data-elements in the structure phys_length: for tracing and evaluation of infections (synonym-analysis) phys_offset: for tracing and evaluation of infections (synonym-analysis) picture: for reports and hyper-graphs of business-rules references: relate to the (statement)-arguments (usage of data-element) redefined_by: relates to the redefining data-element object Data_Record Object Hierarchy

Figure 10 shows an essential part of the applied object hierarchy for data-records. The obtained hierarchy is based on specific generalization / specialization principles to enable precise but fast analysis of large and complex systems / programs. The following attributes (for most of the shown object-classes) are regarded as essential for the present invention: Essential attributes

- source_file: for reports and hyper-graphs of business-rules

- lineno: idem - end_lineno: idem

- col: idem

- end_col: idem

- name: idem

- phys_length: for tracing and evaluation of infections (synonym-analysis) - phys_offset: for tracing and evaluation of infections (synonym-analysis)

- references: relate to the (statement)-arguments (usage of data-record)

Business Rules Extraction Algorithm General The business rules extraction algorithm of the present invention is based on the innovative inside-out tracing concept.

Current / other extraction approaches are bound to the program flow and structure and therefor in essence a top-down approach.

The present invention utilizes a specific and effective object model of the subject program. This model enables an effective and efficient inside-out approach, where the subject external data elements (business entity attributes) are the starting points for a precise and complete search for all its business rule components (imperative and conditional logic).

Figure 11 shows the major steps, flow and iterations of this inside-out tracing algorithm.

Each step is explained in more detail, together with the relevant sub-set of the special designed object model. Object-model for business rules extraction

External Data Determination

The business rules extraction algorithm starts with the determination of data-elements (data-items and data-structures) which represent business entity attributes. As illustrated in figure 12 the first category contains the data-elements of external records (file, database, RDB-tables, print, screens, etc.). Re-definitions and re-named fields are included. Also the data-elements of inter-program communication records

(link-records) are subject for this category.

The second category contains the data-elements of internal records, which are moved from external input-records. This category represents substitutes or synonyms for external input data-elements (Forward-Trace-Records).

The third category contains the data-elements of internal records, which are moved to external output-records. This category represents substitutes or synonyms for external output data-elements (Backward-Trace-Records). As a result of this determination activity, four special sub-classes are added (and populated) to the object model:

External_Data_Element: with link-attribute to External_ Record object or link-attribute to Ftrace / Btrace_Record object

Ftrace_Record: with link-attribute to External_Record object and link-attribute to member External_Data_Element objects

Btrace_Record: with link-attribute to External_Record object and link-attribute to member External_Data_Element objects

External_Record: with link-attribute to member External_Data_Element objects or member Ftrace / Btrace_Record objects. The determination of External Record objects is performed by evaluation of the record classes and by evaluation of read / write / update / display references in the original object model (see embedding technology).

The determination of Btrace / Ftrace_Record objects is performed by evaluation of the arguments of Move_Statement objects from / to External_Record objects. The inhered attributes 'Physical_Length' and 'Physical_Offset' are key for the correct and complete tracing of these type of records.

Basic Operations External Data The second step in the business rules extraction algorithm is the determination of Rule_Operation objects for the determined External_Data_Element objects. Rule_Operation objects represent the imperative logic for the subject business entity attribute. Rule_Operation objects are determined by evaluation of the references of the Exter- nal_Data_Element objects. For each reference, where the subject Exter- nal_Data_Element object is used as a result-field of an appropriate operation / instruction (like add, multiply, subtract, assign, etc.), a Rule_Operation object is added and populated to the model as a special sub-class ofthe statement-class. The Rule_Operation object gets a special link-attribute to the subject Exter- nal_Data_Element object. An External_Data_Element object can have links to multiple Rule_Operation objects/

Evaluation of Rule Operation Arguments As illustrated in figure 13 for each relevant argument (operands only) of a

Rule_Operation object, a special Rule Argument object is created as a sub-class of the initial Argument class. For the business rules extraction algorithm, the arguments are classified as follows:

- Value_Access argument - Constant Field argument

- Local_Data argument

- External Data argument

The Data_Element objects related to these Argument objects are attached to the corresponding and special subclasses Constant_Data or Local_Data objects. The Rule_Argument objects get link-attributes to the subject Rule_Operation object and they inhere the link-attributes to the Data_Element objects.

Note: Only Data_Element objects that are used as arguments for Rule_Operation object can become members ofthe special sub-classes Constant_Data or Local_Data.

Figure 13 shows the special object classes and their relationships.

Secondary Operations for Local Data

Because business rules are to be expressed in external defined / known arguments (or constants and values), the business rules extraction algorithm will trace the deter- mined Local_Data objects further until the complete rule-chain is expressed at the appropriate level.

For each Local Data object, Rule_Operation objects are determined by evaluation of the references of the Local_Data objects. For each reference, where the subject Local_Data object is used as a result-field of an appropriate operation / instruction (like add, multiply, subtract, assign, etc.), a Rule_Operation object is added and populated to the model as a special sub-class ofthe statement-class.

As shown in the overall flow of the business rules extraction algorithm, illustrated in figure 14, the process-steps for the determination of secondary operations and the evaluation of mle arguments are performed by iteration until no new Local_Data objects are found.

Constrain Block & Constrain Operations

The second, and even more important, part of a business mle construct are the constrain operations which represent the conditional logic of the business mle. As explained before, the present invention applies a unique inside-out tracing algorithm to determine all relevant conditional logic for the imperative logic that change / set the value of a business entity attribute.

For each determined Rule_Operation object the existence of a valid constrain is evaluated. The inhered attribute 'Block' from the super-class Statement will indicate if the subject Rule_Operation object is part of a Statement_Block. If the Statement_Block refers to a Conditional_Statement object, then a special Constrain_Block object is created as sub-class of the Statement_Block class. This Constrain_Block object gets a link-attribute to the subject Rule_Operation object and it inheres the link-attribute to the Conditional_Statement object.

Note: As explained before, a constrained operation is part of only one of the condition branches. The other branches and all the other statements in the condition branches are irrelevant for the subject business mle.

For the Conditional_Statement that belongs to the determined Constrain_Block object, a special Constrain object is created as sub-class of the Conditional_Statement class.

This Constrain object inheres the link-attributes to the Constrain_Block object and to its Argument objects. Figure 15 shows the basic object structure for Rule-Operations and Rule-Constraints.

Evaluation of Constrain Arguments For each relevant argument (operands only) of a Constrain object, a special Constrain /Argument object is created as a sub-class of the initial Argument class. For the business mles extraction algorithm, the arguments are classified as follows:

- Value_Access argument

- Count Field argument - Constant_Field argument

- Local_Data argument

- External_Data argument

The Data_Element objects related to these Argument objects are attached to the corresponding and special subclasses Constant_Data or Local_Data objects. The Constrain_Argument objects get link-attributes to the subject Constrain object and they inhere the link-attributes to the Data_Element objects.

Note: Only Data_Element objects that are used as arguments for Constrain objects can become members of the special sub-classes Constant Data, Count_Data or Local Data. Figure 16 shows the special object classes and their relationships.

Secondary Operations for Local Data Constrain Arguments

Because business mles are to be expressed in external defined / known arguments (or constants and values), the business mles extraction algorithm will trace the deter- mined Local_Data objects further until the complete mle-chain is expressed at the appropriate level.

For each Local_Data object, Rule_Operation objects are determined by evaluation of the references of the Local_Data objects. For each reference, where the subject Local Data object is used as a result-field of an appropriate operation / instruction (like add, multiply, subtract, assign, etc.), a Rule_Operation object is added and populated to the model as a special sub-class ofthe statement-class.

As shown in the overall flow of the business mles extraction algorithm, illustrated in figure 17, the process-steps for the determination of secondary operations and the evaluation of mle arguments and the determination of constrain-block and con- strain-operations are performed by iteration until no new Local_Data objects are found.

Constrain Stack In most cases / programs, the conditional logic of a business mle is implemented as nested condition constmcts. However, these condition constmcts control the execution of a variety of intermixed operations. Top-down business mles evaluation is therefor almost impossible.

With the inside-out tracing algorithm ofthe present invention, the relevant condi- tional logic for a particular business mle is 'pulled' from the total program complexity and presented as a Constrain-Stack. This stack contains only distinct constrain-blocks (e.g. a TRUE-branch of a condition statement) that apply to the execution of the mle operation (with reference to the constrain statement). The logical relationship between the stack members is always an AND relationship. The sequence of the constraints is therefor not relevant.

For each determined Constrain object, the existence of a valid constrain is evaluated. The inhered attribute 'Block' from the super-class Statement will indicate if the subject Constrain object is part of a Statement_Block. If the Statement Block refers to a Conditional_Statement object, then a special Constrain_Block object is created as sub-class of the Statement_Block class. This Constrain_Block object gets a link- attribute to the subject Constrain object and it inheres the link-attribute to the Condi- tional_Statement object.

Figure 17 shows a part ofthe special object stmcture as determined so far.

Control Block Stmcture

With reference to figure 18 the execution of program control blocks (paragraphs, procedures, routines, etc.) is conditional or un-conditional. Recursion is to be regarded as an example of program flow logic and therefor not relevant for business mles extraction. A conditional execution of a control block is controlled by a conditional per- form, goto or execute instmction of another control block.

This conditional statement has to be added to the constrain stack of the subject business rule if the execution of the mle or constrain operation(s) is controlled by this conditional statement. The inside-out tracing algorithm of the present invention builds up a chain of Rule Operation, Rule Argument, Constrain Block, Constrain and Constrain /Argument objects until it reaches the boundaries of the program control block where the primary mle operation takes place (when no new Constrain_Block objects are found).

To determine the next constrain for the constrain stack, the existence of a valid constrain for the subject Control_Block is evaluated. The inhered attribute 'GoTo / Perform' from the super-class Statement_Block will indicate if the subject Con- trol Block object is referred by a GoTo, Perform or Execute instmction in another Control_Block. If this GoTo, Perform or Execute instruction is part of a Condition, then a special Constrain_Block object is created as sub-class of the Statement_Block class. This Constrain_Block object gets a link-attribute to the subject Control_Block object and it inheres the link-attribute to the Conditional Statement object.

The inside-out tracing algorithm of the present invention creates a Constrain ob- ject for this conditional statement and repeats (iteration) its search for and evaluation of constrain-arguments, secondary mle operations for local data and additional constrain blocks / statements until it reaches the boundaries if this control block. Then it looks again for constrains for this control block.

Finally it will reach the boundaries of the program by landing in an Entry Point. If no entry point is discovered then the determined business mle chain has to be classified as 'Dead Code'.

Figure 19 shows a simplified example of an object stmcture for a complete business mle.

Program to program linking

After the business mles extraction algorithm has build up all business mle chains for programs, the process can now be finalized by performing program to program linking for those mles that are distributed over multiple programs. Figure 20 shows a simplified example where the value of an argument of a primary mle operation in module A is determined by a secondary mle operation in module B.

In the first stage, the business mles extraction algorithm determines a primary mle operation for the target data-element in module A and a primary mle operation for the 'link-data-element' in module B. In the linking stage, the business mles extraction algorithm searches for connections between 'result-link-data' and 'argument-link-data'.

By utilizing the parent, member, redefine, rename, physical-length and physical- offset attributes of the Data_Element and Data_Record object super-classes, also the hidden and obscure synonym connections can be determined. By utilizing the Ftrace_Record and Btrace_Record objects and relations, even the more obscure move- synonym connections can be determined.

Implementation Business mle analysis workbench

The present invention can / will be implemented as:

Hyper-graph basis for business mle analysis workbenches and program completeness and consistency review workbenches

The hyper-graph in figure 21 is implemented as a 1:1 representation of the underlying object-stmcture. By clicking a node in the graph, the corresponding object is selected and other functions (pull-down menu) are made available which directly utilize and explore the attributes and relationships ofthe selected object.

Figure 21 shows a prototype example of such a hyper-graph based workbench.

Business mle reporting workbench

The present invention can / will be implemented as:

Business mle reporting workbench based on the object structure of the business mles extraction algorithm. The object stmcture enables the complete and consistent reporting of the business rules for each selected business entity attribute (External_Data_Element objects). All direct and alternate mle paths will be reported in terms of imperative and conditional operations and expressed in terms of (other) business entity attributes only (and values and constants).

Figure 22 and example report shows a prototype implementation of such a busi- ness mles reporting workbench.

Example Report: Rules for External Field 'AUSREM'

First Rule: gets value ^*lJNBEK.Cσ if CC(CCIND) equals SPACES or LOWNALUES and if CHECKCC not equals CCALT or KODIND not lower INDMAX Second Rule: gets value 'DOCUMENT NOT PUBLISHED^" if CHECKKODE1 equals 'X' and CC(CCKODIND) not equals CHECKCC and KODE(KODIND) equals CHECKKODE Alternate Second Rule: gets value "DOCUMENT NOT PUBLISHED¹ if CHECK- KODE1 equals 'X' and CC(CCKODIND) not equals CHECKCC and KODE(KODIND) equals CHECKKODE

Third Rule: gets value 'UNBEK.CC^" if AUSANFCC equals SPACES or LOWNALUES and if SAVEKODE equals SPACES and if KODE(KODEIΝD) equals CHECKKODE

Alternate Third Rule: gets value -UNBEK.CC^" if AUSANFCC equals SPACES or

LOWNALUES and if SANEKODE equals SPACES and if KODE(KODEIΝD) equals

CHECKKODE

Alternate Third Rule: gets value -UNBEK.CC^" if AUSANFCC equals SPACES or LOWNALUES and if SANEKODE equals SPACES and if IΝD less then INDMAX and TEXTMATKOD(IND) not equals LOWVALUES and if IND equals NUMERIC Fourth Rule: gets value 'BENANTER VERTRAGSTAAT' if CHECKKODE1 equals 'R' and if SANEKODE equals SPACES and if KODE(KODEIΝD) equals CHECKKODE Alternate Fourth Rule: gets value 'BENANTER VERTRΛGSTAAT^" if CHECKKODE1 equals 'R' and if SANEKODE equals SPACES and if KODE(KODEIΝD) equals CHECKKODE

Alternate Fourth Rule: gets value 'BENANTER VERTRAGSTAAT^" if CHECKKODE 1 equals 'R' and if SANEKODE equals SPACES and if IΝD less then INDMAX and TEXTMATKOD(IND) not equals LOWVALUES and if IND equals NUMERIC

Fifth Rule: gets value 'DESIGNATED COUNTRY^" if CHECKKODE 1 equals 'W' and if SAVEKODE equals SPACES and if KODE(KODEIND) equals CHECKKODE Alternate Fifth Rule: gets value "DESIGNATED COUNTRY^" if CHECKKODE1 equals 'W' and if SAVEKODE equals SPACES and if KODE(KODEIND) equals CHECKKODE

Alternate Fifth Rule: gets value 'DESIGNATED COUNTRY^" if CHECKKODE1 equals ' W and if SAVEKODE equals SPACES and if IND less then INDMAX and TEXTMATKOD(IND) not equals LOWVALUES and if IND equals NUMERIC Other Applications

The present invention can / will be implemented in other areas like complete business mles service offerings or workbench products that cater for the following processes: - Excavation of conditional and imperative logic for each external defined / known field, in each program

- Elimination of program flow control logic

- Inter-link mles of calling / called modules

- Elimination / repair of logic flaws and inconsistencies - Combine mles for synonyms (Data Rationalization)

- Report mles in business entities (Data Rationalization)

Claims

1. Method for extracting business mles from the system-component-sourcecode of business application systems comprising the steps of: c) parsing said sourcecode by means of a parser and generating thereby objects representing entities, sub-entities and characteristics of the system and the system-components ofthe system which are stored in an object oriented repository, d) applying an algorithm for extracting business rules to be expressed in externally defined or known arguments, which algorithm can be subdivided into: b 1 ) determination of data-elements which represent business entity attributes, b2) determination of mle-operation objects for the determined external data- element objects, said mle-operation objects representing the imperative logic for the subject business entity attribute b3) creating a special rule-argument object for each relevant argument, the ar- guments being classified as value access argument, constant field argument, local data argument or external data argument, whereby in case of local data objects the algorithm is applied repetitive until no new local data objects are found b4) evaluating for each determined mle-operation object the existence of a valid constrain, the relevant arguments of a constrain argument object being classified as value access argument, count field argument, constant field argument, local data argument or external data argument, whereby in case of local data objects the algorithm is applied repetitive until no new local data objects are found.

2. Method according claim 1, characterised in that for each programming language the parser action can be subdivided into a language interface action which actually parses the source code applying the language recognition rules for the respective lan- guage, and a modelling action whereby objects are generated according to the language model.

3. Method according to claim 1 or 2, characterised in that in step bl) different catagories are distinguished: a first category containing the data-elements of external records, a second category containing the data-elements of internal records, which are assigned from external input records, - a third category containing data-elements of internal records which are assigned to external records.

4. Method according to claim 3, characterised in that the first category includes: redefined fields, - renamed fields, data-elements of inter-program communication records (link records).

5. Method according to any of the preceding claims, characterised in that mle operation objects according to step b2) are determined by evaluation of the references of the external data element objects, whereby for each reference where the subject external data element object is used as a result field of an appropriate operation or instruction a mle operation object is added and populated to the model as a special subclass ofthe statement class.

6. Method for extracting business mles from business application systems and for presenting these mles to a user or to another workbench, comprising the steps of: a) parsing of the system-component-source-code into an object oriented and object based model (EDT) of the component (e.g. program, table definition, etc.). (performed as automated process) b) linking of essential cross reference information into a separate system model, (performed as automated process) c) evaluating and extending of the component models according to the required and defined object classes and relationships for a business mle tracing algorithm, (performed as automated process) d) extraction of all the detailed business rules (imperative and conditional logic) for all the external defined / known business entity attributes of a business application system. Also for all the direct and indirect local synonyms of these entity attributes, (performed as automated process) e) by-passing and elimination of non-relevant implementation logic (e.g. program flow control) in the derived business mle chain, (performed as automated process) f) linking of business mle chains over program boundaries via call structures, (performed as automated process) g) storing these business mle chains in an object oriented repository.

7. Method according to claim 7, characterised by the further step of: h) presenting these business mle chains as hyper-graphs (with various aggregation levels) to the analyst in an interactive process.

8. Method according to claim 7 or 8, characterised by the further step of: i) using these business mle chains and these hyper-graphs as base in an interactive analysis and remediation workbench for evaluation, repair and restructuring of program flaws and inconsistencies.

9. Method according to one of the preceeding claims 7-9, characterised by the further step of: j) presenting these business mles in selectable reports or interfaces to other work- inches.

10. Method according to any of the preceeding claims 7-10, characterised by the further step of: k) combining these business mle chains with data-rationalization structures (all the implemented representations of business entity attributes) to enable the presentation or reporting of all the relevant business mles for a selected business entity attribute.

11. Method according to any of the preceeding claims 7-11, characterised by the further step of:

1) using these (combined) business mle chains for further aggregation, reconcilia- tion and classification to build-up a technology independent repository to improve the management of those mles once they are captured.

12. Implementation and utilization of the described method in analysis and re- engineering workbenches with the following focus-items:

- presenting these business mle chains as hyper-graphs (with various aggregation levels) to the analyst in an interactive process. - using these business rule chains and these hyper-graphs as base in an interactive analysis and remediation workbench for evaluation, repair and restructuring of program flaws and inconsistencies.

- presenting these business mles in selectable reports or interfaces to other workbenches. - combining these business mle chains with data-rationalization structures (all the implemented representations of business entity attributes) to enable the presentation or reporting of all the relevant business rules for a selected business entity attribute.

- using these (combined) business mle chains for further aggregation, reconciliation and classification to build-up a technology independent repository to improve the management of those mles once they are captured.