Organization of Flexible User Interface for Policy Management Systems Supporting Different Rule Abstraction Levels

Size: px
Start display at page:

Download "Organization of Flexible User Interface for Policy Management Systems Supporting Different Rule Abstraction Levels"


1 Faculty of Computer Science, Electronics and Telecommunication Organization of Flexible User Interface for Policy Management Systems Supporting Different Rule Abstraction Levels Ph.D. Dissertation Author: Bartosz Kwolek Supervisor: Prof. Krzysztof Zieliński Kraków, 2013

2 Wydział Informatyki, Elektroniki i Telekomunikacji Organizacja elastycznego interfejsu użytkownika w systemach zarządzania politykami wspierającego różne poziomy abstrakcji reguł Rozprawa doktorska Autor: Bartosz Kwolek Promotor: Prof. dr hab. inż. Krzysztof Zieliński Kraków, 2013

3 Acknowledgments I would like to express my gratitude to my supervisor, Professor Krzysztof Zieliński, for his support and assistance in carrying out the research described in this dissertation. Special thanks to all those who kept on saying you will do it. i

4 Table of Contents Acknowledgments List of Tables List of Figures Listings Typographic Conventions Trademarks i v vi viii ix x 1 Introduction Motivation Thesis Statement Research Challenges Research Contribution Dissertation Organization Related Work Knowledge of Systems Knowledge Types of Knowledge Knowledge-Based Systems Knowledge Representation Policies and Rules Policy- and Rule-based Systems Knowledge in Traditional Systems Anatomy of Separated System Knowledge Policy-based Management Production Rule Systems Anatomy of a Production Rule System Business Rule Platforms Business Rule Management Systems BRMS Functionality BRMS Platforms Conclusions ii

5 Table of Contents 2.5 Policies and Rules Transformation Aspects Policy-level Transformation Reasons Rule-level Transformation Reasons Conclusions Abstraction Levels Abstraction Level Definition Business Level vs. Technical Level Conclusions Rule Translation Manifestations of Rule Relations Horizontal and Vertical Translations Conclusions Critical Overview Chapter Summary Concept and Model of Inter-level Rule Translation System Objectives System Requirements and Assumptions Basic Terms Modelling of Rule Templates and Rule Instances Modelling of Levels of Abstraction Formal Model of System Mechanisms Elements of Rule Instantiation Mechanism Elements of Inter-Level Translation Mechanism Concept Model Summary Chapter Summary Mechanism of Knowledge-based Translation Representation of Rule Templates Realisation of Rule Translation Mechanism Translation Engine Overview Translation Engine Anatomy Representation of Inter-level Meta-knowledge Rule Change Scenario Chapter Summary Implementation Details Tool Architecture Rule Manager Translation Manager User Interface Technological Aspects Production Rule System Flexible User Interface Technology Integration Mechanism Chapter Summary Evaluation of Vertical Policy Translation Tool Problem Domain Monitoring Policy Diversification Monitoring Policy Abstraction Levels iii

6 6.1.3 Tuning of Monitoring Strategy Translation of Monitoring Strategy Evaluation of the Policy Translator Functionality Policy Structure Definition Tool Usage Philosophy Tool Capability Demonstrations Chapter Summary Conclusions Thesis Verification Novel Concepts Future Work A Token-based Rule Template Notation 111 B Meta-knowledge definition 114 C Rule Tokens Types 118 D Integration of Flex UI with Java Back-end 119 Acronyms 122 Bibliography 125 iv

7 List of Tables 2.1 The knowledge categorization The distinguished token types The phases of vertical translation of rules The change rule scenario phases Exemplary scenarios for global strategy creation Exemplary strategy definitions for two scenarios Exemplary river section characteristics used for experiments v

8 List of Figures 2.1 The Data, Information, Knowledge, and Wisdom pyramid The architecture of a Knowledge-based system Three layer system architecture The IETF/DMTF Policy Architecture Three layer system architecture with separated policy governance Control loop of a Managed Element Rule Engines, Expert Systems and Produciton Rule Systems relation Production Rule System anatomy Rule concepts and languages at different levels of abstraction [47] Policy Refinement and Policy Interoperability with joins via IL [52] Horizontal translation method leveraging XSLT and RIF / RuleML [39] Multi-level policy view and vertical translation concept The scope of interest and types of user of the created solution Elements of a rule - conditions and actions Rule conditions and actions represented with help of defined parameters Rule template structure The significance of a rule formatting function An output rule formula generated by a formatting function Inter-level knowledge binds templates from different levels of abstraction Creation of rule instances at different abstraction levels A policy mapping vs. the proposed knowledge-based rule translation The aspects of inter-level translation function The whole mechanism summary scheme A rule as a list of tokens An example of dependencies in a set of rules The vertical translation process with the use of a production rule system The translation anatomy - the basic elements The translation process flow (upper to lower level) The translation mechanism fact types awareness Functional elements of the tool Components interaction diagram User interface anatomy The elements of main user interface vi

9 List of Figures 5.5 The rule dependency visualization Integration of the employed technologies The changes of conditions at different river sections River sections characteristics Multi-level approach to the fluvial security system A sample of knowledge-based translation of a level 1 rule to a level 2 rules Relations of thread levels and alarm levels for different strategy approaches Exemplary rule based on template 2 - level 1 view Exemplary rule based on template 2 - level 2 view Instatiation of two rules based on provided templates Listing of instantiated and translated rules Tree visualization of rule hierarchy Circular visualization of rule hierarchy, version Circular visualization of rule hierarchy, version Plain rule mapping scenario Rule context check scenario (translation for clay dikes) Translation context check scenario (translation for concrete dikes) Rule merging example Multiple-level rule correlation Original translation before the rule update Translation outcome after the rule update River warning and alert levels calculated for equal dike heights River warning and alert levels calculated for varied dike heights The scope of interest of the work within the functionality of CPMP C.1 Rule token types vii

10 Listings 4.1 A general meaning of a metarule A.1 A fragment of policy structure definition including examples of tokenbased notation of templates in XML form B.1 Exemplary meta-rules definitions D.1 Flex RemoteObject definition D.2 Java endpoint RemoteRuleManagerServiceHandler class D.3 Java remoting configuration of BlazeDS application remoting-config.xml121 viii

11 Typographic Conventions ACRO Definition source code Acronyms are typed with slightly smaller font. When mentioned first time, full name of the acronym is given, and the short name in brackets. Following occurrences of the acronym are written in short form only. Well known acronyms, such as HTTP or IDE, are not explained inline. If required, in several places full name of the acronym is repeated despite its previous definition. Definitions of the important terms and parts that should be emphasised are typed in italics. Source code is typed in courier font and put inside a frame. Terms connected with the source code in text are also typed in courier font. ix

12 Trademarks Trademark names that appear in this dissertation are the property of their respective owners. Rather than use a trademark TM, registered R, or copyright c symbol with every occurrence of a trademarked name, author uses the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. x

13 Chapter 1 Introduction Policy/rule-based system architectures gained a lot of interest in the past years. They owe it mostly to the philosophy of the separation of business knowledge from the hardcoded system logic and also the growing usability of knowledge management systems. The comfort of use of a rule-based system is tightly related to its management mechanisms. In this investigation the author will concentrate on methods of improving the usability of interface for rule supervision by introducing rule dependencies and abstraction level support. The introduction of the techniques of extraction and separation of a system business knowledge from the system operation logic has been one of the most significant breakthrough in the software engineering. Such approach considerably alleviates the design and maintenance aspects of computer systems. The concept has evolved and has been applied to an abundant plethora of knowledge-based solutions of different kinds and scale, such as decision supporting systems or adaptive SOA components. In the same way as in a real life, one of the many ways of representing knowledge of computer systems are policies, simply written down as sets of rules. In recent years, rule-based systems have become increasingly popular [72]. The scale of the increased interest reflects in the number of technologies being developed and the frequency in which they appear. In particular, the amount of platforms implemented (e.g. Oracle Business Rules [115], Drools [107], Jess [110]) as well as the various specifications related to rule expression and enactment (e.g. RuleML [131], RIF [123]) have rendered the rule technological landscape quite complex. However, this evolution can be attributed not only to the better separation of concerns between the knowledge and its implementation logic in contrast to a hard-coded approach; but also to the development of rule repositories that increase the visibility and readability of the knowledge, as well as to better graphical user interfaces that render rules more usable while bridging the gap between users (e.g. domain experts) and IT specialists. The development of modules that support management of assembled knowledge, in particular Business Rule Management Systems (BRMSs) [85], is a logical consequence of the growing popularity of rule-based solutions. However, the progress in this field is not 1

14 Chapter 1. Introduction that aggressive. Graphical user interface for rule management is not a common feature of policy environments (e.g. Drools Guvnor [119], WebSphere ILOG JRules [111] and Visual Rules [118]). Not all frameworks provide it and stages of advancement differ noticeably. On the other hand, the process of policy construction is becoming more and more complex task. Rule notations vary. Rule bases are becoming more and more sophisticated and lengthy. Rules can form more complicated relations in qualitative and quantitative sense. It is therefore becoming increasingly difficult to comprehend and manage huge rule sets. Indeed, policy authoring and presentation methods as well as coherence control have become a new challenge in the implementation of business logic. The described work presents the possibility to provide an enhancement of policy authoring process. 1.1 Motivation The usability of a knowledge-based system reflects in the usability of its knowledge management mechanisms. A comprehensive BRMS should lead an end user through all phases of a policy lifecycle [13]: creation (knowledge extraction, rules creation, edition), testing (conflict analysis, transformation), distribution (storage), and enforcement. This thesis focuses on efficient rule creation and categorization, which result in effective policy maintenance. In the field of rule authoring tools very different approaches may be pointed. For instance, ILOG JRules platform uses external documents created in MSWord and then parsed by the platform. Drools Guvnor provides a set of editors for different types of rules (e.g. DRL or BRL markup, decision tables etc). Finally, Visual Rules, provides graph-based decision modelling UI. Created diagrams are automatically translated into policies and thus a user is not faced with semantic issues of rule notation. This approach resembles Business Process Modelling Notation (BPMN) and represents rather a decision workflow than a policy. The usability of a policy-based system is also tightly related to the ease of use by different actors taking part in the policy management process. The diversity of roles, specializations, skills etc. should be reflected in knowledge assembling process as introduced in [13] [52]. However, what was mostly put into practice, was dividing the users of a policy-oriented system into two groups: experts and non-experts or technicians and business users. Some rule creators are capable of providing business logic and the others can translate them into specific configuration parameters of devices or arguments for services. This dichotomy is also visible in the notation approaches. For domain experts it is often easier to express rules through their natural language or graphical diagram, but a majority of academic and commercial solutions concentrate on abstract notation (e.g. RIF [123], RuleML [131], SWRL [133]), which require learning. User classification to some extent reflects in the definition of policy abstraction. RFC 3198 Terminology for Policy-Based Management [6] states that policy can be represented at different levels, ranging from business goals to device-specific configuration parameters. Also the definition of policy translation does not limit transformation of a policy only to its representation, but it mentions its level of abstraction as well. 2

15 Chapter 1. Introduction The dichotomy of user classification results in defining only two basic abstraction layers: higher (HL) and lower (LL). But what if more fields of interest can be depicted? 1.2 Thesis Statement The author s main point of interest is the user-centric approach to a rule-based system in order to find features that could mitigate the management of big amount of rules. The main emphasis is put on aspects of rule authoring, rule organization and rule transformation. The previous section emphasised three interesting issues. Firstly, the stage of development of rule management systems does not follow the progress in the rule technologies and the approach to the question is not unified. Secondly, the prevalent dichotomy of rule-based systems users was distinguished. Thirdly, the concept of policy abstraction levels was referred and, resulting from the mentioned dichotomy, the acknowledgement of only two levels was pointed out. It raises a question, if presenting a policy at multiple levels of abstraction could give a diverse insight into the substance of the policy (e.g. for different user types). While investigating the current state of research, the author did not find a suitable framework that provided management of multiple levels of abstraction. Also, handling of rule dependencies is not fully supported 1. Still there is a place for extending BRMSs functionality and improving policy authoring mechanisms by investigating and providing new tools. Thus, a new approach is proposed and examined. This dissertation provides a comprehensive study of current works on rule relations and dependencies. Also, the area of policy abstraction levels utilization in the policy creation process is explored. A detailed study of the existing works in the mentioned areas led to the following thesis statement, which should be investigated: Creation of a flexible user interface that provides various abstraction levels for rules makes it possible to augment a usage domain of a rule management system. The augmentation of the usage domain is understood as a significant extension of the standard functionality model, that can be found in existing rule management systems. The improvement bases on adding new features related to the management of policy abstraction levels as well as the introduction of resultant new methods of policy authoring. The flexibility of the user interface refers to its open character, i.e. the solution is domain agnostic and can be adopted for any policy field of interest. The dissertation presents the specification of the mentioned interface as well as its prototype implementation, which finally verifies the stated thesis. The work does not intend to create whole new rule management system, but only build and evaluate a tool providing the features described above. The author does not claim that the solution is the final answer for policy authoring demands or that it is suitable for the creation of every policy. He rather tries to investigate new paths of rule management systems development. 1 Except for the standard method of categorizing rules into packages, e.g. Drools. 3

16 Chapter 1. Introduction 1.3 Research Challenges Flexibility and usability of BRMS graphical user interfaces are limited by insufficient transformation and rule organization support. In response to the aforementioned shortcomings the author proposes new concepts for improving existing solutions. These ideas are presented below as the research challenges addressed by this dissertation: 1. providing methods for the specification of a policy abstraction levels and easy rule browsing throughout those levels, 2. providing methods for correlating rules throughout abstraction levels and maintaining information on such rules dependencies, 3. enabling easy inter-level rules translation, based on rule dependencies; in effect a modification of one business rule could affect another rule(s), change it or even deactivate it, 4. providing comprehensive view of gathered knowledge (rules hierarchy visualization), with the capability of rule dependency overview, 5. design of an open framework architecture that provides the goals mentioned above and meets ergonomic criteria [57] for user interface design. One of the clue elements of the dissertation is translation of rules between policy abstraction levels. However, it is not the goal of this work to provide any semantic-based rule translation. There is no platform so far that provides easy rule translation between different notations. Research on rule engine interoperability via rule interchangeability covering semantic rule translation started only in recent years [39]. Some aspects of the dissertation field of interest resemble a concept called policy refinement [73] [33] [34]. More detailed survey can be found in Chapter 2. A minor aim of the dissertation is also to investigate methods of building interfaces of Rich Internet Application (RIA) and testing the graphical freedom that they offer to a GUI designer of rule management systems. 1.4 Research Contribution The innovative aspect of the dissertation lies in the creation of a open framework with a GUI that supports rule management by providing end users with different abstraction levels control and enables translations of rules between them based on defined rule interrelations. It can introduce BRMSs to a next stage by creating a flexible maintenance tool that i) unifies policy management for end users representing various domains of interest or different degrees of granularity within one field of interest, and ii) enables better organization of assembled knowledge. The specification of rule correlations can enable easy and dynamic rule rephrasing. The main achievements of this dissertation are as follows: an extended survey into the policy-based approach in computer system design with the main stress put on the current research into rule dependencies perception and policy translation, as shown in Chapter 2; 4

17 Chapter 1. Introduction the introduction of a notation agnostic, token-based model of a rule and rule dependencies, that enables representation of rules and rule templates regardless their original format; the approach leaves the rule semantic issues outside of the scope of the work; it eliminates the necessity of notation translations as well as enables any type of rule notation transitions; the approach is open for further functional extensions; the formulation of the concept of the knowledge-based vertical rule translation, that enables translating higher level rules into lower level ones with reference to the defined translation context (e.g. global environment or already created rule set); such approach can result in different translation results for different translation conditions; providing of policy verification methods (for both created and translated rules) based on the translation mechanism knowledge; the method of meta-knowledge formulation enables including robust mechanisms of, for instance, rule coherence or contradiction check; the definition of the necessary domain expert support, i.e. the specification a domain knowledge used by the translating mechanism, including description of a policy characteristics (e.g. rule templates) as well as the domain specific data that propel the translation process; the methodology of gathering and testing the domain expert knowledge is out of the scope of this dissertation and it is taken for granted that, for a specific scenario, the metaknowledge is already prepared; a proof of concept by a prototype implementation of an open, domain agnostic framework that supports rule creation, browsing, translation and policy dependency visualization; the prototype implementation proves the thesis stated in section 1.2; the presentation of the use of the multi-level policy authoring methodology and verification of its functionality by using it in a real life case study concerning a river dikes monitoring scenario, as shown in Chapter Dissertation Organization In what follows, the organization of the dissertation is outlined. In Chapter 2, the author presents the extensive background of introducing rule-based solutions into computer systems. Starting from the basic concepts of knowledge, the chapter aims at showing the crucial aspects of policy structuring. In particular, many issues related to policy translations and rule dependencies are studied. Chapter 3 aims to present a new approach to policy structuring and maintenance based on concepts of rule abstraction levels and vertical rule translation. Having defined the main goals of the system concept, the chapter thoroughly defines the formal models of essential mechanisms - rule instantiation and vertical rule translation. Chapter 4 demonstrates the anatomy of the mechanisms that propel knowledge-based vertical policy translation, created on the base of the ideas given in Chapter 3. Among other things, the chapter describes the token representation of rules and rule interrelations as well as the novel approach to translating engine. The further details of the mechanisms implementations are explained in depth in Chapter 5. 5

18 Chapter 1. Introduction Evaluation and verification of the thesis are performed in Chapter 6. The chapter presents a Case Study that relates to authoring as well as visualizing policies for a river dikes monitoring system. It also widely presents the capabilities of the implemented tool. The dissertation ends with a summary and further work described in Chapter 7. The chapter discusses the achieved results and shows possible ways of enhancing the created solution with additional functionalities. 6

19 Chapter 2 Related Work This chapter aims to introduce the issues relating to governance of policies throughout multiple levels of abstraction. It begins with the basic concepts of knowledge, its representation in the form of policies and its position in computer systems. In further sections, production rule systems and corresponding rule management systems are presented. Finally, multiple aspects of policy structure and its governance are discussed. Before presenting the issues relating to governance of policies throughout multiple levels of abstraction, this chapter summarizes the fundamental concepts related to this area. Background analysis begins with introducing the basic terms and continues with presentation of the development of concepts. Firstly the very fundamental ideas of knowledge, its classification and representation, especially in the form of policies are discussed. The stress is put on the evolutionary impact that the separation of knowledge has brought into the computer systems construction. Systems that can provide separated knowledge based on policies and the usability of corresponding rule management systems are presented in the next part of the chapter. The main part of the chapter shows crucial aspects related to policy structuring. This analysis touches upon various aspects that are the base for policy transformations (e.g. the existance of various relations between rules). The survey examines policy-based and rule-based transformation reasons. Finally, attempts of multi-layered and hierarchical approach to policies are presented and the usage of the concept of policy abstraction levels in various works is studied. In sections 2.1 and 2.2 repsectively, knowledge definition, its types and its application in computer systems are discussed. The influence of policies utilization on system design is shown in section 2.2. Section 2.3 describes modern production rule platforms while section 2.4 shows tools for rule management. In section 2.5 backgrounds and reasons for rule transformations are discussed. The concept of policy abstraction levels is presented in section 2.6. Finally, in section 2.7 rule translation types related to existing rule dependencies are discussed. Conclusions are drawn in section

20 Chapter 2. Related Work 2.1 Knowledge of Systems Any computer system in order to operate needs to know how to act. At the most basic level its capabilities base on a programmed sequence of behaviours hardcoded or not, but specific to a system. With the progress of information techniques, machine thinking evolves computer systems become more and more capable of using provided data in more and more sophisticated ways. In 1965 John McCarthy coined the term Artificial Intelligence (AI) [97] defining it as the science and engineering of making intelligent machines [98]. Eventually it turned out that machines could have knowledge Knowledge The concept of knowledge has been discussed for centuries. The ancient Greek philosophers (Plato, Aristotle)assumed that it originates only with people. In the modern Western philosophy knowledge is perceived as a stand-alone artefact (i.e. a physical record) that could be captured in technology. The academic community has spent years discussing and clarifying what constitutes data, information and knowledge [96] [67]. Worthington [68] gives a definition that is close to the computer science understanding Knowledge is a physical, mental, or electronic record of relationships believed to exist between real or imaginary entities, forces, and phenomena. The Data Information Knowledge Wisdom (DIKW) pyramid [69] [19] presents an interesting concept of the relationships between Data, Information, Knowledge, and Wisdom (also known as Intelligence). Data as its base, followed in the hierarchy by Information, then Knowledge, with Wisdom at the top (Figure 2.1). Adding value: action-oriented measurable efficiency wiser decisions Adding value: comparison, consequence, connections, conversations Adding value: contextualised, categorized, calculated, corrected, condensed WISDOM KNOWLEDGE INFORMATION DATA collective application of knowledge in action experience, values, context applied to a message a message meant to change receiver s perception discrete, objective facts about an event Fig. 2.1: The Data, Information, Knowledge, and Wisdom pyramid Knowledge differs from data or information in that new knowledge may be created from existing knowledge using logical inference. If information is data plus meaning then knowledge is information plus processing. A common form of knowledge, e.g. in a Prolog program, is a collection of facts and rules about some subject Types of Knowledge Knowledge may originate from different sources, may be formed or composed in various manners, may be applied to diverse objectives etc. Therefore, attempts of knowledge 8

21 Chapter 2. Related Work categorization were taken, e.g. one shown in Table 2.1 (source: [11]). Type of knowledge Domain knowledge Meta knowledge Common-sense knowledge Heuristic knowledge Explicit knowledge Tacit knowledge Characteristics Domain knowledge is valid knowledge for a specified domain. Specialists and experts develop their own domain knowledge and use it for problem solving. Meta knowledge can be defined as knowledge about knowledge. Common sense knowledge is a general purpose knowledge expected to be present in every normal human being. Common-sense ideas tend to relate to events within human experience. Heuristic is a specific rule-of-thumb or argument derived from experience. Explicit knowledge can be easily expressed in words/numbers and shared in the form of data, scientific formulae, product specifications, manuals, and universal principles. It is more formal and systematic. Tacit knowledge is the knowledge stored in subconscious mind of experts and not easy to document. It is highly personal and hard to formalize, and hence difficult to represent formally in system. Subjective insights, intuitions, emotions, mental models, values. Table 2.1: The knowledge categorization The presented definitions (in particular domain knowledge, meta knowledge) will be referenced in the following parts of this work Knowledge-Based Systems Knowledge-Based Systems (KBSs) form the major family members of the AI group [16]. It goes beyond the decision support philosophy by transferring the expert system technology into the decision making frameworks. The term Expert System (ES) [15] is normally used to refer to a highly domain-specific type of KBS used for a specialised purpose such as medical diagnosis, while KBS refers to a system for extending and/or querying a collection of knowledge codification [10]. Thus, KBS can use and generate knowledge from data, information and knowledge (DIKW pyramid). What distinguishes these systems from the traditional computer systems is the capability of understanding the residing information/knowledge and taking decision based on it, whereas the regular systems do not comprehend the data/information they process. [11] Knowledge-Based Systems take advantage of new artificial intelligences, as well as neural networks [63], fuzzy logic [70], genetic algorithms [71], and soft system methodology [18]. However, the crucial feature of such systems is the separation of the knowledge it consumes, which enables changeability and reuse of this knowledge. The core components of a Knowledge-Based System are: 9

22 Chapter 2. Related Work knowledge base, acquisition mechanisms, inference mechanisms. A Knowledge Base is used as a repository of knowledge in various forms, e.g. facts and rules about some subject [66]. It may also include an empty Workspace to store temporary results and pieces of information. Knowledge Base (KB) and a search program called Inference Engine (IE) constitute the main part of a KBS. The IE is a software program, which infers the knowledge available in KB. A separate subfield of AI concerned with designing and using systems for storing knowledge is Knowledge Representation. A body of formally represented knowledge is based on a conceptualisation - an abstract view of the world that we wish to represent. In order to manipulate this knowledge we must specify how the abstract conceptualisation is represented as a concrete data structure. An ontology is an explicit specification of a conceptualisation. One of the technology options for modelling knowledge are rule engines [96] that will be widely discussed in section 2.3. Explanation Reasoning Knowledge Base Inference Engine Self Learning User Interface Fig. 2.2: The architecture of a Knowledge-based system The creditability of a KBS also depends on the Explanation and Reasoning of the decision made or suggested by the system and the simulation of such learning process is essential KBS component. The updates may be either manual or automatical (machine learning). Ideally, the basic frame of a KBS rarely needs to be modified. Abovementioned components are shown in Figure Knowledge Representation Policies and Rules In the real world various regulations are met and the concepts of rules and policies are commonly used for describing them. Thus, as it was already mentioned in the previous section, rules and policies constitute a common (but not the only) representation of knowledge. In fact, the concept was adopted into the computer science ground in the latter century. First works in this area authorisation policies, obligation policies, were related to the issues of access control, Quality of Service (QoS) (Differentiated Services (DiffServ), Integrated Services (IntServ)) and Internet Protocol Security (IPsec). In the information systems context, policies are rules governing the choices in behaviour of a (software) system [61]. 10

23 Chapter 2. Related Work The report of the REWERSE project Rule-based Policy Specification: State of the Art and Future Work [84] that provides an overview of the existing approaches to logic and rule-based system behaviour specifications states: Here are some of the potential advantages of representing policies with explicit rule-based representations of their semantics. Writing rules is usually faster and cheaper than writing imperative or OO code. The level of abstraction of rules facilitates their expression in user-friendly languages such as controlled natural language. Rules are more concise and easier to understand, share and maintain, especially in a global open environment such as the web, where self-documenting specifications are one of the current approaches to enabling interoperability. Formal definitions are included in RFC 3198 Terminology for Policy-Based Management [6] (November 2001). The policy rule is formally defined as: A basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions - where the conditions are evaluated to determine whether the actions are performed. In the same document RFC 3198 [6] policy is defined from two perspectives that are not contradictory since individual rules may be defined in support of business goals: A definite goal, course or method of action to guide and determine present and future decisions. Policies are implemented or executed within a particular context (such as policies defined within a business unit). Policies as a set of rules to administer, manage, and control access to network resources (RFC 3060 [4]). RFC 3060 Policy Core Information Model [4] was published at the beginning of The Policy Core Information Model (PCIM) and PCIM extended (PCIMe) (PCIM extended) (RFC 3460 [7]) were developed jointly by Internet Engineering Task Force (IETF) and Distributed Management Task Force (DMTF) groups - the two organizations that have been at the forefront of policy standardization. The PCIM declares an object model representing policy information as an extension to the Common Information Model (CIM) [104]. The PCIM defines the policy classes and associations that are sufficiently generic to allow them to represent policies related to anything. However, the initial application was to represent policies related to QoS and IPsec. The RFC specifies the characteristic, the target and the method of use of policies and rules in a clear manner: (... ) policy is applied using a set of policy rules. Each policy rule consists of a set of conditions and a set of actions. Policy rules may be aggregated into policy groups. These groups may be nested, to represent a hierarchy of policies. The set of conditions associated with a policy rule specifies when the policy rule is applicable. The set of conditions can be expressed as either an ORed set of ANDed sets of condition statements or an ANDed set of ORed sets of statements. Individual condition statements can also be negated. These combinations are termed, respectively, Disjunctive Normal Form and Conjunctive Normal Form for the conditions. 11

24 Chapter 2. Related Work If the set of conditions associated with a policy rule evaluates to TRUE, then a set of actions that either maintain the current state of the object or transition the object to a new state may be executed. This fragment points the fundamental assumptions of the most widespread structure and functionality of policy rules: if-condition-then-action construction. It represents Condition-Action information model, but it needs mentioning that another approaches has been created (cf. section 2.5.2). RFC 3060 specifies also some additional features of policy rules that augment the model presented above. For instance options of rule grouping, rule actions execution ordering or rule prioritization: For the set of actions associated with a policy rule, it is possible to specify an order of execution, as well as an indication of whether the order is required or merely recommended. It is also possible to indicate that the order in which the actions are executed does not matter. Policy rules themselves can be prioritized. One common reason for doing this is to express an overall policy that has a general case with a few specific exceptions. Policies can either be used in a stand-alone fashion or aggregated into policy groups to perform more elaborate functions. Stand-alone policies are called policy rules. Policy groups are aggregations of policy rules, or aggregations of policy groups, but not both. Policy groups can model intricate interactions between objects that have complex interdependencies. These features (and many more) are selectively implemented in different policy frameworks and policy rule notations. A policy language survey will be presented in section In the above sections formal definitions of policies and rules were presented. In the following sections the anatomy of their application to computer system in order to create policy-based systems. 2.2 Policy- and Rule-based Systems Policy-based systems are autonomic (self-managing) in a way that they autonomously determine which policies must be applied to a certain management situation [31]. Therefore, from the emergence of the idea policies gained wide interest and instantly became a popular approach to cope with the increasing complexity of system management (e.g. [29] [103] [2]). In this section it is discussed how the knowledge separation influenced system architectures and motivated the evolution of policy-based systems Knowledge in Traditional Systems A computer system must be provided with business logic unique for an organisation to function, e.g. a single algorithm enclosed in a running program can be perceived as a 12

25 Chapter 2. Related Work representation of the knowledge of this program. At the most abstract level, the logical architecture view of any system can be considered as a set of cooperating components grouped into layers [30]. The most prevalent software architecture and design pattern is the three-tier model [65] [22] [101] (see Figure 2.3): Presentation layer implements functionality for managing user oriented interaction with the system and provides a bridge between user interface elements and actions and the core business logic processes. Business layer contains business components that encapsulate the system business logic. This layer coordinates the system, makes logical decisions and evaluations, performs calculations etc. It also provides a transport means between the two surrounding layers. Data layer provides access to data hosted within the system (e.g. databases) or exposed by other systems (i.e. accessed through services). PRESENTATION LAYER BUSINESS LAYER DATA LAYER Fig. 2.3: Three layer system architecture In fact, in traditional systems it is implied that business components implement the knowledge of the system [20]. Therefore the business knowledge is: expressed in a programming language (e.g. Java), mixed with other functions (e.g. database access), frequently scattered throughout the system. This causes a series of problems in different fields [14]: reusability problems - three layers of a system tend to be tightly interlinked and it is not easy to extract business logic to use it elsewhere, audit and control problems - business knowledge tends to be hidden in code is hard to browse or revise, collaboration problems - domain experts and technical experts literally speak different languages, updating problems - business layer is hard to change without unexpected sideeffects. 13

26 Chapter 2. Related Work Therefore a new need emerged to specify, represent and manipulate system knowledge independently from the authoring of system components to enable dynamic change of system policies and reuse of these components Anatomy of Separated System Knowledge The extraction and separation of business knowledge from its implementation significantly alleviates the design and maintenance aspects of knowledge-based systems [39]. As a generic architecture for such systems a reference model called IETF/DMTF Policy Architecture is found [13]. Even though this architecture is not put out in any of the official documents from the two organisations, it can be found in many Request for Comment (e.g. RFC 2904, RFC 2753) regarding the use of policies in computer communication networks. Policy Administration Point (PAP) Policy Repository Policy Decision Point (PDP) Policy Enforcement Point (PEP) Fig. 2.4: The IETF/DMTF Policy Architecture This policy architecture consists of four components as shown in Figure 2.4: Policy Decision Point (PDP) - evaluates and issues decisions, i.e. examines the policies stored in repository that would be applicable in given circumstance and determine what needs to be done to comply with those politics, Policy Enforcement Point (PEP) - enforces the outcome of those policy decisions, Policy Management Tool or Policy Administration Point (PAP) - provides a user interface for the creation and further control of policies, Policy Repository - provides mechanisms for storing policies and retrieving them as needed by the PDP. Similar elements and terminology are used in [3] or [102]. However, some additional elements that are not considered in the abovementioned model can be found: Policy Retrieval Point (PRP) - retrieves policies from a policy repository, Policy Information Point (PIP) - provides external information (e.g. Lightweight Directory Access Protocol (LDAP) attributes) to a PDP. 14

27 Chapter 2. Related Work Given such assumptions of policy utilization processes the basic three layer application model that was introduced in Figure 2.3 can be augmented. As seen in Figure 2.5 the essential layers were enriched in modules exposing mechanisms for policy management, enactment and storing. PRESENTATION LAYER KNOWLEDGE MANAGEMENT PRESENTATION LAYER KNOWLEDGE MANAGEMENT BUSINESS LAYER KNOWLEDGE (RULES/POLICIES) BUSINESS LAYER KNOWLEDGE (RULES/POLICIES) DATA LAYER RULE REPOSITORY DATA LAYER RULE REPOSITORY Fig. 2.5: Three layer system architecture with separated policy governance The most important change takes place in the business logic layer. Here not only new policy-related components must be added, but the existing system components must be enriched in two sets of functionalities: interfaces that make possible the use of provided separated knowledge, mechanisms for enforcing the decisions taken by the knowledge module. Such assumptions radically influence the software construction of a policy-based system, but on the other hand they significantly facilitate dynamic modification of a system behaviour, without altering the enriched knowledge-enabled system entities that interpret and enforce policies. In effect, rule and policy driven systems are becoming increasingly popular over the past years Policy-based Management Policy-based management is an administrative approach that aims to improve the management tasks by establishing policies to deal with situations that are likely to occur. It can be perceived at various granularity levels, e.g. an overall system (coarse granularity level) and a system component (fine granularity level). A higher level example of policy-based management is Policy Based Access Control framework [102] that provides a strategy for managing user access to systems. POLICY CONTROL SENSORS EFFECTORS MANAGED ELEMENT (COMPONENT/SYSTEM) Fig. 2.6: Control loop of a Managed Element 15

28 Chapter 2. Related Work At lower level, by providing policy enactment methods a single component may be augmented to a policy-based managed entity. Moreover, following control theory principles [23], if the decisions concerning the element behaviour are made based on its current state, the control loop is closed (cf. Figure 2.6), making the element autonomic (self-managing). Such improvement surpasses the basic concepts of management and enters the field of Autonomic Computing [105]. 2.3 Production Rule Systems There are various types of mechanisms that support computer systems with functionalities related to knowledge utilization, e.g. planners (e.g. Drools Planner [107]), process/workflow managers (e.g. jbpm [121]), complex event processors (e.g. Esper [122]) etc. A separate class of such systems that gained a lot of interest recently are Rule Engines that use the rule based approach to implement an Expert System and are more correctly classified as a Production Rule Systems [113]. The term Rule Engine is quite ambiguous in that it can be any system that uses rules, in any form, that can be applied to data to produce outcomes; which includes simple systems like form validation and dynamic expression engines. While a Production Rule System is a kind of Rule Engine and also an Expert System, the validation and expression evaluation Rule Engines are not Expert Systems. A Production Rule System is Turing complete with a focus on knowledge representation to express propositional and first order logic in a concise, non ambiguous and declarative manner. The above categorization identifies Production Rule Systems as a subset of Expert Systems and also Rule Engines at the same time. Thus it locates PRSs within the intersection of the two mentioned system categories as shown in Figure 2.7. Expert Systems Production Rule Systems Rule Engines Fig. 2.7: Rule Engines, Expert Systems and Produciton Rule Systems relation Production-System Models have their roots in the formalisms of computer science and mathematics of the forties of 20th century [62]. They were inspired by the logical modus ponens that says: If A implies B, and we know A, then we can deduce B. The early production-system models were not implemented on a computer and required hand simulation in order to determine their consequences. The first running production system appears to have been Waterman s (1970) poker-playing program [64] and a Newell s works [87] [88]. The approach begun popular in another areas such as human problem-solving [86] and modelling of human cognition [12]. 16

29 Chapter 2. Related Work Anatomy of a Production Rule System The structure of a production rule system is shown in Figure 2.8. The main components are [113] Inference Engine, Working Memory and Production Memory. The brain of a Production Rules System is an Inference Engine that is able to scale to a large number of rules and facts. The Inference Engine performs Pattern Matching i.e. matches facts and data, against Production Rules (also called Productions or just Rules), to infer conclusions which result in actions. Inference Engine (ReteOO/Leaps) Production Memory RULES Pattern Matcher Agenda Working Memory FACTS Fig. 2.8: Production Rule System anatomy A Production Rule is a two-part structure using First Order Logic for knowledge representation: when <conditions>then <actions>. The Rules are stored in the Production Memory and the facts that the Inference Engine matches against the Working Memory. Facts are asserted into the Working Memory where they may then be modified or retracted. A system with a large number of rules and facts may result in many rules being true for the same fact assertion, these rules are said to be in conflict. The Agenda manages the execution order of these conflicting rules using a Conflict Resolution strategy that may make use of e.g. priority relations between rules ( [27], [28]). A production rule system s Inference Engine is stateful and able to enforce truthfulness - called Truth Maintenance [113]. There are two methods of execution for a Production Rule Systems: a data-driven Forward Chaining, and a goal-driven Backward Chaining. Systems that implement both are called Hybrid Production Rule Systems. Forward chaining process is easier and more widespread among the existing platforms. There are a number of algorithms used for Forward Chaining Pattern Matching by Inference Engines including Linear, Rete, Treat, Leaps. Most of the solutions are based on Charles Forgy s RETE algorithm [90] [92]. They implement and extend the algorithm (e.g. Drools [107] implementation is ReteOO, signifying that it is optimized for Object Oriented systems) [24]. The algorithm has been mathematically proven to be faster and more scalable than more traditional handcoded if... then... solutions [14]. The basic principle of RETE is to take a set of conditions and convert them to nodes. Rules that match on the same exact condition reuse existing nodes in the RETE network. The nodes are then joined to other conditions. At the end of the conditions is a terminal node. 17

30 Chapter 2. Related Work The real benefit of such approach is that the performance is not affected by the number of rules deployed. RETE matches each data instance once for all rules [59]. In case of coding the business logic rules in C/C++/Java, the performance decreases when the number of rules or dataset rises. Moreover, in some solutions (e.g. JESS [110], ILOG JRules [111] and Blaze Advisor [117]), it is possible to deploy and undeploy rules dynamically, what significantly increases their usability. For accessing a rule engine from a Java Platform, the Java Specification Request for a Java Rules Engine API (JSR-94) [120], was defined. However, it specifies only how to call rule engine, not the rules themselves, because it does not define or favour any rule standard. What is the result? The Forrester Inc. s Market Overview: Business Rules Platforms 2011 [124] concludes with an interesting recommendation: Stop Coding All Your Business Rules In Java, C#, COBOL, ET AL stating that business rules platforms are better than code for creating and managing decision and policy logic, and they belong in your application development and delivery strategy Business Rule Platforms Over the years diverse technological platforms and frameworks were developed, e.g. WebSphere Operational Decision Management ( [112], previously: ILOG JRules [111]), JBoss Drools (or Drools.Net [107], Java JESS programming language [110], Oracle Business Rules [115], Blaze Advisor [117], Microsoft BizTalk Server [108], Apache Jena Framework [109], OpenRules [114], Pega Business Rules [116]. The business rule platforms market is continuously evaluating and changing, showing vendors consolidations, expansions, and/or retrenchments. 2.4 Business Rule Management Systems The logical consequence in the growing popularity [72] of rule-based systems is the appearance of modules supporting the management of assembled knowledge, in particular Business Rule Management System (BRMS) [85]. Such systems build additional value on top of a general purpose Rule Engines by providing business user focused systems for rule creation, management, deployment, collaboration, analysis and end user tools. One of the factors that increased popularity of BRMS was providing graphical interfaces that could alleviate policy management, in particular editing rules, significantly augmenting the range of potential users. BRMSs help to deal with two basic problems that policy managers are often faced with: great number of rules in a real life system the number of rules may be significant, which results in policy complexity and makes it difficult to comprehend the whole of the assembled knowledge, diverse rule notations for domain-experts (as opposed to technical experts) it is often easier to express rules through their natural language or a graphical diagram, 18

31 Chapter 2. Related Work while a majority of academic and commercial solutions concentrate on abstract proprietary notations (e.g. RIF [123], RuleML [32], extensible Access Control Markup Language (XACML) [102], Semantic Web Rule Language (SWRL) [133], DroolsML [107], Jess [110]). This issues apply to a system using one production rule system platform. However, in multilayered heterogenic systems different components may depend on different rule engine solutions. In this case governance and policies coherence renders troublesome. Moreover, not much work is done in this field [41] [38] BRMS Functionality A Business Rules Management System, as any system, obviously needs to fulfil functional and non-functional requirements leveraging on possibly friendly user interfaces. Generally speaking the main goal is to allow managing rules in multi user environment, providing single point of access. Since there is a granted lifecycle of a policy [95], the most methodical way to describe its management interface is to refer to the lifecycle phases. The successive stages of the rule existence during the application runtime present as follows [13]: 1. creation, 2. transformation, 3. storage, 4. merging (analysis), 5. adaptation to environment, 6. expiration time. The subsequent analysis of the rule management interface adheres to the phases listed above. The detailed analysis of a policy generation process is not the main goal of this work, but it is examined for the sake of the following study of augmenting the policy treatment. Rule management (creation and transformation phase) The rule creation phase target at both the various ways of articulating rule as well as different notation formats (a spoken language, a specific rule mark-up language, a decision table). Another story is providing the abstract data model for the rule domain, including templates, constraints etc. and then the way of casting them into the rules created. These issues address uncountable details of rule editors implementation, text or graphical alike. Policies also need documentation for their future treatment and proper making use of (e.g. information on author and creation date, modifications, transformations). 19

32 Chapter 2. Related Work Rule storage (storage phase) A BRMS facilitates access to a policy repository. In order to ease the comprehension of the knowledge gathered, it should provide some ways of knowledge aggregation and segregation, for instance packages that allow grouping different knowledge bases in separate assemblies together with its model (fact types), business and technical rules (of different categories), tests and so on. A rule repository also provides some functionality for convenient data access, e.g. access control, versioning (database snapshots), easy browsing (by asset status, category etc.) and filtering including personalized user views (i.e. business user view showing only a subset of rules). Rule validation (merging/analysis phase) Rule validation is an extensive question. When there are many authors managing operating behaviours, conflicts may arise not only during the rule definition phase, but also at run-time. Hence, BRMS should provide tools for tracing inconsistencies, solving conflicts (i.e. with rule prioritizing). The action may employ dedicated self-healing or self-protection policies, but also provide help in policy modification in for its optimization purposes (i.e. merging similar rules). Rule activity control (deployment and expiration phases) The issues of this stage include building rule packages, its distribution and deployment, but also logging of policy evaluation actions. Various schemes may be available for the user, such as dedicated scripts, common repository in a system or publish-subscribe messaging scheme [13]. A technologically advanced feature is a runtime access to a working memory for comprehension of the system state or a user s interference (i.e. removing facts in the real time etc.). The last question is visualization of policy deactivation (by user s action) or expiration (according to policy timing settings)that can be accompanied with a report or a choice of possible actions to be taken ( e.g. reactivation, modification or deletion) BRMS Platforms Most BRMS vendors have evolved from rule engine vendors to provide development lifecycle solutions for business-usable software that takes advantage of declarative definitions of business rules executed in their own rule engine. Some vendors come up with different approaches as well, e.g. they map decision trees or graphs (called ruleflows) to executable code. In the context of the rule creation and authoring, three general groups of rules editing methods in BRMSs can be distinguished: verbal (e.g. JESS, OpenRules), verbal supported with graphical editors or wizards (e.g. Drools Guvnor), graphical (e.g. Visual Rules, ILOG JRules). 20

33 Chapter 2. Related Work Some products, come out with their proprietary authoring solution, but others take advantage of existing, well known editing mechanisms. For instance, for rule creation OpenRules leverages on graphical interfaces of MS Word and Excel and for collaborative rule management on Google Docs (e.g. OpenRules [114]). Similarly Drools makes use of MS Excel for defining decision tables. Some solutions (i.e. Drools, ILOG JRules) utilize Eclipse IDE as well. Rule Studio rules and ruleflows editing mechanism of ILOG JRules is Eclipse-based end leverages on Graphical Editing Framework (GEF), Eclipse Modeling Framework (EMF) Runtime and Charting and Reporting plug-ins. Rule Studio allows integrated co-editing and debugging of Java code and rules and enables collaboration with business rule authors through integration with Rule Team Server. Newest releases come out with more and more advanced graphical features. However, Forrester Inc. s BRMS market overview of year 2011 [Forrester2011-1] states that the functional differences between the business rules platforms matter less and less to clients. Most of the products have matured to the point where they share a similar set of features now: a set of developer tools, authoring tools for business experts, execution engines, integration points, and administration and management tools. In fact, the correspondence is not that obvious in case of BRMSs. Comparison of two systems Drools Guvnor [119] (a popular widely used open solution) and Visual Rules Suite [118] (an advanced business product) brings the conclusion that such management systems may vary in a significant way. The mentioned systems represent different classes of frameworks with huge functionality gap and diametrical disparity in approach. Not only the methods for rule defining are different, but in result ways of their deployment vary as well. The storage issues may be developed in unlike ways, nevertheless, in this area similar functionality is defined and achieved (i.e. rule database access operations). Drools Guvnor alleviates writing rules in DroolML notation or using domain-specific, higher-level set of phrases. It also provides mechanisms for converting them into knowledge packages and then storing or making them accessible for rule engine. Visual Rules base on fully graphical modelling of ruleflows and then converting them into ordinary Java libraries. Transitional notation is not needed, which makes the rule authoring stage much more available for a business-level user. Technical level rules are not distinguished. The divergence in rule editing approaches and advancement of tooling mechanisms derives, in great extent, from the systems characteristics (open project vs. business product). Nevertheless, the mentioend examples show the trends in BRMSs development directions Conclusions Two further paths of the progress of rule management systems could be distinguished. On the one hand further improvement of functionality is expected (i.e. easiness and comprehensiveness of knowledge acquisition and management). This includes adaptation of various types of knowledge assets (ruleflows, decision tables, DSL rules etc) and is obviously followed by designing more and more sophisticated user interface for creating, revising, deploying, storing rules. On the other hand, taking into account available 21

34 Chapter 2. Related Work production systems technologies, widening of the interoperability of policy- and ruleoriented systems, as well as BRMSs is required. This assumption must result in solving diverse issues of policies and rules transformations. 2.5 Policies and Rules Transformation Aspects The abundance of BRM technologies and products can be beneficial as different approaches attempt to address a variety of problems. However, it greatly impacts the cooperation of systems that utilize different production rules technologies or the usability of distributed systems that are built upon components using different technologies to specify their behaviours. After selecting a production rule platform and defining the business knowledge in the way that the platform imposes, the organisation should have the system implemented successfully. However, the organisation may be faced with the necessity of not only changing (i.e. updating), but also transforming the system knowledge. For instance, according to some political or business decisions the organisation may be forced to transition to another production rule system or begin cooperating with organisation that utilizes different rule system technology. In case of distributed systems the situation is alike. As far as the system is homogeneous from the point of view of the utilized business rules technology, the knowledge governance does not face problems of policies transformations. The situation complicates when various rule technologies are used. Indeed, the behavioural and functional complexities reduced by rules and policies at the component level translate into management and interoperability issues at the distributed application plane. Considering such heterogeneity many reasons for carrying transformations of policies or rules are to be taken into account. Mostly they derive from the needs of components cooperation or knowledge unification. The issues can be investigated at both policies and rules levels: policy-level: refinement, interoperability, interchange, integration of policies, rule-level: fields of applications, models, notations, abstraction levels of rules. These aspects will be discussed in the following paragraphs Policy-level Transformation Reasons These issues consider transformation of policies as a whole, i.e. as an entire set of rules. The reasons for carrying such transformations may be different, e.g. clarifying the policy, reducing a number of rules, integrating various policies for cooperation or easy governance purposes. Hence, the purposes of such process are global, but actually they base on modifications of component rules. In following paragraphs policy refinement, interchange and integration issues will be introduced. 22

35 Chapter 2. Related Work Policy refinement The process of deriving of low-level enforceable policies from high-level administrative guidelines is called policy refinement [73]. It remains one of the most ambitious goals in policy-based security management because it aims to automate the realization of high-level requirements in executable implementations [36]. Early studies (e.g. [37]) highlighted some of the specific issues of the policy refinement and attempted to address them in a very restricted way. There has been renewed interest in this problem in recent years [33], [73], [34], which address subsets of the problem such as goal decomposition for refinement or transforming specifications using predefined mappings. First solid work [33] proposed a goal-oriented requirements engineering Goal-oriented Requirements Engineering (GORE) method in the field of policy based approaches to network and systems management. Loyola et al. [73] present policy refinement framework as the result of more methodological approach. Policy interoperability and interchange Interoperability refers to the ability of diverse systems and organizations to work together thanks to the capabilities of sharing data or communicating. In policy plane that means the exchange and reuse of policies by different systems or components. Rosenberg and Dustdar [42] present an idea of Service-Oriented Business Rule Broker. Using it under common Web Service layer allows exposing accumulated knowledge to distant components via so called rule web services. Service consumers have no consciousness of exact rule engine existence. The exposed knowledge is actually accumulated within a number of rule engines and also mechanism are provided to exchange gathered rule sets between them. Above authors [43] presented also a way to incorporate business rules managed by different engines into one process-oriented composition depicted by Business Process Execution Language (BPEL). Business Rule Broker service plugged into Enterprise Service Bus (ESB), provided a unified access to the shared knowledge through a dedicated Web service interface. Mayer [44] presented an extension to the IETF s basic model to address system-tosystem interaction in an inter-domain environment. In order to allow exchange of policy information by multiple domains, Policy Exchange Interface is added to basic Policy Based Enterprise Management (PBEM), facilitating a distributed PBEM. Many aspects are considered, including Policy Exchange, Synchronization and Negotiation. Facing the abundance of technologies implemented, de Leusse and Kwolek proposed an integration platform for multi-rule-engine distributed systems leveraging on different products (Drools, Jess) [41] [39]. The authors presented a web-based common interface along with supporting tools that allow discovering rule engines in a distributed environment, retrieving from and registering rules to them and finally interchanging rules between them by providing unique translation utility between different rule notations. As can be seen different approaches for exchanging politics between systems have been presented. The problem has been noticed, but no final concise solution has emerged so far. In fact, the issue is not trival as it incorporates not only transfer of rules from one system to another (e.g. translation, exchange and synchronization questions), but also control of policy correspondence (e.g. negotiations, precedence and conflicts solving). 23

36 Chapter 2. Related Work Knowledge integration Integration refers to combining basic entities into an integral and unified whole. Police integration process brings together basic policies into one unified policy for sake of gaining the global perspective that can alleviate a unified policy governance. The process is somehow contrary to policy refinement that aims in creating lower-level policies based on higher-level assumptions. It needs to be mentioned that the knowledge integration process covers not only syntax issues, but it can be faced with ontological otherness questions. However, the ontological aspect is not investigated in this work. Not many works can be found in literature in this area. De Leusse [38] proposed a framework for an integration platform for governing policies throughout multi-rule-engine distributed systems that leverage on different products (i.e. Drools, Jess). The system enables extracting of basic knowledge artefacts from different policies and combining them into common knowledge items that can be globally managed. In further works [40] such approach is applied in the field of global governance of cross-cloud applications Rule-level Transformation Reasons As opposed to the policy-level, the rule-level transformations focus on a single rule conversion issues. They aim at changing the way of expressing a rule, e.g. for the sake of whole policy transformation or inter-engine rules transfer. Hence, the purposes of such processes are rather local, but actually they constitute the base for transformations of entire policies. The rule level transformation reasons base on the abundance of rule expression methods. In the following paragraphs the aspects that constitute the fundamental source of such rule diversity (e.g. fields of interest, rules models and notations) will be introduced. Policy information models and rule categorization Two approaches to rules classifications are presented in this section. Rule information model emphasises the structure of a rule and categorization bases on a rule purpose. Agrawal et al. [13] specifies three common rule information models: Condition-Action Information Model the the most widespread model in production systems. It distinguishes two parts: condition and action. A rule forms statement: WHEN condition C is true THEN execute action A. Event-Condition-Action (ECA) Information Model an extension of the above type that incorporates the concept of event and is useful in situations when the policy evaluation happens asynchronously. A rule forms statement: UPON occurrence of event E, IF condition C is true THEN execute action A Mode-Subject-Action-Target Information Model the model that bases on modal logic sentences (e.g. deontic or alethic), expressing obligation, possibility, permission, necessity etc. (e.g. Subject S is authorized to action A, Subject S is obliged to perform action A etc.). Some phrases of this kind can be reformulated into condition-action rules (e.g. 24

37 Chapter 2. Related Work if subject is S then perform action A), but modal aspects (e.g. necessity) are not directly translatable. possibility or Wagner s work on rule modelling [47] presents a rule categorization, which in fact is parallel to the taxonomy presented above, but introduces a higher level of granularity and relates the rule formulation with its application objective. In this way the significant non-equivalence of rules of different types is exposed. The designated categories are: integrity rules also known as (integrity) constraints, consist of a constraint modality (the alethic or the deontic) and a constraint assertion, which is a sentence in some logical language such as firstorder predicate logic or OCL. The alethic constraint modality can be expressed by a phrase such as it is necessarily the case that. The deontic constraint modality can be expressed by phrases such as it is obligatory that or it should be the case that (cf.: Mode-Subject-Action-Target Information Model). derivation rules (also called deduction rules) consist of one or more conditions and one or more conclusions, which both play roles of logical formulas i.e. functions from variable bindings to truth values. reaction rules consist of a mandatory triggering event, an optional condition, and a triggered action term or a post-condition (or both). While the condition of a reaction rule is, exactly like the condition of a derivation rule, a quantifier-free formula, the post-condition is restricted to a conjunction of possibly negated atoms (called CAN-formula) (cf.: Event-Condition-Action Information Model). production rules consist of a logical condition and a resultant action (cf. Condition- Action Information Model). transformation rules consist of a set of two expression schemes that allows transformation of the former one into the latter (i.e. XSL Transformations (XSLT) [136]). Integrity and transformation rules have not received as much attention as derivation and reaction rules. Reaction rules are considered to be the most important type of business rule in [48]. In view of specific concepts (i.e. events, modality) the objectives of use and the expressiveness of rule models (or categories) may differ. Such disparity of rule expressing methods may cause problems in rule transformation plane, i.e. some additional external knowledge may be required. Fields of interests Policies are everywhere [Norman Sadeh, Semantic Web Policy Workshop panel, ISWC 2005], which means that they may concern various, sometimes very distant domains: security (e.g. access control policies), privacy (e.g. information collection policies, obfuscation policies), B2B contracts (e.g. quantity flexible contracts, late delivery penalties, etc.), negotiation (e.g. rules associated with auction mechanisms), workflow management (e.g. conditions of flow change decisions), context aware computing (e.g. contextsensitive preferences) etc. Such wide variety of interests casts on rule notations, even though they are intended to be constructed independently of domain biases, in the most 25

38 Chapter 2. Related Work general way possible, and covering the widest area possible. There are many examples of rule languages that are affected by the domain specific character. For instance, noticeable stress in policy research was put on security and network traffic management, since the domains are easily definable in terms of functionality and necessary semantics [4] [60] [29] [45] [46]. These domains were also widely used in the policies refinement studies. This interest results in emergence of rule notations for defining strategies of authorization (e.g. extensible Access Control Markup Language (XACML) [102]), trust management (e.g. Ponder [29]), network access and traffic control (e.g. Cisco Access Control List [126]). Finally, in business sector rules are found in abundant production rule platforms that reinforce organisation systems with business logic. However, another great example in this field are efforts in describing enterprises themselves in terms of the structure of the data those enterprises use, the organization of the functions they perform, and the constraints under which the they operate. For such purposes OMG proposed Semantics of Business Vocabulary and Business Rules (SVBR) [129] that can provide operative rules (using deontic logic), structural rules (using alethic logic), but not action definitions, which means that the rule enforcement is outside of the Semantics of Business Vocabulary and Rules (SBVR) scope. The examples shown above present not only the variety of fields of interest to be supported by policies solutions, but also depict aspects influencing rule formulation that may cause the transformation processes to be troublesome. Rule notations Such variety of fields of interests and schemes of defining rules casts on the multitude of rule languages. Rule notations are intended to be constructed independently of domain specific biases, in the most general way possible, and covering the widest area possible. However, there are many examples of specific domain notations which semantics derives from the domain character. At one extreme policies can be written in natural languages (traditionally used for real life polices, e.g. corporate policies), but those cannot be processed by computers directly. Therefore, some solutions like standardized natural language (e.g. Simplified Technical English (STE) [130]) or casting of natural language phrases to rule code (e.g. Domain Specific Language (DSL) in Drools). On the other extreme, mathematical notations are good for precise representation of policies in order to process them by computers. In particular first order logic, stratified logic, and deontic logic were used. However policies specified in such ways are difficult to understand and have limited expressability [13]. For a long time, logic programming and rule-based formalisms have been considered appealing policy specification languages, as witnessed by a large body of literature [84]. Most policy systems strike a compromise between these two extremes. They use languages that are specifically designed to satisfy the requirements of a policy system. However, even in this case the notation of a rule may vary based on an alleged user type. For domain-experts (as opposed to technical experts), it is often easier to express rules through their natural language or graphical diagram. Majority of academic researchers and commercial technical professionals concentrate on abstract notation, which require learning. 26

39 Chapter 2. Related Work There are many policy languages in use, some are academic standards (e.g. Policy Description Language (PDL) [49]), others were developed for a specific projects (e.g. REI [91]). In the commercial market different vendors of production rules systems released a multitude of proprietary standards (e.g. DroolsML [107], Jess [110]) (cf. section 2.3.2). A lot of rule languages examples has been already mentioned. In section some rule notations for security purposes were shown (Access Control List (ACL), XACML, Ponder). At the same place two CIM-related notations were referred as well (CIM-CQL, CIM- SPL). Due to historical reasons, the Policy Description Language (PDL) [49] from Bell labs, as one of the first ECA-type policy languages that influenced the design of many subsequent policy languages, should be mentioned as well. Even XML transformation mechanism - XSLT may be perceived as a rule language. Two important domains of rule interest should be marked. One group represents semantic-oriented languages that tend to adjoin semantic information to policies. First example is already mentioned Semantics of Business Vocabulary and Rules (SBVR) [129] from OMG. It aims at describing an enterprise data structures, function organizations and constraints based on a semantic model. The second example is Semantic Web Rule Language (SWRL) [133] that was announced by W3C for the needs of Semantic Web movement that encourages the inclusion of semantic content in web pages in order to convert the current web of unstructured documents into a web of data. Second group refers to the area of rule interchange. The formats to number here are the Rule Interchange Format (RIF) [123], which is a W3C Recommendation, RuleML developed by RuleML Initiative and Production Rule Representation (PRR) [132] by OMG, proposed as a cross-vendor rule modelling representation. The issues of rule interchange will be discussed in more details in section Rule Translation Conclusions Various aspects related to policy transformations can be found in the literature. The foundations and objectives for the transformations can be distinguished both at the policy level, as well as the rule level. The need for policy transformability manifests in many issues, e.g. policy refinement, interchangeability or integration. As a single policy consists of component rules, its overall transformation is based on transformability of these building elements, which in turn depends on the way of their expression. Different aspects underlie the rule articulation methods, such as different fields of interests or conventional rule models, what results in abundance of rule notation languages found both in the academic and the industrial planes. Nevertheless, the existence of a method for rule translation is not axiomatic and it is not the syntax of the rule language that may cause the majority of transformation problems. Aspects like the rule objective (i.e. derivation, constraint, obligation) or the scope of expression may cause that a rule is untranslatable into another notation, because it is impossible even to express it (e.g. alethic relations such as necessity, possibility, contingency can not be straightforwardly expressed in the form of if-then statements). In conclusion, it is not the matter of the same field of interest or notation itself, but rather the issue of compatibility of policy information model or rule category that decides whether a rule is translatable or not. 27

40 Chapter 2. Related Work In the following sections aspects related to expressing policies at different levels of abstraction and transitioning them between these levels will be presented. 2.6 Abstraction Levels What was not considered in the previous section is that one coherent policy can be perceived in different ways by different members of an organisation or users of a system in which the policy is used and this may be for the sake of user capabilities (i.e. technical or non-technical knowledge), field of interest (i.e. superior business objectives, cost effectiveness, security, input-output actions) or domain model granularity (i.e. general concepts, technical data) etc. This is not a problem of a single rule syntax (rule notation can be chosen arbitrarily), but it constitutes a new aspect of policy shaping flexibility Abstraction Level Definition The definition of policy abstraction level can be found in RFC 3198 Terminology for Policy-Based Management (2001). POLICY ABSTRACTION Policy can be represented at different levels, ranging from business goals to device-specific configuration parameters. Translation between different levels of abstraction may require information other than policy, such as network and host parameter configuration and capabilities. Various documents and implementations may specify explicit levels of abstraction. However, these do not necessarily correspond to distinct processing entities or the complete set of levels in all environments. Moreover, the same document in the definition of the policy translation specifies levels of abstraction as one of the motives of such translation (cf. section 2.7). The definitions introduce the overall concept of the abstraction levels of a policy. The levels may differ in the field of interest, the notation, the objective of policy usage etc. The document states that various systems may specify they own abstraction levels and hence it does not show a set list of such levels, but only examples such as business goals and configuration parameters. Two years later in RFC 3460 Policy Core Information Model (PCIM) Extensions (2003) the levels of abstractions are presented as one of the extensions to the PCIM model. The document states that policy scopes may be thought of in two dimensions: 1) the level of abstraction of the policy specification and 2) the applicability of policies to a set of managed resources. Here, the concept of abstraction levels of policies is applied strictly to the field of computer systems and networks. In Section Levels of Abstraction the following paragraph can be found: 28

41 Chapter 2. Related Work Domain- and Device-Level Policies vary in level of abstraction, from the business-level expression of Service Level Agreements (SLAs) to the specification of a set of rules that apply to devices in a network. Those latter policies can, themselves, be classified into at least two groups: those policies consumed by a Policy Decision Point (PDP) that specify the rules for an administrative and functional domain, and those policies consumed by a Policy Enforcement Point (PEP) that specify the device-specific rules for a functional domain. The higher-level rules consumed by a PDP, called domain-level policies, may have late binding variables unspecified, or specified by a classification, whereas the device-level rules are likely to have fewer unresolved bindings. What is important, the document points that there is a relationship between these levels of policy specification that is out of scope for this standards effort, but that is necessary in the development and deployment of a usable policy-based configuration system. The translation between different abstraction levels may need additional information. Such knowledge requires familiarity with the domain of a level, or better the domains of both levels and relations between them. Therefore, this is more a meta-knowledge, as it makes up a knowledge about a knowledge. This is the aspect that will be studied further in this work. Fig. 2.9: Rule concepts and languages at different levels of abstraction [47] In the literature another approach to defining the rule levels of abstractions can be found [47]. It concerns categorization of rule concepts and languages as shown in Figure 2.9. Three abstraction levels are pointed: business domain (Common Information Model (CIM)) - rules are statements that express (certain parts of) a business/domain policy (e.g., defining terms of the domain language or defining/constraining domain operations) in a declarative manner, typically using a natural language or a visual language; platform-independent design (Platform Independent Model (PIM)) - rules are formal statements, expressed in some formalism or computational paradigm, which can be directly mapped to executable statements of a software system; 29

42 Chapter 2. Related Work platform-specific implementation (Platform Specific Model (PSM)) - rules are statements in a language of a specific execution environment. This taxonomy, even it concerns only the categorization of rule languages, points different levels of policies definition and hence confirms the wider recognition of the existence of the policy and rules abstraction levels. What can be noticed in the Figure 2.9 is that in fact the rule languages are segregated into platform-independent (PIM level) and platform-specific (PSM level). The highest level (CIM), called business domain level, in fact defines the concepts related to policies and rules and thus it differs from the concept of business level rules that will be used in further sections Business Level vs. Technical Level Although a priori multiple abstraction levels may be present in a system or an organisation, only two layers are commonly referred in the literature: High-Level policies (HL) and Ligh-Level policies (LL) [50] [51] [52]. This dichotomic distinction was drawn by Verma el al. in works concerning QoS [75] [76] [25]. HL are used to express businesslevel rules and LL policies are used to express technology-level rules [52]. Here, the business level refers to overall goals and concepts to maintain by a system or an organization. These objectives are expressed as statements of an execution environment at the technology-level. Such distinction resembles abovementioned PIM and PSM levels. This dichotomy is also maintained by OMG works on business rules standards [134] [135]. One of the integral parts of OMG s Model Driven Architecture (MDA) is the Semantics of Business Vocabulary and Rules (SBVR) [129]. It defines the vocabulary and rules for documenting the semantics of business vocabularies, business facts, and business rules. Although in this case the term business refers to a real-world business organization, it also indicates a definition of HL policies. The SVBR is accompanied by technologyoriented standard - Production Rule Representation (PRR) [132], that concern general representation of LL rules, in this case - IT rules. Rule management systems implemented the concept of distinguishing higher-level business rules and lower-level technical rules as well. For instance, ILOG JRules provides tools for defining ruleflows and creating business rules based on BAL - Business Action Language and technical rules based on IRL - ILOG Rule Language (similar to Java and enabling an easy integration with Java). The Visual Rules use graphical diagrams for business rules and compiled Java libraries as technical rules. In the Drools Guvnor domain experts can make use of DSL - Domain Specific Language and more advanced technical users can define rules directly in DroolsML Conclusions The model consisting of only two abstraciton level was discussed above. However, it should be remarked that, even if only business and technical levels are recognized by current rule models or production rules systems, there might be a need of distinguishing more levels of expressing the same policy. It refers to both defining business goals as well as technical activities. At one hand, the definition of business goals can be expressed in different ways by different members of an organisation or users of a policy-based system. As mentioned 30

43 Chapter 2. Related Work above this may be for the sake of user comprehension capabilities, fields of interest, domain model granularity etc. The higher level of abstraction of a policy - the easier comprehension by a user. The lower level of abstraction - the easier machine processing. On the other hand, considering the complexity and expandability of the modern systems, a single activity completion can be perceived (or coded) at multiple stages of detail. For instance, an action defined in one module, but depending on or consisting of actions realized by other module(s), is perceived differently from the points of view of those various modules (or levels of its completion). In policy definition plane that will mean that conditions and actions are specified differently from the points of view of those various modules or speaking more generally - they are specified differently at different levels of abstraction. In the above sections numerous aspects of rule specification were discussed. The next step in this study is to ponder on the issues of possible translations between those various representations. 2.7 Rule Translation In the section 2.5 the general backgrounds of the needs and goals of transforming policies and rules were presented. In this section the nuances of the policy translation task are discussed, including various rule relations that underlie the process and the distinction of horizontal/vertical translation processes. Rule translation is a very extensive concept that combines many ideas that were already mentioned in previous sections, such as policy refinement [74], policy interoperability [52] or OMG mapping business rules to IT rules [135]. The easiest example of a rule translation task is changing a notation that is used to express a rule or casting high-level description of a rule (i.e. in natural language) into platform specific code. The formal definition that can be found in RFC 3198 Terminology for Policy-Based Management (2001) states: POLICY TRANSLATION The transformation of a policy from a representation and/or level of abstraction, to another representation or level of abstraction. (... ) In this conversion, the translation to the new representation is likely to require a change in the level of abstraction (becoming more or less specific). Although these are logically distinct tasks, they are (in most cases) blurred in the act of translating/converting/mapping. Therefore, this is also known as policy conversion or policy mapping. Such description admits many reasons and purposes of policy translation. Even it equalizes terms translation / conversion / mapping, it points the existence of subtle logical differences of those tasks. The author assumes that: Policy translation refers to rendering a policy into another notation (conversion of language), without changing its meaning. Policy conversion allows change in character, form or function of a rule. 31

44 Chapter 2. Related Work Policy mapping refers to a process of logical binding rules belonging to different sets of rules (e.g. various domains of interests or abstraction levels). There are various details that diversify the translation processes, such as a direction of transformation or the moment of carrying it out. In some cases the process is unidirectional. For instance, as mentioned in section Policy refinement, the refinement is concerned only with the process of mapping a set o HL policies to a set of LL policies. In contrast, Magrath et al. [52] introduce interoperability as a bi-directional mapping. The refinement process occurs before policies are operationally deployed. Interoperability occurs as a part of operational deployment. Nevertheless the translation process concerns different notations or different abstraction levels, it requires additional information that derives from knowing the domains between which the translation is carried as well as the relations between this domains. In order to a system is capable of executing a translation, it has to be provided with a mechanism such as inter-language translator, set of rule bindings, transformation policy etc. In fact this knowledge can be perceived as a meta-knowledge, since it represents a knowledge about a knowledge. In the following section different types of rule relations that were distinguished in the literature are presented Manifestations of Rule Relations Ideas of policy dependencies and transformations were introduced a time ago. In [74], which addressed distributed system management, the importance of understanding hierarchical relationships between policies was postulated. A number of approaches to defining relations between rules can be found in the literature or among solutions of production rule systems. In fact, they express very different aspects of existing dependencies and introduce various schemes for representing them. These aspects concern the following questions: what/how elements of a rule expressed in one notation correspond to elements of this rule expressed in another notation? what/how rules belonging to one set of rules (e.g. field of interest, abstraction level) correspond to rules in another set? what are the dependencies between rules in a set of rules? how to describe rule dependencies? In the following sections some most common concepts are shown. Rule substitution and rule interchangeability concentrate on rules formulation language and address the first question. Refinement mapping and rule interoperability concentrate on relating rules placed on different levels of abstractions and address the second question. Rule hierarchies and metapolicies concentrate on means of pointing relations within a set of rules (i.e. based on level of detail) and also describing these dependencies and address the third and the fourth question. 32

45 Chapter 2. Related Work Rule substitution The simplest way of providing relations between two sets of rules is a literal mapping the fragments of one rule into elements of another rule. Such solution can be found in the Drools platform. It provides two stages of rule definition. Technical specialist use proprietary DRL notation (Drools Java-based syntax), but non-technical users, such as domain experts, that are not familiar with this notation can take advantage of a domain specific semantics that can be close to a natural language. The translation between this two forms relies on simple replacing set phrases of one notation by phrases written in the other notation based on a DSL template definitions. What makes the solution flexible is the possibility of creating the DSL file dedicated for concrete users familiar with concrete area of interest. Nevertheless, the transformation is eventually none but a replacement of strings, unconscious of a rule sense or meaning of parameter values. Rule interchangeability Rule interchangeability concerns the ways of exchanging policies between heterogeneous entities for sake of cooperation, reusability etc. Currently, the main initiatives for rule interchangeability are Rule Markup Language (RuleML) [131], Rule Interchange Format (RIF) [123], REWERSE Rule Markup Language (R2ML) [137] and the Production Rule Representation (PRR) [132]. The RuleML Initiative develops the Rule Markup Language (RuleML). The goal of this initiative is to develop a canonical Web language for rules using XML markup, formal semantics, and efficient implementations. The RuleML initiative started in 2000 and aims at becoming the standard rule markup. It already provides translations to and from different rule languages as well as other tools such as user interface. Rule Interchange Format (RIF) is developed by a dedicated World Wide Web Consortium (W3C) Working Group since RIF focuses on rule exchange rather than develop a specification to replace all the others. In order to address the many challenges of rules interchangeability, RIF is meant to be extensible and is divided into dialects that are all based on a common core and share as many properties as possible but each specialize in a particular domain. REWERSE Rule Markup Language (R2ML), is the result of the FP6 REWERSE project. Although interchange was indeed one of the main objectives, there is currently no result available. Furthermore, there has been no visible activity since September Production Rule Representation (PRR) was proposed by the Business Rules Working Group (set up by the OMG in 2002) for sake of the Business Rules Approach, which defines policies and practices for business organizations specifically. The PRR version 1.0 was published in December The PRR was developed as an OMG specification for providing a vendor-neutral rule-model representation in UML. Its main goals address improving of the modelling of production rules, especially with respect to the Unified Modelling Language (UML) and MDA, and allowing interoperability across different vendors who define production rules in models. The standard is aligned with Production Rule Dialect (PRD) of the RIF. 33

46 Chapter 2. Related Work Rule hierarchization Moffett and Sloman [74] presented policy hierarchies for distributed system management. The solution introduces a way to categorize a policy throughout multiple levels of policies definitions and defines some theoretical concepts of transformation steps for specific relation types. In this way a policy hierarchy is formed in order to automate the management of very large distributed systems. The authors introduced a management action policy represented as a generic policy object. Having analyzed imperatival and authority classes of policies, they identified a set of different relationships within policies partitioned targets, goal refinement, arbitrary refinement of objectives, procedures, delegation of responsibility. The model clarifies many of the issues relating to linking higher level policies with a set of lower level policies (according to the specified relationships). However, it concerns only authority and imperatival policies and lacks practical implementation with a common notation of policy definition. Nevertheless, a discussion was raised concerning the conversion of high level policies into a number of more specific policies to form a policy hierarchy. In this way the model touched two important objectives. The first one refers to definition of a hierarchy between sets of rules (i.e. policy refinement, see the next section). The second concern the creation of a hierarchy within one set of rules in order to form a structured knowledge base. In fact, the problem of flat knowledge bases was recognized recently [26]. Most of the current solutions define policies as sets of equally important rules and do not recognize the dependencies of the rules within a policy. Nalepa introduces the extended Tabular Trees (XTT2) knowledge base structure. The structure recognizes smaller rule sets that relate to own contexts and define dependencies with other sets. Moreover, the author proves that applying such hierarchy that derives from attribute relations can alleviate the inferring process (in comparison to RETE trees). The semantic information may also represent interconnections between rules. Such attempts were done on the base of SWRL language [133]. Hassanpour et al. introduced research on exploration of logical dependencies in SWRL rule base through rule visualization, paraphrasing and categorization [53] [54]. Rule hierarchies derived from OWL references are presented in the form of dependency graphs. According to their observation comparatively little work has been done in mining rule bases themselves to assist user comprehension. Rule argumentation techniques typically examine the relationships between rules, but do not focus on making the rule bases easier to understand. Policy refinement and mapping The process of deriving of low-level enforceable policies from high-level administrative guidelines is called policy refinement [73]. It differs from the abovementioned phrase replacement significantly, as it changes not only the notation, but first before all the abstraction level. Mostly it refers only to two levels HL and LL. Moffett and Sloman [74], identify the main objectives of a policy refinement process as: determine the resources that are needed to satisfy the requirements of the policy. 34

47 Chapter 2. Related Work translate high-level policies into operational policies that the system can enforce. verify that the lower level policies actually meet the requirements specified by the high-level policy. Bandara [33] interprets them in the following way: The first of these objectives involves mapping abstract entities defined as part of a high-level policy to concrete objects/devices that make up the underlying system. The second specifies the need to ensure that any policies derived by the refinement process be in terms of operations that are supported by the underlying system. The final objective requires that there be a process for incrementally decomposing abstract requirements into successively more concrete ones, ensuring that at each stage the decomposition is correct and consistent. To prove that a lower-level specification correctly implements a higher-level one, refinement mappings are used. Abadi et al [50] show that, under reasonable assumptions about the specifications, if S1 implements S2, by adding auxiliary variables to S1 the existence of a refinement mapping is guaranteed. This provides a completeness result for a practical hierarchical specification method. The authors exposition has been purely semantic. They considered specifications, but not languages in which they are expressed, which makes the argumentation adequate for policy mappings as well. Rule interoperability Magrath et al [52] augmented the concept of policy refinement, which is concerned as one direction HL LL mapping. Considering most of the policy specification approaches and languages of that time as not to be able to bind between HL and LL policies innately, a separate Interoperation Layer (IL) was introduced in order to fulfil dynamic policy refinement circle (LL HL LL) and to mediate between HL and LL representations (Figure 2.10 [52]). Fig. 2.10: Policy Refinement and Policy Interoperability with joins via IL [52] All additional binding information that served to bind HL and LL was considered as a set of IL relations that allowed resolving HL policy requirement into LL deployable specification. To allow the linkage between HL and LL to be achieved the join operator was introduced. The solution concerned a network autonomics field of interest. What is worth mentioning in order to achieve more general abstracted policy continuum, the concept was proposed to cascade the interoperability model (i.e. one man s HL is another man s LL ). 35

48 Chapter 2. Related Work Metapolicies Hosmer [77] recognized metapolicies as policies about policies that make the rules and assumptions about policies explicit and coordinate the interaction of multiple policies. Their basic functions were defined as: describe policy structure and interrelationships, control policy additions or modifications, coordinate policies or subpolicies (policies that contribute to a broader policy), establish policy precedence, resolve ambiguities, resolve policy conflicts. The convention did not refer to the production rules specification exclusively, but generally to policies as the plans of an organization to meet its goals [35]. The need for metapolicy definition was presented in the context of multipolicy systems (e.g. multinational corporations enforcing confidentiality rules of different nations or hospitals meeting state, national and local integrity and privacy regulations). Hosmer specifies different types of metapolicies (e.g. description, constraint, subpolicy interaction, coordination etc) and analyses their functions (e.g. sequence, multiple policy organizations, flexibility etc). Among the ways of metapolicies implementation rule-based systems are identified. Baskervill and Siponen [78] showed similar metapolicy provenance. A metapolicy is to control policy making: how policy are created, implemented and enforced. Security policies should be as changeable as the organizations they protect. However, such adaptation cannot be wholly uncontrolled and haphazard. Hence, emergent organizations must address their needs for flexible, adaptive information security by setting supportive meta-policies. These meta-policies describe exactly how and when information security policies are made (or changed). Event that only security is mentioned in the citation, the concept refers to whole spectrum of policy application fields. For instance, Hu and Boley [79] introduced metapolicies into augmented Semantic Web Architecture to provide uniform services of interchange, reconciliation and combination of multi-policies from various domains of the Web Horizontal and Vertical Translations Different classifications of policy transformations can be proposed depending on the frame of reference. For instance, the techniques of policy transformation were classified by Mandis et al [80]. Generic transformation mechanisms were presented and their effectiveness was studied. The article introduced static and dynamic policy conversion approaches: a transformation module supported by a static transformation rule repositories, 36

49 Chapter 2. Related Work an adaptive policy-based systems management architecture supported with an online monitoring component. Within the approaches to the handling of rule relations that were listed in the above section two significant classes of the rule dependencies can be distinguished. The first class concerns rules belonging to the same level of abstraction (e.g. rule interchangeability, phrase replacement) and the other concerns the rules that stay in different levels of abstraction or domains (e.g. policy refinement, rule interoperability). Each of this approaches constitutes a discrete range of problems and defines different challenges to be taken. Such distinction corresponds with the abovementioned IETF s definition of policy translation that indicated two objectives of a policy transformation a change of notation and a change of abstraction level. In this context the author specifies two classes of rule translation: horizontal and vertical. The horizontal translation concerns mechanisms of changing a notation of a rule without interfering the rule sense, which mean that only the syntax changes, not the entities or the actions that are the subjects of the transformed rule. The goal of this class of translation methods is the providing of interchangeability of policies between different notation standards and hence different production rules platforms (e.g. Drools, Jess). The vertical translation refers to mechanisms of changing the level of abstraction (or a domain) of a rule which eventually may affect not only the entities and the actions that are the subject of the transformed rule, but also the number of resulting rules. The goal of this class of translation methods is enabling the interoperability of heterogeneous rule driven systems or system components that operate on different levels of abstraction or refer to various domains of interest. The two types of translations may be composed to provide a general transformation. For instance in order to acquire a Drools code adequate for a general policy expressed in a simplified natural language, two translations can be provided. Firstly, a vertical translation of general policy into specific rules expressed in simplified natural language. Secondly, horizontal translation of the specific rules from simplified natural language into Drools notation. Horizontal translations In general each rule specification has its own particularity and it is necessary for the translation logics to take these into account so that the losses in translation are as little as possible. Even though the interchange process is bound to encounter limitations. First of all, different rule information models exist (cf. section 2.5.2) and elements fundamental in one information model can be untranslatable into another model (e.g. modality or events). Even within one specified rule information model, the expression possibilities can differ for each rule standard or technology and hence no straight translation may exist. Another major limitation lies in the underlying technologies. For instance, Drools and Jess are J2E application, and as such require the rules to be translated from Java code into XML. Recursive, non-declarative (if... then... ) and cycling structures (while, for) translate relatively poorly into XML. 37

50 Chapter 2. Related Work DroolsML XSLT RIF PRD* RuleML* XSLT JessML Fig. 2.11: Horizontal translation method leveraging XSLT and RIF / RuleML [39] In case of a many-to-many-languages translation an intermediate form is needed in order to avoid creating separate translators from each notation to all the others. Current solutions tackle this issue by proposing a new policy-rule notation. De Leusse and Kwolek [39] proposed the approach that makes use of an existing and recognized specification for the shared language RIF PRD or extended RuleML. The successive translation tasks are executed with the use of XSLT transformations. The solution taken by the authors, as illustrated in Figure 2.11, aims at allowing reusability and further extension and modification. Vertical translations In the previous section the possibilities of translation between different rule languages were discussed. The basic assumption was that the input and the output rules were representing the same chunk of knowledge, within the same domain of knowledge, but only expressed in different manner. The vertical translation of rules enables flexible and dynamic generation of rules at one abstraction level (knowledge domain) based on the rules at another abstraction level (knowledge domain), when some relations between those rules can be defined. The concept is common for the policy refinement and interoperability fields (as shown in the section 2.7.1) and classically recognizes two levels: a general business logic rules (business level) and executive rules (IT level, e.g. security assumptions into access lists). However, the concept is much wider. In fact, for one system various abstraction levels can be distinguished. Each level can refer to one own context and have specific relations to other levels. By stacking these pairs a layered structure of policy abstraction levels with inter-level relations can be created. On the other hand, one can distinguish not separate abstraction levels, but simply groups of rules that have the same context and specify some relations with other groups. In this way a more sophisticated hierarchy of a knowledge base can be reached [26]. The vertical translation is not based on substitution of fragments of input rules by fragments of output rules (as in Drools DSL mechanism). This process has to take into account a context of the translation, e.g. parameters values of the input rules. This means that the translation of a rule can bring a different output rules for i) medium and ii) utmost values of the input rule parameters. Moreover, on the contrary to the horizontal translation, the vertical translation can result in creation of not one but several output rules. In this context the relations enabling such vertical transformation constitute a metaknowledge that must be defined separately, e.g. by an inter-domain expert that knows both the input and output rule abstraction levels. That is analogous to providing an inter-language translator to a system in case of horizontal translation. 38

51 Chapter 2. Related Work Conclusions The section shows that various manifestations of interrelations between rules already have been recognized and different methods to dealing with them were created. However, the structuralized approach to this subject has not been developed yet. Different concepts of taking advantage of such rule dependencies have arisen, such as rule transformations (and rule translations among them). The author defined two approaches to rule translations. As shown, they may focus on dissimilar aspects, i.e. syntax (horizontal translation) or semantics (vertical translation). Except for several attempts has been taken, the area of rule translation still needs further exploration, as it appears to have varied applications. 2.8 Critical Overview While the first part of this chapter focused on the definition and taxonomy of knowledge and its evolving role in various types of computer systems (traditional systems, expert systems, rule-based systems), the second part explored the issues of policy structuring. Specifically, the factors that cause the necessity of policy transformations (in particular policy/rule translations) and the existence of various rule relations were studied with the emphasis on multi-abstraction-layer approach. By means of the accomplished analysis a number of limitations in utilization of policies in computer systems has been identified by the author. The main interest areas are stated as follows: 1. The existence of rule relations is underestimated (both within one policy or between different policies). Mechanisms or specifications of description of rules relations have not been studied in great extent. Such approach results in flat knowledge bases and limits the Rete algorithm efficiency [26]. 2. There are no visualisation mechanisms for knowledge bases (e.g. rule relations) allowing knowledge comprehension and correlation since most of the rule-based tools are just shells providing a rule interpreter and editor. The principal limitations of existing solutions result from either the lack of rule design assistance methods or the use of the methods that do not properly address the logical structure of the rule base on both representation and inference levels. 3. Knowledge acquisition constitutes a bottleneck in the design and development process [26], even BRMS tools exist (e.g. sophisticated editors, visual tools). More intelligent rule base management and more structured approach to knowledge-base design is desired (e.g. the application of a higher level of abstraction in knowledge acquisition proposed by Nalepa [26]). 4. The concept of abstraction layers is known, but not appreciated except for scarce distinction of business and technical layers. This causes that the policies are perceived univocally. 5. There is a need for rule translation mechanisms both horizontal (intra-level) and vertical (inter-level), that derives from the need of interoperability of modern heterogeneous systems and interchangeability of knowledge bases. However, modern BRMSs lack such mechanisms. 39

52 Chapter 2. Related Work The shortcomings defined as above found the background for this dissertation. As it will be shown in further chapters, the work shall try to face some of the existing limitations expressed above in order to explore possible augmentation of functionality of business rule management systems. However, the scope of interest is limited and is not going to cover all pointed areas, but only some selected aspects. Specifically, the research focuses on the usage of multiple abstraction levels during policy maintenance (area 4). In order to facilitate the process, mechanisms for vertical rule translation (area 5) that take advantage of rule interrelations (area 1) are investigated. Supplementary visual overview of the relations (area 2) is tested as well. 2.9 Chapter Summary Policy/rule-based systems gained a lot of interest in the past years. They owe it mostly to the philosophy of the separation of business knowledge from the hardcoded system logic and also the growing usability of knowledge management systems. However, it is the field of policy structuring that is still widely open for further exploration. The existence of various interrelations of rules and the necessity of policy transformations have been already recognized and studied. Nevertheless, the concepts have not been introduced into the field of BRMSs yet. This dissertation aims to bring the ideas into action by using them for policy authoring and evaluating its usefulness, while overcoming the limitations specified in detail in the preceding section. The base for the research is the multi-abstraction-level methodology to the policy authoring, that has not been explored before, as opposed to the common two level approach (i.e. business and technical levels). Achieving the goal requires facing a number of challenges (e.g. abstraction level management, vertical rule translation), but first before all verifying the new policy creation methodology. The further work does not intend to create a whole new rule management system, but only build and evaluate a tool for policy authoring that utilizes multi-abstraction-level approach. The scope of interest was specified at the end of section 2.8. Nevertheless, the successful practical employment of the concepts would comprise a new functionality for present rule management systems. 40

53 Chapter 3 Concept and Model of Inter-level Rule Translation In this chapter a new approach to managing policies at multiple levels of abstraction is presented. In order to reach such goal a new way for maintaining the coherence of rule sets at different levels is introduced that bases on a method of vertical translation of rules called Knowledge-based rule translation. The requirements and the proposed model of the concept are demonstrated in the following chapter. As it was demonstrated in the previous chapter, the existence of dependencies between rules has been already noticed and explored in a number of works. In addition, some research has been carried out in the field of rule translation. However, the application of the results into the area of policy maintenance support still leaves room for further works. The definition of dependencies between rules belonging to different levels of abstraction (or different domains) and usable specification of this relations can make possible the augmentation of functionality of business rule management systems and hence the usability of rule-based systems that refer to various domains. The following chapter aims to present a new approach to knowledge structuring and policy maintenance based on concepts of rule abstraction levels and vertical rule translation. To begin with, the conception grounds are presented in section 3.1 the motivation of the work and the objectives to be reached. In addition, the assumptions taken before creation of the solution are defined in section 3.2. The purpose of the next part of the chapter is to elaborate on the formal model of the proposed mechanism of vertical rule translation. At first, in section 3.3 the basic terms and methods of modelling rules, abstraction levels and rule interrelations are explained. Then, the elements of rule instantiation and translation mechanisms are defined and explained in section 3.4. The chapter sets the solid foundations for the solution realisation described in the next chapter. The demonstrated models of rule representation and translation play crucial role in the system design and implementation. 41

54 Chapter 3. Concept and Model of Inter-level Rule Translation 3.1 System Objectives The analysis of the features of existing production rule systems and business rules management systems shown in the previous chapter has led to the conclusion that introducing the concept of managing policies at multiple levels of abstraction enriched with a mechanism for vertical rule transition between various abstraction levels can augment the usability of rule governance tools. The multi-layer approach enables diversified insight into the policy and thus makes the policy maintenance more flexible and adapted for different user types. The gist of the concept is illustrated in Figure 3.1. One policy can be perceived in different manners by different users, who shape the policy at various levels of abstraction. In the figure, sets of rules are depicted at each level as well as dependencies of the rules. The supplementary vertical rule translation mechanism helps maintaining the policy coherence. P O L I C Y POLICY VIEW 1 POLICY VIEW 2 POLICY VIEW 3 ABSTRACTION LEVEL 1 ABSTRACTION LEVEL 2 ABSTRACTION LEVEL 3 VERTICAL TRANSLATION Fig. 3.1: Multi-level policy view and vertical translation concept The multi-layer approach to the specification of policies is supported by a general method for rule modelling that takes advantage of parameterised rule templates and that is further used to formalize the mechanisms of inter-layer vertical rule translation. The mechanism itself is designed in such way that it takes into account additional knowledge and it can bring different translation effects for different translation contexts. Thus it is called knowledge-based rule translation and significantly differs from a usual rule mapping. The knowledge used during the translation process is based on two elements: the domain specific aspects and the translation environment (i.e. the knowledge of the system in the moment of translation). The knowledge related to the policy domain has to be provided by an external expert and is taken for granted in the following deliberations. The methodology of specifying this knowledge is not the subject of this research (c.f. [26]). However, en effective method of its representation is proposed by the author. 3.2 System Requirements and Assumptions The requirements for the vertical translation mechanism introduced in this section derive from the investigation among existing technologies and current solutions for modern business rule management systems. The goal is to provide an improved approach to knowledge modelling support and also facilitate the rule governance. 42

55 Chapter 3. Concept and Model of Inter-level Rule Translation As it was described in the previous chapter, policy-based systems recognize at most business and technical levels of abstraction. Multiple levels of abstraction are not supported and a specific research in this area is not led. The models described in this chapter focus on providing method for the vertical translation between two levels with the assumption of possible stacking such pairs of levels in order to construct a multilayer policy structure. In fact, the approach defined below enables rule translations not only between two layers of abstraction of one policy, but also between policies of different domains of interest, providing the relations between them can be specified. The main requirements for creating the model have been stated as follows: the model must provide the way of defining multiple abstraction levels of policies, the representation of rules (at various levels of abstraction) should be preferably notation-agnostic, the model must enable defining the relations between rules, the model must provide a method for the vertical translation of rule sets from higher to lower levels of abstraction, the translation should not be a simple mapping, but it should take into account the translation context, what results in different translation effect for different contexts, the model should provide the way of representing the meta-knowledge utilized for rule translation. In order to achieve the above goals it can be necessary to provide to the system some additional data that derive from the specificity of the policy domain and the acquaintance with the system application. Thus supplementary assumptions were admitted: for rule representation the system can leverage on a set of rule templates, for vertical translation the system can utilize an external inter-level knowledge. The source of this data can be e.g. a domain expert. Such assumption effects in distinguishing specific users of the system domain experts and strategy creators. The role of the former is to provide the system with all the domain specific knowledge necessary to operate (governance of domain knowledge) and the role of the latter is using the system with provided domain knowledge for authoring the actual policies (development of system strategy), which are eventually represented at various abstraction level. Figure 3.2 demonstrates the relationship of the actors and depicts the target scope of the interest of the created solution. 43

56 Chapter 3. Concept and Model of Inter-level Rule Translation INTER-DOMAIN EXPERT KNOWLEDGE GOVERNANCE STRATEGY CREATOR STRATEGY DEVELOPMENT POLICY AT DIFFERENT ABSTRACTION LEVELS KNOWLEDGE REPRESENTATION Fig. 3.2: The scope of interest and types of user of the created solution The requirements and assumptions defined in this way imply a set of restrictions for the presented solution. The most impacting limitation is that the solution is applicable only to the space of policy definition, which has been specified by a domain expert and the rules out of this scope are not accepted. Such approach significantly increases the automation of vertical translation process, but on the other hand decreased the freedom of rule definition. However, the usage of rule templates is assumed to be promising approach for facilitating rule manageability at any level of abstraction. The concept of rule dependencies that utilizes templates enriched with an external expert knowledge is based on the following assumptions: in some systems there are types of productions (rules) that are more often used and thus the providing of skeletons for this rules is time-saving, the templates can benefit from grouping of various rule schemes or summarizing several similar rule types into one scheme, the alignment of rules to a set of templates enables dynamic and coherent interlevel policy updates (e.g. change of the higher-level rule implies the modification of lower-level productions), the providing of templates with constraint values significantly mitigates the design of the decision model that has to meet the rule context, the usage of templates in great extend simplifies policy comprehension and governance. Therefore, the chosen approach is useful especially when some production rules are recurrent (e.g. defining alarm types for threshold values of health parameters for monitored patients) or when users do not dispose of sophisticated technical capabilities (e.g. at the business level). In this context the work does not aim at creation of a perfect and general-purpose rule editor, but rather tries to provide a user with a tool for specifying policies in an efficient way and adopted to the level of understanding of a user. 44

57 Chapter 3. Concept and Model of Inter-level Rule Translation As the effect of the design of the concept model a tool for a vertical rule translation should be created. It is required that the tool provides: common and efficient access to templates for profiling policies, the listing of abstraction levels and their properties, the mechanism for instant translation of rules from higher level to lower levels, methods of representation of dependencies between created rules, the maintenance of the dependencies between created rules, the ergonomic user interface. The basic terms and the proposed method of modelling rules considering their inter-level relations, that would enable the creation of the abovementioned tool, are presented in the following sections. 3.3 Basic Terms In this section the terms used in the presented model are explained. It starts from the elements of the classically understood production rule and continues with a user-oriented rule template model. Finally, it concentrates on augmenting the model with the multiple abstraction level aspect Modelling of Rule Templates and Rule Instances In the system design, while describing production rules the author uses terms specified by the RFC 3198 rule definition (see Chapter 2): conditions and actions. The rule action is understood as a set of defined component actions a i that the system can execute. The rule condition is understood as a set of component conditions c i that need to be fulfilled. Rule actions and conditions are commonly called rule elements (Figure 3.3). RULE CONDITIONS c 1 c 2 c 3 ACTIONS a 1 a 2 Fig. 3.3: Elements of a rule - conditions and actions Rule elements can be represented as a set of defined parameters (c.f. Figure 3.4). A component action can be treated as a single parameter indicating the action to be taken. If needed, this single parameter can be accompanied by a number of other parameters defining the action arguments. The representation of a component condition is slightly more complex. A component condition equals to a check of a relation (e.g. comparison of a system parameter to a threshold value) that results in a logical true or false. Therefore, from the point of 45

58 Chapter 3. Concept and Model of Inter-level Rule Translation view of a user interface, the modelling of such phrase can be perceived as a combination of three entities: an identifier of a rule parameter, a relation symbol and a threshold value (e.g. weight, >, 55kg ). In a real production system, defined rules refer to the types of facts that the system works with (i.e. the facts that can be injected into its working memory). Therefore, the identifiers of rule parameters in the representation of a component condition representation have to refer to the fields of the used fact objects. That is an important linkage between parameters utilized in the rule representation and the fact types used by the rule engine using these rules. While modelling an element of a rule not all of its elements must be transformed into a parameter. For instance, it is possible that not all three elements of a component condition need to be specified, because two of them stay unchanged and only the third one (e.g. the threshold value) needs to be adjusted. Analogously, a component action can stay constant and only its arguments can be modified. RULE TEMPLATE CONDITIONS ACTIONS c 1 c 2 c 3 a 1 a 2 p 1 p 2 p 3 p 4 p 5 p 6 V 2 V 3 V 4 V 5 V 6 V 7 p 7 V 1 1 V 1 2 V V 2 2 V V 3 2 V V 4 2 V V 5 2 V V 6 2 V V 7 2 V 7 3 Fig. 3.4: Rule conditions and actions represented with help of defined parameters In Figure 3.4 en example of using parameters for modeling rule elements is shown. For each parameter p i a set of constraint values vj i is indicated. The component conditions c 1 and c 3 need only one parameter to be set (p 1 and p 4 respectively), which means that the other elements of these component conditions are defined (e.g. the condition c 1 is declared as fact.field1, is greater than, value of parameter p 1 ). The component conditions c 2 needs two parameters (e.g. it is declared as fact.field2, relation indicated by parameter p 2, value of parameter p 3 ). Analogously, the action a 1 is chosen as parameter p 5 from list v1 5, v5 2,.... For action a 2 not only the action is indicated by the parameter p 6, but also the action argument is set by the parameter p 7. Such approach based on expressing rules with the help of a set of parameters, results in significant simplification of constructing rule templates. A rule template shall be understood as a rule skeleton (unchangeable elements of the modelled rule) with parameter fields (changeable elements of the modelled rule) as shown in Figure 3.5. They are defined by a domain expert as the most needed or most commonly used types of production rules. Also a domain expert specifies template parameters and their constraint values. 46

59 Chapter 3. Concept and Model of Inter-level Rule Translation RULE_TEXT SKELETON OF THE RULE TEMPLATE RULE_TEXT RULE_TEXT PARAMETER_1 PARAMETER_2 PARAMETER FIELDS OF THE RULE TEMPLATE Fig. 3.5: Rule template structure Rule templates provide also logical relations between component conditions (e.g. disjunction, conjunction) that were omitted in the above deliberations. This logic is inscribed in the rule text skeleton and in this way any additional analysis of the rule conditions logic is not run. This is a very strong assumption as it frees rule templates from the semantic understanding of the rule formula. Based on a rule template a rule instance is created during a rule instantiation process by setting the values for all required template parameters. Therefore a rule instance can be perceived as a rule template with filled parameters fields. If possible, default values can be provided for some parameters to simplify the rule instance generation. For each rule template many rule instances may be created (Figure 3.6). The creation of various rule instances is understood as the strategy development process shown in Figure 3.2. Rule instances are created by a strategy creator during the strategy development phase. Rule template T P1 P2 P3 P4 P5 RULE INSTANTIATION setting values of template parameters Rule instance A 1 P1 = v 1 1 P2 = v 2 1 P3 = v 3 1 P4 = v 4 1 P5 = v 5 1 Rule instance A 2 P1 = v 1 2 P2 = v 2 2 P3 = v 3 2 P4 = v 4 2 P5 = v 5 2 Rule instance A 3 P1 = v 1 3 P2 = v 2 3 P3 = v 3 3 P4 = v 4 3 P5 = v 5 3 RULE FORMATTING stringifying a rule instance Rule formula A 1 Rule formula A 2 Rule formula A 3 RULE DEPLOYMENT to a destination rule engine Policy-driven component Fig. 3.6: The significance of a rule formatting function The presented solution on one hand limits the flexibility of creating rules, but on the other significantly simplifies the policy governance and also increases the usability of a user interface and thus improves a user experience quality. 47

60 Chapter 3. Concept and Model of Inter-level Rule Translation RULE FORMULA WHEN v 1 3 v 2 1 v 3 2 v 4 3 THEN v 5 1 v 6 0 v 7 4 Fig. 3.7: An output rule formula generated by a formatting function A rule instance is an entity that needs a mechanism to transform it into a rule formula, i.e. a stringified form consistent with the notation demanded by the destination system (Figure 3.7). This transformation is referred as a formatting function, specific for a rule instance and also for a source rule template. For a created rule instance the function compiles the rule skeleton of the rule template, the set values of the template parameters and adds the syntax necessary for writing down the string version of the created rule that can be deployed to a destination system (Figure 3.6) Modelling of Levels of Abstraction The levels of abstractions as defined in the RFC 3198 are understood as separate domains in which the rules can be defined according to the field of interest of the level. A constructed rule template is attributed to a specific level of abstraction and utilizes system parameters corresponding to this level. LEVEL 1 LEVEL 2 template t INTER-LEVEL METAKNOWLEDGE template t1 template t2 template t3 Fig. 3.8: Inter-level knowledge binds templates from different levels of abstraction The inter-level knowledge is a meta-knowledge that provides binding of rule templates belonging to different levels of abstraction (Figure 3.8). The structure and functionality of this entity is studied in further sections. A priori, the inter-level knowledge needs to administer information such as: notations of rules at different abstraction levels, dependencies between rules or elements of the rules, e.g. algebraic (defined parameter values) or behavioural (defined actions), context of the inter-level translation rules. 48

61 Chapter 3. Concept and Model of Inter-level Rule Translation An inter-domain expert has to recognize rule templates at higher level, rule templates at lower level and stipulate the relations between them. These templates declare skeletons of rules and abovementioned relations (the left part of Figure 3.9). While rule instances at the higher-level are created, the derivative rules or set of rules are instantiated at lower level (the right part of Figure 3.9). The key advantage of such solution is the creation of a coherent model of knowledge that should keep the uniformity of policies throughout all the levels of abstraction. The model to provide such mechanism will be presented in next sections. RULE TEMPLATES RULE INSTANCES template t INTER-LEVEL METAKNOWLEDGE Rule A Rule B Rule C template t 1 template t 2 template t 3 Rule A1 Rule A2 Rule A3 Rule B1 Rule B3 Rule C1 Rule C2 Fig. 3.9: Creation of rule instances at different abstraction levels The author does not assert that the meta-knowledge provided by an interdisciplinary expert can enable casting of the whole definition space of a policy at one abstraction level to the definition space of the policy at another abstraction level. In fact, each level of abstraction can also contain policies that are specific only for this level and are untranslatable to another level. Therefore some simplifications are assumed. The most important is the limitation of the scope of possible inter-level rule translation to the most common use cases, for which rule templates can be indicated. Moreover, the author assumes that in translation process only the following element(s) can be influenced: the existence of an output rule, the structure of an output rule, the condition(s) of an output rule (i.e. values of condition parameters), the actions of an output rule (i.e. action type or action argument). The chosen approach is similar to the policy refinement, but it is not the same. The goal is not to use simple rule mappings, but to introduce the usage of knowledge-based mechanisms to this process. In this way the translation is not a static rule mapping, but gains flexibility in creation the output rules based on the translation context (Figure 3.10). 49

62 LEVEL 2 LEVEL 1 Chapter 3. Concept and Model of Inter-level Rule Translation Template α Template α RULE MAPPING INTER-LEVEL KNOWLEDGE CONTEXT Template β1 Template β2 Template β3 Template β1 Template β2 Template β3 Fig. 3.10: A policy mapping vs. the proposed knowledge-based rule translation The vertical translation tool could not only take into account algebraic and behavioural dependencies (i.e. rewrite rules with new values), but also recognize the conditions under which new rule or new rule element or new rule element value are to be created (i.e. the translation context). It means that for different sets of values of parameters that express a policy at a higher level, different sets of lower level rules can be created. Moreover, the inter-level knowledge can be constructed in such way that many translation results are available. In the moment of the translation only one result is chosen and the decisive factor is the translation context. The goals of the presented solution neither can be reached with the use of Model Driven Engineering (MDE) methods (e.g. Eclipse ATL [93] or OMG Query/View/Transformation [94]) that base on converting the model of representation of data. In the case of presented inter-level policy translation the output is not static and may vary depending on the context of translation. In order to create the translation mechanism that fulfils the abovementioned assumptions the author proposes to take advantage of production rule systems themselves. The translation process will be driven by a rule engine that utilizes inter-level knowledge provided by an expert and responds to the translation context. The details shall be thoroughly studied in Chapter Formal Model of System Mechanisms This section heads towards explaining the formal models of the essential mechanism of the tool to be created. It starts with explaining the formal models of instantiation process elements. Then it discusses in details various aspects of the mechanism of the inter-level translation of rules Elements of Rule Instantiation Mechanism The purpose of this mechanism operation is supplying a system user with an easy way of creating various rules. The concepts of the elements that the mechanism bases on rules, rule templates and rule instances are discussed below. 50

63 Chapter 3. Concept and Model of Inter-level Rule Translation Rules As presented in the section a production rule r i from the global set of production rules R, can be characterized in the simplest way as a combination of component conditions and component actions. where: R r i = R a set of production rules, ( ) {c 1, c 2,..., c n }, {a 1, a 2,..., a m } = (C i, A i ) C i a set of component conditions of a rule r i, A i a set of component actions of a rule r i. It is important to remember that the vital element of a real production rule is its syntax, which is a real text string that expresses the component conditions and the component actions. This stringified phrase may require some specific, auxiliary code. The way of expressing a rule varies according to the purpose of its usage or the technology that is employed. Let the full body of the rule r i based on component conditions C i and component actions A i will be marked as r i = (C i, A i ) The above definitions introduce the aspect of the separation of a production rule entity from its representation. Such approach is crucial to the modelling rules with the use of templates presented in the following section. Rule Templates As explained in the section 3.3.1, for the sake of effective defining of templates and then instantiating rules, as well as the convenient construction of a user interface construction, the representation of rule elements has been simplified. As shown in Figure 3.5 a rule template is represented as an unalterable skeleton (that expresses the rule syntax and unchangeable parts of the rule elements) accompanied by a set of parameter fields (that express the values that can be adjusted while shaping the instantiated rules). Thus a rule template t i from the global set of templates T, can be characterized as: ) T t i = ({p i 1, p i 2,..., p i n}, S i = (P i, S i ) where: P i the set of adjustable parameters p i, S i the template skeleton. 51

64 Chapter 3. Concept and Model of Inter-level Rule Translation The transformation of rules from the condition-action representation into the skeletonparameters form is one of the crucial operations to be taken by a domain expert during the inter-domain knowledge creation. The domain expert has to prototype the templates, i.e. extract the static and the variable elements of the source production rule(s) and then code them as a skeleton and parameter fields respectively. prototype : (C i, A i ) (P i, S i ) If some constraint values can be indicated for a template parameter, this should be done at this stage as well. This means that the value of a parameter p i can be input freely during the rule instantiation phase or it can accept only one of the values from the prepared set V i. V i = {v i 0, v i 1, v i 2,..., v i n} : value(p i ) V i p i P In particular, a distinguished value v i 0 might be indicated within the set V i as the default value for the parameter p i. If the parameter field is not altered during the rule instantiation, the created rule accepts the default value of the parameter automatically. Rule Instances As stated in the previous section, a rule instance can be created based on a rule template by setting the values for all required parameters of this template. The vector of values that were used to instantiate a rule r j i based on a template t i will be referred as a rule value vector w j i (or simply a rule context). It consists of at most one value vn (from the set V n of all available values of p n ) for each template parameter p n. Also, let W i stands for the set of all possible value vectors (rule contexts) of the template t i. A single w j i can be defined as: W i w j i = {v1, v 2,..., v m } : v n V n Hence, the function instantiate that creates rule r j i based on a template t i with the rule context w j i is defined as follows: r j i = instantiate (t i, w j i ) or generally: instantiate : T W R where R is a set of derivative rule instances and W stands for the set of all possible rule contexts: n W = W i i=1 52

65 Chapter 3. Concept and Model of Inter-level Rule Translation Furthermore, there is a need that a text representation of each instantiated rule can be available as an ultimate form to be delivered to the target production rule engine. Such transformation, referred as a formatting function formula, simply combines the skeleton of the rule template with the appropriate rule context vector. Therefore the text of a rule r j i can be defined as follows: r j i = formula(rj i ) r j i = formula ( instantiate(t i, w j i ) ) The goal of the process described above is to introduce a mechanism of generating the proper body of a rule r j i (understood as a set of component conditions C j and component actions A j ) with the use of provided template t i (understood as a combination of a template skeleton S i and a set of parameters P i ). ( ( ) ) r j i = (C j, A j ) formula instantiate (P i, S i ), w j i The above formula determines the crux of the mechanism of generating production rule bodies identical to the notation based on the set of component conditions and actions Elements of Inter-Level Translation Mechanism The previous section focuses on the instantiation of a production rule based on a rule template without taking into account the abstraction level of the rule or, in other words, as if it was done within one abstraction level. However, having acknowledged the existence of multiple levels of abstraction, the existence of the mechanism of instantiation at each level has to be accepted as well. Thus, when referring to a specific level α, the function instantiate presented in the previous section gains a new expanded form: instantiate : T α W α R α where R α, T α, W α define respectively the rules, the rule templates and the rule contexts at the level α. In this section the formalism of the translation of a set of instantiated rules of one level α (i.e. the set R α ) to a set of rules of another level β (i.e. the set R β ) is introduced. The author intends to present a new mechanism of inter-level rule translation. During the research, the author came to the conclusion that the solutions using simple rule mapping based on some conversion model (as shown below) seem unsatisfying. convertion model β α : T α T β mapping β α : R α R β The effect of the functions presented above is the change of the rule representation model, but not necessarily its abstraction level. Furthermore, the mapping is static and its outcome for one rule is always the same, as the process does not take into account the conditions of the translation (cf. Figure 3.10). 53

66 Chapter 3. Concept and Model of Inter-level Rule Translation On the contrary, in the presented mechanism the translation result may vary. It takes into account the context of translation that is the conditions prevailing during the moment of translation (the concept of translation context will be widely descripted in following separate subsection). Therefore, the translate function, that is looked for, differs from the abovementioned mapping function. Besides, it should not be considered as a series of mappings of a rule r α i to a rule r β i, but rather as casting of the set of rules Rα into the set of rules R β. What is important, such translation is not a function, but a multivalued function (or a multifunction), since one rule from level α may be represented by a number of rules at level β. The function translate will be finally defined in a following subsection. However, in order to express the general idea, let a corresponding function translate be tentatively defined as follows: β αtranslate Ctx : R α R β The above translation multifunction translate casts the rule set R α from abstraction level α into rule set R β from abstraction level β with the translation context Ctx. The proposed realization of the translate function, referred as the knowledge-based translation, bases on an inter-level meta-knowledge (i.e. the knowledge about the interrelations between rules located at different abstraction levels). It is taken for granted that this meta-knowledge is provided to the system by an inter-domain expert. The scope of the meta-knowledge that needs to be provided is discussed in this section, while its model will be proposed in the following subsection. Multiple Levels of Abstraction The existence of multiple rule abstraction levels can be easily modelled by presenting a set of translating functions. For instance, four levels - α, β, γ, δ - demand the definition of tree translating functions: 1. β αtranslate Ctx α : Rα R β 2. γ β translate Ctx β : R β R γ 3. δ γtranslate Ctx γ : Rγ R δ The limitation of such approach is that only linear order of dependencies between abstraction levels (i.e. α β, β γ, but not α γ) is accepted. The solution may be extended to serve such interrelations (e.g. by defining additional functions or fake rule objects), however, for the clarity of the model they are skipped. Similarly, the translating function from lower to higher level (i.e. β α) are not taken into account, because only higher to lower level translations lie within the scope of this work. Scope of the translate Function As declared before, a rule r j i is an instantiation of a template t i with a values vector w j i. The instantioation function is assumed to be one-to-one correspondence, thus r j i may 54

67 Chapter 3. Concept and Model of Inter-level Rule Translation be considered as a pair (t i, w j i ). Based on this assumption, the simplified multifunction translate tentatively defined before is finally rephrased into its extended form the translate multifunction, shown below: β αtranslate Ctx α : (T α W α) n (T β W β) m The multifunction translate maps an n-element set of pairs (t α i, wj i α ) (that represent instantiated rules of level α) into an m-element set of pairs (t β k, wl kβ ) (that represent instantiated rules of level β). Such approach implies that the meta-knowledge has to identify two aspects of the rule interrelations (cf. Figure 3.11). Firstly, it has to indicate the lower level templates that have to be used for instantiation of the output rules. Secondly, it has to define the transformation of the value vectors. LEVEL α r α 1 j translate LEVEL β r β 1 r β 2 t α 1 w α 1 translate template translate values t β 1 w β 1, t β 2 w β 2 TRANSLATION CONTEXT Fig. 3.11: The aspects of inter-level translation function The aspects consider not only quality issues (i.e. which lower level rules to create? which parameters to modify?), but also quantity issues of the translation (i.e. how many lower level rules to create?). However, the decisive factor that has an effect on the conditions under which the rule translation process was led, is the translation context. As mentioned before, without considering it the presented translation mechanism would have no difference from a simple mapping. The elements of the translation context will be discussed next. Translation Context The notion of the context is very general and extensive. Therefore, the main question here is to specify what should be considered as the translation context. The author distinguishes three specific groups of the factors that can influence the translation of a set of rules. They are presented below. It is worth reminding that the differences in translation may refer to both the quality and the quantity of translation products. 1. Intra-rule factors, i.e. different vector values used with the same template The rules of level α based on the same template (i.e. r α 1 = (tα 1, wα 1 ) and rα 2 = 55

68 Chapter 3. Concept and Model of Inter-level Rule Translation (t α 2, wα 2 ) ) in a simple mapping would be translated into rules based on the same template of the lower level, but using various values vectors. } β αtranslate Ctx : {(t α 1, w1 α )} {(t β 1, wβ 1 ) } β αtranslate Ctx : {(t α 1, w2 α )} {(t β 1, wβ 2 ) However, using some specific parameter values during the instantiation of a rule based on the same template t α 1 can cause a translation into an instantiation of a different template of level beta (i.e. not t β 1 as above, but a tβ 2 as shown below) or even creation of a different number of output rules. } β αtranslate Ctx : {(t α 1, w3 α )} {(t β 2, wβ 3 ) 2. Inter-rule factors, i.e. different sets of input rules A rule instance r1 α may be translated in different manners depending on the existence (or non-existence) of another rule instances at its level (i.e. r2 α or rα 3 ). β αtranslate Ctx : {r1 α, r2 α } β αtranslate Ctx : {r1 α, r3 α } { } r β 1, rβ 2 { r β 1, rβ 3, rβ 4 3. External factors, i.e. different translation conditions The same rule r1 α may bring dissimilar translation results in different translation conditions (i.e. the current environment prevailing at the initial or target level, the moment of translation etc). β αtranslate Ctx1 : {r1 α } β αtranslate Ctx2 : {r1 α } { } r β 1 { r β 1, rβ 2 The possibility of the independent specification of the translation context considerably clarifies the presented rule governance model by adding the benefits of the separation aspect. The definitions of rule templates are detached from the factors influencing the translation, while in case of simple mapping the templates would need to refer to those factors and thus stay much complicated and require rearticulating when the translation mapping changes. Another significant question is that the translation context may refer not only to the initial level of the translation, but it can use the knowledge about the destination level as well. In fact, the translation context could be treated holistically as a sum of the contexts coming from all levels - Ctx α, Ctx β, Ctx γ etc. That would cause a considerable advantage - the process of rules translation from level α to level β could be conscious of the conditions prevailing at level β or even γ. On the other hand, such approach would contradict the idea of independence and separation of abstraction levels. Finally, one more extremely important question has to be raised. That is what happens when the context of the translation changes. Should all the rules be retranslated? Or should various versions of rules be kept simultaneously? That is a tough issue and the answer to the questions in great extend depends on the usage of the system. On the other hand, the study of the version control for the translation contexts stays aside of the scope of this work. Therefore, for the sake of this work, the author assumes the translation context remains unchanged. } } 56

69 LEVEL β TEMPLATE MAPPING VALUE MAPPING LEVEL α Chapter 3. Concept and Model of Inter-level Rule Translation Concept Model Summary The Figure 3.12 puts together all the elements and concisely summarizes the functionality of the proposed model of rules instantiation and translation that were presented in the above sections in more detail. RULE TEMPLATE + VARIABLE VALUES r α i j t α i w α i j INTER-LEVEL METAKNOWLEDGE TRANSLATION CONTEXT CONTEXT α CONTEXT β t β i w β i j r β i j t β k w β k l r β k l Fig. 3.12: The whole mechanism summary scheme The most important concepts that need to be underlined are: representation of rules as (template, value vector) pairs, rule translation based on the inter-level knowledge, considering the current context in the translation process, separated template and value mappings. The flow of the arrows clearly demonstrates the expected course of the translation process and is crucial to the further design of the mechanism. 3.5 Chapter Summary This chapter introduced a model of managing the representation of policies (i.e. rule sets) at various abstraction levels. The key concept is based on creating (on the customer s demand) rules of the highest level of abstraction and dispersing them throughout the whole structure of related levels of abstraction. The abovementioned functionality, i.e. vertical translation of rules, is based on two mechanisms that reflect the phases of the whole process the rule instantiation and the knowledge-based translation 57

70 Chapter 3. Concept and Model of Inter-level Rule Translation The rule instantiation mechanism facilitates the creation of new rules based on the prepared set of templates. In turn, the knowledge-based translation mechanism is constructed in such way that it not only takes advantage of an inter-level meta-knowledge (i.e. interrelationships between rules), but also refers to the context of the translation. Two aspects needs to be identified in the specification of the meta-knowledge the mapping of templates and the conversion of values. The created model constitutes the base for the mechanism design and then the tool implementation. The most important issue is to identify a solution that can carry the translation while fulfilling the guidelines defined in this chapter. Moreover, the means for notation agnostic representation of rules and templates as well as the translation meta-knowledge have to be determined. The chosen solutions for carrying the whole knowledge-based vertical rule translation that is based on the presented model are described in the following chapter. 58

71 Chapter 4 Mechanism of Knowledge-based Translation This chapter introduces the key concept of the rule-based vertical translation. It demonstrates the crucial aspects of the proposed solution that realize the guidelines of the model presented in the previous section. Finally the advantages of the new approach are presented and contrasted with the standard rule mapping method. In the previous chapter the concept of the knowledge-based inter-level translation was defined. The basic ideas such as rule template, rule instance, rule context, translation context etc. were formalized. The section puts together all the elements, concisely summarizes the functionality and emphasizes the essential ideas of the proposed model. The following chapter gives the answer for such defined guidelines by offering efficient mechanisms to perform rule instantiation and translation. The chapter focuses on three key aspects: the representation of rule templates, the solution of the translation engine and the notation of the inter-level meta-knowledge. Firstly in section 4.1 the chosen notation-agnostic way of representing rules and rule templates is explained. The overall concept of introducing a production rule system into translation tasks is described in section and then clarified in more details in section The proposition of notation of the meta-knowledge used by the translating engine is shown in section 4.3. Finally the analysis of potential use of the new mechanism is demonstrated with the help of a rule change scenario in 4.4 in order to distinguish the advantages of this innovatory solution. 4.1 Representation of Rule Templates The first issue is the representation of rule templates that would be the base for the flexible creation of rule instances at different levels of abstraction. It should provide a way of denoting not only the structure of the represented rules, but also possible relations with another rules. 59

72 Chapter 4. Mechanism of Knowledge-based Translation The requirements for the method of representation of the rule templates and instantiated rules were stated as follows. The method should: stay independent from the rule notation, enable registering both static parts of rules and changeable parameters fields, define relations between rules and rule elements, concern the issues of graphical representation of rules. The first point results from the fact that the notation needs to serve many levels of abstraction which can potentially make use of many notation patterns (e.g. a natural language, a simplified language as STE, Complex Event Processor (CEP) commands, DSL markup, notations specific to production rule systems etc.). That is a strong assumption. However, at this stage of research over the vertical rule translation, the author decided not to engage the semantic analysis of politics being translated. Such course of action would make inevitable the creation of an universal model of rule notation for both various existing rule languages and natural language as well. This kind of studies lay within the scope of not only the interoperability of rules and the horizontal rule translation, but also the natural language processing. The proposed tool for the inter-level rule translation does not analyse the meaning of rules, but only transforms them. The semantic analysis and rule interoperability techniques may be used in the future development of the system. The second point corresponds directly to the ideas given in the previous sections, specifically in the section It reflects the concept of distinguishing in a rule its skeleton (unchangeable elements) and a set of configurable parameter fields (cf. Figure 3.5). The third point is an optional element. It enables denoting simple bindings between various rule parts in order to ensure using the same values, where they should be the same. In this way an additional mechanism for maintaining the coherence of a rule set is provided. The last point refers to the need of effective rendering of templates for the sake of a system user. When the structure is well planed, the visualization process will be more efficient. The proposed rules and rule templates representation method refers to the model shown in section It bases on tokens that reflect various chunks of a rule and also additional information about their interrelationships, mathematical dependencies, value constraints etc. The template is represented as a list of such tokens. Some of them denote the static parts of a rule, some describe the changeable parameter values, others keep the track of bindings between various rule chunks. Furthermore, the list of tokens could be augmented according to the needs in the future. The proposed solution entirely meets the requirements listed at the head of the section. When a patient takes: PARACETAMOL 500 TEXT CHOICE more than TEXT 5 VAR times per day then TEXT Fig. 4.1: A rule as a list of tokens The concept of building a rule template is briefly illustrated in Figure 4.1. The tokens described as TEXT reflect the static parts of a rule (skeleton), while the others are 60

73 Chapter 4. Mechanism of Knowledge-based Translation used for describing the parameters values and interrelationships. As the result of the research, a set of the token types was distinguished. They are shown in Table 4.1. TOKEN TYPE TEXT VALUE CHOICE VARIABLE (option) EXPRESSION (option) FEATURES The basic part of a rule body that carries a string unrecognized by the system (e.g. when a patient takes... ) without additional meta-data. A representation of a parameter, which value can be set during a rule instantiation. It can be used for example, for calculating value of another field or as a decisive factor during creation of derivative rules. A list of constraint values that can be used during a rule instantiation. The functionality of this token is similar to a VALUE token, but limits the possible choice of parameters values to a fixed set (e.g.: a list of parameters to be monitored, a list of medicines etc.). An element that refers to another token, from which it derives its value. A VARIABLE token may refer to VALUE, CHOICE or EXPRESSION tokens. A set of tokens that represents an expression that can be evaluated and its result can be transferred to and used by another token (VARIABLE). Table 4.1: The distinguished token types VALUE and CHOICE tokens provide points for comfortable setting the parameter values for the template parameters. They are meant to reflect user interface widgets. VARIABLE or EXPRESSION tokens are optional and they show an example of augmenting the set of the tokens. In an extended set of rules, whether within the same or different levels of abstractions, a number of dependencies can be observed. The inter-level dependencies are represented within the inter-level knowledge. However, to represent intra-level interrelations the mentioned additional tokens can be used. VARIABLE or EXPRESSION token types are optional and can help with maintaining the coherence of an extensive set of rule instances by keeping the conformity of a value when it is used several times or depends on another value. An example of such situation presented in Figure 4.2 takes advantage of the token types introduced above. The relationships between VARIABLE tokens (VAR) and VALUE tokens (VAL) or EX- PRESSION tokens were symbolically marked to emphasize the potential problems with maintaining the coherence of a rule set. 61

74 Chapter 4. Mechanism of Knowledge-based Translation TEXT VAL TEXT CHOICE TEXT TEXT VAR TEXT VAR TEXT TEXT VAL TEXT TEXT VAR TEXT VAL TEXT EXPRESSION TEXT VAR TEXT VAR TEXT Fig. 4.2: An example of dependencies in a set of rules The token representation fulfills all the requirements specified at the begining of this section. Firstly, it allows for processing a rule independently from its notation. Secondly, it makes storing rules and rule templates easy, while exposing their modifiable elements. Thirdly, the representation is prone to a simple rule visualization execution. Finally, as presented below, the method is open for easy future extention. In result, such solution significantly facilitates the system development, especially during implementation phase. 4.2 Realisation of Rule Translation Mechanism In the previous section a concept of rule templates definition based on a set of specialized tokens was presented. An inter-disciplinary expert should use them in order to supply the system with the models of rules. Based on those templates a strategy creator could instantiate the final rules of the system. Having them specified, a mechanism for performing the final vertical translation is still needed. This section discusses the use of a production rule system in the process of vertical translation of the rule instances Translation Engine Overview As it was explained before, in different conditions templates may be fulfilled with different values of parameters and different sets of rule instances may be created. The set of templates provided by an expert may be easily changed or augmented. The same advantage should be offered by the translation mechanism the principles of the translation (i.e. the knowledge base) should not be encoded into the body of the system, but rather easily exchangeable during the system runtime. Thus, they would form, de facto, the inter-level meta-knowledge about transforming rules of upper level into derivative rules of lower level. The solution that heaves in sight in a natural way here are production rule systems themselves. They offer features, such as easy exchange of a knowledge base, but also dynamic actualization of a working memory state and stateful sessions that would be key issues in case of translations concerning the translation context. For instance, such in-built mechanisms help serving the inter-rule context aspects, i.e. the situation when the existence of a rule triggers some translation actions (cf. section 3.4.2). 62

75 RULE ENGINE METARULES Chapter 4. Mechanism of Knowledge-based Translation 1 RULE TEMPLATES t 1 t 2 t 3 STRATEGY CREATOR 4 RULE INSTANCES A B 5 EXPERT METAKNOWLEDGE 3 2 t 1 t 1 t 2 t 3 LOWER LEVEL SYSTEMS A1 A2 B1 B2 6 Fig. 4.3: The vertical translation process with the use of a production rule system This work introduces the use of production rules systems as translation engines. Such solution fits the concept model and meets all the requirements specified in chapter 3. The overview of proposed solution is presented in this section and technical details are explained in the next section. General translation process flow that is based on a rule engine is shown in Figure 4.3. The numbered actions are summarized in Table 4.2. PREPARATION PHASE (by a domain expert) RUNTIME PHASE (by a strategy creator) 1. An inter-disciplinary expert edits rule templates and defines the rule interrelationships. They are declared as lists of tokens. 2. The inter-disciplinary expert specifies the principles of creating the rules of lower level based on the rules of higher level. Such meta-knowledge is declared as a set of meta-rules. 3. The meta-rules are inserted into the rule engine that performs the vertical translation. 1. A strategy creator formulates instances of higher level rules based on the set of the provided templates (point 1) by specifying values of parameter fields (VALUE and CHOICE tokens). 2. The objects representing the formulated rule instances are inserted into the working memory of the translating rule engine as facts. 3. Based on the declared meta-rules (point 2) the facts representing rules of the lower level are inferred. Table 4.2: The phases of vertical translation of rules As declared in section 3.2 the process requires two actors: an inter-disciplinary expert and a creator of system strategy (c.f. Figure 3.2). The strategy creator authors the 63

76 Chapter 4. Mechanism of Knowledge-based Translation actual policy (rule sets) using the system that is supported by the knowledge provided by an expert. The expert provides: templates of rules, an inter-level knowledge base (i.e. the meta-rules used by the translating rule engine). A creator of system strategy uses the provided templates to instantiate rules for a system during its runtime. The objects representing the instantiated rules are inserted into the working memory of the translating rule engine as facts. The engine uses the provided inter-level meta-knowledge as its knowledge base in order to create the objects representing the output rules, i.e. translated rules belonging to a lower level of abstraction. In fact, the translating rule engine uses the meta-rules as its production rules. The process can be influenced by various context parameters, if it was foreseen by an expert while defining the meta-knowledge. Moreover, the existence or appearance of some fact (i.e. an object representing a rule that is translated or being translated) can cause next inferences within the engine, enriching in this way the possibilities of application of the mechanism Translation Engine Anatomy In this section the translation engine operation is explained in more details. Before the particular aspects of the engine will be shown, Figure 4.4 summarises the elements that have been already discussed. LEVEL 1 SYSTEM RUNTIME F13 F11 F14 F12 F15 STRATEGY CREATOR R1 1 R1 2 R1 3 FACTS 1 RULES 1 DOMAIN EXPERT T1 1 T1 2 TEMPLATES 1 TRANSLATION ENGINE TRANSLATION CONTEXT MR 1 MR 2 MR 3 MR 4 METARULES LEVEL 2 F23 F21 F24 F22 F25 R2 1 R2 2 R2 3 FACTS 2 RULES 2 T2 1 T2 2 TEMPLATES 2 Fig. 4.4: The translation anatomy - the basic elements The distinction of authority ranges of a policy creator and a domain expert is clear. The elements that need to be provided by a domain expert: the templates and the meta-knowledge (a set of meta-rules) are marked in dark blue. Rules R1 i at level 1 are the translation input and R2 i at level 2 the expected translation output. According to the concept model, all of them are instances of appropriate 64

77 Chapter 4. Mechanism of Knowledge-based Translation templates T 1 i or T 2 i. The translation context is symbolized as well in order to enclose all the elements taking part in the translation process. Moreover, in order to emphesize the distinction of external rule-based mechanisms (e.g. rule engines of some dedicated rule-based components), which may take adventage of the rules instantiated or translated by the discussed mechanism, F ACT S1 and F ACT S2 were also shown in the figure. These facts are runtime facts of those external systems. They do not participate in any way in the operation of the proposed mechanism and, thus, are not in the focus of this work. The processing of the rules is clarified in Figure 4.5. After the level 1 rules have been instantiated, they are inserted into the working memory of the translating engine as facts (called meta-facts in order to distinguish them from the facts mentioned above). The translation context provides additional set of context facts which express the current context of the translation. LEVEL 1 F13 F11 F14 F12 F15 R1 1 R1 2 R1 3 FACTS 1 RULES 1 T1 1 T1 2 TEMPLATES 1 WORKING MEMORY PRODUCTION MEMORY TRANSLATION ENGINE MF11 MF12 MF13 TRANSLATION CONTEXT CF1 CF2 CF3 METAFACTS 1 CONTEXT FACTS MF21 MF22 MF23 MR 1 MR 3 MR 2 MR 4 METARULES INFERENCE (TRANSLATION) METAFACTS 2 LEVEL 2 F23 F21 F24 F22 F25 R2 1 R2 2 R2 3 FACTS 2 RULES 2 T2 1 T2 2 TEMPLATES 2 Fig. 4.5: The translation process flow (upper to lower level) Based on these two groups of facts the inference is carried by the translating rule engine, resulting in generation of the translation output i.e. the meta-facts that represent the level 2 facts. The existence of all the entities in the working memory of the translating engine makes possible further fact interaction. Finally, the level 2 facts are extracted from appropriate meta-facts. What is worth mentioning is that in this example only forward chaining type of inference is considered, which results in the higher to lower level translation. However, it leaves the question whether the usage of backward chaining inference would allow the opposite direction translation. 65

78 Chapter 4. Mechanism of Knowledge-based Translation LEVEL 1 F13 F11 F14 F12 F15 fact types 1 R1 1 R1 2 R1 3 FACTS 1 RULES 1 T 1 T 2 TEMPLATES 1 MF11 MF12 MF13 TRANSLATION ENGINE TRANSLATION CONTEXT CF1 CF2 CF3 METAFACTS 1 CONTEXT FACTS context fact types MF21 MF22 MF23 metafact types 1 metafact types 2 MR 1 MR 2 MR 3 MR 4 METARULES METAFACTS 2 LEVEL 2 F23 F21 F24 F22 F25 fact types 2 R2 1 R2 2 R2 3 FACTS 2 RULES 2 T2 1 T2 2 TEMPLATES 2 Fig. 4.6: The translation mechanism fact types awareness To conclude, the description of the translation engine it should be mentioned that the aspect of fact type awareness is fundamental for the correct design of meta-rules. This fact-rule relations are briefly presented in Figure 4.6. In addition the template-rule and rule-metafact dependencies are shown as well. 4.3 Representation of Inter-level Meta-knowledge According to the solution presented above, the translation process is realized by a rule engine fed with the inter-level meta-knowledge that consists of a set of meta-rules. In this section the model of the meta-rules will be shown. As an ordinary production rule a meta-rule should reflect both the conditions and the actions to be taken during the creation of the objects that represent the derivative rules. According to what was said before, while describing the conditions a meta-rule has to base on both the interrelationships of rules and the elements of the translation context. In the action part, two main operations should be reflected - the mapping of templates and the transformation of values, as it was presented in the section The above requirements are taken into account in the summary of a simple meta-rule presented below in Listing 4.1. The WHEN part compares the template type, the values of the rule context and the translation context, whereas the THEN part runs the values conversion and the instantiation of rules based on adequate templates. The final notation of a meta-rule depends essentially on the rule engine technology chosen in the system implementation phase. 66

79 Chapter 4. Mechanism of Knowledge-based Translation WHEN in translation context Ctx at level α exists a rule X 1 of type T 1 with rule context W 1 = (x 1, x 2, x 3,...) (...) {check more conditions} THEN at level β calculate the rule context W 2 = (y 1, y 2, y 3,...) based on W 1 and context Ctx create a rule Y 2 of type T 2 with rule context W 2 (...) {calculate more vector values} {create more rules} Listing 4.1: A general meaning of a metarule The condition of the meta-rule tests the existence of a fact representing a rule X 1 of type T 1 at level α. Under defined circumstances, that is set values of parameters of rule context W 1 (i.e. vector of values of modifiable rule parameters) and set values of parameters of the translation context Ctx, another fact (i.e. rule object Y 2 ) is created. The fact represents a rule of type T 2 at level β. The rule context W 2 of the newly created object is calculated or modified based on the accessible data the values of the translation context Ctx or the rule context W 1 of the source rule object W 1. It may be also defined that more than one derivative object is created (e.g. Y 3, Y 4 etc). The condition chunk of a meta-rule may be more complicated as far as the syntax of the meta-rule language allows. It may take advantage of more parameters that are accessible. In particular, a meta-rule may be constructed in such way that it checks the coexistence of more than one fact (i.e. a rule object) in the condition part. Moreover, for the same initial rule at level α (i.e. the fact representing the rule - X 1 ) under different circumstances, level β rule objects of different types may be created or different values of parameters may be used. Such approach enables a highly flexible way of defining the rule transformation (i.e. vertical translations) and meets all the requirements that were introduced in the previous sections. 67

80 Chapter 4. Mechanism of Knowledge-based Translation 4.4 Rule Change Scenario The following scenario presents the case of a rule change, exposing some specific features of the knowledge-based vertical translation mechanism. The change of a rule is performed in two steps: a deletion of an old rule and then an insertion of the newly updated rule. The following table shows the actions seen from both perspectives the vertical translation mechanisms and the rule engine tasks. The latter is presented in order to show not only how the knowledge-based translation process is executed, but also to illustrate how much the features of rule engines enrich the process of the translation in the manner that is not available in the case of a simple rule mapping. TRANSLATION RULE ENGINE THE PROCESS OF CREATING THE RULES R 1 AND R 2 BEGINS T INSTANTIATION LEVEL 1 VERTICAL TRANSLATION LEVEL 2 T INSTANTIATION LEVEL 1 VERTICAL TRANSLATION LEVEL 2 R 1 R 2 R 1 R 2 1. Instantiation of rules R 1 and R 2 At level 1 based on a template Two objects (facts) repre- T two rules R 1, R 2 senting rules R 1 and R 2 are instantiated by providing appropriate rule contexts. are created and inserted into Working Memory. (*) Checks for fact conflicts at level 1 can be run. 2. Knowledge-based translation of the rules Knowledge-based vertical Based on the facts representing rules R 1 and R 2 translation mechanism translates the rules (considering the translation create the derivative ob- the translation meta-rules context). Thus a set of jects (facts) representing rules R ij is created at the rules R ij. level 2. (*) Checks for fact conflicts at level 2 can be run. R11 R12 R13 R21 R22 68

81 Chapter 4. Mechanism of Knowledge-based Translation THE PROCESS OF CHANGING THE RULE R 1 BEGINS T INSTANTIATION LEVEL 1 VERTICAL TRANSLATION LEVEL 2 T INSTANTIATION LEVEL 1 VERTICAL TRANSLATION LEVEL 2 T INSTANTIATION LEVEL 1 VERTICAL TRANSLATION LEVEL 2 R 2 R21 R22 R 1 R 2 R 12 R 13 R21 R22 R 1 R 2 R 12 R 13 R21 R22 R Deletion of the rule R 1 The current version of the rule R 1 and all of its derivative rules are deleted. The objects (facts) representing the rule R1 and its dependant rules are removed from the Working Memory. (*) Changes resulting from inter-rule dependencies of the missing facts (at both levels) may follow. 4. Re-creation of the updated rule R 1 Based on a template T a An object (fact) that represents the rule R 1 is new rule R 1 is instantiated by providing an updated created and inserted into rule context. The rule R 1 is translated (c.f. point 2) Working Memory and so are the derivative objects into rules R ij. (facts) representing the As shown, the effect of the rules R ij. translation differs from In this case, there are the one shown at point 2, which stems from various translation intra-rule contexts of rules R 1 and R 1. meta-rules that can cause different inference for facts representing rule R 1, but having different attribute values. (*) Checks for fact conflicts can be run. 5. An additional inference Based on the inter-level knowledge a new derivative rule is created. This results from some inter-rule context of rules R 1 and R 2. There are meta-rules that can cause different inference for facts representing rule R 2 in the presence of different accompanying facts (R 1 vs. R 1 ). An additional fact that represents the rule R 23 is created. 69

82 Chapter 4. Mechanism of Knowledge-based Translation T INSTANTIATION LEVEL 1 VERTICAL TRANSLATION LEVEL 2 R 1 R 2 6. A conflict of the rules Some received rules are excluding and thus one of them has to be removed. As an effect of a fact conflicts check, one of the conflicting facts has to be removed. (*) Such conflict checks may be run at points 2-4 in an analogous manner. R 12 R 13 R21 R22 R 23 T INSTANTIATION LEVEL 1 VERTICAL TRANSLATION R 1 R 2 7. The final set of the translated rules The final set of the derivative rules is available. It differs significantly from the set shown at point 2. LEVEL 2 R 12 R21 R22 R 23 THE PROCESS OF CHANGING THE RULE R 1 ENDS Table 4.3: The change rule scenario phases As it can be noticed specific functionality of the rule engines add some new quality into the translation process. The features that were normally utilized for keeping the coherence of the fact set, can now boost the authoring of the rule set of the policy. At the first place, the inter-rule relations can be easily taken into account, emphasizing the context aspect of the translation. Secondly, checks for the conflicts of translated rules are possible, thus the coherence of the created policy at each level is increased. As the effect of this interactions, the received output may vary from the static mapping outcome. 4.5 Chapter Summary This chapter introduced mechanisms that fulfil the requirements and follow the model presented in the previous chapter. The innovative aspect of the proposed approach is the employment of a production rule system as the vertical translation engine. The translated rules are provided to the translation engine as facts and their interrelations as the knowledge of the mechanism, i.e. translating meta-rules, which need to provide both the mapping of templates and the recalculation of values. A token-based approach is chosen as the method of representing rule templates and instantiated rules. They are formed as chains of specialized tokens of different kinds, what makes possible a future extension of the mechanism functionality by adding new token types. The next chapter brings the key points of the implementation of the tool that was created according to the abovementioned solutions. 70

83 Chapter 5 Implementation Details This chapter describes a tool that implements the knowledge-based translation mechanism introduced in the previous chapter. The tool is to enable instantiation of rules based on given templates and then translation of the rules into a number of lower levels of abstraction in view of translation context. The prototype verifies the extent of the augmentation of knowledge management when multiple policy abstraction levels are present. In this chapter the guidelines of the implementation of the vertical rule translation tool are imparted. It needs to be mentioned at the very beginning, that the main purpose of the prototype is not to reach the highest efficiency, but rather to emphasize the user experience aspects and to explore new ways of knowledge governance, which not only broaden the possibilities of knowledge base authoring and supervision, but also enable the automation of the knowledge utilization. The tool architecture is explained in section 5.1 and then three fundamental components of the system are described: Rule Manager (section 5.1.1), Translation Manager (section 5.1.2) and User Interface (section 5.1.3). Finally the technological solutions chosen to implement the system are presented in section Tool Architecture The tool was implemented in accordance with a very clear architecture model that follows Model-View-Controller (MVC) scheme. It is designed as a Rich Internet Application (RIA) in order to make it: easy to reach, attractive for end users, flexible in design. 71

84 Chapter 5. Implementation Details Front-end GUI is available to the main type of users (i.e. strategy creators) through a web browser. There is one important consequence of such approach the translations need to be carried online, i.e. net connection to the back-end module is necessary. Offline translations that could be later synchronized with the main module are not available. Features relating to the efficiency, scalability or changeability of meta-knowledge base, result mostly from the features of rule production system that was chosen for the implementation. This technical aspects are not the focus of this work. Rule database Rule engine Rule export Strategy creator Rich Interface GUI Handler Rule Manager Translation Manager Rule templates Metaknowledge Domain expert Translation Engine Fig. 5.1: Functional elements of the tool Main functional elements of the tool are presented in Figure 5.1. Their main characteristics are described below: Rule Manager and Templates Repository modules that manage the set of rule templates and controls instantiation process, Translation Manager and Meta-Knowledge Repository modules that govern Translation Engine operations based on meta-knowledge provided to the system, Translation Engine rule engine providing vertical knowledge-based rule translation, Rich Interface and GUI Handler modules that make the tool functionality accessible to strategy creator and manages front-end to back-end communication, Export Module and Rule Repositories module that transfers the output of translation process to target rule engines or rule databases. The main interaction between the modules that takes place during process of instantiation of a new rule and its vertical translation is shown in Figure 5.2. RuleManager instantiates a rule with help of a rule template after a user provides a rule context (a vector of parameter values). Then the rule is passed to TranslationManager. 72

85 Chapter 5. Implementation Details UIHandler RuleManager TranslationManager TranslationEngine create rule() instantiate rule() translate rule() insert context() wrap rule() insert rule to translation() return translate output() update rules() extract rules() inform user() Fig. 5.2: Components interaction diagram Before passing the rule into TranslationEngine it is wrapped in order to make it a metafact. Then the meta-fact is transferred to TranslationEngine, or in other words it is inserted into the Working Memory of the translating rule engine, which maintains a stateful knowledge session. The translation process ran by TranslationEngine bases also on previously provided translation context. After the inference is done, the results are extracted and the output is transferred through RuleManager and UIHandler to UI Rule Manager The main function of Rule Manger component is governance of rule templates and instances, which covers a number of tasks: keeping abstraction level definitions, loading and maintaining rule templates, creating new rule instances, maintenance of rule instances repository, passing rule instances to translation manager, updating the rule repository according to the translation results. 73

86 Chapter 5. Implementation Details Rule Manager is implemented by class The essential classes provided by RuleManager component are: AbstractionLevel, RuleTemplate, RuleToken, RuleInstance, RuleContext. Rule Manager maintains a list of abstraction levels AbstractionLevel objects. At present they keep level identifiers and names, but further extension is feasible (e.g. adding data about notation, services relating to the level, target rule engines or databases, their access methods etc). The second important task of Rule Manager is governance of RuleTemplate objects. Except for basic template information (i.e. name, abstraction level etc) a RuleTemplate object contains two RuleElement objects condition and action. According to the rule model presented in chapter 4 those object represent a list of rule tokens of different kinds. For sake of prototyping four basic types were implemented: RuleToken for static parts of a rule, RuleTokenVariable for values that could be modified by a user, RuleTokenChoice for values to be chosen out of a constraint list and RuleTokenValue referring to values of another tokens. The object model of that classes is shown in Figure C.1 in Appendix C. Rule templates are stored in the form of XML codes. (De)serialization process is ran by dedicated classes TemplateDefinition and TemplateDefinitionLoader. An example of two templates is shown in listing A.1 in Appendix A. Each template code has a set of nodes describing general data (e.g. <label>, <level>, <salience>) and two nodes (<action> and <condition>) that specify their own lists of tokens: <text> for RuleTokens, <choice> for RuleTokenChoice, <variable> for RuleTokenVariable and <insert> for RuleTokenValue. The third fundamental task of Rule Manager is tracking created rule instances that are represented by RuleInstance objects. They are specified by pointing a RuleTemplate and a set of values for the template tokens (i.e. RuleContext object). Moreover, Rule- Instance objects keep track of the inter-level dependencies by maintaining parent and child instance references. Rule templates collect references to all their instances. Such organisation fully follows the model presented in chapter Translation Manager The main function of Translation Manager component is to control vertical translation processes. The majority of its tasks relate to the supervision of Translation Engine and also communication with other components. Translation Manager is implemented by class The operation of Translation Manager covers: maintenance of Translation Engine (i.e. translating rule engine) instance, injecting meta-knowledge into Production Memory of Translation Engine, injecting translation context into Working Memory of Translation Engine, wrapping rule instances received from RuleManager into meta-facts, transferring meta-facts to and from the Working Memory of Translation Engine, extraction rule instances from meta-facts and transferring them to RuleManager. 74

87 Chapter 5. Implementation Details Translation Engine component, as it was mentioned before, is a production rule engine instance. Thus it takes advantage of classes that provide Production Memory and Working Memory functionality of production rule system. It utilizes a dedicated opensource libraries, as described in section 5.2. Translation Engine prepares KnowledgeBase object loads meta-rules from files or from Guvnor manager (KnowledgeLoader), compiles it into KnowledgePackage. An example of a DRL meta-rules can be found in Appendix B (listing B.1). Then, based on the package, it starts StatefulKnowledgeSession, that eventually enables stateful forward chaining inference, which in this case serves the contextual translation. Translation Engine also makes available interfaces for inserting and retracting metafacts or clearing a session. It provides FactHandle references to the objects that have been inserted into Working Memory, i.e. MetaFacts (representing RuleInstances and TranslationContext). In this way, the translation results can be accessed User Interface The main function of the user interface module is to facilitate policy structure perception and rule manipulation. It provides a set of panels designed with careful consideration to ease basic operations on rule sets, such as rule instantiation, browsing, visualisation, with emphasis on exposure of rule abstraction levels. The tool s UI is a web interface that contacts the back-end Rule Manager in order to: obtain information about policy (i.e. rule templates list), policy description, abstraction levels list, obtain information about current contents of the authored knowledge base (i.e. instantiated rule set), fire essential rule operations (i.e. instantiation and translation) that were demanded by a user via rule manipulation panels. The UI has a component structure and it is designed according to MVC paradigm as shown in figure

88 Chapter 5. Implementation Details Graphical User Interface UI Controller UI View MXML-defined panels item renderers sort objects UI Model UIRuleManager LocalPolicyStructure RemoteRuleManager Fig. 5.3: User interface anatomy The UI controller is the main component that coordinates user actions and system operations. It superintends not only behaviours of rule manipulation (i.e. creation, deletion, update, browsing) and visualization panels, but also handles data requests (local and remote). It is represented by the main GUI class. The construction of the UI view takes advantege of many advanced features of the chosen Flex technology (as explained in more details in section 5.2). It consists of a set of panels that are constructed in the XML-based fashion using Flex MXML tags. The panels are compound of not only widely used widgets, but also take advantage of some smart mechanisms. For instance, item renderers allow diverse presentation of the same data set, depending of the current need. Sort objects define varied ordering of elements of a set. Thus, applying different item renderers or sort objects to the same data listing widgets results in creation of different UI control elements for the data. Moreover, the policy structure visualization uses non-standard graphical elements and techniques that the chosen technology makes available. The UI model based on two components UIRuleManager and RemoteRuleManager. The former is responsible of local data caching and the latter manages the back-end calls. Two types of local data can be distinguished. The first one is the general information about the processed policy, that is requested at the tool initialization phase (i.e. policy description, abstraction levels list, rule templates list). The second comprises cached current data chunks received from the back-end (i.e. list of rules at pointed abstraction level). RemoteRuleManager is a specialized component to process the back-end calls. It implements functions such as rule creation, deletion or update, but also queries for rule browsing or rule dependency visualization purposes. It coordinate all actions related to data (de)serialization and passing control to event handlers (i.e call fault). More details about front-end back-end integration can be found in section

89 Chapter 5. Implementation Details Fig. 5.4: The elements of main user interface A brief overview of the tool GUI is presented in figures 5.4 and 5.5. The first one shows the main interface. The panels providing information about policy, defined abstration levels and current translation context are dispalyed on the left side. The major part of the interface is taken up by panel for instantiating rules based on tamplates, which can be selected from the templates list that lies above. Fig. 5.5: The rule dependency visualization 77

90 Chapter 5. Implementation Details The visualization panel shows all created rule instances in the form of circular hierarchical graph. It locates rules of the same abstraction level at the same distance from the circle center - the higher the level, the closer to the center. All rule dependencies are also marked. In the basic example presented in figure 5.5 only simple tree dependencies are shown, but a real situation the rule dependency structure may appear much more complex. 5.2 Technological Aspects The tool is implemented as a Java servlet deployed in Apache Tomcat 7 container [141]. However a range of supplementary technologies were employed in order to create particular elements of the tool, including: Drools 5 Expert (version 5.5) [107], Apache Flex [138] (previously Adobe), Adobe Blaze Data Services framework [140]. Apache Tomcat 7 container Adobe Flex RIA Rule Translation Adobe BazeDS Java remoting Rule instantiation and translation module Drools 5 libraries Rules repository Metarules repository Templates repository Fig. 5.6: Integration of the employed technologies The positions of the used technologies is shown in Figure 5.6. The backgrounds of rule engine and UI technologies selection are explained in following sections Production Rule System The production rule system chosen to implement Translation Engine is Drools 5 Expert [107] one of the most popular Java-compliant open-source rule engines. It uses a simplified ASL/BSD/MIT-esque license (as opposed to the more restrictive GPL). It was selected not only due to its popularity, efficiency and usability features, but also because it constitutes a part of a broader scale business logic integration platform, what could make possible easy tool extension in the future. 78

91 Chapter 5. Implementation Details Since the heart of Rule Translation Module, i.e. Translation Engine, is implemented as Drools rule engine, expert s meta-knowledge is provided to the system in the form of DRL rules, i.e. in Drools notation. It can be managed separately with the use of Drools Guvnor [119] system. Drools platform, among others, takes advantage of Codehouse Xstream library [142]. The library was also used by the created tool to automate (de)serialization of Java objects (i.e. RuleTemplate objects used by Rule Instantiation Module) into the form in which they are stored by the tool (i.e. XML codes) Flexible User Interface Technology The prototype interface was implemented with the use of Apache Flex (previously Adobe Flex) technology. Its wide graphical features make possible creation not only basic web forms composed of standard widgets, but also make possible more sophisticated graphical and functional UI design, including generation of flexible visualisations of data. This enables a further research in the field of experimental user interfaces that introduce rules presentation at different abstraction layers by supporting visualisation of rule dependencies within and throughout abstraction levels. The technology was chosen out of a set of modern RIA solutions: Apache Flex [138] the longest player in the market with a stable position (it originates in 2002 from Macromedia and Adobe, in December 2012 becomes a top level Apache Software Foundation project), it makes available very flexible and unorthodox UI design solutions for all system platforms (including mobile), Microsoft Silverlight [143] technology that bases on strong background, offering capabilities similar to Adobe, however, it is available only for MS Windows and MacOS platforms, Asynchronous JavaScript and XML (AJAX) [145] (e.g. Google Web Toolkit (GWT) [146], jquery UI [147]) relatively new technique based on long-standing solutions (JavaScript [144], XML), which offers some graphical capabilities, but it is comparatively slow and not suitable for flexible graphic applications, HTML 5 [148] flourishing solution that receives significant attention from main players (e.g. Adobe, Microsoft), but it is still evolving and incomparable to Flash libraries abundance yet. Apache Flex technology facilitates creation of a wide range of highly interactive, expressive applications. It was chosen to implement GUI not only because of its graphical flexibility and rich library background, but also because of capability of creating clients for web browsers (Adobe Flash Player) or desktops (Adobe Integrated Runtime) and mobile devices (including ios, Blackberry and Android). A data visualization application built in Flex can pull data from multiple back-end sources and display it visually. Finally, the technology time in the market and also the author s practical experience with Flash solutions had a bearing on the choice. 79

92 Chapter 5. Implementation Details Integration Mechanism Flex application can integrate with all major back ends including Java, Spring, Hibernate, PHP, Ruby,.NET, Adobe ColdFusion, and SAP using industry standards such as Representational State Transfer (REST), Simple Object Access Protocol (SOAP), JavaScript Object Notation (JSON), Java Message Service (JMS), and Action Message Format (AMF). Dedicated Java remoting frameworks are already well developed (i.e. Adobe LiveCycle Data Services ES, Blaze DS, Granite Data Services etc.). The technology originates from Adobe Flash and maintains full compability, making the integration of rich Flash components seamless. GUI of the vertical translation tool, implemented with Apache Flex 4.9, communicates with its Java back-end via Java remoting functionality of Blaze DS component. Basically Blaze DS provides a skeleton of a web application (i.e. a base servlet) which can be extended with developer s Java classes and deployed in a web container (e.g. Apache Tomcat). For highly efficient communication, Flex client can take advantage of binary serialization format AMF, that outstrips basic HTTP, HTTPS communication channels. Additional integration techniques (e.g. messaging, proxying) are also available, but not used in the created tool. In 2007 BlazeDS and AMF technologies were contributed to open source under the GNU Lesser General Public License (LGPL v3). The clarity and simplicity of integration of Flex UI with Java classes exposed by BlazeDS back-end, i.e. Java remoting technique, is presented in Appendix D. Essentially, the mechanism bases on three elements: 1. RemoteObject component defined in Flex UI (the Flex RemoteObject declaration is shown in listing D.1), 2. Java remoting configuration in BlazeDS (the configuration file remoting-config.xml is shown in listing D.3), 3. Java endpoint component in Java application (the skeleton of RemoteRuleManagerServiceHandler Java class is shown in listing D.2). The integration process is significantly facilitated, when Adobe Flash Builder IDE is used, because it supports the development process with automatical detection of Blaze DS service structure and also generation of Action Script stub classes. 5.3 Chapter Summary In this chapter the key points of the created tool architecture are described. The tool is designed as a Rich Internet Application, i.e. the main modules are deployed on a web server and the rich GUI is available via a browser, making the tool easily accessible. The main modules that the tool is comprised of are: Rule Manager, Translation Manager and UI module. The managers are Java-based and the GUI uses the Apache Flex technology, while BlazeDS solution enables the integration of the modules. Such approach imposes a specific way of the application deployment on the web server. Moreover, Flash-based features of the GUI significantly contribute to the final efficiency of the tool. 80

93 Chapter 5. Implementation Details The most intriguing element of the implementation is the use of a rule engine (Drools Expert) as the Translation Engine, controlled by Translation Manager. The tool ingeniously takes advantage of the rule engine features, e.g. for translation triggering or for translation conflicts resolution. It also imposes a specific way of translating meta-rules notation that will be pondered in more detail in the following chapter, which evaluates the solution. 81

94 Chapter 6 Evaluation of Vertical Policy Translation Tool This chapter evaluates the created prototype of vertical policy translator. For the purpose of the evaluation a dedicated policy-based Case Study is introduced. The assessment is divided into several experiments that focus on different aspects of vertical knowledge-based policy translation. In the chapter it is also shown how the metaknowledge for the translation engine can be constructed by a domain expert and examples of both translated rules and translating meta-rules are discussed as well. The following chapter is to illustrate the employment of the technique of modelling a system policy at multiple levels of abstraction in a real life scenario and to evaluate the functionality of the prototyped policy translation tool, what, as a consequence, leads to the thesis verification. The first part of the chapter (section 6.1) introduces a functional Case Study that takes advantage of presentation of the system policy at multiple levels of abstraction. The case relates to a river dikes monitoring system and specifies the scopes of exemplary policy abstraction levels. This part explains why the methodology of multi-level insight into a policy is useful and how it is performed. The main part of the chapter (section 6.2) evaluates the features and usability of the created prototype of vertical policy translator. It practically shows how the system policy can be shaped with the use of the created tool for Case Study scenarios. The main emphasis is put on how the knowledge-based approach contributes to the vertical rule translation. This part also explains the actions taken by the tool users a strategy creator and a domain expert by specifying the information that need to be provided to the system by each of them. Finally, in a series of demonstrations the basic vertical rule translation is tested and then the extended tool functionality is examined and evaluated. The summary of the evaluation can be found in section

95 Chapter 6. Evaluation of Vertical Policy Translation Tool 6.1 Problem Domain The purpose of the exemplary policy-based system, which was used for testing the multi-level policy presentation technique, is tracking of the condition of river dikes. The monitoring process takes advantage of a set of dedicated sensors arranged in the embankments along the river-bed (c.f. Figure 6.1). The idea of the system relates to modern concepts of sensor networks [81] [82]. SECTION 1 SECTION 2 RIVER CURRENT A SENSOR Fig. 6.1: The changes of conditions at different river sections Having analysed the sensed parameters values the system is capable to take (or to suggest) appropriate actions. The type of actions depends on the policy declared by the system operator and the process of authoring of this policy is the main focus of the Case Study. The mechanism has application to not only the monitoring of the current condition of the dikes and thus the facilitation of its continuous maintenance, but also the support for managing temporary crisis situations such as higher water thread or flood Monitoring Policy Diversification Various parameters can be measured by the sensors (e.g. water level, water speed, embankment humidity, dikes pressure) that can further enable making a decision and undertaking precautionary or emergency actions. However, in a real life scenario we are faced with alike conditions at various sections of a river, i.e. different river currents, different dike types, different surroundings, different sensor location density (c.f. Figure 6.1). In such varied environments the system behaviour of a comparable seriousness level can look different, considering both the causes and the results of the reaction. For instance, in the situation of extremely high water emergency alert an evacuation should be started in a city, while in an uninhabited area a deliberate breaking the dike line could be advisable with the aim of sparing a city located down the river. Furthermore, the extremely high water emergency alert itself may be defined by distant sets of conditions for a city zone and for an uninhabited area. 83

96 Chapter 6. Evaluation of Vertical Policy Translation Tool Such diversification of river conditions renders the maintenance of dikes not a trivial task. The creation of a one coherent policy that can serve all situations in all sections of a river is complex, if doable at all. Furthermore, the complexity of the problem to solve clashes with the prominent idea of providing a single point of managing the policy in a simple way. GLOBAL FLUVIAL SECURITY STRATEGY RIVER SECTION 1 River current: slow, River shape: straight, Embankment type: soil, Sensor location: sparse, Zone: uninhabited RIVER SECTION 2 River current: rapid, River shape: curved, Embankemnts: concrete enforced, Sensor location: dense, Zone: city Fig. 6.2: River sections characteristics The possibility of a global tuning of dike maintenance or emergency policies is needed. On the other hand, specialized strategies that are applicable to particular fragments of the fluvial security system should be composed (c.f. Figure 6.2). In addition, in such extensive monitoring system, tools for managing sensors, which can provide methods of adjusting their power consumption or data delivery schemes, are also essential. Such requirements result in an multilevel approach to the policy governance in the presented case. The identified levels of policy abstraction are introduced in the following section Monitoring Policy Abstraction Levels As stated in Chapter 2, when talking about policy abstraction levels, conventionally only two levels are distinguished the business level and the technical level. The business level represents generally expressed system objectives, while the technical one is usually associated with a specialized code of rules dedicated for runtime instruments. In the presented use case, the specification of the policy abstraction levels was performed in a different manner. First of all, the requirements specified in the above section were taken into account. Secondly, amongst the levels presented below there is no technical level, which would represent a DSL code of rules. It results from the fact that the author perceives the articulating a policy in a specialized code as a plain (although technically complex) change of the way of a policy expression (i.e. a horizontal translation of a policy). 84

97 Chapter 6. Evaluation of Vertical Policy Translation Tool LEVEL 1 POLICY Global strategy CONTEXT: River current: slow, River shape: straight, Embankment type: soil, Sensor location: sparse, Zone: uninhabited CONTEXT: River current: rapid, River shape: curved, Embankemnts: concrete enforced, Sensor location: dense, Zone: city CONTEXT LEVEL 2 POLICY Regional strategy 1 LEVEL 2 POLICY Regional strategy 2 CONTEXT LEVEL 3 POLICY Sensor maintanance 1 LEVEL 3 POLICY Sensor maintanance 2 Fig. 6.3: Multi-level approach to the fluvial security system In effect, as illustrates Figure 6.3, in the presented case of a river dikes tracking and maintenance system, four levels of abstraction have been distinguished: 1. Global strategy, 2. Regional strategy, 3. Sensor data, 4. Sensor maintenance. Global strategy policy level represents the entry point for shaping the overall approach to the system tactics. It operates on a set of higher abstraction level parameters (e.g. FloodThreadLevel, EmbankmentStateEvaluation) that represent the general state of the dikes system and do not need to refer to the actual measurements of sensors. The purpose of this level is to maintain one compact, cohesive and coherent politics for whole fluvial system. Regional strategy policy level keeps the track of system behaviour for particular river sections. The sections are to be uniform and describable by a common and unambiguous characteristics (called CONTEXT in Figure 6.3 or Figure 6.4). The policy at this level of abstraction refers to physical quantities. The form of the policy for a particular river section derives from both the global policy settings and local context parameters. Sensor data level policies relay on parameters that are actually monitored by sensors. This level helps to express the level 2 physical quantities with the use of current readings. The use of policies at this stage makes possible different ways of calculating the values in different circumstances, what provides much more flexibility into the system operation. For instance, when some sensors stop answering, the calculation method can be changed or alarm level can be increased. Sensor maintenance policy level refers to the tactics of utilization of sensors. It deals with the issues of not only data acquisition, but also sensor state monitoring and 85

98 Chapter 6. Evaluation of Vertical Policy Translation Tool conservation. It keeps track of sensor operational readiness control, power consumption thrift and data reporting manners. The policies at this level follow upper level resolutions, but also take into consideration the characteristics of local sensor set. In the presented system only the translations from upper to lower level are taken into consideration. That is a strong assumption and may appear groundless, since some tuning may be necessary from the regional strategy side. However, this is the effect of the acknowledged way of the system operation that bases on one coherent global policy definition. WHEN FLOOD_THREAD lower/greater thread_treshold THEN SET_ALARM_LEVEL m CONTEXT 1: River current: slow, River shape: straight, Embankment type: soil, Sensor location: sparse, Zone: uninhabited CONTEXT 2: River current: rapid, River shape: curved, Embankemnts: concrete enforced, Sensor location: dense, Zone: city WHEN EFFECTIVE_WATER_LEVEL> 1.2*th*THREAD_LEVEL THEN _UNINHABITED_ZONE_ALARM_ACTIONS_SET_2 WHEN EMBANKMENT_HUMIDITY> 1.2*th*THREAD_LEVEL AND _EMBANKMENT_FACTOR_ < 0.6 THEN _UNINHABITED_ZONE_ALARM_ACTIONS_SET_3, _EMBANKMENT_ENFORCEMENT_1 WHEN EFFECTIVE_WATER_LEVEL> 0.8*th*THREAD_LEVEL THEN _CITY_ALARM_ACTIONS_SET_1 WHEN EMBANKMENT_HUMIDITY> 0.8*th*THREAD_LEVEL AND _EMBANKMENT_FACTOR_ < 0.8 THEN _CITY_ALARM_ACTIONS_SET_2, _EMBANKMENT_ENFORCEMENT_ WHEN EFFECTIVE_WATER_LEVEL> 1.2*th*THREAD_LEVEL AND _RAINFALL_FACTOR_ > 0.7 THEN _CITY_EVACUATION_PREPARATION_, _EMBANKMENT_ENFORCEMENT_1 Fig. 6.4: A sample of knowledge-based translation of a level 1 rule to a level 2 rules An example presenting rules located at different levels of abstraction of the river dikes maintanance system and also the use of knowledge-based vertical rule translation are depicted in Figure 6.4. As can be seen, one rule coming from level 1 is translated into distinct sets of level 2 rules depending on the provided context. That is the global strategy alarm rule will be implemented in different manners in different river parts. The next two sections clarify why (section 6.1.3) and explain how (section 6.1.4) river dikes protection strategies are modelled and translated according to the presented multiabstraction-level policy authoring methodology. They do not refer do the tool usage presentation yet, but rather provide further methodology details. The demonstrations carried out with the use of the created tool for multi-abstraction-level policy insight and vertical translation will be described in section Tuning of Monitoring Strategy This section discusses the idea of creating various strategies according to the presented methodology and can be achieved with the use of rule templates. The aspects described below refer to the runtime phase of the vertical translation shown in section and summarized in table 4.2 (row 2, step 1). They also exemplify the actions specified in step 1 of rule change scenario demonstrated in table 4.3 in section

99 Chapter 6. Evaluation of Vertical Policy Translation Tool The main idea of the multi-level policy insight has been already mentioned - the purpose is to author one global strategy at the top abstraction level and then vertically translate it into regional strategies having provided the translation context (i.e. the description of region conditions). One global strategy ensures a coherent approach to the dike system maintenance and monitoring. For instance, let us consider the handling of emergency situations. It can be described by a set of bindings of flood thread levels with corresponding emergency actions, defined as rules based on the template: TEMPLATE 1: WHEN flood thread exceeds level X THEN set alarm level Y When different aspects are considered during rules specification, the created rule sets will vary. On the one hand people security is important, but on the other emergency action expenses matter as well. The higher the alarm level, the more actions are taken. The number and range of emergency operations reflect in their costs (who and when is notified? how far the alert area reach?). Maybe taking the risk of postponing raising alarms can save money? Two exemplary strategy approaches are summarized in Table 6.1 SCENARIO BALANCED RISKY OBJECTIVES Actions follow flood thread, what causes bigger expenses. Alarm level grows gradually. The spectrum of actions taken changes proportionally, what leads to better organization of emergency actions. Actions are postponed, what allows for saving money. Alarm is raised not until the risk of flood is significantly raised. The spectrum of actions taken augments rapidly with the situation change, what can cause chaos. Table 6.1: Exemplary scenarios for global strategy creation The defined emergency policy (i.e. a flood thread - emergency actions binding) reflects in the character of system reactions during a flood thread. The exemplary bindings for scenarios defined above are shown in Figure 6.5 The higher the line goes, the more precautions and emergency actions are taken. The costs of emergency actions are proportional to the field under the alarm level graphs. Fig. 6.5: Relations of thread levels and alarm levels for different strategy approaches The instantiated rule sets expressing the two abovementioned strategies are summarized 87

100 Chapter 6. Evaluation of Vertical Policy Translation Tool in Table 6.2. It is worth noticing that rule sets contain different number of elements, what illustrates the goal-oriented character of the strategy creation phase. SCENARIO STRATEGY DEFINITION BALANCED WHEN flood thread exceeds level 1 THEN set alarm level 2 WHEN flood thread exceeds level 3 THEN set alarm level 4 WHEN flood thread exceeds level 5 THEN set alarm level 6 WHEN flood thread exceeds level 7 THEN set alarm level 8 WHEN flood thread exceeds level 9 THEN set alarm level 10 RISKY WHEN flood thread exceeds level 2 THEN set alarm level 1 WHEN flood thread exceeds level 5 THEN set alarm level 2 WHEN flood thread exceeds level 7 THEN set alarm level 4 WHEN flood thread exceeds level 8 THEN set alarm level 9 Table 6.2: Exemplary strategy definitions for two scenarios The next step of the strategy definition is the translation of the created global rules into distinct sets of regional policy rules. The following section thoroughly illustrates the process, while section 6.2 deliberates on the support provided by the prototype implementation of vertical policy translator Translation of Monitoring Strategy In section the policy abstraction levels for the discussed system were enumerated. In section it was presented how a strategy is created at the global level by instantiating rules based on level 1 templates. Analogously, rules at level 2 are instantiated based on level 2 templates, but the result depends on level 1 rule instances and actual translation context factors (i.e. river section, dike condition etc). This section presents an example of translating a rule from the highest to a lower level of abstraction and discusses what it means for the operator of the river dikes protection system. The aspects described below exemplify the actions specified in step 2 of rule change scenario demonstrated in table 4.3 in section 4.4. They refer to the runtime phase of the vertical translation shown in section and summarized in table 4.2 (row 2, step 2-3). The section continues to analyse the application of the multi-abstraction-level policy insight methodology, before the mechanism prototype tests are demonstrated (section 6.2). Let us consider another rule template that allows more sophisticated alarm level shaping by reacting to the dynamicity of condition changes: TEMPLATE 2: WHEN flood thread grows X at time Y THEN increase alarm level by N When used, i.e. when a rule at global level is instantiated by strategy creator, it makes the system reacts more intensely, when danger grows rapidly. With this rule the operator can decide what rapidly and intensely mean. Figure 6.6 shows an effect of incorporating an exemplary rule: WHEN flood thread grows 3 at time 2h then increase alarm level by 1. If the alert level changes slowly, as the lower line shows, the system reacts proportionally. However, when there is a rapid grow of the alert level, the system reacts accordingly. The dashed field in Figure 6.6 shows the 88

101 Chapter 6. Evaluation of Vertical Policy Translation Tool additionally increased alert level when the raise of alert was rapid in the highlighted time period. Fig. 6.6: Exemplary rule based on template 2 - level 1 view That is the level 1 point of view: alert level depends on the rate of alert level growth. However, when translated to level 2 the rule changes and used concepts not available at level 1. For instance, the danger can be expressed in elevated water level (among others). Thus the level 2 point of view will be: alert level depends on the rate of water level growth. This is shown in Figure 6.7. The basic alert is raised when the warning water level is exceeded. However, after rapid growth of water level, alert level is increased additionally, what is represented by the dashed fields. Fig. 6.7: Exemplary rule based on template 2 - level 2 view The meaning of the dynamicity reaction rule explained above seems easy, but it is not the clue of this section. The example is to realize, that the person who authors the global strategy at the global level does not have to know the details of the lower levels (e.g. the values of warning levels of water, values of water flow rates etc). It is enough to think abstract and general, what makes the comprehension of the strategy easier, because there is less details to grasp and to synchronize. This abstract ideas expressed by the global level rules will be translated for the strategy creator by the provided tool, if only it is supported with a domain expert knowledge (i.e. codified and inserted to the system meta-knowledge). It needs emphasizing that the presented HL LL attitude significantly differs from the standard approach. It is not the business-technical relation, which in general transformes a non-technical description into a technical specification, which talks about the same 89

102 Chapter 6. Evaluation of Vertical Policy Translation Tool subject, but more precisely. It is rather transitioning from general to more detailed policy specification and thus, it can relate to different object types at each level. This concludes the presentation of the problem domain which the Case Study refers to. The following section describes the use of the created tool for vertical policy translation within the area described above. The demonstrations aspire to prove the usability of the tool. 6.2 Evaluation of the Policy Translator Functionality The created tool provides multi-abstraction level policy authoring and insight, which are supported by knowledge-based vertical translation of rules. The section is devided in two parts that reflect the tool usage phases (c.f. section 4.2.1). Firstly, in section the resources used in the tests are introduced. This part strictly refers to the preparation phase of the vertical translation mechanism summarized in table 4.2 (row 1, steps 1-3). It illustrates the problem domain analysis that a domain expert needs to conduct how the abstraction levels and rule templates are distinguished as well as how this knowledge is written down to be used by the tool. The resources specified in this part are based strictly on the case study presented in section 6.1. Then, in section the demonstrations of the tool in action are described. This part illustrates the runtime phase of the vertical translation mechanism defined in table 4.2 (row 2, steps 1-3). In order to emphasize the unique functionality of the tool, this part was divided into several demonstrations that highlight various aspects of the knowledgebased vertical translation process Section also makes complete the information about the translation meta-knowledge that needs to be delivered by the domain expert. The translating meta-rules are explained during the tool features presentation. That was done deliberately in order to make it possible to explain how each presented tool feature is supported by the metaknowledge. Thus, section refers not only to the tool capability issues, but to the expert metaknowledge formulation aspects as well Policy Structure Definition This section illustrates the definition of the meta-knowledge that represents the policies related to the presented case study. The later demonstrations consider three policy abstraction levels and take advantage of a set of rule templates. To make the later demonstrations clearer, in this section the acknowledged sets of rule templates belonging to each level are described together with the facts types that they refer to. The rules use a simplified English notation in order to make the ideas comprehensible, but it is not obligatory. The token-based rule representation (c.f. section 4.1) lets the use of any notation (e.g. DRL). In the end of this section, the aspects considered as the translation context are depicted as well. The resources described in this section should be identified by a domain expert and provided to the system in the form of a policy structure file prior to the use of the system by a strategy creator. This is a XML file, called PolicyStructure.xml, that contains an enumeration of abstraction levels and a token-based notation of rule templates. Additional information such as a short policy description or choice lists items may be also 90

103 Chapter 6. Evaluation of Vertical Policy Translation Tool included. Some essential fragments of PolicyStructure.xml file used in the experiments can be found in Appendix A. Abstraction Level 1 The highest abstraction level of the dikes monitoring policy operates on the most general quantities. The simplified approach is based on highly abstract concepts, such as FLOOD THREAD, ALARM LEVEL, MAINTANANCE CHECK TYPE, EMBANK- MENT CONDITION etc. expressed in 0-10 scale. As described in section these concepts should be understood as the final system fact types (c.f. Figure 4.6). The strategy creator does not need to know what stands behind their meaning. He only has to author the character of the global policy, as described in section A number of highly abstract rule templates can be identified for the sake of flood alerting, dike conservation, power management etc. The exemplary rule templates for this level of abstraction are: 1. WHEN FLOOD THREAD exceeds X THEN set ALARM LEVEL Y 2. WHEN FLOOD THREAD grows X at time Y THEN increase ALARM LEVEL by N 3. WHEN EMBANKMENT CONDITION falls below X THEN advise MAINTANANCE CHECK TYPE N In the experiment the TEMPLATE 1 that refers to handling of a flood thread is analysed in more details. Abstraction Level 2 Level 2 is used for expressing regional strategies, but it also verbalizes the meaning of abstract concepts from the level 1 with the aid of measurable physical quantities. These are physical parameters, but not actually sensed values, i.e. the level 2 rules can use a RIVER SPEED factor, but it does not specify how to calculate it for a whole river section. The level 2 rule factors are calculated in more details at next level of abstraction. Another important assumption for choosing the level 2 factors is that they reflect rather dynamically changing parameters than static factors describing a river section (i.e. context factors). This level is dedicated for users that are better oriented in the details of the policy domain. The fact types used in definition of level 2 rules could be: dike features (HUMIDITY, PRESSURE, DISPLACEMENT, CONDITION ESTIMATION), river features (WARNING WATER LEVEL, ALARM WATER LEVEL, CURRENT WATER LEVEL, SPEED, 6H FLOW, 3H FLOW), alarm level specification (CURRENT ALARM LEVEL, LEVEL ACTION LIST), weather forecast (3DAY RAIN, 6H RAIN). 91

104 Chapter 6. Evaluation of Vertical Policy Translation Tool The level 1 template 1 FLOOD THREAD is an abstraction of various factors and can be expressed by, for instance: RAISED WATER LEVEL - exceeding a set high river level (e.g. in the case of unexpected water flush from a dam), WATER SPEED exceeded water speed when river level is raised, what can cause outwash of the riverbed, raised pressure at river bends, washing away of bridges etc., HUMIDITY exceeding a dike humidity when river level is raised (e.g. during long term rains), FORECAST coming long-term rains etc., DESTRUCTION (extremely high threads) unexpected dike displacements caused not by humidity or washout, but demolition by floating objects. What is important, the factors mentioned above can be used in various configurations with different threshold values for different conditions (i.e. translation context). Exemplary level 2 rule templates that were used in the experiments look as follows: 1. WHEN CURRENT WATER LEVEL exceeds WATER LEVEL THRESHOLD THEN set ALARM LEVEL Y 2. WHEN CURRENT WATER LEVEL exceeds WARNING WATER LEVEL and RIVER.SPEED exceed SPEED THRESHOLD THEN set ALARM LEVEL Y 3. WHEN CURRENT WATER LEVEL exceeds WARNING WATER LEVEL and DIKE.HUMIDITY exceed HUMIDITY THRESHOLD THEN set ALARM LEVEL Y 4. WHEN CURRENT WATER LEVEL exceeds WARNING WATER LEVEL and FORECAST.6H RAIN exceeds RAIN THRESHOLD THEN set ALARM LEVEL Y 5. WHEN DIKE.DISPLACEMENT exceeds X THEN set MAXIMUM ALARM LEVEL The values for the threshold values (e.g. WATER LEVEL THRESHOLD, HUMID- ITY THRESHOLD, SPEED THRESHOLD) and some values specific for a river section (i.e. RIVER.WARNING WATER LEVEL, RIVER.ALERT WATER LEVEL) are calculated based on level 1 rule values, differently for different river section characteristics, i.e. different translation context (c.f. section 6.2.1). Many more conditions for flood thread can be specified by an expert. It could include dike condition estimation, tracking of the dynamicity of river level changes or even coordination between river sections etc. However, to keep the tests comprehensible the limited set of templates was used in the experiment. 92

105 Chapter 6. Evaluation of Vertical Policy Translation Tool Abstraction Level 3 At this level the meaning of level 2 rules is expanded by providing definitions of actual methods for calculating the physical quantities used by level 2 rule templates. The calculations takes advantage of readouts from sets of sensors located along the riverbed, i.e. the concepts of physical quantities evolve into real measurements of sensors. The calculations can be formulated in different manners, depending on specific parameter features, measurement condition or river section characteristics. For instance, a value can be calculated as an average of readouts from all sensors of a river section or a maximum measured value or a value at the middle sensor etc. Some more sophisticated calculations can be based on correlations between river sections, e.g. concerning actual water flow by estimating how much water is going to enter next river sections, which can effect in rules such as WHEN city is in extreme danger THEN blow up dikes in an uninhabited area. The fact types that the level 3 bases on are the information from (SENSED VALUE) and about sensors (e.g. MEASUREMENT FREQUENCY, REPORTING PERIODS etc). The level 3 rule templates that were used in the experiment exchange the physical quantities with the measured values, e.g. the RIVER.CURRENT WATER LEVEL is casted on SENSED WATER LEVEL. However, in view of power consumption and inhabitants safety issues, the SENSED WATER LEVEL value is calculated with different precision and frequency in different conditions, i.e. in the city centre the value is checked as maximum of all sensors, but in an uninhabited area, a round robin sensor check is used. If necessary, the sensor management can be the base for further level 4 policy development. Another type of information can describe the sensor operation, such as sensor power consumption, sensor state (DISABLED, FAILURE, STANDBY STATE, MEASURE STATE, REPORTING STATE etc.) or sensor communication conditions (PBS ACCESS, AD HOC ROUTING etc). Translation Context The core of the translation context for the river dike monitoring policy consists of the parameters describing the permanent characteristics of a river section. However, as stated in section 3.4.2, what can influence the translation could also be the rule parameters values or even rule existence. All those factors were used during the experimental policy creation. For regional policy specification the river section characteristics was described by exemplary factors: REGION uninhabited area, suburbs, city centre, DIKE dike type (clay/concrete), height, base, RIVER average level, average speed. For the sake of level 3 translations the list should be extended with permanent data describing sensors location and operation, such as sensor model, location density, power 93

106 Chapter 6. Evaluation of Vertical Policy Translation Tool consumption, sensor communication options (WI-FI access, available mobile data service etc). During the experiments it appeared that extension of the context values is useful, i.e. some context values were re-calculated into another context values, characteristic for given conditions. For instance, RIVER.WARNING WATER LEVEL and RIVER.ALERT WATER LEVEL values were calculated based on the height of embankments and depending on a region type and materials used. The calculation method is described in section SECTION CHARACTERISTICS 1 uninhabited area, a clay dike, a wide riverbed, scarce sensors 2 suburbs, a clay dike, a narrow riverbed, scarce sensors 3 a city centre, a concrete dike, a narrow riverbed, dense sensors Table 6.3: Exemplary river section characteristics used for experiments The tests of river security policy creation were led for a modelled river which has three sections of distinct characteristics shown in Table 6.3. Appropriate context values were attributed in each case. This concludes the first part of the translation knowledge preparation phase led by a domain expert. The above results of the domain analysis need to be written down in the form of PolicyStructure.xml file and provided to the tool. Some essential fragments of the file can be found in Appendix A. The second part of the translation meta-knowledge, i.e. the definition of translating meta-rules, is explained in section Tool Usage Philosophy Before the tool capabilities are shown, the philosophy of its use shall be briefly presented. The tool implements translation mechanism explained in section The instantiation process bases on the templates defined earlier by a domain expert (c.f. section 3.3.1). The description of usage of the tool includes both the rule instantiation process and the translation outcome browsing. The visualization of rule interrelations is presented in more details, because it shows also various diagram types that were tested during the tool implementation phase. This section shall make the tool features presentations easier to comprehend (section 6.2.3), as they will focus on the translation outcome analysis and the rule instantiation phase will be omitted then. When using the tool, a strategy creator builds only the top abstraction level rules and the tool disperses the rules down to the lower levels automatically by translating them with the use of the meta-rules (also delivered by the domain expert). Below, the rule instantiation interfaces are presented (Figures 6.8 and 6.9). The rule delete/update functionality is also available, although not presented. 94

107 Chapter 6. Evaluation of Vertical Policy Translation Tool Fig. 6.8: Instatiation of two rules based on provided templates In Figure 6.8 instantiation of two rules is demonstrated. On the left side, the choice of the highest abstraction level can be seen. In the central part, the list of rule templates is activated and below two templates are prepared to be filled with the rule parameter values by the tool user. When that is finished, the INSTANTIATE ALL RULE PROTOTYPES button is pressed and the rule instances are sent to the tool back-end Translation Manager. Fig. 6.9: Listing of instantiated and translated rules 95

108 Chapter 6. Evaluation of Vertical Policy Translation Tool In Figure 6.9 the instantiation results are shown. The list of created rules can be presented to the tool user for any abstraction level after selecting the level of interest on the panel on the left side of the interface. In the rule hierarchy visualization interface only the names of the rules will be used. The rule names and the parent templates names can be seen for each rule in both Figures 6.8 and 6.9. At this stage of the strategy creation process, the rule sets are ready to be exported to the destination policy-based system, that are capable of utilizing the prepared knowledge. It is worth reminding that the presented rule translator is not a knowledge-based system itself, but only a tool supporting policy authoring. The use of the created knowledge is out of the scope of the tool application. Some efficient policy export mechanisms should be used now to transfer the knowledge to appropriate applications congruent with particular policy abstraction levels. In the further part of this chapter, while demonstrating the tools capabilities, the phase of rule instantiation is referred, although not described any more. Only the translation outcome, presented with the use of rule hierarchy visualization interface, will be analysed. The rule dependency visualization is explained in the next section. More details on the user interface elements can be found in section Rule Dependencies Visualization The outcome of the rule vertical translation process is visualized by the tool as well. A dedicated interactive diagram for presenting inter-abstraction-level rule relations was implemented. During the works on the knowledge-based vertical rule translator the way of visualizing was one of the major challenges. Such diagram should be easily readable. For each rule it should picture its abstraction level, as well as its parents and children rules. A number of relational graphs was checked. Some examples are shown below in Figures 6.11, 6.12 and Fig. 6.10: Tree visualization of rule hierarchy 96

109 Chapter 6. Evaluation of Vertical Policy Translation Tool Fig. 6.11: Circular visualization of rule hierarchy, version 1 Fig. 6.12: Circular visualization of rule hierarchy, version 2 97

110 Chapter 6. Evaluation of Vertical Policy Translation Tool At each diagram a node represent a rule (originally instantiated by a strategy creator or translated by the system) and an edge a rule dependency. When a rule is clicked, then a path to its parents, i.e. the rules that it is derived from (green edges) and its children, i.e. the rules that it is translated to (red edges) are highlighted, as can be seen in Figure 6.10 or Out of the diagram types, the circular version shown in Figure 6.12 was chosen as the clearest and the most comprehensible. The other circular version (Figure 6.11) becomes increasingly unreadable for a growing number of rules. The tree version (6.10) emphasizes the abstraction level hierarchy, but it does not arrange the nodes in the diagram plane efficiently. In the chosen diagram type, the rules of the same level of abstraction are gathered in groups. The closer to the circle centre the group is located, the higher abstraction level it represents. Such node arrangement stays clear even for a bigger number of rule nodes and dependency edges. Moreover, it stays attractive from the graphical point of view. In the following sections the demonstrations of the tool features are presented. The descriptions base on the tool usage scheme explained above. The instantiation phase descriptions will be omitted and mainly visualizations of the translation outcomes will be analysed Tool Capability Demonstrations The demonstrations are organized in such way that they illustrate different features of the prepared tool usage. They are to proof the tool usability for easy creation of policies, their knowledge-based vertical translation and their presentation at various levels of abstraction (c.f. section 4.2.1). The method is a completely new approach and thus is not comparable to any existent BRMS. The review starts from running a simple rule mapping (c.f. section 2.7.1) in demonstration 1. On the one hand, it is to present the tool aptitude for performing the basic tasks, but on the other, the demonstration shows the simplicity of defining rule translation schemes (i.e. translating meta-rules). Demonstrations 2 and 3 present context-based aspects of the translation mechanism. The influence of rule context and a general translation context are explained. Demonstration 4 describes a powerful feature of the knowledge-driven translation that enables using the expert metaknowledge for the verification of created policy (i.e. the coherence control and the conflict elimination). Originally, the feature was not anticipated during the translation mechanism construction, but it was revealed during the tool test phase. Demonstration 5 shows a rule update operation. It refers to a rule change scenario, that was theoretically defined in section 4.4. Finally, demonstration 6 touches upon the reformulation of the translation context (mentioned in section 6.2.1). For the clarity of the results presentation in the first four demonstrations only two levels of abstraction are used and only in the fifth one the third level is engaged. The demonstrations base on translating meta-knowledge that should be formulated by a domain expert and provided to the system prior to the use of the tool by a strategy 98

111 Chapter 6. Evaluation of Vertical Policy Translation Tool creator. The first part of the meta-knowledge, i.e. the policy structure definition, was already demonstrated in the preceding section. Now, the translating meta-rules shall be introduced. Practically, this part of the meta-knowledge is recorded in the form of Drools DRL file MetaKnowledge.drl. Different variants of meta-rule formulas will be referred within the experiment descriptions in order to explain how the tool functionality is achieved. Some essential fragments of MetaKnowledge.drl file used in the experiments can be found in Appendix B. Demonstration 1. Rule Mapping This experiment shows the easiness of performing standard rule mapping (c.f. section 2.7.1) with the use of the presented vertical translation method. Simple rule mapping expects that each HL rule is translated into a defined set of LL rules with rule values calculated appropriately. In this example the higher level rules are thread-alarm bindings (c.f. section 6.2.1). They need to be mapped into three lower level rules: high water level, river speed and dike humidity monitoring rules. There is no context check performed and for any value of higher level rule parameters, the same set of lower level rules is instantiated. All lower level rule parameter values are calculated in the same manner, without concerning region or dike type. To reach the goal of the experiment a basic translating meta-rule was prepared. The actions performed by this meta-rule reflect the operations defined in the translation mechanism presented in section 4.3. The example of rule mapping meta-rule is shown in Appendix B (rule Rule mapping ). The scheme of rule translation is the base of further examples. The left-hand side (LHS) of the meta-rule just finds a created higher level rule to be translated. The right-hand side (RHS) of the meta-rule performs four major tasks: 1. Calculates values for the descendant rule based on the initial rule parameters, 2. Memorizes the new values in a Rule Context object (ALARM LEVEL and WA- TER LEVEL tokens), 3. Creates a descendant Rule Instance (based on chosen Rule Template and created Rule Context), 4. Registers new rule dependency in Rule Manager. In order to achieve the defined rule mapping, three translating meta-rules were used. Each of them translates the initial higher level rule into a separate lower level rule of a different kind (i.e. high water level, river speed or dike humidity monitoring rule). In the experiment, four HL rules were instantiated in the manner explained in section Then the translation was triggered. The visualization of the translation outcome (i.e. the hierarchy of the instantiated rules as well as the ones created by the translation mechanism) is shown in Figure Four HL rules (called n FLOOD THREAD UP ) form a group closer to the diagram centre. Each of them is related to three descendant 99

112 Chapter 6. Evaluation of Vertical Policy Translation Tool LL rules (called n SPEED, n HUMIDITY, n HIGH WATER ) as highlighted in the diagram. The LL rules form an easily distinguishable group located farther from the diagram centre. Fig. 6.13: Plain rule mapping scenario The demonstration showed the basics of the knowledge-base rule translation performed by the created tool. The purpose was to not only to prove its capability of achieving a basic rule mapping (as described in 2.7.1), but also to introduce the philosophy of the tool utilization (i.e. its preparation for carrying the translations) that the following demonstrations will base on. The demonstrations will show capabilities not available for any other present rule management solution. Demonstration 2. Rule Context Check This demonstration presents the possibility of using parameters of a higher level rule as a context for the rule vertical translation (c.f. intra-rule factors in section 3.4.2, point 1). It refers to the actions shown at the beginning of the rule change scenario example (c.f. section 4.4, rows 1 and 2 of Table 4.3), where a different translation outcome for instances of the same rule template are allowed, as opposed to the simple rule mapping illustrated in Demonstation 1. Let us assume that for lower values of flood thread (HL) only water level checking rules (LL) are needed, but for higher flood thread (HL) additionally river speed checking rule (LL) should be instantiated. In this case, the translating meta-rule should additionally analyse the HL rule parameters. The example of such rule parameter checking meta-rule is shown in Appendix B (rule Rule parameter check ). The LHS of the meta-rule extracts the THRESHOLD LEVEL parameter value and checks a condition. Only then the RHS actions are taken. In this demonstration, the translating meta-rules from the previous demonstration were used. However, two of them where modified by adding parameter checks the humidity checking rule is instantiated only for flood thread greater than 3 and the speed checking 100

113 Chapter 6. Evaluation of Vertical Policy Translation Tool rule for flood thread greater than 5. These threshold values would be arbitrary set by a domain expert and included in the MetaKnowledge.drl. Fig. 6.14: Rule context check scenario (translation for clay dikes) In the experiment, four HL rules from demonstration 1 were instantiated and translated. The visualization of the translation outcome is shown in Figure As it can be seen, the results differs - various sets of LL rules are instantiated for different HL rules depending on their parameters, as it was demanded by this demonstration assumption. Demonstration 3. Translation Context Check This demonstration illustrates the powerful mechanism of affecting the vertical translation by the translation context (c.f. external factors in section 3.4.2, point 3). For different translation context (i.e. different dike type) dissimilar lower level rule set is generated. Let us assume that no rules concerning dikes humidity change are required for concrete dikes. As defined in section a dike type is the context parameter. Thus, the LHS of a translating meta-rule needs to be enriched with translation context condition check. The example of such rule parameter checking meta-rule shown in Appendix B (rule Translation context check ) demonstrates how easy is the use of translation context in the presented solution. In the experiment, the translation context values were changed in the context panel (parameter dike type ). Again, four HL rules from demonstration 1 were instantiated and translated. In effect, the significant translation outcome change is noticed. The rule translation results for clay dikes are those shown in Figure 6.14, while results for concrete dikes are presented in Figure For concrete dikes no humidity checking rules are created. Moreover, the values for new rules can be calculated in a different manner for different contexts (e.g. water speed threshold is estimated in different way for clay dikes and for concrete dikes). 101

114 Chapter 6. Evaluation of Vertical Policy Translation Tool Fig. 6.15: Translation context check scenario (translation for concrete dikes) The demonstration showed the means for respecting the translation context in the translation process. The context check can be easily considered by the domain expert during constructing the meta-knowledge. The approach reflects the concepts introduced in section and implements the mechanisms introduced in section As presented, it significantly differs from the standard rule mapping shown in demonstration 1. Demonstration 4. Strategy Coherence Verification This demonstration illustrates another robust capability that gives the presented knowledgebased translation method. Except for the vertical translation process, the used metaknowledge can provide mechanisms for verifying the coherence of the created strategy, e.g. recognize contradictions, identify repeating or mergeable rule instances etc. Originally, the feature was not widely discussed during the translation mechanism construction (c.f. section 4.4), but it was revealed during the tool test phase. In fact, the capability significantly enriches the proposed mechanism of knowledge-driven translation. A domain expert can predict some kinds of policy incoherency. Some examples of them will be given below. Their detection demands providing special meta-rules, different from the translating ones. Those meta-rules recognize a conflict and then carry out a dedicated repair procedure. They need to be delivered to the system just as translating meta-rules by a domain expert, because it is him who can define a rule conflict or possible rule merging situation. In this experiment two examples of such verification actions are presented. The first example shows a capability of recognizing contrary rule instances. The second one illustrates an identification of overlapping rules that can be merged, i.e. a rule, which refers to conditions served by another rule is removed. A specific subset of this action is removing repeating rules. 102

115 Chapter 6. Evaluation of Vertical Policy Translation Tool Contradiction check. Let us suppose that the strategy creator by mistake defined two rules: 1. WHEN flood thread exceeds level 6 THEN set alarm level 4 2. WHEN flood thread exceeds level 5 THEN set alarm level 5 Such combination does not make sense, because higher thread raises alarm of lower level. The system should report it or even solve it automatically by removing one of the rules. An example of a rule parameter checking meta-rule that would handle this situation by deleting the first rule is shown in Appendix B (rule Correlate FLOOD THREAD UP rule ). In result, the system clarifies the HL rule set during the instantiation phase. Merging overlapping rules. The case refers to the co-existence of rules, among which one rule eliminates the need of having the other. For instance, repeating the same alarms for different thread levels may be unnecessary. Let us suppose that in the process of rule translation two rules were created: 1. WHEN water level exceeds level 900cm THEN run alarm action list 4 2. WHEN water level exceeds level 750cm THEN run alarm action list 4 This means than when water level raised up to 750cm the actions of alarm level 4 are run. Maybe they do not need to be run again when water level reaches 900cm. In fact, this is the domain expert s decision, because in the case of other rules repeating alarms can make sense. A merging meta-rule can solve this problem. The one shown in Appendix B (rule Merge HIGH WATER rules ) removes the rule with higher thread level and takes over the dependencies of the removed rule. Fig. 6.16: Rule merging example The exemplary effect of such merging action is illustrated in Figure Two rule merging procedures were carried: HIGH WATER 1 rule was merged with HIGH WATER 2 rule and HIGH WATER 3 rule was merged with HIGH WATER 4 (rules HIGH WATER 1 103

116 Chapter 6. Evaluation of Vertical Policy Translation Tool and HIGH WATER 3 were removed). In effect, HL rules have common derivative LL rules (e.g. 1 FLOOD THREAD UP and 1 FLOOD THREAD UP share a child rule HIGH WATER 2). Removing repeating rules. A specific subset of merging rule activity is the removal of repeating rules. It helps avoiding situation when a strategy creator by mistake creates two identical rule instances with different names or in the process of rule translation two lower level rules with the same parameters are created. A universal meta-rule that solves that problem is shown in Appendix B (rule General merging rule ). During creation of such meta-rule a domain expert may decide whether inform a strategy creator about the case or just arbitrary remove one rule. The order of translation and coherence verification processes. The tool tests also showed that the order of translation and coherence verification processes is important. Firstly after creating level 1 rule instances the first coherence check should be carried (identification of repeating of contrary rules) and only then the translation of level 1 can be done. Then level 2 rules should be verified, then translated into level 3 and so on. This can be easily controlled by appropriate salience property assignment for translating and coherence meta-rules in the meta-knowledge definition. Fig. 6.17: Multiple-level rule correlation The problem is illustrated in Figure The highlighted level 2 rule 3 HIGH WATER can be translated into level 3 SENSOR rule only after the merging process is finished. Demonstration 5. Rule Update In section 4.4, a process of a rule change was presented. It considered the theoretical groundings of the knowledge-based translation and referred to a number of possible rule interferences. Now, when the tool is implemented and the main translation features have been explained, the scenario is verified practically as well. However, the demonstration 104

117 Chapter 6. Evaluation of Vertical Policy Translation Tool does not refer to all the rule interferences, but rather focuses on presenting the rule update process. Let us suppose that the strategy creator defined two rules: WHEN flood thread exceeds level 7 THEN set alarm level 6 WHEN flood thread exceeds level 5 THEN set alarm level 4 However, at some point, he decides to make the strategy safer and change the second rule into: WHEN flood thread exceeds level 5 THEN set alarm level 6 The tool update facility, which resembles the rule instantiation form (Figure 6.8), lets redefine any HL rule and re-run the whole translation process. However, in place of analyzing all the dependencies of the changed rule, simply a new inference is executed. All translated rules are removed by the Rule Manager and a new source set of instantiated rules is defined, that contains an updated rule in place of the original one. Then the new translation process is triggered. Fig. 6.18: Original translation before the rule update Fig. 6.19: Translation outcome after the rule update The former and the latter translation outcomes are shown in Figures 6.18 and 6.19 accordingly. As it can be noticed, the second translation includes a unification action (c.f. demonstration 4) just as in step 6 of the rule change scenario (Table 4.3). Demonstration 6. Translation Context Reformulation During the works on the metaknowledge formulation a necessity of recalculating some translation context values appeared. For instance, in the context panel a user can declare dikes height and river depth, but in further level 2 rules declarations a used quantity is WARNING WATER LEVEL or ALERT WATER LEVEL. To avoid calculating them in every rule template, an idea of general translation context reformulation came out. This very simple experiment shows how the system can achieve it. 105

118 Chapter 6. Evaluation of Vertical Policy Translation Tool For the purpose of concept tests it was assumed that outside of a city a later alerting is possible (i.e. a higher warning water level), but within the city an alarm should be raised earlier (i.e. a lower warning water level). On the other hand, concrete dikes are stronger, so when they are used a warning and alert water levels could be slightly higher. Fig. 6.20: River warning and alert levels calculated for equal dike heights Fig. 6.21: River warning and alert levels calculated for varied dike heights During the test the system was provided with specification of different types of river sections (i.e. different values in Translation Context panel), as declared in section As the output the recalculated values of WARNING WATER LEVEL or ALERT WATER LEVEL were checked in the back-end command line output (unavailable for a regular strategy user). The readouts for each section were presented in the diagrams 6.20 and As can be seen the recalculated values of warning and alert water levels change according to the river section type and the dikes height (marked as a green line). The rules that allow for redefining translation context values are shown in Appendix B (rules Translation Context recalculate 1 - city and Translation Context recalculate 2 - concrete ). The technique is also very useful for introducing to the system some standard values, which could be constant or changeable depending on translation context. For instance, default actions taken at each alarm level may be prearranged, but depending on context they could be slightly reorganized (some alarms raised earlier, some never, the alerted area may vary etc.). 106

Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie

Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki KATEDRA INFORMATYKI PRACA MAGISTERSKA PRZEMYSŁAW DADEL, MARIUSZ BALAWAJDER ANALIZA

More information

Adaptive Deployment of Component-based Applications in Distributed Systems


More information

Goal-driven Adaptive Monitoring of Dynamic Service Oriented Systems

Goal-driven Adaptive Monitoring of Dynamic Service Oriented Systems Faculty of Computer Science, Electronics and Telecommunications Goal-driven Adaptive Monitoring of Dynamic Service Oriented Systems Ph.D. Dissertation Marek Psiuk Supervisor: Prof. Krzysztof Zieliński

More information

Generic ESB Monitoring Architecture Compliant With JBI

Generic ESB Monitoring Architecture Compliant With JBI Generic ESB Monitoring Architecture Compliant With JBI Marek Psiuk Tomasz Bujok Supervisor: Prof. Krzysztof Zieliński Department of Electrical Engineering, Automatics, Computer Science and Electronics

More information

JCR or RDBMS why, when, how?

JCR or RDBMS why, when, how? JCR or RDBMS why, when, how? Bertil Chapuis 12/31/2008 Creative Commons Attribution 2.5 Switzerland License This paper compares java content repositories (JCR) and relational database management systems

More information


PROJECT FINAL REPORT PROJECT FINAL REPORT Grant Agreement number: 212117 Project acronym: FUTUREFARM Project title: FUTUREFARM-Integration of Farm Management Information Systems to support real-time management decisions and

More information

An architectural blueprint for autonomic computing.

An architectural blueprint for autonomic computing. Autonomic Computing White Paper An architectural blueprint for autonomic computing. June 2005 Third Edition Page 2 Contents 1. Introduction 3 Autonomic computing 4 Self-management attributes of system

More information

Interactive Process Models

Interactive Process Models Interactive Process Models Håvard D. Jørgensen Department of Computer and Information Science Faculty of Information Technology, Mathematics and Electrical Engineering Norwegian University

More information Coordination Action on Digital Library Interoperability, Best Practices and Modelling Foundations Coordination Action on Digital Library Interoperability, Best Practices and Modelling Foundations Coordination Action on Digital Library Interoperability, Best Practices and Modelling Foundations Funded under the Seventh Framework Programme, ICT Programme Cultural Heritage and Technology Enhanced

More information

Nr.: Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg

Nr.: Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Nr.: Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Nr.: Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Impressum ( 5 TMG) Herausgeber: Otto-von-Guericke-Universität Magdeburg

More information

SOA Development and Service Identification. A Case Study on Method Use, Context and Success Factors

SOA Development and Service Identification. A Case Study on Method Use, Context and Success Factors Frankfurt School Working Paper Series No. 189 SOA Development and Service Identification A Case Study on Method Use, Context and Success Factors by René Börner, Matthias Goeken and Fethi Rabhi April 2012

More information

Introduction When Lifecycle People Products Management Development Tailoring Other. 2002-2008 DSDM Consortium. DSDM Public Version 4.

Introduction When Lifecycle People Products Management Development Tailoring Other. 2002-2008 DSDM Consortium. DSDM Public Version 4. DSDM Public Version 4.2 Manual Introduction When Lifecycle People Products Management Development Tailoring Other 2002-2008 DSDM Consortium [12-1-2008

More information


NEER ENGI ENHANCING FORMAL MODEL- LING TOOL SUPPORT WITH INCREASED AUTOMATION. Electrical and Computer Engineering Technical Report ECE-TR-4 NEER ENGI ENHANCING FORMAL MODEL- LING TOOL SUPPORT WITH INCREASED AUTOMATION Electrical and Computer Engineering Technical Report ECE-TR-4 DATA SHEET Title: Enhancing Formal Modelling Tool Support with

More information

Final Report. DFN-Project GRIDWELTEN: User Requirements and Environments for GRID-Computing

Final Report. DFN-Project GRIDWELTEN: User Requirements and Environments for GRID-Computing Final Report DFN-Project GRIDWELTEN: User Requirements and Environments for GRID-Computing 5/30/2003 Peggy Lindner 1, Thomas Beisel 1, Michael M. Resch 1, Toshiyuki Imamura 2, Roger Menday 3, Philipp Wieder

More information

Analysis, Design and Implementation of a Helpdesk Management System

Analysis, Design and Implementation of a Helpdesk Management System Analysis, Design and Implementation of a Helpdesk Management System Mark Knight Information Systems (Industry) Session 2004/2005 The candidate confirms that the work submitted is their own and the appropriate

More information

Designing workflow systems

Designing workflow systems TECHNISCHE UNIVERSITEIT EINDHOVEN Department of Mathematics and Computing Science MASTER S THESIS An algorithmic approach to process design and a human oriented approach to process automation by Irene

More information

Installation of complex e-science applications on heterogeneous cloud infrastructures

Installation of complex e-science applications on heterogeneous cloud infrastructures AGH UNIVERSITY OF SCIENCE AND TECHNOLOGY IN KRAKÓW, POLAND Faculty of Electrical Engineering, Automatics, Computer Science and Electronics Department of Computer Science Installation of complex e-science

More information

Development of a 3D tool for visualization of different software artifacts and their relationships. David Montaño Ramírez

Development of a 3D tool for visualization of different software artifacts and their relationships. David Montaño Ramírez Development of a 3D tool for visualization of different software artifacts and their relationships David Montaño Ramírez Development of a 3D tool for visualization of different software artifacts and their

More information

Generic Statistical Business Process Model

Generic Statistical Business Process Model Joint UNECE/Eurostat/OECD Work Session on Statistical Metadata (METIS) Generic Statistical Business Process Model Version 4.0 April 2009 Prepared by the UNECE Secretariat 1 I. Background 1. The Joint UNECE

More information

Universiteit Leiden Computer Science

Universiteit Leiden Computer Science Internal Report 2012-04 Universiteit Leiden Computer Science A Method for Automated Prediction of Defect Severity Using Ontologies Name: Student-no: Martin Pavlov ILIEV s1053574 Date: 10/07/2012 1st supervisor:

More information

State of art in the field of Adaptive Service Composition Monitoring and Management

State of art in the field of Adaptive Service Composition Monitoring and Management D5.1 Version: 0.7 Date: 2008-07-30 Author: UNITN Dissemination status: PU Document reference: D5.1 State of art in the field of Adaptive Service Composition Monitoring and Management Project acronym: COMPAS

More information

SERVICE RESCUE! An Implementation and Improvement Guide for Incident Management. Nicole Conboy Jan van Bon

SERVICE RESCUE! An Implementation and Improvement Guide for Incident Management. Nicole Conboy Jan van Bon SERVICE RESCUE! An Implementation and Improvement Guide for Incident Management Nicole Conboy Jan van Bon SERVICE RESCUE! An Implementation and Improvement Guide for Incident Management This book is dedicated

More information

1 Applications of Intelligent Agents

1 Applications of Intelligent Agents 1 Applications of Intelligent Agents N. R. Jennings and M. Wooldridge Queen Mary & Westfield College University of London 1.1 Introduction Intelligent agents are a new paradigm for developing software

More information

Introduction to Recommender Systems Handbook

Introduction to Recommender Systems Handbook Chapter 1 Introduction to Recommender Systems Handbook Francesco Ricci, Lior Rokach and Bracha Shapira Abstract Recommender Systems (RSs) are software tools and techniques providing suggestions for items

More information

A compositional model for the formal specification of user interface software. Panagiotis Markopoulos

A compositional model for the formal specification of user interface software. Panagiotis Markopoulos A compositional model for the formal specification of user interface software Panagiotis Markopoulos Submitted for the degree of Doctor of Philosophy March 1997 A compositional model for the formal specification

More information

Cognitive architectures: Research issues and challenges

Cognitive architectures: Research issues and challenges Available online at Cognitive Systems Research xxx (2008) xxx xxx Cognitive architectures: Research issues and challenges Action editor: Ron Sun Pat

More information

2. Tuning methodology 5. 3. Competences in the teaching and learning process 17. 4. ECTS, student workload and learning outcomes 47

2. Tuning methodology 5. 3. Competences in the teaching and learning process 17. 4. ECTS, student workload and learning outcomes 47 Introduction to Tuning-2.indd a 7/3/07 18:08:28 Content 1. Introduction 1 2. Tuning methodology 5 3. Competences in the teaching and learning process 17 4. ECTS, student workload and learning outcomes

More information

Requirements and Design for an Extensible Toolkit for Analyzing EMR Audit Logs

Requirements and Design for an Extensible Toolkit for Analyzing EMR Audit Logs Requirements and Design for an Extensible Toolkit for Analyzing EMR Audit Logs Eric Duffy, Steve Nyemba, Carl A. Gunter, David Liebovitz, and Bradley Malin April 2013 Abstract Over the past decade, various

More information

Recommendations for Interdisciplinary Interoperability (R 3.3.1)

Recommendations for Interdisciplinary Interoperability (R 3.3.1) Recommendations for Interdisciplinary Interoperability (R 3.3.1) Version 15.02.2013 - V. 1.0 Arbeitspaket 3.3 Interdisciplinary Interoperability Verantwortlicher Partner DAI DARIAH-DE Aufbau von Forschungsinfrastrukturen

More information

CRISP-DM 1.0. Step-by-step data mining guide

CRISP-DM 1.0. Step-by-step data mining guide CRISP-DM 1.0 Step-by-step data mining guide Pete Chapman (NCR), Julian Clinton (SPSS), Randy Kerber (NCR), Thomas Khabaza (SPSS), Thomas Reinartz (DaimlerChrysler), Colin Shearer (SPSS) and Rüdiger Wirth

More information