In explaining kBridge, we are going to start with the basics and build as we go. At its core, kBridge Rules are based on a language that is declarative, demand-driven, and implements dependency directed evaluation.
That is all technical terminology to say that the approach has some similarities to Excel (but extends it well beyond Excel into the engineering world). In Excel, when you make a formula with an ‘=’ sign, you are making a declaration about the relationship between cells. In the example below, the simple declaration ‘= A2*B2’ in C2 declares a relationship between A2, B2, and C2 — the content of C2 is the product of A2 x B2. Excel keeps track of this relationship for you, so that if A2 changes, then C2 updates. And if C2 is used in any other formula, that cell will also update and so on. These are what we refer to as dependencies.
In kBridge, instead of cells of a spreadsheet, we have properties associated with engineering objects. Each property is like the cell of a spreadsheet and has a formula associated with it. That formula relates this property to other properties. The formula of a property together with other information that controls the type and behavior of the property are referred to as a Rule.
The Name of a Rule is equivalent to the address of a cell in Excel. The Area value of the Excel example is found in cell C2, and you can reference it in a formula by "C2." In kBridge, this would be named "Area." Just as in Excel, to obtain the value of C2, it must get the values of A2 and B2 and multiply them. In doing this it forms a dependency tree, where each value knows what was required to compute it.
Demand-driven execution
In Excel, when you change A2, ALL cells recompute their values. In kBridge, only Area will need to be recomputed, because the system knows it depends on A2. Because of this, it does only as much work as necessary to answer any question that is asked of it. For example, asking to show a model of a table demands the size, location, and orientation of each object in the model, but it does not need to know the cost. So, if there are Rules that are used to calculate the cost, those Rules will not be executed; they will not be ‘demanded’ until they are needed.
As we mentioned, engineers think in terms of objects, not spreadsheets (like accountants). In kBridge, related Rules are grouped together in a Design. A Design can have any number of Rules associated with it.
For example, if we have a Design of a table top, it might have Rules like Length, Width, Height, Material, etc. Although there is nothing that forces us to put any particular Rules with any object, it helps our ability to understand a solution if the Designs represent common engineering objects and the Rules associated with those Designs represent the expected properties of those engineering objects.
[Insert pic of table model tree]
This is a good time to introduce the concepts of Design vs. Model. These concepts are fundamental to kBridge and are important for you to understand and use kBridge effectively.
A Design contains the Rules for defining an object; a Design is a recipe for how to make that object. For example, if we have a Table Top Design, with Rules for length, width, height, location, and orientation, then that Design can be used to make many table tops with many different specific sizes, locations, and orientations.
If we provide the Table Top Design with input values so that it can calculate the specific size and location of a specific table top, then that specific table top is referred to as a Model. A Model is one specific instance of a Design.
In our simple Excel example, the formula ‘= A2 * B2’ is a Rule, expressed as a formula in C2. When A2 = 10 and B2 = 20, then the instance of C2 is 200.
