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?

Jason Sender

Author: Jason Sender

Software Architect with five degrees (including a PhD and an MBA) and experience in management, business analysis, project management, finance, research, and strategy.

Specialties: Oracle Policy Automation (OPA)/Oracle Policy Modeling (OPM), Software Engineering, Business Analysis, Project Management, Research, Analysis, Strategy, Finance, and Consulting.

He can be contacted via LinkedIn.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Logo by Southpaw Projects LLC