BNL: Common Pieces

Business Natural Languages: Introduction
Business Natural Languages: The Problem
Business Natural Languages: The Solution
Business Natural Languages: DRY code, DAMP BNL
Business Natural Languages: Moving to the web and multiple contexts
Business Natural Languages: Limitations
Business Natural Languages: Common Pieces

What is common between applications using Business Natural Languages?
Applications using Business Natural Languages often have common functionality. The most often seen functionality includes workflow for approving proposed business logic, history containing previous versions of business logic, an environment that allows you to test proposed business logic, and an editing environment that includes syntax and contextual validation.

All of these features have been fairly simple to implement in the systems I've worked on. In general the business logic is stored in a database as a string. The same table also contains a status field where you can store the current state of the business logic. For example, logic could be marked as 'proposed' if it has not yet been approved. Keeping a history is also as easy as inserting a new row into the table for each newly proposed string of logic. When the new logic is approved, the old logic is kept with a status of expired. In general, once logic has expired, it is not brought back to an active status. If you wish to revert, you should clone an expired version and activate it within the workflow.

The most complicated common piece to implement is the test environment. This environment often allows you to write ad-hoc logic and immediately execute to view results. Implementation of the test environment varies by project; however, in general it means executing the logic in a slightly different context. For example, you can still use the same code to process the business logic; however, you may persist the results to a table where only test data is persisted. Another option would allow you to execute the logic and see the results rendered in the UI instead of persisting to the database. Each project will have it's own implementation that makes sense, but in general they will all require some type of test environment.

While creating an editing environment that includes syntax and contextual validation sounds like a large task, it's actually nothing more than evaluating the same BNL script in another context. As previously shown a BNL can be executed to create a parse tree that is used for execution. For syntax and contextual validation the same BNL can be executed to create a parse tree of syntax validation objects. Once the syntax validation parse tree is created it can be used to provide feedback to the user. The most common question to this approach is how to keep the syntax validation classes in sync with the primary context classes. The answer to this question will vary with project and language; however, using Ruby it's possible to build the syntax checking classes using metaprogramming and using the primary context classes as templates. For example the RootSyntaxValidation class could define it's methods by grabbing all of the methods of Root that begin with an underscore.

class RootSyntaxValidation
  Root.instance_methods.grep(/^_[^_]/).each do |phrase|
    define_method phrase.to_sym do
      ...
    end
  end

  def method_missing(sym, *args)
    SyntaxError.new(sym)
  end
end

Now that we've touched on identifying the common pieces the upcoming chapters will provide examples of how to implement these ideas in our sample application.