From Requirements to Tables to Code and Tests
It is generally reckoned that the process of getting from requirements to implementation is error prone and expensive. Many reasons are given for this: a lack of clarity on the part of the user; incomplete or inadequate requirements; misunderstandings on the part of the developer; catch-all "else" statements; and so on. We then test like crazy to show that what we have done at least satisfies the law of least surprise! Now I want to focus here on the business logic, not the interconnecting tissue. The execution of the business logic delivers the value of our application.
Let's abstract business logic a little. We can imagine that for some circumstance — say, evaluation of a client or a risk, or simply the next step in a process — there are some criteria that, when satisfied, determine one or more actions to be performed. It would be convenient to capture the requirements in this form: a list of the criteria, C1, C2, ..., Cn and a list of corresponding actions. Then for each combination of criteria we have a selection of actions, Am. If each of the criteria is simply a condition that evaluates to a Boolean, we know that there are possibly 2n possible criteria combinations to be addressed. This is a big step forward from conventional requirements capture. We can prove completeness!
Further, if the requirements are captured in this form then we have an opportunity to largely automate the code generation process. In doing this we have massively reduced the gap between the user and the developer. Some readers may recognise what I am describing: decision tables, which have been around for at least 40 years! Although there are processors around for decision tables, they are not necessary to get many of the benefits. For example, the enumeration of the criteria and the actions is a significant step in abstraction and understanding of the problem. It also provides the developer with the opportunity to analyse and detect logical nonsense in the requirements because of the formalism of the decision table representation. By feeding this back to the user — in a constructive manner, of course — we can overcome some of the tension in the relationship.
We can explore the code generated from a decision table. We can write (or generate) conventional if-then-else logic. This is just one choice. We could also use the combination of criteria to index into an in-memory table representation of the decision table. This has the advantage of preserving the clear relationship between the decision table used for requirements specification and its implementation. Of course, there is nothing that says the table need be in memory — we could store it in a relational database, and then access the appropriate table and index directly to the set of actions.
I hope that you can see where this is going. The general idea is to try to capture logic in a tabular form, and interpret it at runtime. You can of course have (simple) real-time modification of table content.
Implementations of this type of system run from the humble programmer using the technique as a private coding method to full run-time environments with natural English translation to generate rule tables for interpretation.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page