This is an old revision of the document!
Author: Grzegorz J. Nalepa and Igor Wojnicki
Version: Draft 2008Q3
ARD+ stands for Attribute Relationship Diagrams. It is aimed to be as the final ARD version for the official HeKatE project (grant).
The basic goal of rule design is to build a rule-based knowledge base from system specification. This process is a case of knowledge engineering (KE). In general, the KE process is different in many aspects to the classic software engineering (SE) process. The most important difference between SE and KE is that the former tries to model how the system works, while the latter tries to capture and represent what is known about the system. The KE approach assumes that information about how the system works can be inferred automatically from what is known about the system.
In real life the design process support (as a process of building the design) is much more important than just providing means to visualize and construct the design (which is a kind of knowledge snapshot about the system). Another observation can be also made: designing is in fact a knowledge-based process, where the design is often considered a structure with procedures needed to build it (it is at least often the case in the SE).
In case of rules, the design stage usually consists in writing actual rules, based on knowledge provided by an expert. The rules can be expressed in a natural language, this is often the case with informal approaches such as business rules. However, it is worth pointing out that using some kind of formalization as early as possible in the design process improves design quality significantly.
The next stage is the rule implementation. It is usually targeted at specific rule engine. Some examples of such engines are: CLIPS, Jess, and JBoss Rules (formerly Drools). The rule engine enforces a strict syntax on the rule language.
Another aspect of the design - in a very broad sense - is a rule encoding, in a machine readable format. In most cases it uses an XML-based representation. There are some well-established standards for rule markup languages:, e.g. RuleML and notably RIF (see http://www.w3.org/2005/rules).
The original ARD method was first proposed by A. Ligęza in (ali-book) and later on developed and described by G. J. Nalepa and A. Ligęza in (gjn2005:kkio), (ali-book-springer). It was a supportive, and potentially optional, design method for XTT (gjn2005:syssci:xtt). It provided simple means of attribute identification for the XTT method.
The first version of ARD was applied to simple cases only, and had no practical prototype implementation. The evolution of XTT, as well as larger complexity of systems designed with it, gave motivation for the major rework, and reformulation of ARD, which resulted in the version called ARD+. ARD+ was defined by G. J. Nalepa and I. Wojnicki in (gjn2008flairs-ardformal) and (gjn2008aaia).
The primary motivation for this research is an apparent lack of standard prototyping method for rules, that would support the hierarchical and gradual design aspect covering the entire process. Such a method should be formalized with use of some logic-based calculus in order to allow a formal analysis. The research presented in this paper is a part of the HeKatE project, that aims at providing an integrated and hierarchical rule design and implementation method for rule-based systems. The actual rule design is carried out with a flexible rule design method called XTT (eXtended Tabular Trees) (gjn2005sysscixtt). The method introduces a structured rulebase. So one of the main requirements for the new prototyping method should be the support for XTT.
The ARD+ method aims at supporting the rule designer at a very general design level, where the conceptualization of the design takes place (gjn2008flairs-ardformal), (gjn2008aaia). It is a knowledge-based approach, based on some classic AI methods (norvig). ARD+ covers requirements specification stage. Its input is a general systems description in the natural language. Its output is a model capturing knowledge about relationships among attributes describing system properties. The model is subsequently used in the next design stage, where the actual logical design with rules is carried out.
The main concepts behind ARD+ are:
Based on these concepts, a formalization of the method is put forward in the following section.
The ARD+ method aims at capturing relations between attributes in terms of Attributive Logic (AL)~\cite{ali-book-springer,ali2007flairs-granular,gjn2008ruleapps}.
It is based on the use of attributes for expressing knowledge about facts regarding world under consideration.
A typical atomic formula (fact) takes the form A(o) = d, where A is an attribute, o is an object
and d is the current value of A for o.
More complex descriptions take usually the form of conjunctions of such atoms and are omnipresent in the AI literature.
Please read the separate ARD+ SYNTAX page for details.
Diagram transformations are one of the core concepts in the ARD+.
They serve as a tool for diagram specification and development.
For the transformation T such as T: G1 → G2, where G1 and G2 are both diagrams, the diagram G2 carries more system related knowledge, is more specific and less abstract than the G1.
All of the transformations regard properties.
Some transformations are required to specify additional dependencies or introduce new attributes though.
A transformed diagram G2 constitutes a more detailed diagram level.
Please read the ARD+ TRANSFORMATION page for details.
During the design process some properties or attributes can be missed or treated as not important, hence not included in the diagram. Refactoring allows to incorporate such artifacts or remove unnecessary ones. Refactoring consists in modifying any of the existing transformations: finalization or split in a particular ARD+ diagram.
A Finalization Refactoring consist in adding or removing an attribute, modifying a past finalization transformation.
Removing an attribute Ar results in removing it from all already defined complex properties.
If there is a simple property which regards such an attribute, it should be removed then.
The Finalization Refactoring with adding an attribute implies that at some point a split has to be performed on a property involving the new attribute. Furthermore, appropriate dependencies between the property which consists of the introduced attribute and other properties have to be stated as well. This constitutes a Split Refactoring
In general a Split Refactoring regards:
Removing a property implies that all other properties that were split from it, even transitionally, have to be removed. Adding a property leads to defining its dependencies, between the property and other already defined ones.
In general adjusting dependencies can be based on:
In the first case the dependencies are defined for the most detailed diagram level only. Since there is a hierarchical design process (see Sec. Hierarchical Model), these changes are taken into consideration at previous levels automatically.
The second case implies that the designer updates appropriate past splits in a gradual refinement process. Stopping this process at more general level than the most detailed one, generates appropriate splits in all more detailed levels automatically.
During the design process, upon splitting and finalization, the ARD+ model grows, becoming more and more specific. This process constitutes the hierarchical model. Consecutive levels make a hierarchy of more and more detailed diagrams describing the designed system.
The purposes of having the hierarchical model are:
The implementation of such hierarchical model is provided through storing the lowest available, most detailed diagram level, and, additionally, information needed to recreate all of the higher levels, so called Transformation Process History, TPH for short (see Def. TPH).
The TPH captures information about changes made to properties at consecutive diagram levels. These changes are carried out through the transformations: split or finalization. The TPH forms a tree structure then, denoting what particular properties is split into or what attributes a particular property attribute is finalized into, according to Def. TPH.
An example TPH for the transformation presented in Fig.~\ref{fig:attfin} is given in Fig.~\ref{fig:final-tph}.
It indicates that a property described by an attribute Time is refined into a property described by attributes: Date, Hour, season, operation.
Another TPH example for the split transformation shown in Fig.~\ref{fig:hsplit} is given in Fig.~\ref{fig:split-tph}.
It indicates that a property described by attributes: Date, Hour, season, operation is refined into two properties described by: Date, Hour and season, operation attributes respectively.
\begin{figure}
\centering
\includegraphics[scale=0.5]{final-tph}
\caption{Transformation Process History for the diagrams from Fig.~\ref{fig:attfin}}
\label{fig:final-tph}
\end{figure}
\begin{figure}
\centering
\includegraphics[scale=0.5]{split-thp}
\caption{Transformation Process History for the diagrams from Fig.~\ref{fig:hsplit}}
\label{fig:split-tph}
\end{figure}
Having a complete TPH and the most detailed level (namely ARD+), which constitute the DPD (according to Def.~\ref{def:cdiagram}) it is possible to automatically recreate any, more general, level.
