from policy to procedure
declarative specification versus procedural specification
The curious case of the Florida electionveryard projects > modelling > from policy to procedure > the Florida election
|Intention||The elected president is the one who gets the most votes in Florida.||Exercise for geeks: express this rule in OCL or Prolog.|
|The election procedure in Florida involves a complicated series of recounts, appeals and counter-appeals.||Exercise for geeks: express this procedure using UML.|
Many people have reason to feel uncomfortable with recent events in Florida. Even those who are pleased with the outcome may feel unhappy about the way this outcome was achieved. Doubts remain about the robustness of the procedure, and its ability to convince all stakeholders that the actual outcome matches the intended outcome.
If there is a mismatch between intention and action, there are two approaches to closing the gap. One is to fix the procedure even more tightly, introduce additional control mechanisms and perhaps feedback loops to provide additional guarantees of a satisfactory outcome. The other is to be clearer about the exact outcome. Although the officials may have some latitude about the mechanisms, there should be no room for ambiguity about the result.
In a highly politicized situation, such as the recent US presidential election, there may be little trust, and a desire to control everything. Sometimes it may seem that if you don't trust someone, it's better to tell them how to do something, rather than leave it up to them to choose how to do your bidding.. This example shows that procedural specifications can be just as fraught with difficulties as declarative specifications.
Apparently, one of the biggest problems in Florida was
working out what counted as a vote. If someone intended to vote for Al
Gorithm, did that count as a vote? If the ballot paper was confusing, if
the paper wasn't properly punched, how should that be counted? If a district
returned an unlikely result, how should that be interpreted?
|Joseph Maguire draws some interesting lessons about data modelling from recent elections in Florida and Guam.|
|On our own website, read more about modelling and trust.|
Chris Date's new bookveryard projects > modelling > from policy to procedure > Chris Date's new book
What Not How: The Business Rules Approach to Application Development
Chris Date, one of the early database gurus, has written a book about business rules. In his opinion, a business rule is simply a data integrity constraint, which can be used as a form of declarative specification. These rules are implemented by a CASE tool or rule engine that converts these rules directly into executable code.
Date's book is written simply and with great energy, and provides a useful introduction to declarative specification, especially for those with a database background. I am a great fan of declarative specification, and Date's book will undoubtedly encourage many developers to consider this approach, and to experiment with the available tools.
Date is right to point out the value of a data-oriented design approach in handling a wide class of business rules, as well as data derivations and mappings. Many complicated procedures and algorithms can be represented simply and powerfully using his approach, and many developers would benefit from adopting it. But a data-oriented approach doesn't solve all the problems of procedural specification, and Date's notion of business rule is rather limited and self-serving.
A simple view of business rules is highly convenient for Date, as it allows him to claim that he got the whole thing worked out in the early 1970s, together with his friend Ed Codd. He makes much of the fact that Codd's work was first published in 1969, and that his own book was actually written in 1972, three years before the copyright date. Much of the current book is devoted to the relational data model, and how it handles data integrity constraints. He seems to be still fighting the battles of the 1970s, as he takes many side-swipes at entity-relationship (ER) modelling, which he regards as both unnecessary and insufficient. He deliberately chooses to confuse ER modelling with ER diagramming, and then complains that the diagram doesn't represent all the rules. He applies a similar criticism to object modelling, complaining that UML diagrams alone cannot provide a formal specification - as if anybody thought they did!
As a database guru, Date regrets that the popular databases have not provided adequate support for data integrity constraints. He recommends standalone tools with a touch of sadness, and would much prefer to be able to incorporate business rules in the database software, where he thinks they belong. He accepts reluctantly that the rule engine is to be a separate component, sitting on top of the database.
But even if databases were able to handle data integrity constraints properly, this would not cover the full range of business rules. What about workflow and resource allocation rules, security policies and quality of service policies, internal delegation and authority structures, external laws and regulations? Surely even he can't expect the database management system to handle that lot?
Date's simple view of business rules is also highly convenient for Versata, a product company that helped Date to write the book. Date supports his argument with quotes from Versata executives, and has recently been speaking at events sponsored by Versata, promoting both the book and the Versata toolset. By a strange coincidence, Versata markets a tool of just the kind that Date recommends, compiling rules into software applications.
The Versata notion of business rules can be very effective in a closed, stable and centralized world, where changes to the rules can be reflected by recompiling the application, and clashes between rules can be removed before the application goes live. But there is a problem when we try to apply the approach to open distributed systems, where the responsibility for enforcing different rules is shared across a large number of collaborating components and services, and where rule changes and rule conflicts need to be managed dynamically without recompilation and retesting.
Date also has a simple view of logic. He claims that "any declarative business rules language is basically just predicate logic". He mentions Frege's work on first-order predicate calculus, and (following John Sowa) sarcastically dismisses entity-relationship modelling as a pre-1879 logic because it fails to use Frege's notation for existential and universal quantifiers. As his is an introductory text, he doesn't bother to mention deontic logic, modal logic, fuzzy logic, three-valued logic, intuitionistic logic or higher-order predicate logic. Or semantics.
Notwithstanding these minor niggles, this book is a useful and readable
one, which will introduce Date's fans in the database world to some new
ideas. Date's passion for declarative specification is entirely justified,
and his partiality is pretty transparent. In a field that is crowded with
bloated volumes, it is a pleasure to find a text as short and clear as
Copyright © 2000-2001 Veryard Projects Ltd