Component assembly and theorem proving in constraint handling rules

Texto

(1)Universidade Federal de Pernambuco Centro de Informática. Mestrado em Ciências da Computa¸cão. COMPONENT ASSEMBLY AND THEOREM PROVING IN CONSTRAINT HANDLING RULES Cleyton Mário de O. Rodrigues ˜ DE MESTRADO DISSERTAC ¸ AO. Caixa Postal CDU 7851, Recife, PE, Brasil July 1, 2009.

(2)

(3) Universidade Federal de Pernambuco Centro de Informática. Cleyton Mário de O. Rodrigues COMPONENT ASSEMBLY AND THEOREM PROVING IN CONSTRAINT HANDLING RULES. Trabalho apresentado ao Programa de Mestrado em Ciˆ encias da Computa¸ c˜ ao do Centro de Inform´ atica da Universidade Federal de Pernambuco como requisito parcial para obten¸ c˜ ao do grau de. Mestre em Ciˆ encia da Com-. puta¸ c˜ ao.. Orientador: Prof. Dr. Jacques Louis Pierre Robin. Caixa Postal CDU 7851, Recife, PE, Brasil July 1, 2009.

(4)

(5)

(6)

(7) I dedicate this victory to my teachers, friends and family, without which I could not have reached this new level in my education..

(8)

(9) ACKNOWLEDGEMENTS Now are we sure that thou knowest all things, and needest not that any man should ask thee: by this we believe that thou camest forth from God. —JOHN 16:30 (Holy Bible). First, I would like to demonstrate my eternal gratitude, for my great Father, God, who granted me the gift of life and always guide me throughout my journey. It is mainly for him that I dedicate this dissertation, as consideration for all the good that he has provided every day of my life. During these two years of research, some people also were responsible for incentives, with forces in times of great pressures. For these, do I dedicate in this small, but significant part of the dissertation, my gratitude. On the academia, I would like to show my gratitude to my advisor Dr. Jacques Louis Pierre Robin, responsible for providing wisely the key knowledge necessary to develop this dissertation. It is up to him too my gratitude for having been able to detect and exploit the best of me as a scientific researcher. I would like to thank also, my master friends with whom I shared the victories achieved over the years, in particular Marcos Aurelio Almeida da Silva, a friend who provided great help in this dissertation. I could not fail to mention also those responsible for the learning during a stage of six months in INRIA - Institute National de Recherche en Informatique et Automatique in Rocquencourt/Paris, as my teacher and advisor Dr. Francois Fages and my co-worker, Thierry Martinez. My thanks are also dedicated to those who are the reason for my life: my family. I want to thank everyone that give strength and that always had faith in me: my mother, Severina Rita de Oliveira Rodrigues, my father, Mário José Rodrigues, my brother, Caio Marcelo de Oliveira Rodrigues, my sister, Cintya Millena de Oliveira Rodrigues, and my niece, Sarah Beatriz Rodrigues da Cruz. I would also like to thank all my friends who always showed respect, attention and that directly or indirectly contributed to this new level conclusion in my education. In special, Danielle Albuquerque, my girlfriend, which has given me constant support and encouragement in moments of weariness and uncertainties. Friends, this victory is also for you. For all, my most sincere thanks. Cleyton Mário de Oliveira Rodrigues. ix.

(10)

(11) A Jade stone is useless before it is processed; a man is good-for-nothing until he is educated. —AUTHOR UNKNOWN (Chinese Proverb).

(12)

(13) RESUMO Devido à grande demanda por softwares cada vez mais robustos, complexos e flex´ıveis, e, sobretudo, pelo curt´ıssimo tempo de entrega exigido, a engenharia de software tem procurado novos meios de desenvolvimento que supram satisfatoriamente essas demandas. Uma forma de galgar esses novos patamares de produtividade provém do uso de uma metodologia baseada em agentes que se comunicam e com isso, ao invés dos programas serem estritamente programados, o comportamento destes sistemas de software emerge da intera¸cão de agentes, robôs, ou subsistemas autônomos, independentes, além de declarativamente especificados. Isto provê a habilidade para automaticamente configurá-los, otimizá-los, monitorá-los, adaptá-los, diagnosticá-los, repará-los e protegê-los dentro do ambiente. Contudo, um grande problema das linguagens declarativas é a falta de mecanismos que permitem a melhor estrutura¸cão de dados, facilitando portanto, o reuso. Portanto, esta disserta¸cão explica o desenvolvimento de nova linguagem lógica declarativa para programar sistemas de racioc´ınio automático de uma forma modularizada: C2 HR∨ . A linguagem base escolhida para a extensão com componentes lógicos foi CHR. Os motivos para essa escolha são definidos ao longo da disserta¸cão. Duas abordagens, portanto, são apresentadas: a primeira, conhecida como CHRat, foi desenvolvida numa parceria juntamente com o grupo de pesquisas CONTRAINTES do INRIA/Rocquencourt-Paris, onde o programador é o responsável direto por definir os componentes CHR, permitindo o seu reuso por outros componentes; a segunda aplica¸cão, CHRtp , visa atender prioritariamente requisitos de completude e, por isso, se baseia em procedimentos lógicos de inferência como: o racioc´ınio para frente, o racioc´ınio para trás, e a resolu¸cão/factoring. A disserta¸cão mostra também alguns exemplos práticos, onde uso de componentes facilita radicalmente sua implementa¸cão. As contribui¸co˜es almejadas com essa disserta¸cão são: a defini¸cão de uma fam´ılia bem formalizada de provadores de teoremas automáticos, que podem trabalhar com senten¸cas especificadas em lógica horn ou em lógica de primeira ordem, a extensão de CHR como uma linguagem modular de propósito geral, a melhor estrutura¸cão de bases conhecimentos e até o uso em conjunto de bases heterogêneas, a defini¸cão de uma linguagem para a fácil e direta estrutura¸cão de dados por meio de componentes, dentre outras. Palavras-chave: Programa¸cão Lógica de Restri¸cões, Desenvolvimento Baseado em Componentes, Representa¸cão de Conhecimento, Provador de Teoremas. xiii.

(14)

(15) ABSTRACT Due to large demand for software increasingly robust, complex and flexible, and, by very short delivery time required, the software engineering has been devoted to finding new means of development that supply these demands satisfactorily. One way to climb these new levels of productivity comes from the use of an approach based on agents that communicate with themselves and, instead of the programs are strictly programmed, the behavior of these systems emerges from the interaction of autonomous, independent, and declaratively specified agents, robots, or subsystems. This provides them with the ability to automatically configure, optimize, track, adapt, diagnose, repair and protect within their environment. However, a problem of declaratively language is the lack of mechanisms that allow for better organization of data, thus facilitating the reuse. Hence, this dissertation explains the development of new logic declarative language for programming automated and modular automated reasoning system: C2 HR∨ . The language chosen for the basic components logical extension was CHR. The reasons for this choice are defined along the dissertation. Two approaches, therefore, are presented: the first, known as CHRat, was developed in partnership with the research group of INRIA CONTRAINTES/Rocquencourt-Paris, where the programmer is responsible for defining direct the CHR components, allowing its reuse by other components, the second application, CHRtp , primarily aims to meet requirements of completeness and therefore is based on procedures of logical inference as the forward chaining, the backward chaining and resolution/factoring. The dissertation shows also some practical examples where the use of components radically facilitates its implementation. Contributions desired with this dissertation are: the definition of a family of formalized automatic theorems provers, which can work with sentences specified either in logic horn or in first order logic, the extension of CHR as a modular general purpose language, the better structuring of knowledge bases and even the use together of heterogeneous databases, the definition of a language for easy and direct structuring of data by means of components, among others. Keywords: Constraint Logic Programming, Component-Based Developing, Knowledge Representation, Theorem Prover. xv.

(16)

(17) CONTENTS. Chapter 1—Introduction. 1. Chapter 2—Base Technologies. 1. 2.1. 2.2. 2.3. Meta-Object-Facility (MOF) . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 General Goals and Use in this dissertation . . . . . . . . . . . . . 2.1.2 Simplified meta-circular MOF metamodel in itself . . . . . . . . . The Fluent Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 General Goals and Use in this dissertation . . . . . . . . . . . . . 2.2.2 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 FC and Domain Sorts . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 FC and Domain Functions . . . . . . . . . . . . . . . . . . . . . . 2.2.5 FC and Domain Predicates . . . . . . . . . . . . . . . . . . . . . . 2.2.6 FC and Domain Abbreviations . . . . . . . . . . . . . . . . . . . 2.2.7 Foundational Axioms . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.8 A domain axiomatization in Fluent Calculus . . . . . . . . . . . . 2.2.8.1 Domain State Axioms . . . . . . . . . . . . . . . . . . . 2.2.8.2 Precondition Axioms . . . . . . . . . . . . . . . . . . . . 2.2.8.3 State Update Axiom . . . . . . . . . . . . . . . . . . . . 2.2.8.4 Ramification Axioms . . . . . . . . . . . . . . . . . . . . Constraint Handling Rules with Disjunctions (CHR∨ ) . . . . . . . . . . . 2.3.1 CHR∨ by Example . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Abstract Syntax of CHR∨ as a MOF Metamodel . . . . . . . . . . 2.3.3 Concrete Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 Declarative Semantics for Monotonic Applications in Classical FirstOrder Logic (CFOL) . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4.1 General Definition . . . . . . . . . . . . . . . . . . . . . 2.3.4.2 Illustration on Example . . . . . . . . . . . . . . . . . . 2.3.4.3 Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5 Operational Semantics of CHR∨ in Fluent Calculus . . . . . . . . 2.3.5.1 Theoretical Operational Semantics ωt∨ in the FC . . . . 2.3.5.1.1 Domain Sorts . . . . . . . . . . . . . . . . . . . 2.3.5.1.2 Predicates . . . . . . . . . . . . . . . . . . . . . 2.3.5.1.3 Functions . . . . . . . . . . . . . . . . . . . . . 2.3.5.1.4 Fluents . . . . . . . . . . . . . . . . . . . . . . xvii. 1 1 2 3 3 3 3 4 4 4 4 5 5 5 5 6 6 7 10 13 14 14 16 16 16 16 18 18 19 19 19.

(18) Component Assembly and Theorem Proving in Constraint Handling Rules 2.3.5.1.5 2.3.5.1.6 2.3.5.1.7. 2.4. Actions . . . . . . . . . . . . . . . . . . . . . . Axioms . . . . . . . . . . . . . . . . . . . . . . Example: Map Coloring Program Operational Semantics . . . . . . . . . . . . . . . . . . . . . 2.3.5.2 Detailed Operational Semantics of CHR∨ in the Fluent Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5.2.1 Sorts . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5.2.2 Predicates . . . . . . . . . . . . . . . . . . . . . 2.3.5.2.3 Functions . . . . . . . . . . . . . . . . . . . . . 2.3.5.2.4 Fluents . . . . . . . . . . . . . . . . . . . . . . 2.3.5.2.5 Actions . . . . . . . . . . . . . . . . . . . . . . 2.3.5.3 Axioms . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5.3.1 Initial State . . . . . . . . . . . . . . . . . . . . 2.3.5.3.2 Solve . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5.3.3 Activate . . . . . . . . . . . . . . . . . . . . . . 2.3.5.3.4 Reactivate . . . . . . . . . . . . . . . . . . . . . 2.3.5.3.5 Drop . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5.3.6 Default . . . . . . . . . . . . . . . . . . . . . . 2.3.5.3.7 Simplify . . . . . . . . . . . . . . . . . . . . . . 2.3.5.3.8 Propagate . . . . . . . . . . . . . . . . . . . . . 2.3.6 Automated Reasoning Services Supported by CHR∨ Engines . . . 2.3.7 Strengths of CHR∨ . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.8 Weaknesses of CHR∨ . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.9 Weaknesses Addressed by this dissertation . . . . . . . . . . . . . Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Definitions of Software Components . . . . . . . . . . . . . . . . . 2.4.2 Diversity of Software Components . . . . . . . . . . . . . . . . . . 2.4.3 The UML2 Component Model . . . . . . . . . . . . . . . . . . . . 2.4.3.1 The Basic UML 2.1 Component . . . . . . . . . . . . . . 2.4.3.2 Connector . . . . . . . . . . . . . . . . . . . . . . . . . .. Chapter 3—Theorem Proving in CHR∨ 3.1 3.2. 3.3. General Principles and Overview of Approaches . . . . . . . . . . . . . . Forward Chaining Horn CFOL Theorem Proving . . . . . . . . . . . . . 3.2.1 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Basic Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Illustrative Proof Example . . . . . . . . . . . . . . . . . . . . . . Forward Chaining Horn CFOL Theorem Proving in CHR∨ . . . . . . . . 3.3.1 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 The CHR∨ rule base to rewrite a HCFOL theorem proving problem into an equivalent CHR∨ constraint solving problem: CHR∨f c . . . 3.3.3 Illustrative Proof Example . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Benchmark experiments . . . . . . . . . . . . . . . . . . . . . . .. Cin-UFPE. Cleyton Rodrigues. 20 20 22 28 29 29 29 29 29 29 29 29 30 30 30 30 31 31 31 33 34 34 34 34 35 35 35 36 39 39 40 40 41 42 43 43 43 45 47 xviii.

(19) Component Assembly and Theorem Proving in Constraint Handling Rules. 3.4. 3.5. 3.6. 3.7. 3.3.5 Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.6 Limitations and Weaknesses . . . . . . . . . . . . . . . . . . . . . BackwardChaining Horn CFOL Theorem Proving . . . . . . . . . . . . . 3.4.1 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Basic Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 Illustrative Proof Example . . . . . . . . . . . . . . . . . . . . . . Backward Chaining Horn CFOL Theorem Proving in CHR∨ . . . . . . . 3.5.1 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 The CHR∨ rule base to rewrite a HCFOL theorem proving problem into an equivalent CHR∨ constraint solving problem . . . . . . . . 3.5.3 Illustrative Proof Example . . . . . . . . . . . . . . . . . . . . . . 3.5.4 Benchmark experiments . . . . . . . . . . . . . . . . . . . . . . . 3.5.5 Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.6 Limitations and Weaknesses . . . . . . . . . . . . . . . . . . . . . Resolution and Factoring Full CFOL Theorem Proving . . . . . . . . . . 3.6.1 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.2 Basic Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.3 Illustrative Proof Example . . . . . . . . . . . . . . . . . . . . . . Resolution and Factoring Full CFOL Theorem Proving in CHR∨ . . . . . 3.7.1 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.2 The CHR∨ rule base to rewrite a FCFOL theorem proving problem into an equivalent CHR∨ constraint solving problem . . . . . . . . 3.7.2.1 Implies() Operation: toSort . . . . . . . . . . . . . . . . 3.7.2.2 Implies() Operation: toFactor . . . . . . . . . . . . . . . 3.7.2.3 Implies() Operation: toResolve . . . . . . . . . . . . . . 3.7.2.4 CHR∨rf Improvement: Heuristics . . . . . . . . . . . . . 3.7.3 Illustrative Proof Example . . . . . . . . . . . . . . . . . . . . . . 3.7.4 Benchmark experiments . . . . . . . . . . . . . . . . . . . . . . . 3.7.5 Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.6 Limitations and Weaknesses . . . . . . . . . . . . . . . . . . . . .. Chapter 4—C2 HR∨ : Extending CHR∨ with Components and Deep Guards 4.1. 4.2. 4.3 4.4 4.5 4.6 4.7. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 The Framework of Concurrent Constraint Programming 4.1.2 CHRat: General Idea . . . . . . . . . . . . . . . . . . . . CHRat: Constraint Handling rules With Ask And Tell . . . . . 4.2.1 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Concrete Syntax . . . . . . . . . . . . . . . . . . . . . . The stratified ask method . . . . . . . . . . . . . . . . . . . . . CHRat and Disjunctive bodies . . . . . . . . . . . . . . . . . . . Program Transformation: CHRat 7→ CHR . . . . . . . . . . . . Parser Developed . . . . . . . . . . . . . . . . . . . . . . . . . . Operational Semantics . . . . . . . . . . . . . . . . . . . . . . .. Cin-UFPE. Cleyton Rodrigues. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. 48 49 49 49 50 50 51 51 51 52 53 55 55 55 55 56 57 58 58 58 59 59 61 62 63 64 64 65 67. . . . . . . . . . . .. . . . . . . . . . . .. 67 67 68 69 69 73 76 79 80 84 86 xix.

(20) Component Assembly and Theorem Proving in Constraint Handling Rules 4.7.1. 4.8. CHRat operational Semantis in Fluent Calculus . . 4.7.1.0.1 Domain Sorts: . . . . . . . . . . . 4.7.1.0.2 Syntactic Sugar for Domain Sorts 4.7.1.0.3 Fluents . . . . . . . . . . . . . . 4.7.1.0.4 Functions . . . . . . . . . . . . . 4.7.1.0.5 Actions . . . . . . . . . . . . . . Classical Examples . . . . . . . . . . . . . . . . . . . . . . 4.8.1 Max Component . . . . . . . . . . . . . . . . . . . 4.8.2 Prime Component . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. Chapter 5—Case Study: Family Component Assembly 5.1. Family Problem . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Family Problem: Overview . . . . . . . . . . . . . . 5.1.2 The family problem according to CHRat approach . 5.1.3 The family problem according to CHRtp approach .. 93 . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. Chapter 6—Related Work 6.1. 6.2. 93 93 98 108 111. Related in Work in CFOL Theorem Proving . . . . . . . . . . . . . . . . 111 6.1.1 Forward Chaining and Backward Chaining for Horn CFOL Theorem Provers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 6.1.1.1 OTTER . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 6.1.1.2 Final consideration: Other logic types and real applications112 6.1.2 Refutation Theorem Provers for Full FOL . . . . . . . . . . . . . 112 6.1.2.1 SATCHMO . . . . . . . . . . . . . . . . . . . . . . . . . 112 6.1.2.2 PTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 6.1.2.3 SIMPLIFY . . . . . . . . . . . . . . . . . . . . . . . . . 115 Related Work in Rule Bases, Logic Programs and Constraint Program Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6.2.0.4 Extending Arbitrary Solvers with Constraint Handling Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.2.0.5 Schrijvers et al. CHR implication . . . . . . . . . . . . . 117 6.2.0.6 Abdnennadher and Fruehwirth CHR base integration . . 118 6.2.1 Components and Rule-Based Languages . . . . . . . . . . . . . . 119 6.2.1.1 Modular Rule-Based Programming . . . . . . . . . . . . 119 6.2.1.2 Adaptable Component Model . . . . . . . . . . . . . . . 119 6.2.1.3 The ReServCom Approach . . . . . . . . . . . . . . . . . 120 6.2.2 Components in Logic Programming . . . . . . . . . . . . . . . . . 120 6.2.3 Components in Constraint Solving . . . . . . . . . . . . . . . . . 120. Chapter 7—Contributions 7.1 7.2. 88 88 88 88 88 89 90 90 91. 123. Contributions to Automated Reasoning and Theorem Proving . . . . . . Contributions to Constraint Programming . . . . . . . . . . . . . . . . .. Cin-UFPE. Cleyton Rodrigues. 123 123 xx.

(21) Component Assembly and Theorem Proving in Constraint Handling Rules 7.3. Contributions to Rule-Based Knowledge Representation . . . . . . . . . .. Chapter 8—Conclusion and Future Work Nomenclature. 124 125 134. Appendix A—CHR∨ Rules to Convert horn FOL clauses into CHR∨ Rules for Forward Chaining 135 Appendix B—CHR∨ Rules to Convert horn FOL clauses into CHR∨ Rules for Backward Chaining 139 Appendix C—CHR∨ Rules to Convert full FOL clauses into CHR∨ Rules for Resolution/Factoring 145 Appendix D—CHR∨ program perfoming Resolution/Factoring. 149. Appendix E—Auxiliary Prolog Lybraries. 155. Appendix F—Problems and Puzzles. 157. Appendix G—CHRat Components and the correspondent CHR∨ Version. 161. Cin-UFPE. xxi. Cleyton Rodrigues.

(22)

(23) LIST OF FIGURES. 1.1. AR/KR Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11. The 4-level Architecture of MDE . . . . . . . MOF Simplified Metamodel in itself . . . . . . General View of the abstract syntax of CHR∨ Atom Package . . . . . . . . . . . . . . . . . . Formula Package . . . . . . . . . . . . . . . . Program Package . . . . . . . . . . . . . . . . Concrete Syntax of CHR∨ in BNF . . . . . . . The metaclass for the component package . . The general view of a UML Component . . . . The external view and the internal view . . . The Connector class Structure . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. 2 2 10 11 11 12 15 35 36 37 37. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9. Frog/Canary Foward Chaining example . . . . . . The West Problem in English notation . . . . . . The West Problem in CNF notation . . . . . . . . The West Problem in Forward chaining notation . Frog x Canary example by Backward Chaining . . The West Problem in Backward chaining notation Frog/Canary example in CNF . . . . . . . . . . . Frog x Canary example by Resolution . . . . . . . CNF notation for Tuna’s Problem . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 42 45 45 46 51 52 57 57 63. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12. Component Architecture . . . . . . . . . . . . . . . . . . . . . General view . . . . . . . . . . . . . . . . . . . . . . . . . . . Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The pedagogical CHRat constraint solver for ordering relations Rules to hold the entailment checking . . . . . . . . . . . . . . The CHRat min component. . . . . . . . . . . . . . . . . . . . Concrete Syntax of C2 HR∨ in BNF . . . . . . . . . . . . . . . Thace of execution for leq/2, min/3 CHRat components. . . . Screenshoot of the CHRat Compiler. . . . . . . . . . . . . . . The CHRat max component. . . . . . . . . . . . . . . . . . . . The CHRat prime component. . . . . . . . . . . . . . . . . . . The CHRat gemini component. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. 69 69 70 74 74 75 78 83 86 90 91 91. 5.1. Parent, Gender, Sibling, MotherFather and BrotherSister Components . .. 94. xxiii. . . . . . . . . . . .. 2.

(24) Component Assembly and Theorem Proving in Constraint Handling Rules 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20. WeddedDivorced, Date and BornDna Components . . . . . . . . . . . . . Twin, TwinGender, TwinIdenticalFraternal Components . . . . . . . . . GrandParent and GrandParentGender Components . . . . . . . . . . . . StepParent Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . ParentInLaw, MotherFatherInLaw and BrotherSisterInLaw Components . AuntUncle Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . Knowledge Facts for the Family problem . . . . . . . . . . . . . . . . . . CHRat Parent Component . . . . . . . . . . . . . . . . . . . . . . . . . . CHRat Gender Component . . . . . . . . . . . . . . . . . . . . . . . . . CHRat Sibling Component . . . . . . . . . . . . . . . . . . . . . . . . . . Flat transformation into different rules . . . . . . . . . . . . . . . . . . . Flat transformation to a unique rule . . . . . . . . . . . . . . . . . . . . MotherFather Component . . . . . . . . . . . . . . . . . . . . . . . . . . Renaming ask rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Date Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Valid Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CHRtp Sibling Component . . . . . . . . . . . . . . . . . . . . . . . . . . CHRtp BrotherSister Component . . . . . . . . . . . . . . . . . . . . . . CHRtp WeddedDivorced Component . . . . . . . . . . . . . . . . . . . .. 95 96 97 98 99 100 100 101 101 102 103 104 105 106 107 108 109 109 110. 8.1. General view of CHR∨ extensions . . . . . . . . . . . . . . . . . . . . . .. 127. Cin-UFPE. Cleyton Rodrigues. xxiv.

(25) LIST OF TABLES. 3.1 3.2 3.3. Results for the foward chaining prover . . . . . . . . . . . . . . . . . . . Results for the backward chaining prover . . . . . . . . . . . . . . . . . . Results for the resolution/factoring prover . . . . . . . . . . . . . . . . .. 48 53 64. 4.1. Results of the parsing for some Classical CHRat Components . . . . . . .. 87. 6.1 6.2 6.3. Comparison: Satchmo x CHRtp . . . . . . . . . . . . . . . . . . . . . . . Comparison: PTTP x CHR∨ . . . . . . . . . . . . . . . . . . . . . . . . . CHR rules transformation to maintain changes of the store . . . . . . . .. 113 115 118. xxv.

(26)

(27) LIST OF ALGORITHMS 1 2 3 4 5 6 7 8. Forward Chaining Algorithm . . . . . . . . . . CHR∨f c Result Test . . . . . . . . . . . . . . . Resolution inference engine . . . . . . . . . . . Backward Chaining Algorithm . . . . . . . . . Resolution Algorithm . . . . . . . . . . . . . . Factoring Algorithm . . . . . . . . . . . . . . Pseudo-Code for the CHRat 7→ CHR∨ Parser OTTER main while . . . . . . . . . . . . . . .. xxvii. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 41 45 49 50 56 60 85 111.

(28)

(29) ACRONYMS. ACM AOM AOSE AR BICS CBDS CBSE CFOL C2 HR∨ CHR CHRat CHROME CHR∨ CLP CNF COST COM CORBA FC Flux GUI HCFOL INRIA JTP KB MDA MDE ME MOF OCL OMG OO ORCAS. Adaptable Component Model Adaptive object-model Agent-Oriented Analysis and Design Automated Reasoning Built-in Constraint Store Component-Based Development System Component-Based Software Engineering Classical First Order Logic Component Constraint Handling Rules Constraint Handling Rules Constraint Handling Rules with Ask And Tell Constraints Handling Rules On line Model-driven Engine Constraint Handling Rules with Disjunction Constraint Logic Programming Conjunctive Normal Form Commercial-Of-The Shelf Component Object Model Common Object Request Broker Architecture Fluent Calculus Fluent Calculus Executor Guide User Interface HORN Classical First Order Logic Institute Nationale de Recherche en Informatique et Automatique Java Theorem Prover Knowledge Base Model Driven Architecture Model Driven Engineering Model Elimination Meta-Object Facility Object Constraint Language Object Management Group Object Oriented Off-the-Shelf Reasoning Components for Autonomic Systems xxix.

(30) Component Assembly and Theorem Proving in Constraint Handling Rules OTTER PTTP SATCHMO TP UDCS UML. Cin-UFPE. Organized Techniques for Theorem-proving and Effective Research Prolog Technology Theorem Prover SATisfiability CHecking by MOdel generation Theorem Prover User Defined Constraint Store Unified Modeling Language. Cleyton Rodrigues. xxx.

(31) CHAPTER 1. INTRODUCTION ′′. The best thing for being sad,′′ replied Merlin, beginning to puff and. blow, ′′ is to learn something. That’s the only thing that never fails. You may grow old and trembling in your anatomies, you may lie awake at night listening to the disorder of your veins, you may miss your only love, you may see the world about you devastated by evil lunatics, or know your honour trampled in the sewers of baser minds. There is only one thing for it then to learn. Learn why the world wags and what wags it. That is the only thing which the mind can never exhaust, never alienate, never be tortured by, never fear or distrust, and never dream of regretting. Learning is the only thing for you. Look what a lot of things there are to learn.′′ —T.H. WHITE (The Once and Future King). The market software evolution has recently reached levels never before achieved. With the growing demand for more efficient, safeness, complete, robust, easy to use and flexible software, but also with the speed of the delivery being directed by the curve of time-to-market [Mel99], the field of Software Engineering felt the increasing need to seek alternatives to develop these new applications. Due to significant competition from companies of software, it is known that the property of time-to-market is extremely strict, since delays affect the lookup of the company, causing the massively loss of customers. However, by delivering products of low quality and inflexible, but in a quickest way is not, obviously, the way to below estimates and meet deadlines. Indeed, the maintenance of systems and the re engineering of software is one of the most loss-time for development teams currently. Another aggravating factor is based on the fact that the complexity and size of the required systems has increased drastically, and many are critical for real-time and, above all, by the fact that the need and the environment in which the product works, is subject to constant changes. Over the past decades, much has been said and done in terms of structured software development, namely object oriented. The main feature of these systems is based on the reuse of previously developed artifacts. However, much of what were promised was not met solely by the object-oriented (O.O.) approach. In this scenario, then, emerges the paradigm of component-based programming. This new paradigm allows the internalization of specific functionality within modules formally established (black-box), where it is not necessary to know the content of these components to interact with them. Actually, no matter if its implementation is based on Java, C, C++, C#,..., or any other imperative, object-oriented language, or even if it was done using a declarative one, as Haskell. Rather, these units of deployment are interface-centric in the sense that, to assembly 1.

(32) Component Assembly and Theorem Proving in Constraint Handling Rules components and make them cooperate, the task comes down to an application of typed plug-and-play. By typed means that the one which ask a service and the other which provides it, need to be in conformance with respect the interfaces. More recently, however, many researches still geared to speed up the delivery time, but also concerned with the efficiency of the software, reached a new trend of development known as Agent-Based System (Multi-Agents Based System) [CW00]. In this paradigm (if we can call it like that), the program’s information is abstracted within one or more agents that communicate with each other (interacting) to seek solutions. Thus, instead of being strictly programmed, the behavior of these software systems emerges from the interaction of these autonomous, independently and declaratively specified cognitive agents, robots or subsystems. This provides them with the ability to automatically configure, optimize, monitor, adapt, diagnose, repair and protect themselves in their environment. These agents therefore are characterized due an automated behavior and for the interaction with each other, not only through the knowledge they hold, but also with the environment around them. This communication is achieved by standardization of the representation of knowledge involved and the non-ambiguity of knowledge itself.. Figure 1.1 AR/KR Roadmap. Any inference engine built for automated reasoning is defined in terms of three orthogonal views, outlined in accordance with the axes in the tri-dimensional region represented by figure 1.1. An inference engine, initially, is designed to one (or more) specific purposes, like: constraint solving, entailment, belief update, belief revision, abduction and so on. Therefore, this first vision defines the reasoning task of the engine. Then, in a second dimension, according to an ontological assumption, it is defined what types of logic languages with the engine can reason: Propositional Logic, First-order Logic (specialized in Object oriented or Relational) or high-order Logic (also, O.O. or relational). Finally, in a Epistemological Commitment, a knowledge representation language can be described in a boolean logic system (in a closed-world or open-world assumption), also, with a ternary Cin-UFPE. Cleyton Rodrigues. 2.

(33) Component Assembly and Theorem Proving in Constraint Handling Rules logic system, or even with the probabilistic or plausibilistic logical system. As shown in the same figure, we see some languages, such as Constraint Handling Rules with disjunction (CHR∨ ) [AS98] which is a declarative language originally defined for constraint solving, optimization and for satisfiability problems proofs, using either the propositional logic or FOL relational. Also note that many of the engines created for a certain reasoning task (Ontology Web Language [Lac05] for object classification, Semantic Web Service Language [BBB+ 05] for default reasoning and so on), extends CHR∨ . Thus, in the same sense, our engine of reasoning focuses on the task of entailment, and it also uses CHR∨ as the basis for this purpose. This figure generally defines not only an overview of recent advances in the field of automated reasoning and representation of knowledge, but also highlights some of the reasons why CHR∨ was chosen as the basis for the search. In this context, emerges the ORCAS project. This project aims to make crossdisciplinary scientific, technological and methodological breakthroughs to lower the cost and time-to-market involved in engineering multi-agent and autonomic systems, while simultaneously improving their reliability and reusability and widening their applicability. To reach its aim, ORCAS will deeply unify and extend a set of largely mismatching and non-interoperable yet complementary, cutting-edge languages, tools and processes from formal, model-driven, component-based and agent-oriented software engineering as well as from object-oriented, rule-based, constraint and logic programming. It will deliver the first ever unified framework to support the fast prototyping of robust, highly reusable, cognitive agents that correctly reason and effectively interact in environments that are simultaneously partially observable, ramifying, noisy, non-deterministic, concurrent, realtime, ontologically complex, cooperative and competitive. The desirable framework, namely C2 HORDATE, will then, provide methods, tools and components which permit the deployment of faster and cheaper applications based on Automated Reasoning services. Further, it will enable the modeling of autonomous agent societies and software service orchestrations. The deployment of this framework will be done with some parallel extension from its kernel: the CHROME, where each extension will adopt one of its features, like: the component-based assembly, the object oriented inheritance, a Guide User Interface (GUI) mechanism, and so on. Inside this project, my dissertation focuses in the extension of the rule-based constraints programming language CHR∨ with the assembly of component bases: C2 HR∨ . CHR∨ builds rewriting programs which solve constraints defined by the user. As a general language, CHR∨ subsumes three main rule-based paradigms: (i) Conditional rewrite rules (i.e., d1 , d2 <=> g1 , g2 |b1 , b2 ., where d1 and d2 are rewrite into b1 , b2 , once g1 and g2 is verified); (ii) Event-Condition-Action rules (i.e., k1 , k2 \d1 , d2 <=> g1 , g2 |b1 , b2 ); (iii) Constraint Logic programming rules (i.e., d1 <=> (b1 , b2 ); (b3 , b4 ) leading to efficient search strategies). The projects’ motivation for using CHR∨ relies also upon its flexibility: an inference engine for this language can implement the following reasoning services: deduction, abduction, belief update and constraint solving. Throughout the development of this dissertation, there was also that CHR could be used as a new feature not yet seen before and that, fortunately, marry with the primary objective of this work which is the formal syntactically and semantically definition of Cin-UFPE. Cleyton Rodrigues. 3.

(34) Component Assembly and Theorem Proving in Constraint Handling Rules C2 HR∨ : CHR∨ as a theorem prover. In fact, by propagating additional constraints or rewriting them into another set of predicates, turns CHR∨ capable of reason forwarding or backwarding, respectively, with horn clauses. Not so directly, however, the computational power of CHR also allows the development of solvers able to combine the restrictions in accordance with the pair Resolution/Factoring logical inference procedure. Consequently, CHR∨ integrates the power of draw complete and sound logical proofs for first-order logical sentences. Therefore, the dissertation can be broken into two main parts. The first one focuses on a new discipline of programming, designed to develop component CHR∨ solver, called CHRat. This approach was proposed during my stage of six months at INRIA and was developed with the co-partners from this institution. Overall, each CHRat program is a component with its well-defined interface, based on the import and export declaration, where it lists the constraints required and provided, respectively. CHRat, thus, proposes an extensibility of the Concurrent Constraint Programming Paradigm, once it enables user defined required constraints within guard and body rules. Actually, besides the host platform with the well-defined Constraint System, a component solvers is deployed also over another CHR base. Additionally, I will depict out a transformation guide to convert an assembly of N-CHRat components into a unique CHR∨ file that can be compiled in any current CHR implementation, as SWI-Prolog. Furthermore, it is worth to notice that C2 HR∨ concerns only the component assembly requirement of ORCAS project. Another branch of the research of this project aims to extend CHR∨ with the object-oriented framework (Aurelios’ Master dissertation extension CHORD), for future integration. This demonstrates the need to have C2 HR∨ formally defined: its abstract syntax is modeled in MOF standard design and its operational semantics is depicted out based on the Flux axiomatization. Alternatively, the dissertation proposes some transformation techniques which aim to transform a set of logical horn or full first-order logical sentences into CHR∨ rules and predicates, to reason with them and infer some proof calculus in order to answer about entailment of queries. Visually, the trace provided by the CHR implementation concerns the proof history. Entailment is nothing more than the test conducted by the method ask inside the framework of Concurrent Constraint Programming. Hence, the point is: a CHR∨ program might have user-defined constraints within a guard rule and the entailment checking can,thus, be performed by any of the previous inference procedure mentioned. As the completeness of CHRat relies entirely upon the ability of the programmer, this new approaches emerges as an alternative that can be used either alone or even as an extra test in conjunction with CHRat. In order to validate the proposed methodologies, first some case studies of benchmarking problems existing on the Internet are validated, aimed to test the automatic theorem provers. These tests will be important to carry out a comparison between the family of logical inference procedures provided, comparing them in terms of time, the search space, and especially completeness. Going further, I intend to investigate a more complex example with server and clients bases, to deal with rules to define family relationships, as father, mother, children (twins or not), uncles, aunts, ancestral, married, separated, and so on. The latter will be discussed by the two alternatives. Cin-UFPE. Cleyton Rodrigues. 4.

(35) Component Assembly and Theorem Proving in Constraint Handling Rules The dissertation is organized as follows: chapter 2 starts defining the base technologies used throughout the dissertation, namely, MOF, Fluent Calculus (and its implementation Flux), CHR (and specially, CHR∨ ) and the superstructure of the components modeling defined by UML 2.1; following, in chapter 3, I give an overview about what is and what for a theorem prover, highlighting, then, the forward chaining, backward chaining, and resolution/factoring, as well as the main contributions of this research project, which is how CHR∨ subsumes these sorts of reasoning. Some strategies of search (heuristics) will also be presented, showing how it solves problems and speed up the proof calculus. Chapter 4 focuses on showing the techniques developed during this academic master to extend CHR∨ with assembly of components. I start up investigating the framework of Concurrent Constraint Programming and then show how the methodologies implements the method ask of this framework. Chapter 5, in turn, focuses on a specific case study: the problem of family relationships. The related theorem proving (in fact, only those most recent and widely used, since each year a dozen of new theorem provers are developed in the academic world) as well as the yet cross-disciplinary use of Constraint Programming and Component development are addressed in chapter 6. Chapter 7 aims to explore the contributions of this dissertation with respect the Automated Reasoning, the Constraint Programming and the Knowledge Representation. I finalize with some conclusions and point out the future works which will be conducted in the Ph.D. project. The section of annexes lists the source-code of the implementations.. Cin-UFPE. Cleyton Rodrigues. 5.

(36)

(37) CHAPTER 2. BASE TECHNOLOGIES I have never met a man so ignorant that I couldn’t learn something from him. —GALILEO GALILEI. 2.1 2.1.1. META-OBJECT-FACILITY (MOF) General Goals and Use in this dissertation. A modeling language can be defined by a pair of specifications: the abstract syntax (defining its main high-level entities) and the concrete syntax (defining their realizations by the means of characters or graphical symbols and drawings). A metamodel is a model of the abstract syntax of a language. It focuses on the concepts and on the relationships among them. Thus, it plays the role of a grammar but in a more abstract level. The Meta-Object Facility (MOF) [Mof08] is an abstract language for defining modeling languages. It was created by the Object Management Group (OMG) in the context of Model Driven Architecture (MDA) [Mda08], which main objective is to organize the work thread as a pipeline of models that goes on by the means of model transformations. In this context, MOF is the unified modeling language defining the abstract syntax of all modeling languages in this process. It will provide a standard way to create, query and update models. Indeed, MOF corresponds to the metaformalism used by the OMG consortium inside the Model Driven Engineering (MDE) architecture. MDE, thus, proposes essentially to raise the level of abstraction where most of the development effort is spent from source code to models, meta-models and model transformations. MDE defines also three levels of abstractions (figure 2.1) regarding model formalisms: the model, the formalism for modeling (metamodel) and the metaformalism and a fourth one to represent the instance. MOF expresses itself as a metametamodel (M3). Also, MOF reuses at another level and for another purpose the UML class diagram. Whereas in UML these diagrams at level M1 are used to model the application, MOF uses these diagrams at level M2 and M3 to model languages. In this dissertation, MOF will be used as the metamodeling tool for the C2 HR∨ language. The benefits of this utilization are twofold: on the one side, during its design, we are going to concentrate on the abstract elements of the language, instead of the crude items in its syntax; on the other side, our language will be ready to be used in a MDA pipeline as well as in the ORCAS framework. 1.

(38) Component Assembly and Theorem Proving in Constraint Handling Rules. MOF Metamodel. Metamodel. Model. M3 - MOF Level. M2 - Metamodel Level. Metamodel. Model. i1:C1. Model. i2:C2. M1 - Model Level. M0 - Application Level. Figure 2.1 The 4-level Architecture of MDE. Operation +ownedOperation *. Class isAbstract : boolean. +ownedAttribute *. *. Property. +memberEnd 2..*. Association. +superclass. Figure 2.2 MOF Simplified Metamodel in itself. 2.1.2. Simplified meta-circular MOF metamodel in itself. The Figure 2.2 describes the main abstract entities of a MOF metamodel. It is formed by a set of class definitions (metaclass Class) which can be abstract or concrete (meta-attribute isAbstract). A class also can have an unlimited number of superclasses (meta-association superclass). The operations and properties of a class are respectively described by the Operation and Property metaclasses. The associations (metaclass Association) define relationships between two or more classes by the means of their properties. Cin-UFPE. Cleyton Rodrigues. 2.

(39) Component Assembly and Theorem Proving in Constraint Handling Rules 2.2 2.2.1. THE FLUENT CALCULUS General Goals and Use in this dissertation. Fluent Calculus [Thi00] is an axiomatization in Sorted Second Order Logic which accounts for a great variety of monotonic and non-monotonic reasoning tasks. It was initially proposed as a specification language and system for solving the intrinsic difficulties faced in the cognitive robots area, such as uncertainty, non-determinism, ramifications and concurrency. In this dissertation, we are going to use the Fluent Calculus in order to define the semantics for C2 HR∨ . On the one side, it will provide a more precise and still high level framework for reasoning about programs in the language while on the other side, it will allow us to create a prototypical execution engine for it. This will be possible by the means of the FLUX (Fluent Calculus Executor) library which allow Fluent Calculus specifications to be translated into Prolog and CHR code. 2.2.2. Principles. The Fluent Calculus is formally a Sorted Second Order Logic with equality, employing the standard logical connectives: “¬” (negation), “∧” (conjunction), “∨” (disjunction), “⊃” (implication), “≡” (equivalence), “∀” (universal quantification) and “∃” (existential quantification). The concept of sorts play the role of types for variables, functions and predicates; in the sense that variables, functions and predicates can only be associated or applied to elements of the right sorts. Sorts are commonly supposed to be disjoint, when this is not the case, we indicate it by the notation A < B, indicating that the sort A is a subsort of the sort B, i.e., every element of the sort A is an element of the sort B. We use this language to build a domain axiomatization, which contains; aside from the reserved sorts, predicates, functions and axioms; a set of domain specific sorts, predicates and functions. These axiomatizations are used to reason about the domain. The three basic reasoning use cases are: prediction (when we try to predict the outcome of our actions); explaining (when we try to explain our observations) and planning (when we try to construct a plan in order to achieve a certain goal). At the following sections, we are going to show the reserved elements of a fluent calculus domain axiomatization. 2.2.3. FC and Domain Sorts. Fluent Calculus defines the built-in sorts FLUENT, STATE, ACTION and SIT. A FLUENT is an atomic dynamic property of the world, e.g., the position or the velocity of an object. A STATE is a composition of fluents. An ACTION is executed by the agent and changes the state of the world (some fluents in it). A situation (SIT) is the historic of action performances. The FLUENT and STATE sorts are not disjoint, in fact, the former is a subsort of STATE, in the sense that every FLUENT is formally an atomic STATE and each STATE can be decomposed into a set of FLUENTs. Cin-UFPE. Cleyton Rodrigues. 3.

(40) Component Assembly and Theorem Proving in Constraint Handling Rules 2.2.4. FC and Domain Functions. States are composed by the predefined binary function ◦ : ST AT E×ST AT E 7→ ST AT E, for example, the state a◦b is composed by the fluents a and b. The function ∅ :7→ ST AT E defines the empty state, i.e., the state composed by no FLUENTs. The function Do : ACT ION ×SIT 7→ SIT maps a situation in the obtained situation after executing some action. The function State : SIT 7→ ST AT E maps a situation (SIT) into its current STATE. 2.2.5. FC and Domain Predicates. The reserved predicate P oss : ACT ION × ST AT E holds for the ACTIONS which are executable (possible) in a given STATE. 2.2.6. FC and Domain Abbreviations. The following abbreviations are utilized in Fluent Calculus specifications: def. Holds(f, z) = (∃z ′ )z = f ◦ z ′ def. Holds(f, s) = Holds(f, State(s)) def. P oss(a, s) = P oss(a, State(s)) def. z − f = z ′ = ¬Holds(f, z ′ ) ∧ [z ′ ◦ f = z ∨ z ′ = z] The first Eq. defines the predicate Holds : F LU EN T ×ST AT E from the predicate ◦. Holds(f, z) is true if there is a state z ′ where the state z is the composition of the fluent f and z ′ . The second one and third, in turn, make it possible to use the predicates Holds and P oss with situations apart from states. Thus, in the second case, a fluent f is true in a situation s, if it is true in the state mapped from s, namely, State(s). In the same sense, an action a is possible to fire in a situation s, if it is possible in the state indicated by s. Finally, the last Eq. defines the function − : ST AT E ◦ F LU EN T 7→ ST AT E which allows removing fluents from a given state. Removing f from z leads to a new state z ′ , where the fluent is no more true (¬Holds(f, z ′ )) and we have to consider also two exclusive clauses: (i) that f was really inside the original state or (ii) that f was not a component of z, and thus, z = z ′ . 2.2.7. Foundational Axioms. The following axioms are part of every Fluent Calculus Axiomatization and they define the semantics of the defined predicates and functions: (z1 ◦ z2 ) ◦ z3 = z1 ◦ (z2 ◦ z3 ) z1 ◦ z2 = z2 ◦ z1 Cin-UFPE. Cleyton Rodrigues. 4.

(41) Component Assembly and Theorem Proving in Constraint Handling Rules. z◦z =z z◦∅=z Holds(f, f1 ◦ z) ⊃ f = f1 ∨ Holds(f, z) The first four equations conceive, respectively, the algebraic properties of associativity, commutativity, idempotency and unit element. Further, the last one states the decomposition axiom which relates equality of fluents. 2.2.8. A domain axiomatization in Fluent Calculus. A domain axiomatization in Fluent Calculus is formed by a set of state constraints, an action precondition axiom for each domain action symbol, state update axioms and the foundational axioms and further domain specific axioms. It defines the semantics of the predicates that were not defined by the foundational axioms. 2.2.8.1 Domain State Axioms These axioms define state constraints and they are commonly used to define invariants of the system. Only two kinds of atoms are allowed in these formulas: Holds(φ, z) and domain specific predicates. 2.2.8.2 Precondition Axioms A Precondition Axiom defines the conditions that must hold in order to the agent be able to execute one given action. This kind of axiom has the following general form: P oss(A(~x), z) ≡ ΠA (~x, z) It means that the execution of the action A with the parameters ~(x) is possible in the state z iff ΠA (~x, z) is true. 2.2.8.3 State Update Axiom State Update Axioms define how the execution of the actions change the world state. They follow the general form: P oss(A(~x), s) ∧ ∆(~x, State(s)) ⊃ State(Do(A(~x), s)) = State(s) ◦ V + − V − It means that if the action A can be executed with the parameters ~x and it is executed, than the final state will be the initial one, removing a set V − of fluents, the negative effects, and adding another set V + , the positive effects. Furthermore, ∆ is a sub-formula with additional conditions. For clarity, follows a simple example. It was extracted from the operational semantics in FC of CHRat, detailed in chapter 4. Now, we only care about the syntax of the axiom because its semantics is explored in the chapter about CHRat. Cin-UFPE. Cleyton Rodrigues. 5.

(42) Component Assembly and Theorem Proving in Constraint Handling Rules. P oss(Ask(r@hk \hr ⇔ g|d, u1 , u2 , t), State(s)) ◦ Holds(U dcs(u1 ⊎ u2 ⊎ u), State(s)) ◦ Holds(Goal(q), State(s)) ◦ Holds(Existencial(x), State(s)) ◦ Holds(V arCons(l), State(s)) ⊃ State(Do(Ask(r@hk \hr ⇔ g|d, u1 , u2 , t), s)) = State(s) ◦ Goal(q ⊎ {ask(t, K)} ⊎ {ex} ⊎ {idR}) ◦ InP ropHistory(id(u1 ), id(u2 ), r) − Goal(q), where ex = makeConstraintEq(x, K) ∧ idR = makeConstraintId(r, x, K). Note that in addition to the axiom of pre-condition for firing the ask transitive step, there is a number of additional conditions. The direct consequences of expressing these conditions outside of pre-condition stems from the fact that we can work with those conditions to evidence the changes after the execution of the action. Thus, one can more clearly represent the new fluents added and those no longer true, and therefore which were removed from the state. 2.2.8.4 Ramification Axioms Ramifications allow the separation between the direct effects of an action and their indirect effects. This is done by defining a new predicate, Causes : ST AT E × ST AT E × ST AT E × ST AT E × ST AT E × ST AT E. The instance, − + − + − Cause(z1 , e+ 1 , e1 , z2 , e2 , e2 ), means that adding e1 and removing e1 from z1 , leads to the − state z2 , result of the positive effects e+ 2 and negative effects e2 . 2.3. CONSTRAINT HANDLING RULES WITH DISJUNCTIONS (CHR∨ ). CHR (Constraint Handling Rules [Fru98]) emerges in the context of the Constraint Logic Programming (CLP) as a language for describing Constraint Solvers. In CLP, a problem is stated as a set of constraints, a set of predicates and a set of logical rules. Problems in CLP are generally solved by the interaction of a logical inference engine and constraint solving components. The logical rules (written in a host language) are interpreted by the logical inference engine and the constraint solving tasks are delegated to the constraint solvers. For example, let’s assume that the logic programming language is Prolog, and we have the following logical rule: balance(ac, 100). closedAccount(C) :- balance(C,B), B < 0. In this case, let’s suppose closedAccount(X) and balance(C,B) are predicates and X<Y is a constraint. Let’s suppose we provide the following goal to the Prolog engine: closedAccount(ac) In this case, the Prolog engine will expand this goal to the following set of goals: Cin-UFPE. Cleyton Rodrigues. 6.

(43) Component Assembly and Theorem Proving in Constraint Handling Rules balance(ac, B), B < 0 It will then expand the first goal and then instantiate B as 100. The list of goals will be: 100 < 0 Since this goal is composed by constraints the Prolog inference engine will delegate its execution to the internal Constraint Solver, which will rewrite it to: fail These internal solvers are commonly black boxes provided along with the logical inference engines. They are often written in very low level languages and are very integrated to the logical inference engine they are bundled into. These characteristics certainly improve their overall performance but reduce their extensibility and modifiability. In this context, CHR allows the definition of constraint solvers which are at the same time very efficient and are described in a very high level language. The following CHR rules describe the solver for the X<Y constraint utilized in the previous example: X<X ==> false. X<Y, Y<X ==> false. X<Y, Y<Z ==> X<Z. The CHR rules are interpreted by a CHR inference engine, rewriting the initial set of constraints by the means of the iterative application of the rules. Some of its characteristics, such as committed choices and rule matching1 allow these engines very good performance results. CHR∨ [AS98] extends CHR with disjunctions in the rule bodies. This extension boosts its expressiveness power, turning CHR∨ in a general programming language (with no need of an host language). 2.3.1. CHR∨ by Example. The following rule base is a CHR∨ program that handles the graph coloring problem. In this problem, we want to assign colors from finite domain (which can vary from one node to another) in such way that no adjacent nodes receive the same color. r1 @ indomain(X,[]) <=> false. r2 @ indomain(X,[C|R]) <=> X = C ; indomain(X,R). r3 @ connected(X,Y) <=> X != Y. 1 It is only possible instantiate variables from the head of the rule to match it with some part of the goal.. Cin-UFPE. Cleyton Rodrigues. 7.

(44) Component Assembly and Theorem Proving in Constraint Handling Rules In CHR∨ there are two kinds of constraints: the user defined and the built-ins. The first set is formed by the constraints whose semantics is given by the set of rules and the second set is formed by the constraints whose semantics is provided by the inference engine. In this program we have two user defined constraints and two built-ins. The user defined are: connected(X,Y) and indomain(X,D) and the built-ins are: X=Y, X!=Y and false. The CHR∨ constraint connected(X,Y) means that the node X and the node Y are adjacent and can’t thus receive the same colors (this is enforced by the rule r3). The constraint indomain(X,D) means that the color of the node X must be in the list represented by D. The constraint X=Y means the usual mathematical equality between two terms and X!=Y is the opposite relation (inequality). false is the constraint that is always inconsistent. Every rule in CHR∨ have an optional identifier, a head, a guard and a body. The identifier is the part before the @ sign. The head, in this case, is the set of constraints between the @ and the <=> signs. The guard is omitted in all this cases and the body is the set of constraints after the <=> sign. Form more details about the syntax of CHR∨ rules, refer to the section 2.3.3. In this program, the rule r1 states that if the domain of some node is empty no coloring is possible. The rule r2 states that the color of a node must be one of the colors in its domain. In order to execute a CHR∨ program we must provide an initial set of constraints (called goal ). The inference engine will iteratively apply the rules in the program rule base until no rule is applicable or the current set of constraints becomes inconsistent. The set of constraints is called Constraint Store. Every time no rule is applicable, the inference engine backtracks to the last disjunctive rule applied. This is a very important characteristic of CHR∨ w.r.t CHR: even if both are a committed choice language (in the sense that any rule choice is committed, that is, can’t be undone), CHR∨ tries all the branches from the disjunctive bodies leading to a very efficient engine. When the CHR engine chooses non-deterministically a rule (with just a body), by other side, it can’t backtrack the execution of this normal rule. Hence engine will iteratively apply the rules in the program rule base until no rule is applicable or the current set of constraints becomes inconsistent. The set of constraints is called Constraint Store. Every time no rule is applicable, the inference engine backtracks to the last disjunctive rule applied. This is a very important characteristic of CHR∨ w.r.t CHR: even if both are a committed choice language (in the sense that any rule choice is committed, that is, can’t be undone), CHR∨ tries all the branches from the disjunctive bodies leading to a very efficient engine. When the CHR engine chooses non-deterministically a rule (with just a body), by other side, it can’t backtrack the execution of this normal rule. Let’s simulate the execution of this problem. For example, let the initial constraint store be: connected(A, B), indomain(A, [red, blue]), indomain(B, [red]) If we apply the rule r2, matching the head of the rule with the constraint indomain(B,[red]), we get the following constraint store: Cin-UFPE. Cleyton Rodrigues. 8.

(45) Component Assembly and Theorem Proving in Constraint Handling Rules. connected(A, B), indomain(A, [red, blue]), B = red Observe that the applied rule has a disjunction in its body. In this case we need to choose one of the options and add the resulting constraints to the current constraint store. We chose the first one. We can now then apply the same rule again, matching the head of the rule with the constraint indomain(A,[red,blue]), we get then: connected(A, B), A = red, B = red The only applicable rule is the r3. In this case we match its head with the constraint connected(A,B), we get: A! = B, A = red, B = red In this case, we have got an inconsistent constraint store (because A and B should be different), and we need than to backtrack to the last disjunction (in this case, it was the last application of the rule r2. We go back to the following constraint store: connected(A, B), indomain(A, [red, blue]), B = red We now choose the second option in the disjunction of the rule r2 and we get: connected(A, B), indomain(A, [blue]), B = red Now we can apply the same rule again, matching the constraint indomain(A,[blue]) with the rule head and we get: connected(A, B), A = blue, B = red We can finally apply the rule r3, matching the constraint connected(A,B) with its head and get: A! = B, A = blue, B = red We call this constraint store a Final Constraint Store. In this case, no rule can be applied and it is consistent. We say that this constraint store is a solution for this constraint solving problem. It means that the node A should be colored with the color blue and the node B should receive the color red. Notice that with CHR∨ it was possible to obtain a completely defined instantiation for the problems. If we had just CHR, we would have just the rule r3 and all we would be able to conclude are intentional results like: A! = B With disjunctions we can test any possible coloring (as we did with the rules r1 and r2). This process is called labeling and in CHR it should have been executed in the host language. This is one of the advantages of CHR∨ over CHR. Cin-UFPE. Cleyton Rodrigues. 9.

(46) Component Assembly and Theorem Proving in Constraint Handling Rules 2.3.2. Abstract Syntax of CHR∨ as a MOF Metamodel. From now we will see a series of contributions to this dissertation. Initially, we will focus on the abstract syntax of CHR∨ based on MOF. Next, the concrete syntax is representanda by Backus Naurs Form, and finally, we focuse on its declarative semantics based on an approach made in Fluent Calculus. These innovations came to formalize further CHR∨ through techniques either already defined as a standard by OMG, or which have an engine formally defined for tests and measurements. The abstract syntax of CHR∨ (or CHRD) is held by a package CHRD. This package, in turn, is internally constituted by three other minors: CHRD :: Atom, CHRD :: F ormula and CHRD :: P rogram. All these packages are linked by the meta-relationship merge. Accordingly, the contents of Atom is merged with the contents of Formula, and this latter are merged with the contents of the Program package (it is important to emphasize that the entire contents of all packages are public). The separation, however, makes clear the structure of the syntax of CHRD since Atom defines the most basic structures of the solver, Formula defines how these atoms can be linked leading to something higher (a formula or a molecule), and finally , Program reflects how the formulas are organized to set rules, and thus programs. Figure 2.3 reflects this general view of the internal structure of CHRD package. Then, the dissertation details the contents of each constituent.. Figure 2.3 General View of the abstract syntax of CHR∨. The meta-class CHRD :: Atom :: T erm defines the most basic element that can exist in a CHR∨ program, and it has a derivate attribute ground of type boolean. This class specializes in two others (whenever necessary, the full path of the classes will be omitted): N onF unctionalT erm, which specializes , in turn, on Constant and V ariable, and F unctionalT erm. A FunctionalTerm is an aggregation of one or more other terms (i.e., the functional term f() and its terms X and g(Y), f(X,g(Y))). All these classes are also a N amedElement, that is, each element is identifiable by the means of its name of type String. Like FunctionalTerm, the meta-class AtomF ormula is an aggregation of other terms (in other words, its attributes). Figure 2.4 depicts out this package. The meta-class AtomFormula, as observed in figure 2.5, is a kind of formula (CHRD::Formula::Formula). The other sort is the meta-class AndOrF ormula which has the attribute connective, whose type is an enumeration with the following values: and and or. In fact, this class defines the logical connections, making a conjunction or a disjunction of AtomFormula, or even a mixed of both. That meta-class can still be specialized in AndF ormula, which only allows the use of connective and. Note also that AndOrF ormula is an aggregation of two or more other formulas, i. e., a hypothetical Cin-UFPE. Cleyton Rodrigues. 10.

(47) Component Assembly and Theorem Proving in Constraint Handling Rules. Figure 2.4 Atom Package. AndOrFormula g is formed by f(X,Y) ; g(Y), h(Y, X).. Figure 2.5 Formula Package. There are certain restrictions which can not be represented by a diagrammatic notation, or when they can, leaves it confused to be interpreted. So there is a declarative language that can be used together with UML, even at the level of metamodeling, which provides query expressions and constraints to supply UML for possible incompleteness: OCL (Object Constraint Language) [OCL08]. OCL is a non-ambiguous language that is, Cin-UFPE. Cleyton Rodrigues. 11.

(48) Component Assembly and Theorem Proving in Constraint Handling Rules moreover, navigable for graph-based models. Follows one ocl restriction (the syntax and semantics of OCL is beyond the purpose of this dissertation). context CHR::CHRD::Formula::AndFormula inv : self.connective = Connective::and The above code restricts the only connective of AndFormula as and. The package P rogram is the more general. Here, the meta-abstract class Rule defines as a CHR∨ rule is formed: zero or more AndFormula labeled with keep (the head keep part of the rule), zero or more AndFormula with the label remove (including the simplification part of the head’s rule), zero or more AndFormula of sort guard, and finally, one compulsory Formula (therefore, allowing disjunction) body. Rule specializes on the three classes of rules: Simplif icationRule, P ropagationRule and SimpagationRule. Each class is distinguished by the presence (or not) of the heads keep and/or remove. These restrictions are expressed by means of OCL expressions that are below. A Rule is also a NamedElement, that is, it has an identification (its name) single in the program. Still, a Program is a meta-class formed by a collection of rules (at least, a rule must exist). Note also that a program has several instances of AtomSignature. Each AtomFormula has an AtomSignature: a declaration of the CHR constraints in the program, formed by a name and its arity. For CHR∨ , only two types of constraints are present: UDC and BICS, both represented by papers given by the meta-association between Program and AtomSignature. In addition, follows the OCL restrictions for this metamodel. Each one has a comment, with a brief explanation of its functionality.. Figure 2.6 Program Package. --The rules name is unique: context CHR::CHRD::Program::Rule inv: let listName = select(Rule.name) in forAll(listName.count(Rule.name)=1) Cin-UFPE. Cleyton Rodrigues. 12.

(49) Component Assembly and Theorem Proving in Constraint Handling Rules. -- For a Propagation Rule, only the remove head is empty context CHR::CHRD::Program::PropagationRule inv OwnsOnlyPropagatehead: self.remove->isEmpty() and self.keep->notEmpty() -- For a Simpagation Rule, none of the keep or remove head is empty context CHR::CHRD::Program::SimpagationRule inv AtLeastAHeadFromEach: self.remove->notEmpty() and self.keep->notEmpty() -- For a Simplification Rule, only the keep head is empty context CHR::CHRD::Program::SimplificationRule inv OwnsOnlySimplificateHeads: self.keep->isEmpty() and self.remove->notEmpty() -- Defining an atom context CHR::CHRD:AtomFormula::atom : Set(AtomFormula) def: Set{self} context CHR::CHRD:AndOrFormula::atom : Set(AtomFormula) def: self.formula.atom->asSet() -- Defining the types for keep, remove, guard and body formulas context CHR::CHRD::Program::Rule inv : keep.atom -> forAll(e| self.program.udc.atomsignature -> includes(e.atomsignature)) inv : remove.atom -> forAll(e| self.program.udc.atomsignature -> includes(e.atomsignature)) inv : guard.atom -> forAll(e| self.program.bic.atomsignature -> includes(e.atomsignature)) inv : body.atom -> forAll(e| self.program.udc.atomsignature -> union(self.program.bic.atomsignature)-> includes(e.atomsignature)) -- A constraint cannot be udc and bic at the same time context CHR::CHRD::Program::Program inv : self.udc->intersection(self.bic)->isEmpty() 2.3.3. Concrete Syntax. As said before, there are two kinds of constraints in CHR∨ : the user-defined constraints and the built-in constraints. The formers are defined by the user and their semantics are provided by the rules in the CHR∨ program. The last ones are defined and handled internally by the inference engine, and their semantics can not be changed by the user. Cin-UFPE. Cleyton Rodrigues. 13.

(50) Component Assembly and Theorem Proving in Constraint Handling Rules The set of built-in constraints is assumed to contain at least the equality built-in (=) and the true (which is always consistent) and the f alse (which is always inconsistent) predicates. However it usually contains other built-ins for mathematical expressions, lists handling and so forth. There are three kinds of rules in CHR∨ : simplifications, propagations and simpagations. The simplification rules are syntactically described as follows: r@H ⇔ G|B. In this case, r is the identifier for the rule, H is said to be its head, G its guard and B its body. The propagation rules are described as follows: r@H ⇒ G|B. In this case, r is the identifier for the rule, H is said to be its head, G its guard and B its body. Finally, the simpagation rules are described as follows: r@Hk \Hr ⇔ G|B. In this case, r is the identifier for the rule, Hk is said to be its head keep and Hr its head remove, G its guard and B its body. In all cases, the head expressions can only contain user-defined predicates, while the guard expressions can only contain built-in constraints. The body expression can contain both user defined and built-in constraints. If the guard part is empty or contains just the true constraint it can be omitted together with the vertical bar |. The rule identifier can also be omitted, since it does not interfere with the program semantics. This variety of rule syntax possibilities is redundant, in the sense that one kind of rule often can be translated into another. For example, each simplification rule in the form r@H ⇔ G|B can be translated to the following semantically equivalent simpagation rule r@∅\H ⇔ G|B. Each propagation rule in the form r@H ⇒ G|B can be translated to the following semantically equivalent simpagation rule: r@H\∅ ⇔ G|B. The same happens with the simplification rules: each simpagation rule in the form r@Hk \Hr ⇔ G|B can be translated to the following semantically equivalent simplification rule r@Hk , Hr ⇔ G|Hk , B. Each propagation rule in the form r@H ⇒ G|B can be translated to the following semantically equivalent simplification rule: r@H ⇔ G|H, B. That is why some semantics definitions for CHR∨ consider only a subset of the syntactical variety of rules presented here. Figure 2.7 states the concrete Backus Naur Form syntax of a CHR∨ program. For simplicity, consider the symbols name and arity as terminal. 2.3.4. Declarative Semantics for Monotonic Applications in Classical First-Order Logic (CFOL). 2.3.4.1 General Definition The logical meaning of a CHR∨ rule base is the conjunction of the logical meanings of all its rules and the Constraint Theory (CT) which defines the semantics of the built-ins. Cin-UFPE. Cleyton Rodrigues. 14.

(51) Component Assembly and Theorem Proving in Constraint Handling Rules. <program> ::= <declaration> <rule>+ <declaration>::= <atomFormula> ’/’ arity | <atomFormula> ’/’ arity <declaration> <rule>::= <simplificationRule> | <propagationRule> | <simpagationRule> <simplificationRule>::= [name ’@’] <remove>+ ’<=>’ [<guad> ’|’] <body> ’.’ <propagationRule>::= [name ’@’] <keep>+ ’<=>’ [<guad> ’|’] <body> ’.’ <simpagationRule>::= [name ’@’] <keep>+ ’\’ <remove>+ ’<=>’ [<guad> ’|’] <body> ’.’ <keep>::= <andFormula> <remove>::= <andFormula> <guard>::= <andFormula> <body>::= <formula> <andFormula>::= <atomFormula> | <atomFormula> ’,’ <andFormula> <formula>::= <andFormula>| <andFormula> ’;’ <formula> <atomFormula>::= <term> | <term> <atomFormula> <term>::= <functionalTerm> | <nonFunctionalTerm> <nonFunctionalTem>::= <variable> | <constant> <functionalTerm> ::= <term> | <term> <functionalTerm> <variable>::= name <constant>::= name Figure 2.7 Concrete Syntax of CHR∨ in BNF. Cin-UFPE. Cleyton Rodrigues. 15.