Transforming rule-based methods of computer application logic into hierarchical decision graphs

Abstract

Transforming rule-based methods of computer application logic into hierarchical decision graphs 100, comprising accessing a sequence of rule-based tasks 101, where rules are grouped into tasks and the

Description

[0001] The present invention relates to rule-based methods of computer application logic, and more specifically, to transforming rule-based methods into hierarchical decision graphs.

[0002] In a first phase of modernization, some enterprises adopted rule-based systems to separate the application logic from complicated application code and thus enable a better maintenance of this logic. Whereas each rule has a clear semantics and thus is understandable for all stakeholders, the combination of multiple rules may lead to a complex behavior which is not easy to understand. Many rule-based systems provide some control layer where rules are grouped into tasks and the tasks are executed in sequence. This constrains the possible orders in which multiple rules are executed. If some first rules need the results from some second rules, this technique ensures that the first rules are not applied before the second rules. A sequence of rule-based tasks thus permits an organization of the rules that leads to expected results.

[0003] However, a sequence of rule-based tasks does not show how the rules are interacting. It neither indicates the intermediate decisions made by rules, nor which other rules depend on these intermediate decisions. Furthermore, the task-based model relies on the notion of a global computational state which may be updated in any way by any rule in any task. It does not highlight which rules modify and access which part of this computational state. Decomposing an application logic into independent parts is not straightforward due to the sequential nature of the rule processing. This impactsexplainability, analysis, and parallel execution.

[0004] In a second phase of modernization, enterprises are seeking to move to higher-level modeling artifacts that are giving a fine-grained picture of the decisions and their dependencies. However, it is far from evident how to discover the decisions and dependencies within their existing sequential rule-based systems. SUMMARY

[0005] According to an aspect of the present invention there is provided a computer-implemented method for transforming rule-based methods of computer application logic into hierarchical decision graphs, said method comprising: accessing a sequence of rule-based tasks where rules are grouped into tasks and the tasks are executed in sequence; building an attribute-dependency graph by analyzing object-oriented navigation of the rules in the tasks, where the attribute-dependency graph has nodes representing values of object variables and attributes that are accessed or modified by the rule-based tasks, with edges between the nodes of ownership links, version links, and rule dependency links; reorganizing the attribute-dependency graph by resolving cycles within a task based on rule order to obtain an acyclic graph; and transforming the acyclic attribute-dependency graph into a decision variable-dependency graph as a hierarchical decision graph.

[0006] According to another aspect of the present invention there is provided a system for transforming rulebased methods of computer application logic into hierarchical decision graphs, comprising: a processor and a memory configured to provide computer program instructions to the processor to execute the function of the components: an input component for accessing a sequence of rule-based tasks where rules are grouped into tasks and the tasks are executed in sequence; an attribute-dependency graph building component for building an attribute-dependency graph by analyzing object-oriented navigation of the rules in the tasks, where the attributedependency graph has nodes representing values of object variables and attributes that are accessed or modified by the rule-based tasks, with edges between the nodes of ownership links, version links, and rule dependency links; an attribute-dependency graph reorganization component for reorganizing the attribute-dependency graph by resolving cycles within a task based on rule order to obtain an acyclic graph; and a graph transforming component for transforming the acyclic attribute-dependency graph into a decision variable-dependency graph as a hierarchical decision graph.

[0007] According to a further aspect of the present invention there is provided a computer program product for transforming rule-based methods of computer application logic into hierarchical decision graphs, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to: access a sequence of rule-based tasks where rules are grouped into tasks and the tasks are executed in sequence; build an attribute-dependency graph by analyzing object-oriented navigation of the rules in the tasks, where the attribute-dependency graph has nodes representing values of object variables and attributes that are accessed or modified by the rule-based tasks, with edges between the nodes of ownership links, version links, and rule dependency links; reorganize the attributedependency graph by resolving cycles within a task based on rule order to obtain an acyclic graph; and transform the acyclic attribute-dependency graph into a decision variable-dependency graph as a hierarchical decision graph.

[0008] The computer readable storage medium may be a non-transitory computer readable storage medium and the computer readable program code may be executable by a processing circuit. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings: Figure 1A is a flow diagram of an example embodiment of a method in accordance with embodiments of the present invention; Figure 1B is a flow diagram of an example embodiment of a method in accordance with embodiments of the present invention; Figure 2A is a schematic diagram of an example set of rule-based tasks as an input into a method in accordance with embodiments of the present invention; Figure 2B is a schematic diagram of an example decision variable-dependency graph as an output of a method in accordance with embodiments of the present invention; Figures 3A to 3D are schematic diagrams illustrating an example generation of an attribute-dependency graph in a method in accordance with embodiments of the present invention; Figures 4A to 4B are schematic diagrams illustrating an example reorganization of an attribute-dependency graph in a method in accordance with embodiments of the present invention; Figures 5A to 5D are schematic diagrams illustrating an example transformation of an attribute-dependency graph in a method in accordance with embodiments of the present invention; Figure 6A and 6B are schematic diagrams illustrating a decision variable-dependency graph in a method in accordance with embodiments of the present invention; Figure 7 is a block diagram of an example embodiment of a system in accordance with embodiments of the present invention; and Figure 8 is a block diagram of an example embodiment of a computing environment for the execution of at least some of the computer code involved in performing the present invention.

[0010] It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numbers may be repeated among the figures to indicate corresponding or analogous features. DETAILED DESCRIPTION

[0011] Embodiments of a method, system, and computer program product are provided for transforming rulebased methods of computer application logic into hierarchical decision graphs. This transforms a rule-based procedural programming paradigm into a hierarchical decision graph for a functional programing paradigm.

[0012] A method is disclosed to identify the decisions and dependencies made by sequential rule-based methods to produce a hierarchical rule-based decision policy, which will permit a more efficient rule execution, accurate rule analysis, and structured forms of explanations. This may be applied to legacy computer applications to separate the application logic from complicated application code and thus enable a better maintenance of this logic.

[0013] The transforming of rule-based methods of computer application logic into hierarchical decision graphs is an improvement in the technical field of computer application interpreting application logic generally and more particularly in the technical field of maintenance of legacy code and modeling applications.

[0014] The method and system are described that transform a sequence of “rule-based tasks” into a hierarchical rule-based decision policy which reveals the decisions made by the rule-based tasks as well as the dependencies between these decisions. In rule-based systems, control is provided by grouping rules into tasks, where the tasks may be executed in sequence. This constrains the possible orders in which multiple rules are executed. A sequence of "rule-based tasks” thus permits an organization of the rules that leads to expected results.

[0015] The resulting decision policy may be provided as a dependency graph between decision variables, with type definitions for the decision variables, and with decision logic of the decision variables. A decision logic is obtained by collecting all rules and decision tables from the rule-based tasks and by adapting them to the dependency graph. This transformation does not change the overall input-output behavior. This means that the hierarchical rule-based decision policy returns the same final decision as the sequence of rule-based tasks if supplied with the same inputs.

[0016] Whereas the rules and decision tables in rule-based tasks are modifying the attribute values of given objects, the decision logics of the hierarchical decision policy must not have any side-effect. The decision logic can set the value of the resulting decision variable, but cannot modify the attribute values of any object that is given as input. Hence, sequential rule-based tasks follow a procedural programming paradigm, whereas the hierarchical decision policy follows a functional programming paradigm. Due to this fundamental difference, a direct transformation of the former into the latter is challenging.

[0017] The described method and system achieve the transformation by building an attribute-dependency graph in an intermediate step. The nodes of this graph represent the objects manipulated by the rule-based tasks and their attributes. There are nodes for both initial and modified attribute values that are obtained due to the different rule-based tasks. Hence, the same attribute may have multiple nodes. The edges of this graph represent the dependencies between these attribute values. For example, if a rule modifies the sensor format of a camera system based on the level of the photographer, there will be a node for the level, a node for the sensor format, and an edge from the former to the latter.

[0018] Referring to Figure 1 A, a flow diagram 100 shows an example embodiment of the method for transforming rule-based methods of computer application logic into hierarchical decision graphs. The method is supplied with a sequence of rule-based tasks 101 and returns a dependency graph for decision variables 112.

[0019] The method is supplied 101 with a sequence of rule-based tasks as input, where rules are grouped into tasks and the tasks are executed in sequence. Rules and decision tables in rule-based tasks are modifying the attribute values of given objects referred to as variables.

[0020] The method builds 102 an attribute-dependency graph. The building includes analyzing 102 the rulebased tasks and extracting dependencies between attributes. The attribute-dependency graph includes information about the objects to which the attributes belong. The nodes of the attribute-dependency graph represent the objects manipulated by the rule-based tasks and their attributes. The attribute-dependency graph has nodes representing values of object variables and attributes that are accessed or modified by the rule tasks, with edges between the nodes of ownership links, version links, and rule dependency links. There are nodes for both initial and modified attribute values that are obtained due to the different rule-based tasks. Hence, the same attribute may have multiple nodes. The edges of the attribute-dependency graph include representation of the dependencies between these attribute values.

[0021] The method reorganizes 104 the attribute-dependency graph to bring it into a suitable form by resolving cycles. The reorganizing may, optionally, regroup attributes into a single node that are modified by the same rules. Cycles are resolved by duplicating nodes for attributes. If a rule modifies several attributes, it needs to be considered by the node of each of these attributes, thus leading to a duplication of this rule. Regrouping different attributes into a single node prevents this duplication; however, this is only possible for attributes that are modified by the same rules. The method provides 105 the reorganized attribute-dependency graph.

[0022] The method transforms 106 the attribute-dependency graph into a dependency graph over decision variables referred to as a variable-dependency graph. This step transforms a decision about an attribute of an object into a decision variable that has a composite value that preserves information about the object. This provides a dependency graph for decision variables 112, a rule-based decision logic for each decision variable 113, and a list of type definitions 111 for the decision variables. This step transforms nodes for modified attribute values into decision nodes of a suitable type. Such a decision node needs to preserve information about the owner of the attribute and has a dedicated composite type with attributes for the owner and the value. It also creates decision nodes for objects that have modified attribute values. Such a decision node will have a dedicated composite type that has the modified attributes and an attribute for the original object. So instead of modifying attributes of an object, the resulting hierarchical decision policy creates a wrapper of the object.

[0023] The task sequence constrains the order in which the rules are executed. The rules of a task can only be executed once all the rules of the preceding tasks have been executed. Hence, the task sequence provides control information to the rule engine, but does not answer the following questions: Q1: What are the inputs and outputs of the task sequence? Q2: What are the intermediate decisions? Q3: Which decision depends on which other decision? Q4: Which rules are making which decisions? Q5: Which rules in a task are independent of each other?

[0024] Answers to these questions are important for a variety of reasons: • They serve as a specification for the rule engine, allowing it to check whether the rules are respecting this specification. • They provide information about rules that can be executed in parallel. • They give information for incremental computation showing which values of the decisions remain valid if the values of some of the inputs are changed. • They permit the generation of explanations showing which decisions have been made by using which other decisions.

[0025] The described method discovers the decisions and their dependencies within a sequence of rule-based tasks. This system also adapts the rules of these tasks to the newly discovered dependency structure. If a rule-based task contains several rules that are independent of each other, they will be attached to separate decision nodes. Hence, the method produces a new artifact that answers the questions Q1 to Q5.

[0026] Referring to Figure 1B, a flow diagram 110 shows an example embodiment of the method for transforming rule-based methods of computer application logic into hierarchical decision graphs with further implementation steps of the overall method of Figure 1 A. The method accesses a sequence of rule-based tasks that may be parsed 101 to obtain syntax trees.

[0027] The method may build 102 an attribute-dependency graph by analyzing object-oriented navigation of the rules in the tasks. Building the attribute-dependency graph may include creating 111 an outline of the attributedependency graph containing all nodes for variables and attributes as well as ownership links between variables and attributes for same computational state and task version links, and adding 112 rule dependency links to the graph outline. The method may simplify 113 the attribute-dependency graph by removing superfluous nodes.

[0028] The method may include reorganizing 104 the attribute-dependency graph by resolving cycles within a task based on rule order to obtain an acyclic graph. The acyclic attribute-dependency graph has clear semantics and describes which decisions are made for attributes and variables depending on other decisions for attributes and variables as well as the initial values of attributes and variables.

[0029] Reorganizing 104 may include regrouping 121 decision nodes as a single node, where the regrouped nodes have ingoing dependency links that are coming from the same nodes and that are labeled by the same rules, have ingoing ownership links that are coming from the same node, and do not have any outgoing ownership link.

[0030] The building 102 and reorganizing 104 may apply operators on the syntax trees parsed from the rulebased tasks. Operators may include: a first operator creates nodes for variables; a second operator creates nodes for attributes; an operator for creating dependency links for each rule of each rule-based task; a simplification operator; and an operator for resolving cyclic dependencies to each rule-based task.

[0031] The method includes transforming 105 the acyclic attribute-dependency graph into a decision variabledependency graph as a hierarchical decision graph. The transforming may include transforming nodes for modified attribute values into nodes for decision variables which embed information about the owning object, adapting the navigation constructs of the rules in the tasks to the decision variable-dependency graph, and introducing decision logic and new type definitions.

[0032] The transforming 105 may include: enriching 131 decision attributes by information about their owning objects. The transforming may further include: reversing 132 ownership relations and transforming into dependency links to transforms decision nodes for attributes into decision nodes for variables. The transforming may further include: removing 133 all input nodes for attributes and delegating their outgoing dependency links to their owner nodes.

[0033] A resulting decision variable-dependency graph 112 has a flat representation of decisions in the form of single-valued or multi-valued variables, where a single-valued attribute is represented by a multi-valued variable in the graph if its owning object is the value of a multi-valued attribute. Type definitions 111 for decision variables and decision logic 113 for each variable are also provided.

[0034] The discovery of the decisions and their dependencies faces several technical issues, which are all addressed by the described method as follows,

[0035] A hierarchical rule-based decision policy requires rules that determine the value of a decision variable, but do not cause any side-effects on independent rules. As such, they must not modify the values of other variables. The rules of the sequential rule-based tasks do not meet this requirement as they modify the attribute values of objects that are given as input. For example, Rule 1 modifies the value of the attribute “model” of the object “the body of “camera system", which is provided as input.

[0036] The decisions and dependencies should be sufficiently fine-grained. If two rules are modifying the values of two different attributes that belong to the same object, then these are two separate decisions with separate dependencies. Hence, it is not sufficient to express dependencies between object-valued variables manipulated by the given rules, but necessary to express dependencies between individual attributes of those objects.

[0037] The dependency graphs may contain cycles.

[0038] The same rule may modify multiple attributes. Introducing separate decision variables for these attributes will require a duplication of the rule condition, thus leading to some evaluation overhead for the rule engine.

[0039] The hierarchical rule-based decision policy is therefore provided by a directed acyclic graph (V, D) defining dependencies D between variables V. Variables may have complex values (typically a composite object). The value of a variable x is uniquely determined by the values of its parents P(x) := {y in V | (y,x) in D }. Therefore, considering two assignments v1, v2 of values to variables. If v1 (y) = v2(y) for all y in P(x), then v1 (x) = v2(x).

[0040] This is a special case of an influence diagram that provides a graphical way to look at factors involved in making a decision. This allows a shift to the Object Management Group (OMG) standard Decision Model Notation (DMN) (Object Management Group, OMG, Decision Model Notation, and DMN are trademarks of the Object Management Group).

[0041] As task rules are expressed over object-oriented data structures and have constructs for navigating through these structures, they may access and modify the values of deeply nested attributes. This results in difficulties addressed by the described method.

[0042] The described method addresses the difficulty of dependency detection. Dependency detection involves identifying the different pieces of information (e.g. attributes of objects) that are accessed and modified by the rules in order to understand which rules are accessing and / or modifying the same piece of information.

[0043] The described method addresses the difficulty of transformation of state-modifying rules into decision rules. This difficulty is in describing these pieces of information (which may be attributes of objects) in terms of decision variables. This requires a change of the object-oriented representation and an adaption of the rules to this new representation.

[0044] The described method addresses the resolution of cycles. This addresses the problem of cyclic dependencies that are obtained if two rules are accessing the values of attributes that are modified by the other rule.

[0045] The described method has several advantages. It rewrites procedural “if-then" rules into a form that fits into a clear specification provided by the dependency graph between decision variables. The resulting hierarchical rule-based decision policy permits a deferred and / or parallel execution of independent decision logics, thus leading to a faster execution of large rulesets and an overall better scalability. The resulting hierarchical rule-based decision policy permits an informed and accurate rule analysis (completeness, consistency, redundancy) of the rule sets as it discovers the specification that is missing in the rule-based tasks. Similarly, the resulting hierarchical rulebased decision policy permits an optimization of the ruleset for faster execution for the same reasons. The resulting hierarchical rule-based decision policy permits the generation of explanations of a final decision by showing the results for the intermediate decisions and the rules applied by each decision logic. Such a structured explanation is easier to understand than sequential traces. The resulting hierarchical rule-based decision policy is more robust against changes (e.g., new intermediate decisions may be added without requiring a reorganization of the rulebased tasks by the user).

[0046] The described system may provide a tool that will help existing customers of business automation platforms to modernize their rule-based applications and to move from procedural rule flows to declarative decision models. Declarative decision models provide more information, are more intuitive, and have the technical advantages listed above. This allows a shift to the Object Management Group (OMG) standard Decision Model Notation (DMN), but without sacrificing the expressiveness of the rule language.

[0047] The described method is explained with the help of an example shown in Figure 2A of a simple task sequence and its decision logic. The example concerns the configuration of a camera system consisting of a body and one or more lenses. Figure 2A shows a sequence of a start 201 with two rule-based tasks 202, 203 and an end 104. The first rule-based task 202 configures the camera and the second rule-based task 203 configures the optics (for example, the lenses). Each rule-based task 202, 203 has one or more condition-action rules:

[0048] Rule R1 of task T1: if the weight limit of the body of 'camera system' is 500g and the sensor format of the body of 'camera system' is Full-Frame then set the model of the body of 'camera system' to "mW";

[0049] Rule R2 of task T1: if the level of 'photographer' is professional then set the sensor format of the body of 'camera system' to Full-Frame;

[0050] Rule R3 of task T2: for each lens called 'lens', in the lenses of 'camera system' if the lens type of 'lens' is wide-angle zoom and the sensor format of the body of 'camera system' is Full-Frame then set the focal length of 'lens' to ‘20-35’;

[0051] Figure 2B shows an example of a final decision variable-dependency graph 210 that provides these answers for the considered example.

[0052] The graph 210 shows a photographer 211 and a camera system 212 with nodes for decision variables for the camera model / Taskl 213, the sensor format / Taskl 214, focal Iengths / Task2 215, body / Task1, Ienses / Task2, camera system / Taskl 218 and camera system / Task2 219.

[0053] The graph 210 shows that the intermediate decisions about camera model 213 and the focal lengths 215 of the lenses are independent of each other, but both depend on the decision about the sensor format 214. The rule R1 determines the camera model 213 and the rule R3 the focal lengths 215. As these decisions are independent of each other, these two rules R1 and R3 can be executed in parallel.

[0054] The modified rules of the decision-dependency graph 210 are discussed below once the development of the decision-dependency graph 210 has been explained using the following figures.

[0055] Referring to Figures 3A to 3D, schematic graphs illustrate the creation of the attribute-dependency graph for the example.

[0056] The attribute-dependency graph contains nodes for the values of variables and attributes that are accessed or modified by the rules of the given task sequence. It has different kinds of edges between these nodes, namely ownership links, dependency links, and version links.

[0057] The disclosed method creates the attribute-dependency graph in several steps. The method creates an outline of the graph containing all nodes as well as ownership links and version links. The method adds dependency links. The method simplifies the graph by removing superfluous nodes.

[0058] Figure 3A illustrates in its upper part 300 the creation of versions for a task sequence for an attribute “Attributel” 311 of a variable “Variablel” 301. This includes a node for the initial value of variable “Variablel” 301 and node for the initial value of its attribute “Attributel" 311. Furthermore, there is an ownership link leading from the node for the variable 301 to the node for the attribute 311 indicated by a dashed line. The nodes for the initial values are referred to as “input nodes” in the following. Similar attribute “Attribute2” 315 of another variable “Variable2” 305 may be provided.

[0059] As the values of the variables and attributes may be modified by the different rule-based tasks, the attribute-dependency graph 310 contains a copy of these nodes for each task. Figure 3A shows this for two rulebased tasks in its lower part 310. The nodes called “Variable1 / Task1” 302 and “Attribute1 / Task1” 312 represent the values of the variable and its attribute after the execution of the first task. Both are linked by an ownership link. Furthermore, there is a version link leading from the node for the previous value of the attribute or variable to its new version. The version links are indicated by a dotted line. Figure 3A also shows the nodes for the values after the execution of the second task. The nodes called “Variable1 / Task2" 303 and “Attribute1 / Task2” 313 represent the values of the variable and its attribute after the execution of the second task. Again, they are connected by an ownership links and there are version links for the nodes for the previous values leading to these nodes. The nodes for the values after executing a task are called “decision nodes” in the following.

[0060] It should be noted that there are several variables or attributes that have the same composite type. For example, there may be two variables “main camera system” and “second camera system” that both have the type “Camera System". The attribute-dependency graph will have a distinct node for each of these variables. In addition, the attribute-dependency graph will have a distinct node for each attribute of these variables. For example, there will be a node for the attribute “body” of variable “main camera system” and another node for the attribute “body” of variable “second camera system”. These two nodes for the same attribute will have different ingoing ownership links.

[0061] The disclosed system creates the attribute-dependency graph 310 by parsing the given rules and by applying the following operators to the syntax trees resulting from the parsing. A first operator creates nodes for variables. It checks whether a variable occurs in the syntax tree of some rule. If it finds such a variable, it creates a node representing the initial value of this variable. Furthermore, it creates a node for each rule-based task. This node represents the value of the variable after the execution of the rule-based task. Furthermore, the operator connects these nodes by version links as explained before.

[0062] A second operator creates nodes for attributes. It checks whether an attribute occurs in the syntax tree of some rule. If it finds such an attribute, the operator retrieves the object to which this attribute belongs and applies an operator that creates the nodes for this object. The first operator then creates a node for the initial value of this attribute and adds an ownership link leading from the node for the initial value of the object to the newly created node for the attribute. Furthermore, it creates a node for each rule-based task. This node represents the value of the attribute after the execution of the rule-based task. The operator adds an ownership link from the corresponding node of the owning object to this node. Furthermore, the operator connects these nodes for the attribute by version links as explained before.

[0063] After creating this outline of the attribute-dependency graph 310, the disclosed system applies an operator for creating dependency links for each rule of each rule-based task. This operator searches the syntax tree of a rule for expressions that read the value of an attribute of variables. Furthermore, it determines expressions that modify the value of an attribute or variable. The operator retrieves the nodes that represent the values of these attributes or variables after the execution of the considered task. The operator then creates dependency links leading from the nodes for values that are read by a rule to the nodes for values that result from a modification. Furthermore, the operator labels these dependency links by the name of the rule. If the dependency link already exists, the operator will simply add the rule name to its label.

[0064] Figure 3B shows the creation of a dependency between attributes for a rule of a task and shows a dependency link 321 for a rule R1 that belongs to task Taskl. This rule reads the value of the attribute “AttributeT' 312 of an object that is the value of variable “Variablel” 302 and modifies the value of the attribute “Attribute2” 314 of an object that is the value of variable “Variable2” 304. Therefore, the operator creates a dependency link 321 leading from the node “Attribute 1 / Task 1" 312 to “Attribute2 / Task1 ” 314.

[0065] The operator for creating the dependency links produces a fully-fledged attribute-dependency graph that represents the values of attributes and variables after the execution of each task. However, most rules modify only a small number of values. If the value of a variable or attribute is not modified by any rule of a task, its value after the execution of the task will be the same as its value before the execution of the task. Hence, both values can be represented by the same graph node without loss of any information. As the value of the attribute or variable is not changed by any rule of the task, the node representing its value after the execution of the task has no ingoing dependency link. Such a node could potentially be merged with its previous version (i.e., the node that represents the value of the attribute or variable before the execution of the task).

[0066] Figure 3C shows the removal of a version without ingoing dependencies and child. For example, the node “Attribute1 / Task1”312 in the upper part of Figure 3C does not have any ingoing dependency link. Therefore, it represents the same value as its previous version “Attributel” 311 and can be merged with this node. The lower part of the Figure 3C shows the result of this merging. The node "Attribute1 / Task1" 312 has been deleted and its outgoing dependency to node "Attribute2 / Task1" 314 has been delegated to node “Attributel" 311.

[0067] It should be noted that a node cannot be merged with its previous version if it has an outgoing ownership link. For example, the node “Variable2 / Task1” 304 in the upper part of Figure 3C has an outgoing ownership link that leads to the node “Attribute2 / Task1 ” 314. If the node “Variable2 / Task1” 304 were merged with the node nVariable2” 305, this ownership link would lead from the node "Variable2" 305 to the node “Attribute2 / Task1” 314. An ownership link should only connect two nodes if these two nodes belong to the same computational state. However, this is not the case for the nodes "Variable?' 305 and “Attribute2 / Task1 ” 314.

[0068] The disclosed method simplifies the fully-fledged attribute-dependency graph by applying the following simplification operator step by step. The operator works with a current attribute-dependency graph, which is initialized by the fully-fledged attribute-dependency graph. The operator checks whether the current attributedependency graph contains a decision node without ingoing dependency link and without outgoing ownership link. If yes, the operator selects one of these nodes and retrieves its previous version (i.e., the node that has an outgoing version link to the selected node). If the selected node has an outgoing dependency link to a third node, the operator adds a dependency link to the current attribute-dependency graph. This link leads from the previous version to the third node. Similarly, if the selected node has an outgoing version link to a fourth node, the operator adds a version link that leads from the previous version to the fourth node. After this, the operator deletes the selected node and all its ingoing and outgoing links from the current attribute-dependency graph.

[0069] The simplification stops when the current attribute-dependency graph does not contain any decision node without ingoing dependency link and without outgoing ownership link. This graph is in a simplified form.

[0070] Figure 3D shows the removal of versions without ingoing dependencies and child. The attributedependency graph in the upper part of Figure 3D contains a single decision node without ingoing dependency link and without outgoing ownership link. This decision node is "Variable1 / Task1" 302. The lower part of the Figure 3D shows the attribute-dependency graph obtained by applying the simplification operator to this node. Due to the removal of the node “Attributel / Taskl” 312, the node “Variablel / Taskl” 302 has no outgoing ownership link in this modified graph. Moreover, it has no ingoing dependency link. The simplification operator is therefore applied to this node as well.

[0071] The lower part of Figure 3D shows the graph resulting from this second simplification. This graph has only two decision nodes, none of which can be simplified for the following reasons: decision node “Attribute2 / Task1” 314 has an ingoing dependency link; decision node “Variable2 / Task1” 304 has an outgoing ownership link. Therefore, no further simplification operator is applied, meaning that this graph is in simplified form.

[0072] The attribute-dependency graph may then be re-organized. The simplified attribute-dependency graph requires further re-organization steps in order to describe a hierarchical decision policy in a meaningful form. The re-organization may involve one or two steps: in a first step, cyclic dependency links are resolved; and in a second step optional step, nodes with same ingoing dependencies are re-grouped into a single node.

[0073] The dependency graph of a hierarchical rule-based decision policy must be acyclic due to the hierarchical nature of this policy, but the simplified attribute-dependency graph does not necessarily satisfy this requirement. Figure 4A illustrates a cycle within a task based on rule order. This graph is produced for a rule-based task that contains two rules R1 411 and R2 412. Rule R1 411 reads the value of an attribute “AttributeT' 312 and modifies the value of an attribute “Attribute2” 314. Rule R2 412 reads the value of an attribute "Attribute2” 314 and modifies the value of an attribute “AttributeT' 312. The upper part of Figure 4A shows the cyclic attribute-dependency graph, whereas the lower part of Figure 4A shows a modified graph obtained by duplicating 316 one of nodes in the cycle. It supposes that Rule R1 411 is applied before Rule R2 412 and not vice versa. It should be noted that cycles can only occur among the decision nodes belonging to the same task.

[0074] The disclosed system applies an operator for resolving cyclic dependencies to each rule-based task. A cycle is a sequence of at least two nodes such that the last node is equal to the first node and each node in the sequence, except the last one, has an outgoing dependency link that leads to its direct successor node in the sequence. A cycle is simple if all nodes in the sequence (except for the last one) are all different. Cycles that are not simple can be decomposed into multiple simple cycles. The operator for resolving cyclic dependencies will resolve all simple cycles. As the resulting graph does not contain any simple cycle, it will not contain any non-simple cycle either.

[0075] The operator for resolving simple cycles works with a current attribute-dependency graph, which is initialized by the simplified attribute-dependency graph. In each step, the operator examines a subgraph of the current attribute-dependency graph which contains all nodes of its rule-based task and all dependency links between these nodes, but no version or ownership link. The operator checks whether this subgraph contains a simple cycle. It does so by a standard method for finding cycles. For example, it may do a depth-first search and classify the dependency links into tree edges, forward edges, cross edges, and backward edges. A backward edge leads from a node to one of its ancestors in the tree and thus defines a simple cycle. This cycle consists of all nodes along the path in the tree from the ancestor to the node, followed by the ancestor. If the operator finds one or more backward edges, it will select a backward edge that leads to a node that has been explored first by the depth- first method. If there are several such backward edges, it will select one that starts at a node that has been explored first by the depth-first method. The operator will then resolve the cycle defined by this backward edge.

[0076] The operator resolves the detected cycle by creating a copy of the first node of the cycle (which is the destination of a backward edge). The operator creates a version link leading from the original node to the copy and creates an ownership link between the owner of the original node and the copy. Furthermore, it delegates the outgoing version link to the copy, i.e., replaces it by a version link that leads from the copy to its destination. Next, the operator examines all dependency links involving the original node. Ingoing dependency link from nodes of other tasks are preserved. Similarly, ingoing dependency links from nodes that have been explored before the current node by the depth-first search are preserved. However, ingoing dependency links from nodes that have been explored after the considered node (or from the same node) are delegated to the copy. This means that such a dependency link is deleted in the current attribute-dependency graph and replaced by one that leads to the copy of the node. As far as outgoing dependency links are concerned, it should be noted that the copy should be used instead of the original node for all nodes that are explored after the last node of the cycle. Hence, if the considered node has an outgoing dependency link leads to a node that is explored after the cycle, then it delegated to the copy. This means that this dependency link is replaced by one that leads from the copy to the destination of the link. Once the operator has modified all dependency links, it has successfully resolved the cycle.

[0077] After resolving a cycle, the operator is applied again. It is important that it explores the nodes in the same depth-first order as before. This procedure will be repeated until all cycles are resolved. It should be noted that the same node may be copied several times if this node belongs to different cycles. It should also be noted that the result of the operator for resolving cycles depends on the chosen depth-first ordering. This order may be chosen in accordance with the order of rules within a task.

[0078] Figure 4A shows a simple cycle in its upper part that consists of the nodes “Attribute1 / Task1” 312, “Attribute2 / Task1 ” 314, and again "Attribute 1 / Task1” 312. The lower part of Figure 4A shows the result of the operator for resolving cycles. Node "Attribute1 / Task1" 312 has been copied 316. The copy 316 is labelled “Attributel / Task1 / R2” indicating that it represents the value of Attribute “Attributel" after the application of Rule R2. The dependency link between the nodes “Attribute2 / Task1" 314 and “Attributel / Task 1" 312 has been replaced by one leading to the copy “Attributel / Task1 / R2” 316.

[0079] Figure 4B shows another example of a cyclic dependency graph in its upper part. It has the same nodes as the previous examples, but different rules and different dependency links. In this example, Rule R2 reads the value of Attribute “Attribute2” 314 and modifies it, but leaves the value of Attribute “Attributel” 312 unchanged. Consequently, the dependency graph has a cycle consisting of the nodes “Attribute2 / Task1 ” 314 and “Attribute2 / Task1” 314. Therefore, node “Attribute2 / Task1" 314 is copied in the lower part of Figure 4B and the copy 317 is named “Attribute2 / Task1 / R2” 317. The dependency between the nodes “Attribute2 / Task1" 314 and “Attribute2 / Task1" 314 is replaced by one leading from node "Attribute2 / Task1” 314 to node “Attribute2 / Task1 / R2” 317.

[0080] The acyclic attribute-dependency graph produced by the operator for resolving cycles has a clear semantics and describes which decisions are made for attributes and variables depending on other decisions for attributes and variables as well as the initial values of attributes and variables. The decisions are made by a modified version of the rules attached to the ingoing dependency link of a decision node. A rule of a rule-based task may modify the values of several attributes and variables. However, a rule of a decision node for an attribute or variable may only modify the value of this attribute or variable. Hence, the action of this rule needs to be limited to this attribute or variable. If the original rule has actions for modifying the values of other attributes and variables, these actions must be removed in the version of the rule attached to the considered dependency link.

[0081] Version links contribute to the semantics of the attribute-dependency graph as well. They describe an implicit default rule that copies the value of the previous version to the current version if none of the rules of the current version has been applied. For example, the following default rule is used for the decision node “’camera system7T2”: if 'camera system / T2' is undefined then set 'camera system7T2 to 'camera system' / T 1;

[0082] Moreover, it should be noted that rules modifying the values of multiple attributes and variables will be attached to multiple dependency links in the attribute-dependency graph. Whereas each version of this rule will have a distinct rule action as described above, these versions all have the same rule condition. As such, part of the decision logic is duplicated, leading to additional effort for the rule engine.

[0083] One way to mitigate this slight overhead consists in regrouping decision nodes that are satisfying the following conditions: 1. The decision nodes have ingoing dependency links that are coming from the same nodes and that are labeled by the same rules. 2. The decision nodes have ingoing ownership links that are coming from the same node. 3. The decision nodes do not have any outgoing ownership link.

[0084] A regrouping operator checks whether the current attribute-dependency graph has such a group of decision nodes. If yes, it replaces them by a single decision node in the current attribute-dependency graph. The ingoing dependency links and ownership links will be delegated to this new node. Similarly, any outgoing dependency link from any node in the group will be delegated to the new node. Ingoing and outgoing version links will be delegated to the new node as well. The new node represents the values of multiple attributes or variables. The rules attached to the ingoing dependency links of the node will thus include all actions from the original rules that modify the values of these attributes or variables.

[0085] The application of the cycle-resolving operator and the regrouping operator results into a reorganized attribute-dependency graph, which describes a hierarchical decision policy involving decisions about attributes in addition to decisions about variables.

[0086] The attribute-dependency graph is then transformed into a variable-dependency graph. This is explained with reference to Figures 5A to 5D.

[0087] As a hierarchical rule-based decision policy should only decide the values of variables and not that of attributes, the disclosed method will transform the attribute-dependency graph into a variable-dependency graph. For this purpose, it will transform decision nodes for attributes into decision nodes for variables. These new variables will have composite values providing information about the owner of the attributes. Therefore, this transformation not only changes the dependency graph, but also the decision logic and introduces new type definitions.

[0088] The transformation requires several steps. In a first step, decision attributes are enriched by information about their owning objects. In a second step, ownership relations are reversed and transformed into dependency links. This transforms decision nodes for attributes into decision nodes for variables. In a third step, all input nodes for attributes are removed and their outgoing dependency links are delegated to their owner nodes.

[0089] These steps are changing the representation of the decisions and thus require new ways for accessing and modifying the values of these decisions by a rule. Therefore, the rules will be transformed as well and adapted to this new representation.

[0090] The attribute-dependency graph uses an object-oriented representation of decisions. Decisions for attributes are accessed via the owning object of the attribute, which may be the value of a variable or of another attribute. For example, Rule R3 has an expression “the lenses of 'camera system'. This expression accesses the value of the variable 'camera system', which is an object of type ‘Camera System'. Then it accesses the values of the multi-valued attribute “lenses” and iterates over its different values, which are objects of type ‘Lens’. Furthermore, it uses the expression ‘the lens type’ of ‘lens' in order to access the value of the attribute ‘lens type’ of this lens object. Rule R3 thus uses quite sophisticated instructions to access a first information about the camera system. However, it also accesses a second information about the same camera system, namely with the help of the expression “the sensor format of the body of 'camera system'”.

[0091] Rule R3 of task T2: for each lens called 'lens', in the lenses of 'camera system' if the lens type of 'lens' is wide-angle zoom and the sensor format of the body of 'camera system' is Full-Frame then set the focal length of 'lens' to ”20-35";

[0092] If the first and second information satisfy a condition, Rule R3 is applicable. It is important to note that the first and second information are about the same camera system. This constitutes another condition, which is implicitly expressed by the fact that both pieces of information are accessed via expressions that have a variable in common.

[0093] The resulting variable-dependency graph will use a flat representation of decisions in form of single-valued or multi-valued variables. A single-valued attribute may be represented by a multi-valued variable in this graph if its owning object is the value of a multi-valued attribute. For example, the attribute ‘lens type' is single-valued, but its owning object is a value of the multi-valued attribute ‘lenses'. If the camera system has a lens of lens type ‘wide-angle zoom' and another one of lens type ‘standard zoom', the multi-valued variable for the lens types will have the values ‘wide-angle zoom’ and ‘standard zoom’, but no information about the corresponding lenses. Similarly, there will be a multi-valued variable for the focal lengths and a single-valued variable for the sensor format.

[0094] Rule R3 could then be adapted as follows: for each lens type called 'lens type', in 'lens types' if 'lens type' is wide-angle zoom and 'sensor format' is Full-Frame then add ‘20-35’ to 'focal lengths';

[0095] There may be a similar rule adding a focal length of '24-70' for standard zooms. If the variable ‘lens types' has the values 'wide-angle zoom' and ‘standard zoom’, the variable ‘focal lengths' will have the values ‘20-35’ and ‘24-70’. But which value of the variable 'focal lengths' belongs to which value of the variable ‘lens types'? This information is not represented by these variables, which is problematic if some other rules refer both to the lens type and the focal length of the same lens object.

[0096] Information about the owner object therefore needs to be included in the values of the decision variables. The first step is achieving this by modifying the attribute-dependency graph and the rules associated to it. It will also create new type definitions. The disclosed system uses an operator for representing ownership information. This operator is applied to each decision node for attributes in the re-organized attribute-dependency graph. Each application of the operator modifies the current attribute-dependency graph, which is initialized by the re-organized attribute-dependency graph. The order in which the decision nodes are processed does not matter.

[0097] The operator will add ownership information to a decision node for an attribute by changing the type of the attribute. The new type is a composite type consisting of the original value as well as of the owner of the attribute. The operator will then adapt each rule to this new representation. Ingoing dependency links of the decision node are labeled with rules that modify the value of the attribute. Instead of just providing the new value, the modified rules will construct a new composite value consisting of this new value and the owner. For example, the operator will transform the rule action for setting the focal length to '20-35' into the following rule action that sets the focal length to a composite value with owner ‘lens’ and the value ‘20-35’: set the focal length of 'lens' to a new focal length where the value is '20-35', the owner is 'lens';

[0098] Outgoing dependency links of the decision node are labeled with rules that access the value of the attribute. In order to access the original value, the rules need to access the value of the attribute 'value' of the new composite type. The operator will therefore adapt the expression for accessing the value of the attribute ‘focal length’ by embedding it into an expression that accesses the value of the attribute ‘value’.

[0099] As the modified decision node embeds information about its owner, the operator adds a dependency link to the current attribute-dependency graph in order to reflect this dependency. It is important to note that the original owner is included in the composite value and not a version resulting from some modification by a rule-based task. The operator therefore adds the dependency link between the original version of the owner and the decision node of the attribute.

[00100] Figure 5A shows adding ownership information to decision attributes. Figure 5A resumes the example of Figure 3D. Its lower part shows the graph resulting from applying the operator to the decision node "Attribute2 / Task1 ” 314. The owner of this node is the decision node "Variable2 / Task1” 304. The original version of this node is the input node “Variable2” 305. The operator therefore adds a dependency link 511 between the node ‘‘Variable2” 305 to the node “Attribute2 / Task1 ” 314, thus reflecting the fact that the value of this decision node depends on the value of the node “Variable2” 305.

[00101] Once the operator for adding ownership information has been applied to all decision nodes for attributes, the current attribute-dependency graph is an attribute-dependency graph with explicit ownership information. The disclosed system will transform this graph into a variable-dependency graph. For this purpose, it applies an operator for eliminating ownership links to all decision nodes in the attribute-dependency graph with explicit ownership information. Each application of the operator modifies the current dependency graph, which is initialized by the attribute-dependency graph with explicit ownership information. The order in which the decision nodes are processed does not matter.

[00102] The operator will eliminate the ingoing ownership link of a decision node for an attribute by removing it from the current dependency graph and by replacing it with a dependency link leading from the decision node to the former owner node. This is illustrated in Figure 5B showing changing ownership relations into reverse dependencies, which continues the example of Figure 5A. The ownership link 512 leading from the node “Variable2 / Task1” 304 to the node “Attribute2 / Task1” 314 in the upper part of the Figure 5B is replaced as shown in the lower part of Figure 5B by a dependency link 513 leading from the node “Attribute2 / TaskT' 314 to the node “Variable2 / Task1” 304.

[00103] As a result of this modification, the attribute is transformed into a variable. The variable is multi-valued if the attribute is multi-valued or one of its direct or indirect owners is multi-valued. The operator will then adapt each rule to this new representation. Ingoing dependency links of the decision node are labeled with rules that modify the value of the attribute. The operator will transform the rule action into one that modifies the value of the variable (if it is single-valued) or that adds a value to the variable (if it is multi-valued). For example, it will change the action for setting the value of the single-valued attribute ‘focal length' into one that adds a value to the multi-valued variable ‘focal length / T2': add a new focal length where the value is '20-35', the owner is 'lens' to ‘focal length / T2’;

[00104] Outgoing dependency links of the decision node are labeled with rules that access the value of the attribute. The operator will transform the expressions that first access one of the direct or indirect owners of the attribute and then the value of the attribute by constructs that directly access the value of the variable (if it is singlevalued) or that iterate over all values of this variable (if it is multi-valued).

[00105] As the decision node no longer has an ingoing ownership link, an additional decision logic is needed to incorporate its value into the former owner. The operator has added a dependency link leading from the decision node to the former owner node for this purpose. Furthermore, it replaces the version link between the previous and current versions of the owner object by a dependency link. After this modification of the current dependency graph, the operator will change the type of the owner node to a composite type that contains the following information: • The original version of the owner object, which serves as an identity key, • The previous version of the owner object. • The owner of the owner object (if it has one). • The value of the attribute which is represented by the decision node.

[00106] If another application of the operator has already created this composite type, the operator will simply add the attribute that it currently processes. The operator will adapt each rule that accesses or modifies the value of the owner node in the way that has been described for the previous operator. In particular, the operator will modify the default rule that initialized the value of the owner node. For example, it will change the default rule for the node "’camera system7T2” as follows: definitions set 'lenses' to all lenses / T2 in lenses / T2 where the owner is 'camera system'; if 'camera system / T2' is undefined then set 'camera system 7T2 to a new camera system / T2 where the original value is 'camera system', the previous value is 'camera system' / T 1, the lenses is 'lenses';

[00107] This rule selects all values of the variable ‘lenses / T2’ that have as owner the value of variable ‘camera system'. It sets the value of variable ‘camera system / T2' to a composite value that includes the original value variable ‘camera system', its previous value, and the selected lenses.

[00108] Once the operator for eliminating ownership links has been applied to all decision nodes for attributes, the current dependency graph no longer has decision nodes for attributes. Nevertheless, it still has input nodes for attributes. The disclosed system simply removes these input nodes for attributes and delegates their outgoing dependency links to their owner. The disclosed system uses an operator for eliminating input nodes for attributes. This operator will modify the current dependency graph. It will check whether this graph has an input node for an attribute without outgoing ownership link. If it detects such an input node, it will retrieve the owner node of the input node. It will remove the ownership link between this owner node and the input node from the current dependency graph. Furthermore, it will retrieve each dependency link leading from the input node to a third node and replace it by a dependency link leading from the owner node to this third node.

[00109] Figure 5C removes input nodes for attributes and shows the result of the operator when being applied to input node “AttributeT’ 311. This node and its ingoing ownership link are removed in the lower part of Figure 5C. Moreover, the dependency link 514 leading from the node “AttributeT1 311 to the node “Attribute2 / Task1" 314 in the upper part of Figure 5C is replaced by a dependency link 515 leading from the node “VariableT’ 301 to the node “Attribute2 / Task1 ” 314 in the lower part of Figure 5C. However, there is another input node for an attribute shown in the upper part of Figure 5D, namely node “Attribute2” 315. This will be removed by another application of the operator and the result is shown in the lower part of Figure 5D.

[00110] Once the operator for eliminating ownership links has been applied to all decision nodes for attributes, the current dependency graph no longer has nodes for attributes. It therefore has the form of a dependency graphs between decision variables. It constitutes the dependency graph of a hierarchical rule-based decision policy.

[00111] A complete picture for a single dependency summarizing the transformations made is given by looking at Figure 3C (top part) as the full-fledged attribute-dependency graph and the lower part of Figure 5D which shows the resulting variable-dependency graph. Although this example is quite simplistic, it shows that the transformations are quite significant and difficult to achieve in a single step.

[00112] The main steps of the disclosed method will now be shown for the example of Figure 2A. Figure 2A shows the sequence of rule-based tasks that is given as input and the rules associated to these tasks were as follows:

[00113] Rule R1 of task T1: if the weight limit of the body of 'camera system' is 500g and the sensor format of the body of 'camera system' is Full-Frame then set the model of the body of 'camera system' to ‘mW;

[00114] Rule R2 of task T1: if the level of 'photographer' is professional then set the sensor format of the body of 'camera system' to Full-Frame;

[00115] Rule R3 of task T2: for each lens called 'lens', in the lenses of 'camera system' if the lens type of 'lens' is wide-angle zoom and the sensor format of the body of 'camera system' is Full-Frame then set the focal length of 'lens' to '20-35';

[00116] Figure 6A depicts the input nodes 600 for variables and attributes, which are created by the operators for creating nodes for variables and attributes. The decision nodes are not shown for the sake of simplicity. The operators create two copies of each node, namely one for Task T1 and the other one for Task T2.

[00117] Figure 6B shows the simplified attribute-dependency graph for the example. It neither has cyclic dependencies, nor multiple decision nodes that have ingoing dependencies labeled with the same rules. Hence, the re-organization step will not modify this simplified attribute-dependency graph. Therefore, the graph shown in Figure 6B also corresponds to the re-organized attribute-dependency graph.

[00118] Figure 2B shows the resulting dependency graph 210 between decision variables. All nodes for attributes have been eliminated, meaning that this graph can used by a wide range of tools supporting hierarchical rule-based decision policies.

[00119] The dependency links of the graph 610 of Figure 6B and the graph 210 of Figure 2B are labeled by the transformed rules R1’, R2’, and R3’:

[00120] Rule RT of task T1: if the weight limit of the body of 'camera system' is 500g and the sensor format of the body of 'camera system' is Full-Frame then set model / T 1 to a new model / T 1 where the owner is the body of 'camera system', the value is ‘m10’;

[00121] Rule R2’ of task T1: if the level of 'photographer' is professional then set sensor format / T 1 to a new sensor format / T 1 where the owner is the body of 'camera system', the value is Full-Frame;

[00122] Rule R3’of task T2: for each lens called 'lens', in the lenses of 'camera system' definitions set 'body' to a body / T1 from body / T1 where the owner is 'camera system'; set 'sensor format’ to a sensor format / T 1 from sensor format / T 1 where the owner is the value of 'body'; if the lens type of 'lens' is wide-angle zoom and the value of 'sensor format' is Full-Frame then add a new focal length / T2 where the owner is 'lens', the value is '20-35'; to focal length / T2;

[00123] Furthermore, the system has created default rules for all decision nodes. These rules are creating composite values that include information about the owner and the value if the decision node represents a primitive value. If the decision node represents an object value, the rules are creating composite values that include information about the owner, the original and previous values, and all attributes that have been decided.

[00124] Default Rule for camera system / T 1: definitions set 'body' to a body / T1 from body / T1 where the owner is 'camera system'; if 'camera system / TT is undefined then set 'camera system 7T1 to a new camera system / T 1 where the value is 'camera system', the body is 'body';

[00125] Default Rule for camera system / T2: definitions set 'lenses' to all lenses / T2 in lenses / T2 where the owner is 'camera system'; if 'camera system / T2' is undefined then set 'camera system 7T2 to a new camera system / T2 where the value is 'camera system' / T1, the lenses is 'lenses';

[00126] Default Rule for body / T1: definitions set 'model' to a model / T 1 from model / T 1 where the owner is the body of 'camera system'; set 'sensor format’ to a sensor format / T 1 from sensor format / T 1 where the owner is the body of 'camera system'; if body / T1 is undefined then set body / T1 to a new body / T 1 where the owner is 'camera system', the value is the body of 'camera system', the model is 'model', the sensor format is 'sensor format';

[00127] Default Rule for model / T1: if model / T1 is undefined then set model / T 1 to a new model / T 1 where the owner is the body of 'camera system', the value is the model of the body of 'camera system';

[00128] Default Rule for sensor format / T 1: if sensor format / T1 is undefined then set sensor format / T 1 to a new sensor format / T 1 where the owner is the body of 'camera system', the value is the sensor format of the body of 'camera system';

[00129] Default Rule for lenses / T2: for each lens called 'lens', in the lenses of 'camera system' definitions set 'focal length' to a focal length / T2 in focal lengths / T2 where the owner is 'lens'; if there is no lens / T2 in lenses / T2 where the value is 'lens' then add a new lens / T2 where the owner is 'camera system’, the value is 'lens', the focal length is 'focal length' to lenses / T2;

[00130] Default Rule for focal length / T 1: for each lens called 'lens', in the lenses of 'camera system' if there is no focal length / T2 in focal lengths / T2 where the owner is 'lens' then add a new focal length / T2 where the owner is 'lens', the value is the focal length of 'lens' to focal lengths / T2;

[00131] Again, these rules can be used by any tool supporting hierarchical rule-based decision policies.

[00132] Referring to Figure 7, a computer system 700 is shown at which the described decision graph generator system 710 may be provided for transforming rule-based methods of computer application logic into hierarchical decision graphs.

[00133] The computer system 700 may include at least one processor 701, a hardware module, or a circuit for executing the functions of the described components which may be software units executing on the at least one processor. Multiple processors running parallel processing threads may be provided enabling parallel processing of some or all of the functions of the components. Memory 702 may be configured to provide computer instructions 703 to the at least one processor 701 to carry out the functionality of the components.

[00134] The decision graph generator system 710 may include an input component 711 for accessing a sequence of rule-based tasks where rules are grouped into tasks and the tasks are executed in sequence. The input component 711 may include a rule-based task parsing component 712 for parsing the rule-based tasks to obtain syntax trees on which operators may be applied.

[00135] The decision graph generator system 710 may include an attribute-dependency graph building component 720 for building an attribute-dependency graph by analyzing object-oriented navigation of the rules in the tasks, where the attribute-dependency graph has nodes representing values of object variables and attributes that are accessed or modified by the rule-based tasks, with edges between the nodes of ownership links, version links, and rule dependency links.

[00136] The attribute-dependency graph building component 720 may include: a graph outline component 721 for creating an outline of the attribute-dependency graph containing all nodes for variables and attributes as well as ownership links between variables and attributes for same computational state and task version links; and a rule dependency adding component 722 for adding rule dependency links to the graph outline. The attributedependency graph building component 720 may include a simplifying component 723 for simplifying the attributedependency graph by removing superfluous nodes.

[00137] The decision graph generator system 710 may include an attribute-dependency graph reorganization component 730 for reorganizing the attribute-dependency graph by resolving cycles within a task based on rule order to obtain an acyclic graph.

[00138] The attribute-dependency graph reorganization component 730 may include a regrouping component 731 for regrouping decision nodes as a single node, where the regrouped nodes have ingoing dependency links that are coming from the same nodes and that are labeled by the same rules, have ingoing ownership links that are coming from the same node, and do not have any outgoing ownership link.

[00139] The decision graph generator system 710 may include a graph transforming component 740 for transforming the acyclic attribute-dependency graph into a decision variable-dependency graph as a hierarchical decision graph. The graph transforming component 740 may include a node transforming component 741 for transforming nodes for modified attribute values into nodes for decision variables which embed information about the owning object. The graph transforming component 740 may include a navigation adapting component 742 for adapting the navigation constructs of the rules in the tasks to the decision variable-dependency graph. The navigation adapting component 742 may reverse ownership relations and may transform these into dependency links to transform decision nodes for attributes into decision nodes for variables. The navigation adapting component 742 may remove all input nodes for attributes and may delegate their outgoing dependency links to their owner nodes.

[00140] The graph transforming component 740 may also include: a decision logic component 743 for introducing decision logic; and a type definition component 744 for providing new type definitions.

[00141] Various aspects of the present disclosure are described by narrative text, flowcharts, block diagrams of computer systems and / or block diagrams of the machine logic included in computer program product (CPP) embodiments. With respect to any flowcharts, depending upon the technology involved, the operations can be performed in a different order than what is shown In a given flowchart. For example, again depending upon the technology involved, two operations shown in successive flowchart blocks may be performed in reverse order, as a single integrated step, concurrently, or in a manner at least partially overlapping in time.

[00142] A computer program product embodiment ("CPP embodiment" or “CPP”) is a term used in the present disclosure to describe any set of one, or more, storage media (also called "mediums") collectively included in a set of one, or more, storage devices that collectively include machine readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP claim. A "storage device" is any tangible device that can retain and store instructions for use by a computer processor. Without limitation, the computer readable storage medium may be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these mediums include: diskette, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device (such as punch cards or pits I lands formed in a major surface of a disc) or any suitable combination of the foregoing. A computer readable storage medium, as that term is used in the present disclosure, is not to be construed as storage in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through a fiber optic cable, electrical signals communicated through a wire, and / or other transmission media. As will be understood by those of skill in the art, data is typically moved at some occasional points in time during normal operations of a storage device, such as during access, de-fragmentation or garbage collection, but this does not render the storage device as transitory because the data is not transitory while it is stored.

[00143] Referring to FIG. 8, computing environment 800 contains an example of an environment for the execution of at least some of the computer code involved in performing the inventive methods, such as decision graph generator system code 850. In addition to block 850, computing environment 800 includes, for example, computer 801, wide area network (WAN) 802, end user device (EUD) 803, remote server 804, public cloud 805, and private cloud 806. In this embodiment, computer 801 includes processor set 810 (including processing circuitry 820 and cache 821), communication fabric 811, volatile memory 812, persistent storage 813 (including operating system 822 and block 850, as identified above), peripheral device set 814 (including user interface (UI) device set 823, storage 824, and Internet of Things (loT) sensor set 825), and network module 815. Remote server 804 includes remote database 830. Public cloud 805 includes gateway 840, cloud orchestration module 841, host physical machine set 842, virtual machine set 843, and container set 844.

[00144] COMPUTER 801 may take the form of a desktop computer, laptop computer, tablet computer, smart phone, smart watch or other wearable computer, mainframe computer, quantum computer or any other form of computer or mobile device now known or to be developed in the future that is capable of running a program, accessing a network or querying a database, such as remote database 830. As is well understood in the art of computer technology, and depending upon the technology, performance of a computer-implemented method may be distributed among multiple computers and / or between multiple locations. On the other hand, in this presentation of computing environment 800, detailed discussion is focused on a single computer, specifically computer 801, to keep the presentation as simple as possible. Computer 801 may be located in a cloud, even though it is not shown in a cloud in Figure 8, On the other hand, computer 801 is not required to be in a cloud except to any extent as may be affirmatively indicated.

[00145] PROCESSOR SET 810 includes one, or more, computer processors of any type now known or to be developed in the future. Processing circuitry 820 may be distributed over multiple packages, for example, multiple, coordinated integrated circuit chips. Processing circuitry 820 may implement multiple processor threads and / or multiple processor cores. Cache 821 is memory that is located in the processor chip package(s) and is typically used for data or code that should be available for rapid access by the threads or cores running on processor set 810. Cache memories are typically organized into multiple levels depending upon relative proximity to the processing circuitry. Alternatively, some, or all, of the cache for the processor set may be located "off chip.” In some computing environments, processor set 810 may be designed for working with qubits and performing quantum computing.

[00146] Computer readable program instructions are typically loaded onto computer 801 to cause a series of operational steps to be performed by processor set 810 of computer 801 and thereby effect a computer-implemented method, such that the instructions thus executed will instantiate the methods specified in flowcharts and / or narrative descriptions of computer-implemented methods included in this document (collectively referred to as “the inventive methods"). These computer readable program instructions are stored in various types of computer readable storage media, such as cache 821 and the other storage media discussed below. The program instructions, and associated data, are accessed by processor set 810 to control and direct performance of the inventive methods. In computing environment 800, at least some of the instructions for performing the inventive methods may be stored in block 850 in persistent storage 813.

[00147] COMMUNICATION FABRIC 811 is the signal conduction path that allows the various components of computer 801 to communicate with each other. Typically, this fabric is made of switches and electrically conductive paths, such as the switches and electrically conductive paths that make up busses, bridges, physical input / output ports and the like. Other types of signal communication paths may be used, such as fiber optic communication paths and / or wireless communication paths.

[00148] VOLATILE MEMORY 812 is any type of volatile memory now known or to be developed in the future. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, volatile memory 812 is characterized by random access, but this is not required unless affirmatively indicated. In computer 801, the volatile memory 812 is located in a single package and is internal to computer 801, but, alternatively or additionally, the volatile memory may be distributed over multiple packages and / or located externally with respect to computer 801.

[00149] PERSISTENT STORAGE 813 is any form of non-volatile storage for computers that is now known or to be developed in the future. The non-volatility of this storage means that the stored data is maintained regardless of whether power is being supplied to computer 801 and / or directly to persistent storage 813. Persistent storage 813 may be a read only memory (ROM), but typically at least a portion of the persistent storage allows writing of data, deletion of data and re-writing of data. Some familiar forms of persistent storage include magnetic disks and solid state storage devices. Operating system 822 may take several forms, such as various known proprietary operating systems or open source Portable Operating System Interface-type operating systems that employ a kernel. The code included in block 850 typically includes at least some of the computer code involved in performing the inventive methods.

[00150] PERIPHERAL DEVICE SET 814 includes the set of peripheral devices of computer 801. Data communication connections between the peripheral devices and the other components of computer 801 may be implemented in various ways, such as Bluetooth connections, Near-Field Communication (NFC) connections, connections made by cables (such as universal serial bus (USB) type cables), insertion-type connections (for example, secure digital (SD) card), connections made through local area communication networks and even connections made through wide area networks such as the internet. In various embodiments, UI device set 823 may include components such as a display screen, speaker, microphone, wearable devices (such as goggles and smart watches), keyboard, mouse, printer, touchpad, game controllers, and haptic devices. Storage 824 is external storage, such as an external hard drive, or insertable storage, such as an SD card. Storage 824 may be persistent and / or volatile. In some embodiments, storage 824 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 801 is required to have a large amount of storage (for example, where computer 801 locally stores and manages a large database) then this storage may be provided by peripheral storage devices designed for storing very large amounts of data, such as a storage area network (SAN) that is shared by multiple, geographically distributed computers. loT sensor set 825 is made up of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.

[00151] NETWORK MODULE 815 is the collection of computer software, hardware, and firmware that allows computer 801 to communicate with other computers through WAN 802. Network module 815 may include hardware, such as modems or Wi-Fi signal transceivers, software for packetizing and / or de-packetizing data for communication network transmission, and / or web browser software for communicating data over the internet. In some embodiments, network control functions and network forwarding functions of network module 815 are performed on the same physical hardware device. In other embodiments (for example, embodiments that utilize software-defined networking (SDN)), the control functions and the forwarding functions of network module 815 are performed on physically separate devices, such that the control functions manage several different network hardware devices. Computer readable program instructions for performing the inventive methods can typically be downloaded to computer 801 from an external computer or external storage device through a network adapter card or network interface included in network module 815.

[00152] WAN 802 is any wide area network (for example, the internet) capable of communicating computer data over non-local distances by any technology for communicating computer data, now known or to be developed in the future. In some embodiments, the WAN 802 may be replaced and / or supplemented by local area networks (LANs) designed to communicate data between devices located in a local area, such as a Wi-Fi network. The WAN and / or LANs typically include computer hardware such as copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and edge servers.

[00153] END USER DEVICE (EUD) 803 is any computer system that is used and controlled by an end user (for example, a customer of an enterprise that operates computer 801), and may take any of the forms discussed above in connection with computer 801. EUD 803 typically receives helpful and useful data from the operations of computer 801. For example, in a hypothetical case where computer 801 is designed to provide a recommendation to an end user, this recommendation would typically be communicated from network module 815 of computer 801 through WAN 802 to EUD 803. In this way, EUD 803 can display, or otherwise present, the recommendation to an end user. In some embodiments, EUD 803 may be a client device, such as thin client, heavy client, mainframe computer, desktop computer and so on.

[00154] REMOTE SERVER 804 is any computer system that serves at least some data and / or functionality to computer 801. Remote server 804 may be controlled and used by the same entity that operates computer 801. Remote server 804 represents the machine(s) that collect and store helpful and useful data for use by other computers, such as computer 801. For example, in a hypothetical case where computer 801 is designed and programmed to provide a recommendation based on historical data, then this historical data may be provided to computer 801 from remote database 830 of remote server 804.

[00155] PUBLIC CLOUD 805 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer capabilities, especially data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically leverages sharing of resources to achieve coherence and economies of scale. The direct and active management of the computing resources of public cloud 805 is performed by the computer hardware and / or software of cloud orchestration module 841. The computing resources provided by public cloud 805 are typically implemented by virtual computing environments that run on various computers making up the computers of host physical machine set 842, which is the universe of physical computers in and / or available to public cloud 805. The virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine set 843 and / or containers from container set 844. It is understood that these VCEs may be stored as images and may be transferred among and between the various physical machine hosts, either as images or after instantiation of the VCE. Cloud orchestration module 841 manages the transfer and storage of images, deploys new instantiations of VCEs and manages active instantiations of VCE deployments. Gateway 840 is the collection of computer software, hardware, and firmware that allows public cloud 805 to communicate through WAN 802.

[00156] Some further explanation of virtualized computing environments (VCEs) will now be provided. VCEs can be stored as "images.” A new active instance of the VCE can be instantiated from the image. Two familiar types of VCEs are virtual machines and containers. A container is a VCE that uses operating-system-level virtualization. This refers to an operating system feature in which the kernel allows the existence of multiple isolated user-space instances, called containers. These isolated user-space instances typically behave as real computers from the point of view of programs running in them. A computer program running on an ordinary operating system can utilize all resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and devices assigned to the container, a feature which is known as containerization.

[00157] PRIVATE CLOUD 806 is similar to public cloud 805, except that the computing resources are only available for use by a single enterprise. While private cloud 806 is depicted as being in communication with WAN 802, in other embodiments a private cloud may be disconnected from the internet entirely and only accessible through a local / private network. A hybrid cloud is a composition of multiple clouds of different types (for example, private, community or public cloud types), often respectively implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technology that enables orchestration, management, and / or data / application portability between the multiple constituent clouds. In this embodiment, public cloud 805 and private cloud 806 are both part of a larger hybrid cloud.

[00158] The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

[00159] Improvements and modifications can be made to the foregoing without departing from the scope of the present invention.

Claims

1. A computer-implemented method for transforming rule-based methods of computer application logic into hierarchical decision graphs, said method comprising:accessing a sequence of rule-based tasks where rules are grouped into tasks and the tasks are executed in sequence;building an attribute-dependency graph by analyzing object-oriented navigation of the rules in the tasks, where the attribute-dependency graph has nodes representing values of object variables and attributes that are accessed or modified by the rule-based tasks, with edges between the nodes of ownership links, version links, and rule dependency links;reorganizing the attribute-dependency graph by resolving cycles within a task based on rule order to obtain an acyclic graph; andtransforming the acyclic attribute-dependency graph into a decision variable-dependency graph as a hierarchical decision graph.

2. The method of claim 1, wherein transforming the acyclic attribute-dependency graph into a decision variable-dependency graph includes:transforming nodes for modified attribute values into nodes for decision variables which embed information about the owning object;adapting the navigation constructs of the rules in the tasks to the decision variable-dependency graph; and introducing decision logic and new type definitions.

3. The method of claim 2, wherein adapting the navigation constructs includes:reversing ownership relations and transforming into dependency links to transforms decision nodes for attributes into decision nodes for variables.

4. The method of claim 1, wherein adapting the navigation constructs includes:removing all input nodes for attributes and delegating their outgoing dependency links to their owner nodes.

5. The method of claim 1, wherein building an attribute-dependency graph includes:creating an outline of the attribute-dependency graph containing all nodes for variables and attributes as well as ownership links between variables and attributes for same computational state and task version links; andadding rule dependency links to the graph outline.

6. The method of claim 5, building an attribute-dependency graph includes simplifying the attributedependency graph by removing superfluous nodes.

7. The method of claim 1, wherein reorganizing includes regrouping decision nodes as a single node, where the regrouped nodes have ingoing dependency links that are coming from the same nodes and that are labeled by the same rules, have ingoing ownership links that are coming from the same node, and do not have any outgoing ownership link.

8. The method of claim 1, wherein a resulting decision variable-dependency graph has a flat representation of decisions in the form of single-valued or multi-valued variables, where a single-valued attribute is represented by a multi-valued variable in the graph if its owning object is the value of a multi-valued attribute.

9. The method of claim 1, wherein building an attribute-dependency graph parses the rule-based tasks to obtain syntax trees and applies operators on the syntax trees.

10. The method of claim 9, wherein operators include:a first operator creates nodes for variables;a second operator creates nodes for attributes;an operator for creating dependency links for each rule of each rule-based task;a simplification operator; andan operator for resolving cyclic dependencies to each rule-based task.

11. A system for transforming rule-based methods of computer application logic into hierarchical decision graphs, comprising:a processor and a memory configured to provide computer program instructions to the processor to execute the function of the components:an input component for accessing a sequence of rule-based tasks where rules are grouped into tasks and the tasks are executed in sequence;an attribute-dependency graph building component for building an attribute-dependency graph by analyzing object-oriented navigation of the rules in the tasks, where the attribute-dependency graph has nodes representing values of object variables and attributes that are accessed or modified by the rule-based tasks, with edges between the nodes of ownership links, version links, and rule dependency links;an attribute-dependency graph reorganization component for reorganizing the attribute-dependency graph by resolving cycles within a task based on rule order to obtain an acyclic graph; anda graph transforming component for transforming the acyclic attribute-dependency graph into a decision variable-dependency graph as a hierarchical decision graph.

12. The system of claim 11, wherein the graph transforming component includes:a node transforming component for transforming nodes for modified attribute values into nodes for decision variables which embed information about the owning object;a navigation adapting component for adapting the navigation constructs of the rules in the tasks to the decision variable-dependency graph.

13. The system of claim 11, wherein the navigation adapting component includes reversing ownership relations and transforming into dependency links to transforms decision nodes for attributes into decision nodes for variables.

14. The system of claim 11, wherein the navigation adapting component includes removing all input nodes for attributes and delegating their outgoing dependency links to their owner nodes.

15. The system of claim 11, wherein the graph transforming component includes:a decision logic component for introducing decision logic; and a type definition component for providing new type definitions.

16. The system of claim 11, wherein the attribute-dependency graph building component includes:a graph outline component for creating an outline of the attribute-dependency graph containing all nodes for variables and attributes as well as ownership links between variables and attributes for same computational state and task version links; anda rule dependency adding component for adding rule dependency links to the graph outline.

17. The system of claim 11, wherein the attribute-dependency graph building component includes: a simplifying component for simplifying the attribute-dependency graph by removing superfluous nodes.

18. The system of claim 11, wherein the attribute-dependency graph reorganization component includes aregrouping component for regrouping decision nodes as a single node, where the regrouped nodes have ingoing dependency links that are coming from the same nodes and that are labeled by the same rules, have ingoing ownership links that are coming from the same node, and do not have any outgoing ownership link.

19. The system of claim 11, including a rule-based task parsing component for parsing the rule-based tasks to obtain syntax trees to which operators are applied.

20. A computer program product for transforming rule-based methods of computer application logic into hierarchical decision graphs, the computer program product comprising a computer readable storage mediumhaving program instructions embodied therewith, the program instructions executable by a processor to cause the processor to:access a sequence of rule-based tasks where rules are grouped into tasks and the tasks are executed in sequence;build an attribute-dependency graph by analyzing object-oriented navigation of the rules in the tasks, where the attribute-dependency graph has nodes representing values of object variables and attributes that are accessed or modified by the rule-based tasks, with edges between the nodes of ownership links, version links, and rule dependency links;reorganize the attribute-dependency graph by resolving cycles within a task based on rule order to obtain an acyclic graph; andtransform the acyclic attribute-dependency graph into a decision variable-dependency graph as a hierarchical decision graph.36

Images