Category: Rule Design

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation #2

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation #2

In a previous post by our guest writer Dr Jason Sender, he investigated improvements in Oracle Policy Automation rules by applying some of the principles of refactoring, and then he began to discuss Object-Oriented Design Patterns and Oracle Policy Automation, and their application in real-world contexts.

As before, this third article draws on the work and publications of Martin Fowler, which we discussed in the previous post, those of Joshua Kerievsky from his highly regarded book “Refactoring to Patterns”, and the ground-breaking work on design patterns called “Design Patterns: Elements of Reusable Object-Oriented Software”, which had four authors known collectively as the Gang of Four (GoF).

Before studying some further examples of patterns and their application to Oracle Policy Automation, it is probably wise to step back and take a broad view of the context. Computer science is often defined as dealing in abstraction, and software engineering as managing complexity, and the connection is that only by considering different parts of programs and systems as abstract concepts are we better able to manage complexity.

Design Patterns and Oracle Policy Automation in Context

To put it in terms more related to our daily jobs, Oracle Policy Automation is often integrated with other systems that the Oracle Policy Automation developer does not need to understand, and can think of in abstract terms. A good example would be the Siebel CRM or Oracle Service Cloud database that Oracle Policy Automation may interact with, but about which the Oracle Policy Automation developer may not need to know anything – beyond understanding the available attributes for mapping and having a brief overview of the context. Abstraction is about ignoring irrelevant details, and this is often accomplished by what is a theme running through many design patterns, which is to: “encapsulate the concept that varies” (GoF, p. 54).

We often obtain abstraction in Oracle Policy Automation by using indirection (interposing an intermediate attribute) to encapsulate the attribute that varies. This allows us to “Program to an interface, not an implementation“, as the GoF (p. 18) term it, the rationale for which is that the implementation can be changed if other parts of the program only depend on the interface.

If you come, like some of us here on the OPA Hub Website, from a CRM background, you will be familiar with the concept whereby access to a CRM Object is provided through an interface, and the interface does not change even if the Object undergoes modifications (such as when using the GetMetadata Operation of the Oracle Policy Automation Connector Framework).

Although design patterns and refactoring techniques should serve the goals of reduced duplication, reduced complexity, and increased clarity, these goals can be in conflict, not just with each other, but with certain Oracle Policy Automation-specific goals. Take for example one of the stand-out benefits of Oracle Policy Automation: Policy Isomorphism. This means having the same form (i.e., you can copy and paste legislation or other source material directly into Microsoft Word, and base your rules on this and compare them side-by-side) and this is in tension with the concept of intermediate attributes (adding more attributes to increase clarity).

Design Patterns and Oracle Policy Automation : Strategy and Template Patterns

With that in mind we return to another example of how Object-Oriented Design patterns can be applied to Oracle Policy Automation. The following extended example will be given to demonstrate how useful the Strategy and Template Method design patterns (which we adapt from the GoF book) could be in reducing the number of tables and increasing the flexibility of calculations. We show this extended example to demonstrate the size of the reduction in rules from applying these design patterns to Oracle Policy Automation. We start with an information collection screen and associated Boolean rules to derive values from the drop down list items:

Example Model and Interview

We then look at the top level goals for determining the total profit of the company, which is our main goal:

Design Patterns and Oracle Policy Automation

These are then derived from three very similar tables of calculations, which are listed in succession below:

Table of Conclusions

Object-Oriented Design Patterns and Oracle Policy Automation 4

Object-Oriented Design Patterns and Oracle Policy Automation 5

Design Patterns with OPA : Implementing the Design Pattern

We can now alter this to implement our design pattern. We first create a main rule to determine the total profit:

Object-Oriented Design Patterns and Oracle Policy Automation 6

This is the Template Method pattern since it delegates a part of the algorithm – the tax factor, a newly created attribute. Then, we employ the Strategy pattern to effectively split up the tax factor into one of three algorithms (in effect, we are treating the tax factor as an algorithm and then applying Strategy to it). We do this by parameterising, based on type of company, using a feature called Apply Sheet that avoids multiply proven attributes by letting the parameter determine which Excel Worksheet applies:

Object-Oriented Design Patterns and Oracle Policy Automation 7

Then each of the subsequent tabs has a small table. As an example, here is the mining sheet. The others have identical structure and adjusted values for the tax factor.

Object-Oriented Design Patterns Example

For the Strategy and Template Method patterns, applying these design patterns has transformed our example rulebase into something much more easily extensible.

Improved Maintenance and Clarity

If we were to create another sector (e.g., oil), it would be very easy to add on another sheet in the Excel Workbook and add it to the Apply Sheet. In fact, we could easily add another 20 sectors, whereas there would be a lot of time-consuming ‘find and replace’ work to do in the original, and we would have ended up with dozens of pages of rules. Moreover, the original algorithm had a lot of code duplication, as the same Boolean attributes were repeated in row after row in table after table.

Furthermore, if we had needed to add or remove conditions from the tables it would have taken extensive work in order to verify that each and every table was updated correctly. In the reformed algorithm, the conditions were written only once and these are easily changeable. And, we were able to eliminate three (possibly confusing) and unnecessary sub-totals relating to each of the company types. The unvarying part of the algorithm (the total revenue – the total cost) is now written once, rather than 15 times, and so it is easily changeable.

Finally, our new algorithm mentions only the tax factor. This means that if all tax rates were harmonised, a single tax rate declared, or a new formula implemented that did not depend on the company type, since we have encapsulated the part of the algorithm that varies, we could just delete the Excel table and introduce a new table for the tax factor that did not mention the type of company. This would not have been so easy to do with the original algorithm.

Once again, even from a very simple set of examples, it should be clear that Oracle Policy Automation rules will benefit from the targeted application of principles from programming – in this case, the Strategy and Template Method design patterns. For more information about the ideas discussed in this article, Dr Sender can be reached using his LinkedIn profile, at the end of this article.

Design Patterns and Oracle Policy Automation : Going Further

The OPA Hub and Dr Sender are currently working towards the launch of advanced training based on his work. If you are interested, please take a moment to answer the 1 question survey below (if you have not already registered for the OPA Hub you can do that here before you answer). Thank you!

What kind of advanced OPA training would you be interested in attending?

Back to Basics Fun with Relationships

Back to Basics Fun with Relationships

The other day I had cause to discuss Relationships with an Oracle Policy Automation developer, and as a result of the discussions and the level of interest expressed in the learning curve, I thought I would share here the project that I used to illustrate some of the main concepts used when working with them in an Interview. Firstly, to put Back to Basics Fun with Relationships in context, here are the entities we will discuss :

  • Global (of course)
  • the car
  • the passenger

The entities are in part received from another system, and look like this:

To simulate the external system in this demonstration, the data for the cars is coming from a Microsoft Excel spreadsheet which infers various vehicles. The passengers are manually entered in the Interview and then different relationships are using to construct the connections between the cars and the passengers. In this case, we need to identify the passengers in each car (which has been called the car’s passengers here), and then to specify which passenger is sitting in the front seat (which has been called the copilot here). So the car entity has the following reference relationships, both of them with the passenger but of different cardinality.

Back to Basics Fun with Relationships 3

When we look at the first two Screens there is not much to report. The first displays the cars and the second gets the passengers.

Back to Basics Fun with Relationships Cars Back to Basics Fun with Relationships Passengers

The third Screen is where some students can go wrong. The key is to display the relationship (the car’s passengers) . In the case shown, a label has been added to display the car name. Notice how the choice of display is limited to Checkbox because of the cardinality of the relationship. This makes for a situation where the user can choose the passengers and of course a passenger can only be in one car. Selecting the same passenger for two cars produces an error (as it should, even if the error message is generic).

Back to Basics Fun with Relationships Choose Passengers

  1. The relationship is added to the Screen
  2. The selection control is displayed
  3. Only Checkbox is available

The Screen looks like this in the Debugger:

Back to Basics Fun with Relationships Selecting Passengers for Cars

Finally, the fourth Screen will allow the selection of one of the passengers to be assigned as the front seat passenger (a.k.a the copilot). The Screen is displayed below and the key areas highlighted:

  1. Again we add the relationship to the Screen
  2. The cardinality means the default display option is a Drop-down, although others are available in the Toolbar this time (fixed list or radio buttons). I wish these were customizable using Control Extensions but they are not…as of 18A.
  3. The display will allow you to select a copilot, and filtering the data ensures that only passengers of the correct car are available. In this way, the first relationship (the car’s passengers) drives the second (the copilot).

The Screen looks like this in the Debugger:

Back to Basics Fun with Relationships Copilot

Finally there was a requirement to associate the copilot with the car in a more direct fashion. Specifically, the car entity had attributes to contain the name of the copilot. The basics (not complete) of this are shown below:

Back to Basics Fun with Relationships Mapping

So the car has a front seat occupant boolean attribute and the value is retrieved from the passenger entity and the copilot relationship and copied into the car attribute. The relationships and the entities allow us to retrieve data in the structure and place it in the car.

Back to Basics Fun with Relationships Data Tab

Hopefully this example will let you imagine how relationships can be used to enhance your Oracle Policy Modelling. I hope you enjoyed this Back to Basics Fun with Relationships post. As always the official Oracle Policy Automation documentation can be found here.

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation

In a previous post by our guest writer Dr Jason Sender, he investigated improvements in Oracle Policy Automation rules by applying some of the principles of refactoring. Hopefully the short examples he gave revealed some of the increases in readability, maintenance and flexibility that you can build into your rules.Now, in the second article in this series, Dr Sender looks at Object-Oriented Design patterns and Oracle Policy Automation. This article draws on the work and publications of Martin Fowler, which we discussed in the previous post, and those of Joshua Kerievsky from his highly regarded book “Refactoring to Patterns”.

Design Patterns

Kerievsky makes two very important observations on design patterns. His first point is that, as he terms a section heading, “There are many ways to implement a pattern.” (Kerievsky, p. 26). This is key to what we shall see in this article, since with Oracle Policy Automation we should be aiming at implementing the core concept of a given design pattern, rather than strictly following the implementation example given in GoF (1995).

Design Patterns: Elements of Reusable Object-Oriented Software is a software engineering book describing software design patterns. It has been influential to the field of software engineering and is regarded as an important source for object-oriented design theory and practice…The authors are often referred to as the Gang of Four (GoF) (Wikipedia).

The second key point that Kerievsky (p. 32) makes is that: “In general, pattern implementations ought to help remove duplicate code, simplify logic, communicate intention, and increase flexibility. However…people’s familiarity with patterns plays a major role in how they perceive patterns-based refactoring.” So we see here both our aims in using design patterns, and a constraint (developer knowledge). Since OPA does not have objects and classes in the same sense as an object-oriented language, we should not expect a straightforward application to OPA.

In this article we will focus on one single pattern, known as the Adapter pattern.

Summary: “Convert the interface of a class into another interface clients expect.
Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.” (GoF, p. 139)

Let’s look at applying the Adapter pattern to Oracle Policy Automation rules.  At one level, translation is possible; Oracle Policy Automation can translate all its attributes into another language so that the rules can be used once and deployed in multiple languages just by translating the variables, statements, and similar features, while not rewriting the rules. This example from Oracle (2016) demonstrates this:

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation

As a second example, we can make a variable equal to another variable, or a Boolean true if another Boolean is true. For example:

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation 2

Here we have adapted the ‘the sky is blue’ to ‘the sun is shining’ (but not vice versa) and adapted ‘the value of the car’ to ‘the value of the vehicle’ (but not vice versa). It might be thought that this is pretty simplistic and not all that useful. The following example highlights more complexity, and, instead of simply adapting the interface, as the above examples do, it goes beyond that to override some of the adaptee’s behaviour:

 

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation 3

 

Here we have adapted the interface from ‘the storey of the building’ to two different interfaces, ‘the lift floor’ and ‘the elevator floor’. British lifts start at 0 (or G) and US elevators start on the 1st floor and do not have a 13th floor. So not only have we changed the interface, we have adapted the behaviour. The new variables can be used elsewhere in the policy model in place of the original one.

Object-Oriented Design Patterns and Oracle Policy Automation : Adapter Pattern Summary

The Adapter pattern seems “made for OPA”. When discussing the Adapter pattern the GoF (p. 142) stress that:

“Adapters vary in the amount of work they do…There is a spectrum of possible work, from simple interface conversion – for example, changing the name of operations – to supporting an entirely different set of operations.”

The examples shown in this article illustrated three aspects:

  • The first adapted the language that users would see
  • The second was an example of changing the name of an operation
  • The third supported a different operation but was also an Oracle Policy Automation-specific variant of what the GoF (1995) term “two-way adapters”, since it adapted two variables from one underlying one.

Each of the three examples has different costs and benefits. The language translation tightly couples the adaptee and adapter, while the changing of the name allows for the other variable to change how it is derived without changing the adapter (i.e., a level of indirection).

It is important to note that the one-way variable name change or Boolean name change simply allow a new term to be used, but these might very well be used in more complicated ways in rule tables (for variables) or rules (for a Boolean) where the adaptee’s value equalled the adapter’s value only in certain circumstances. The two-way adapter allowed for a single variable to be used to provide multiple adapters, thus minimizing code duplication.

The Bigger Picture

It’s worth stepping back at this point to understand the broader context.  Computer science is often defined as dealing abstraction, and software engineering as managing complexity, and the connection is that only by considering different parts of programs and systems as abstract concepts are better able to manage complexity.  For example, Oracle Policy Automation is often integrated with other systems that the Oracle Policy Automation  developer does not need to understand, and can think of in the abstract, like the database that Oracle Policy Automation may interact, but which the Oracle Policy Automation developer may not need to know anything about beyond mapping attributes in Oracle Policy Automation.

So abstraction is about ignoring irrelevant details, and this is accomplished by what is often the theme running through many design patterns, which is to: “encapsulate the concept that varies” (GoF, p. 54).  We often obtain abstraction in Oracle Policy Automation by using indirection (interposing an intermediate attribute) to encapsulate the attribute that varies.  This allows us to “Program to an interface, not an implementation“, as the GoF (p. 18) term it, the rationale for which is that the implementation can be changed if other parts of the program only depend on the interface.

Once again, even from a very simple set of examples, it should be clear that Oracle Policy Automation rules will benefit from the targeted application of principles from programming – in this case Object-Oriented Patterns. The best approach is not a slavish application, rather a pragmatic use of those best-suited to the unique nature of the Oracle Policy Automation platform.

For more information about the ideas discussed in this article about Object-Oriented Design Patterns and Oracle Policy Automation, Dr Sender can be reached using his LinkedIn profile, below. Look out for more articles about Object-Oriented Design Patterns and Oracle Policy Automation coming soon!

Guest Post : Refactoring in Oracle Policy Automation #1

Refactoring in Oracle Policy Automation #1

The OPA Hub Website is extremely happy and very lucky to be able to welcome an esteemed guest author, Dr Jason Sender. Over the course of several months I have had the pleasure of reading Dr Sender’s work and conversing with him. His dissertation, entitled “The Application of Design Patterns to Oracle Policy Automation”, is a fascinating read and after due discussion with him, he has kindly agreed that parts of it might be republished here for the wider community; specifically in this article, an introduction to his excellent work on Refactoring in Oracle Policy Automation.

Dr Sender, of the University of Oxford, was Rules Architect for nearly four years on the most complex Rulebase used by the Legal Aid Agency in the United Kingdom, which is used to determine capital and income eligibility of applicants.

In this, the first of a series of posts, he looks at Refactoring Techniques based on Martin Fowler’s work and applies them to Oracle Policy Automation where appropriate. To simply state the goal of such an exercise, it can do no harm to state the goal of the book I just linked to:

“Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which “too small to be worth doing”. However the cumulative effect of each of these transformations is quite significant. “

How to Apply Object-Oriented Design Patterns to OPA?

At a broader level, it is possible to apply design patterns from Object-Oriented Design Patterns to OPA. Since OPA does not have objects and classes in the same sense as an object-oriented language, we should not expect a straightforward application to OPA. Not all of the patterns will be technically applicable, and even some of those will be unfeasible or without any great impact. Dr Sender’s work discusses the application of the eight most common patterns. If you would like to read further on this matter, please feel free to contact Jason using the information at the end of this article.

Improving your design Approach to OPA Rulebases

Object-Oriented languages come equipped with advanced development environments and a plethora of automation tools to help the refactoring effort. Oracle Policy Automation uses Microsoft Word and Excel, and is classified as a Production Rules System rather than a fully-fledged object-oriented language. As Fowler states (since it is particularly relevant to our daily lives as Oracle Policy Automation Consultants or Architects):

“There are also many languages where you don’t have tools, so knowing how to do it yourself is still important.”

The Application of Object-Oriented Refactoring in Oracle Policy Automation

This introductory article will focus on simple refactoring techniques that everyone can adopt, and which bring clarity and maintainability to Oracle Policy Automation rules. In a later article, Dr Sender will reveal OPA-specific refactoring techniques that were discovered during the course of his work.

Extract Variable Rule

Extract Variable Rule is a more meaningful OPA rebranding of Fowler’s Extract Method, since OPA does not have Methods. Have you ever seen something like this in an Oracle Policy Automation Word document?

Refactoring in Oracle Policy Automation - Extract

By applying the Extract Method: “You have a code fragment that can be grouped together. Turn the fragment into a method whose name explains the purpose of the method.” we find ourselves with a revised version that looks a little like the example below.

Refactoring in Oracle Policy Automation - Extract Example Complete

The gain in readability and ease of maintenance should be obvious. Now that Dr Sender has gotten us on the right track, let’s take a couple more examples from his work. These revolve around the removal of conditional expressions from Microsoft Word or Microsoft Excel tables.

Extract Rules from Rule Table

Extract Rules from Rule Table is a more meaningful OPA rebranding of Fowler’s Decompose Conditional Method. Consider the following table, where conditions and premises meet convoluted conclusions:

Refactoring in Oracle Policy Automation - Decompose Conditional

Now, here is the table, following an OPA-esque application of the Decompose Conditional refactoring technique, for situations where (according to Fowler):

You have a complicated conditional (if-then-else) statement. Extract methods from the condition, then part, and else parts.

Refactoring in Oracle Policy Automation - Decompose Conditional Complete

The aim of Extract Rules from Rule Table is to reduce code duplication and/or duplicated conclusion values.  It should be noted that it can add a level of indirection (i.e., flexibility) too, but its main use would be to extract duplicated rules from a complicated Word rule table, not, as in the example above, to extract only the conditions and conclusions of a single row, which arguably would add indirection at the cost of more code, unneeded flexibility, and complexity.

We would look to refactor to simplify code and increase clarity – if they do not do so in a given situation then they are probably not needed in that situation.

It’s worth restating the above in terms of goals.  One must understand one’s goals before applying a refactoring technique, and not every refactoring technique will be appropriate in every situation, and indeed many refactoring techniques are inverses of each other.  In certain situations flexibility is needed, even if it creates more code.  For example, instead of hard-coding a value in (e.g., an amount) in twenty different conclusions of a rule table you could set a variable equal to the amount and put the variable in the rule table, as this would add the ‘flexibility’ to change the amount if needed.  We would say it adds a level of indirection – but it does create more lines of code and complexity.

Almost everything is a balancing act and understanding one’s goals is hard, and it’s even harder to then figure out approaches that will help you achieve these goals, and that comes with Oracle Policy Automation experience, and a little help from OPA experts in articles like this one!

Refactoring in Oracle Policy Automation : There’s (Much) More!

Obviously these two simple examples can hope only to briefly demonstrate the value of the hard work that Dr Sender has put in to developing tools and techniques to improve the readability, maintenance and effectiveness of Oracle Policy Automation rules. He can be contacted using the link below should you wish to discuss his work, and he has kindly agreed to let me publish a couple more articles on this subject.

Watch this space for more valuable content on the topic of Refactoring in Oracle Policy Automation. The OPA Hub and Dr Sender are currently working towards the launch of advanced training based on his work. If you are interested, please take a moment to answer the 1 question survey below (if you have not already registered for the OPA Hub you can do that here before you answer) . Thank you!

What kind of advanced OPA training would you be interested in attending?

Rule Design – How Far Do You Go?

Rule Design – How Far Do You Go?

The topic of genericization in rule design came up the other day. I should explain first what was meant, and the easiest way to do that is with an example.

Suppose an OPA Customer conceives a rule that looks a little bit like this

Rule Design OPA 12Some time later, the same customer finds that there are several similar rules, such as the next one below.

An attempt is made to streamline the rules into a more appropriate structure first of all. So a rule might be rewritten to take into account not just a boolean conclusion but something more interesting, such as return codes.

Rule Design OPA 12Shortly after that, as the realization dawns that there are thousands of rules like this, a further effort occurs to streamline the concept even further as shown in the example below.

Rule Design OPA 12Here we can see the rules are broken down in the manner of with input arguments that may be numbers, Booleans and so on. The exact components of each validation are detailed. This is further extended and generalized, broken across Excel and Word (to cope with grouping operators like either) and what have you.

And so the usage of the validations becomes something a little like this (I am exaggerating for effect). Further tables are created to schematize which rules are used in which business context. We shorten the attribute names, create legends, standardize the text used.

Rule Design OPA 12

We are so far away from anything resembling natural language that we might as well be using the Microsoft Win32 API. We have delivered our Rule Design but have we best served the customer? Of course the context is key (the audience for the rule design documents, the purpose of the rules – Web Service or Interview, to mention only a couple of criteria) but the presence of different teams and different competing teams – internal or external – seems to lead to black box designs that only serve to frustrate the customer.

Worldwide
Logo by Southpaw Projects LLC