The declarative approach specifies what is to be done rather than how to do it. When adopted in information systems development, this implies that the system should be seen as a collection of business rules that can be enacted using a business rules engine. Business rules should be expressed in a form that is as close to the one in which business people perceive the rules. A business rules management system is needed to acquire, store, and allow modification of a business rules database. The rules are then handed over to a rules engine for enactment. The BRMS considered in this chapter uses an antecedent-consequent form for representing rules. These are based in a first order logic. Rules are formed with courses of actions and conditions in rules antecedents and courses of actions in rule consequents. It also introduces notions of state change in the business rule and temporal relation within rule and between different rules. Business rules are structured into atomic, complex, and abstract rules. The business rules are translated into enactment rules and converted to Java.
TopIntroduction
Business rules have been extensively investigated in Artificial intelligence & Expert systems, Databases and Software engineering/Information system development domain. In the Expert systems, Rule has been used as a medium of knowledge representation and knowledge inference in rule-based systems (Kingston, 1987). Languages like PROLOG (Colmerauer & Roussel, 1996) and LISP (Norvig, 1991) have been developed to infer knowledge form using rules. Forgy (1982) developed a Patten matching algorithm, namely the Rete Algorithm, to implement production rule system/expert systems. Various expert systems shells also referred as rule engines have been developed. Droople, ILOG JRule, JEES, BizTalk are some of the popular rule engines implementing Rete. In the software systems, Rules Engines are used to execute business rules at runtime (Ernest, 2008).
In software systems development, business rules are recognized as important because such ruler describe how to do business (Ioana & Ileana, 2007). A business rule can be either used to express business requirements, or define the constraints under which a business operates. As the business grows and its operations expand, the rules change/evolve and this may happen at varying frequencies, sometimes very frequently. In order to capture this dynamic nature of business rules and adopt rule changes, the software system should be flexible enough to adapt such changes gracefully. Traditional procedural approaches are known to be relatively inflexible as compared to declarative approaches to systems development.
Declarative approaches aim to specify needs, perhaps, as rules, and rely on the existence of specific platforms that “execute” these declarations. The idea is to manage and store rules and enact these as and when required. Such systems have been referred to as Business Rule Management Systems, BRMS. These systems use a rule engine as a core component to perform inferencing (Husemann & Schafer, 2006). BRMS (Oubelli & Oussalah, 2016; Zoet, 2014).
A BRMS hides the complexity of rule management and provides:
- •
A repository to store rules.
- •
A user interface to write, manage and evolve business rules.
- •
A rule engine to invoke and execute rules.
A BRMS allows business people to define and maintain its operations and reduces the intervention of IT people in rule management. It is crucially dependent on the formulation of the right business rules that faithfully reflect the business. It may also get tied to the specific vendors and moving away from legacy platforms may be difficult.
To be sure, there is a body of opinion that is not favorably disposed towards the BRMS approach. According to Smith (2017) rule engines provides a complicated solution to simple problems. Further, the challenges any organization face during software development are about how to represent their core function like processes and logic instead of how to execute logic. According to (Mahmoud, 2005; Pau, 2010) the BRMS approach just makes thing worse due to lack of standards and ends up “deterring businesses from using rule-based applications”.