0

I need to find a software architecture to support object configuration and validation in a dynamic environment.

Lets say I want to configure a bike where I have many physical components available to be used. Componentes like, tires, frame, gears, brakes, etc. And each of this components have their own attributes, for example:

  • Tires
    • Name
    • Profile
  • Gears
    • Material
    • Number of speeds
  • Frame
    • Color
    • Size

Besides that, there are physical and conceptual rules that defines how components can be combined between themselves to produce a bike. For now I now that truth-tables are an inicial approach to solve this problem, where I can indicate how components can be related. For example:

|-----------------------------------------|---------------|
|                    Input                | Output        |
| Tires(profile) | Gears (numberOfSpeeds) | Frame (size)  |
|----------------|------------------------|---------------|
| 21 mm          | 4 speeds               | 21"           |
| 22 mm          | 6 speeds               | 22"           |
| 22 mm          | 8 speeds               | 23"           |
|----------------|------------------------|---------------|

It means, if the user sends for the rule engine the values profile=22 mm and numberOfSpeeds=6 speeds, then the engine will define the frame size=22". However, when a new attribute is added in the truth-table to support a specific configuration, how I can support all previous conditions without modifying them and attending the specific case?

For example, there is a new configuration that is specific for gears material:

|------------------------------------------------------------|---------------|
|                               Input                        | Output        |
| Tires(profile) | Gears (numberOfSpeeds) | Gears (material) | Frame (size)  |
|----------------|------------------------|------------------|---------------|
| 21 mm          | 4 speeds               |                  | 21"           |
| 22 mm          | 6 speeds               |                  | 22"           |
| 22 mm          | 8 speeds               |                  | 23"           |
| 22 mm          | 8 speeds               | Carbon           | 24"           |
|----------------|------------------------|------------------|---------------|

How I can guarantee the previous rules execution without refactoring them (adding specific values or new lines for the gears material or frames less than 24)?

  • Does the new attribute constrain any of the previous conditions? – Robert Harvey Aug 15 at 20:00
  • Yes, in the following way. As "carbon" wasn't considered in the previous records, then the negation of "carbon" hold for them. For example, if the user informs profile=22 mm, numberOfSpeeds=8 and material=steel then frame size=23" should be found. But if the profile=22 mm, numberOfSpeeds=8 and material=carbon then frame 24" holds. Basically, we try to find the most specific record. – João Pedro Schmitt Aug 16 at 10:23
0

This depends a bit on the semantics of your rule engine and on what you mean with "guarantee the previous rule execution". For example, the initial table did not consider gears material at all. This would imply that it's irrelevant, and a carbon gears bike would have the same 23" frame size as a non-carbon gears bike. Under the new rules, it is unclear whether the bike would be required to have a 24" frame or could have either 23" or 24" because the last two lines match (if the rule engine treats empty values in the material column as don't care).

If the number of possible combinations is still small, you could programmatically create a list of all of them and keep a flag for each saying whether this is allowed under the old rules (by evaluating the old rule engine, so no manual and error-prone input). Then after you extend the rule engine, you can run all the listed combinations through it and check whether they still give the same results. If you see differences, you need to decide whether these are regressions or intended consequences of your rule changes.

  • Your suggesting is to use a flag (that could be a counter) to control what rule has priority over the others. Therefore, when different results are found, who is creating the new rule must select what rule should be prioritized. Now I need an efficient way to test what rules will be impacted by the new rule.Should I test the new rule engine using only attributes of the new rule known in the previous rule engine. Therefore, rules must prioritized based on the returned differences. – João Pedro Schmitt Aug 16 at 10:51
  • No, actually I just recommend to keep a complete list of all rule evaluation results so you could check for which inputs the results have changed when you use new rules or a modified rule engine. Priority settings in the rules might be helpful to get consistent results, but it's not really part of the mechanism to detect evaluation differences after rule changes. – Hans-Martin Mosner Aug 16 at 11:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.