Specification and Verification of Declarative Open Interaction Models: A Logic-Based Approach (Lecture Notes in Business Information Processing)

Lecture Notes in Business Information Processing Series Editors Wil van der Aalst Eindhoven Technical University, The N...

Author: Marco Montali

15 downloads 357 Views 9MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

Lecture Notes in Business Information Processing Series Editors Wil van der Aalst Eindhoven Technical University, The Netherlands John Mylopoulos University of Trento, Italy Michael Rosemann Queensland University of Technology, Brisbane, Qld, Australia Michael J. Shaw University of Illinois, Urbana-Champaign, IL, USA Clemens Szyperski Microsoft Research, Redmond, WA, USA

56

Marco Montali

Specification and Verification of Declarative Open Interaction Models A Logic-Based Approach

13

Author Marco Montali University of Bologna V.le Risorgimento 2, 40136 Bologna, Italy E-mail: [email protected]

Library of Congress Control Number: 2010931106 ACM Computing Classification (1998): H.3.5, I.2.4, F.4.1, D.2.11, J.1 ISSN ISBN-10 ISBN-13

1865-1348 3-642-14537-X Springer Berlin Heidelberg New York 978-3-642-14537-7 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. springer.com © Springer-Verlag Berlin Heidelberg 2010 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper 06/3180 543210

Dedicated to Valentina and Giulia, and to Evita and Micol.

Foreword

Many emerging settings, such as business process management systems, clinical guidelines, services composition/choreographies and multi-agent systems, are characterized by a distribution of activities and resources and by exhibiting complex dynamics. This is due to their intrinsic openness, to the autonomy of their stakeholders, and to the unpredictability of the environment in which they are situated. To understand such dynamics and to develop methods and tools apt to accommodate modeling and reasoning about them is a very challenging goal. All these systems center around the interaction of the involved parties. Interaction, in turn, must be disciplined so as to ensure that the interacting entities comply with external regulations, norms, business rules, and internal policies. Such forces have the eﬀect of constraining the courses of interaction, and can be thus grouped under the umbrella term of business constraint. Business constraints constitute a form of declarative knowledge: they restrict the set of compliant courses of interaction, without explicitly stating how the interacting entities must behave. Unfortunately, traditional modeling approaches have a closed and procedural nature, and thus require writing down explicitly all the compliant behaviors, producing “spaghetti-like” models which tend to sacriﬁce ﬂexibility and readability. In this respect, a shift toward open and declarative modeling abstractions is needed. However, the adoption of declarative open interaction models poses two challenging questions: how can we specify them, and what is their semantics? How is it possible to support their design, execution, veriﬁcation and analysis? In this book, Montali answers both of these fundamental questions. A broad survey of the state of the art is given, where Montali puts forward convincing evidence that closed, procedural approaches must be complemented with open and declarative ones. He then presents a great deal of background material on various languages and techniques belonging to diﬀerent, usually unrelated, domains such as business process management, logic programming, knowledge representation and reasoning and multi-agent systems.

VIII

Foreword

The main theme of the book is the integration and extensions of all these contributions within a computational logic-based framework called CLIMB. The result is a uniﬁed, synergic, and comprehensive framework, where non-IT experts can graphically specify interaction models, automatically obtaining a corresponding formal representation and a set of fully automated sound and complete veriﬁcation facilities. CLIMB exploits both the declarative advantages of computational logic and its computational power. On the one hand, computational logic deﬁnes a declarative and meaningful semantics to open and declarative interaction models. On the other hand, it provides a plethora of eﬀective reasoning techniques that support interaction models prior to, during, and after their execution. The book contains one of the most clever corpora of ideas centered around the application of computational logic-based techniques for the speciﬁcation and veriﬁcation of interaction models. It constitutes a solid and motivating ground for future developments. The technical excellence of the book and the signiﬁcance of its multifarious contributions will be a valuable asset for researchers of diverse scientiﬁc communities, practitioners in emerging application domains, and future generations of doctoral students.

May 2010

Paola Mello

Preface

This book contains a revised and extended version of the dissertation the author wrote in the Artiﬁcial Intelligence Division of the Department of Electronics, Computer Science and Systems at the University of Bologna, Italy. The dissertation was submitted to the University of Bologna in conformity with the requirements for the degree of Doctor of Philosophy in April 2009. It was honored with the 2009 “Marco Cadoli” prize, awarded by the Italian Association for Logic Programming to the most outstanding theses focused on computational logic and discussed between 2007 and 2009.

Abstract The advent of distributed and heterogeneous systems has laid the foundation for the birth of new architectural paradigms, in which many separated and autonomous entities collaborate and interact, with the aim of achieving complex strategic goals, impossible to be accomplished on their own. A non-exhaustive list of systems targeted by such paradigms includes business process management, clinical guidelines and careﬂow protocols, service-oriented computing, and multi-agent systems. It is largely recognized that engineering these systems requires novel modeling techniques. In particular, many authors are claiming that an open, declarative perspective is needed to complement the closed, procedural nature of the state-of-the-art speciﬁcation languages, toward ﬂexibility, usability, and veriﬁability. For example, the ConDec language has been recently proposed to target the declarative and open speciﬁcation of business processes, overcoming the over-speciﬁcation and over-constraining issues of classical procedural approaches, which tend to force unnecessary rigidity on the way the systems sub-parts coordinate. On the one hand, the success of such novel modeling languages strongly depends on their usability by non-IT savvy: they must provide an appealing, intuitive graphical front-end. On the other hand, they

X

Preface

must be apt to veriﬁcation, in order to guarantee the trustworthiness and reliability of the developed model, as well as to ensure that the actual executions of the system eﬀectively comply with it. The claim of this book is that computational logic is a suitable supporting framework for declarative open interaction models. In particular, the CLIMB (Computational Logic for the verIﬁcation and Modeling of Business constraints) framework is proposed to address the speciﬁcation, veriﬁcation, execution, monitoring, and analysis of interaction models. After having introduced the main distinctive features of open declarative interaction models and motivated their suitability in diﬀerent application domains, we propose to adopt an extended version of the ConDec language for their graphical speciﬁcation. We then show how all the (extended) ConDec constructs can be automatically formalized by using a subset of the SCIFF language. SCIFF is a framework based on computational logic (Abductive Logic Programming in particular), which encompasses a rule-based language with a clear declarative semantics for specifying the interaction, and a family of proof procedures for concretely addressing reasoning and veriﬁcation. We illustrate how such reasoning techniques can be successfully exploited to provide support and veriﬁcation capabilities along the whole life cycle of the targeted systems. A number of challenging tasks are addressed, including static veriﬁcation of properties, composition and interoperability of interaction models, run-time compliance veriﬁcation, monitoring, and mining. The investigation is carried out spanning from theoretical aspects, such as proofs of formal properties and comparison with temporal logics, to practical applications, experimental evaluations, case studies, and tools. The book is organized in four parts. Part I: Speciﬁcation. Chapter 2 gives a very accessible and precise overview of the application domains. Chapter 3 provides a critical overview of the ConDec language and introduces the framework of propositional linear temporal logic. Chapter 4 presents the CLIMB rule-based language, discusses its declarative semantics, and proves some interesting formal properties. Chapter 5 draws a bridge between the CLIMB and the ConDec languages, by proposing a translation and by running a theoretical investigation about the expressiveness of the two formalisms. Chapter 6 introduces and studies some very signiﬁcant extensions to ConDec. Chapter 7 concludes this part with a discussion of related work and a summary. Part II: Static Veriﬁcation. Chapter 8 introduces the problem of interaction model design-time veriﬁcation. Chapter 9 presents two proofprocedures for reasoning from CLIMB speciﬁcations, and formally investigates their properties of termination, soundness, and completeness. Chapter 10 addresses the static veriﬁcation of ConDec models. Chapter 11 conducts an experimental evaluation of the proposed methods, by comparing their performance with that of model checkers. Chapter 12 discusses related work and gives a summary of this second part.

Preface

XI

Part III: Runtime and A Posteriori Veriﬁcation. Chapter 13 introduces the problem of open declarative interaction model run-time veriﬁcation, and discusses the application of the and proof-procedures to the run-time veriﬁcation of interacting entities with respect to ConDec models. Chapter 14 presents a reactive form of event calculus, axiomatized on top of SCIFF, which enables monitoring and enacting ConDec models. Chapter 15 presents innovative declarative process mining techniques based on CLIMB, and it describes two implemented tools and their application. Chapter 16 concludes with related work and summary. Part IV: Conclusions and Future Work.

Ac

ow ed

e ts

First and foremost, I would like to thank my supervisor, Prof. Paola Mello, for having constantly supported and encouraged my research activity. She guided me through the intriguing world of computational logic with her deep knowledge and open mind. Thanks to Federico Chesani, for having shared with me every working day as a colleague and a friend. His observations and feedback have been fundamental to ﬁnalizing my thoughts. Thanks to Paolo Torroni, for having always encouraged me to pursue my research and for having shared with me his strong research attitude. A special thanks goes to Marco Gavanelli, for his constant support on the SCIFF Framework. I am grateful to Prof. Bob Kowalski, for having ﬁrst inspired and then appreciated my work. I am greatly indebted to Prof. Wil van der Aalst and Maja Pesic. The insightful and illuminating discussions I had with them during my two visits at TU/e strongly contributed to shaping the ideas presented in this book. Without their work on ConDec and declarative business process management, this book would have never been possible. Last but not least, I would like to thank all the people who contributed to my education and research. In alphabetical order: Marco Alberti, Matteo Baldoni, Cristina Baroglio, Alessio Bottrighi, Anna Ciampolini, Carlo Giannelli, Evelina Lamma, Michela Milano, Fabrizio Riguzzi, Davide Sottara, Sergio Storari, Paolo Terenziani, Alessandra Toninelli. My research activity has been partially supported by the FIRB Project TOCAI.IT: Knowledge-Oriented Technologies for Enterprise Aggregation in Internet and by the PRIN 2005 Project Languages for the Speciﬁcation and Veriﬁcation of Agents Interaction Protocols. “Words cannot describe everything. The heart’s message cannot be delivered in words.” — Mu-mon 1228. Grazie a Valentina e Giulia. Grazie a mamma, pap` a e Anna. Grazie ai nonni e agli zii. Grazie ad Annetta e Gigi. Grazie ai Marco – Kebir e Cmyk. Grazie ad Antonio. Grazie a Matteo. Grazie a Cate e Luchino. E grazie Bologna. May 2010

Marco Montali

Acronyms

ALP B2B B2C BDD BMK BP BPM BPMN CEC CEP CG CHR CLIMB

Abuctive Logic Programming Business-To-Business Business-To-Consumer ordered Binary Decision Diagram Basic Medical Knowledge Business Process Business Process Management Business Process Modeling Notation Cached Event Calculus Complex Event Processing Clinical Guideline Constraint Handling Rules Computational Logic for the verIﬁcation and Modeling of Business constraints CLP Constraint Logic Programming EBS Event-Based System EC Event Calculus FOL First Order Logic ILP Inductive Logic Programming KB Knowledge Base LP Logic Programming LTL propositional Linear Temporal Logic MAS Multi-Agent System MTL Metric Temporal Logic NAF Negation As Failure QoS Quality of Service REC Reactive Event Calculus SCIFF Social Constrained IFF Framework sciff SCIFF Proof Procedure g-sciff g-SCIFF Proof Procedure SOA Service Oriented Architecture

XIV

SOC TPTL UML WfMS WS

Acronyms

Service Oriented Computing Timed Propositional Temporal Logic Uniﬁed Modeling Language Workﬂow Management System Web Service

Contents

1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Main Contributions of the Book . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Speciﬁcation of Open Declarative Interaction Models . . . 1.1.2 Static Veriﬁcation of Interaction Models . . . . . . . . . . . . . . 1.1.3 Run-Time Veriﬁcation, Monitoring and Enactment Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4 A-Posteriori Veriﬁcation and Declarative Process Mining 1.2 Organization of the Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Part I: Speciﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Part II: Static Veriﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Part III: Run-Time and A-Posteriori Veriﬁcation . . . . . . 1.2.4 Part IV: Conclusion and Future Work . . . . . . . . . . . . . . . . 1.3 Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 3 3 4 4 5 6 6 7 8 8 8

Part I Speciﬁcation 2

Declarative Open Interaction Models . . . . . . . . . . . . . . . . . . . . . . 2.1 An Informal Characterization of Interaction Models . . . . . . . . . . 2.1.1 Interaction Abstractions: Activity, Event, Execution Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Characterization of Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.4 Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.5 Openness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Modeling Business Processes . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Limits of Procedural Business Process Modeling . . . . . . . 2.3 Service Oriented Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Service Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Orchestration and Choreography . . . . . . . . . . . . . . . . . . . .

11 11 11 13 14 16 19 20 22 23 25 25 26

XVI

3

4

Contents

2.3.3 Limits of Procedural Choreography Modeling . . . . . . . . . 2.4 Multi-Agent Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Clinical Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Basic Medical Knowledge and Clinical Guidelines . . . . . . 2.5.2 Semi-Openness of Clinical Guidelines . . . . . . . . . . . . . . . . 2.6 Lesson Learnt: Compliance vs. Flexibility . . . . . . . . . . . . . . . . . . . 2.7 Desiderata for a Supporting Framework . . . . . . . . . . . . . . . . . . . . 2.7.1 Internal Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.2 Participation to an External Life Cycle . . . . . . . . . . . . . . . 2.8 The CLIMB Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29 34 36 37 38 39 41 42 43 44

The ConDec Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 ConDec in a Nutshell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 ConDec Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Existence Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Choice Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Relation Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Negation Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.5 Branching Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 ConDec at Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 The Order Management Choreography in Natural Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 The Order Management Choreography as a Contract . . 3.4.3 Identiﬁcation of Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4 Elicitation of Business Constraints . . . . . . . . . . . . . . . . . . . 3.4.5 Completing the ConDec Model . . . . . . . . . . . . . . . . . . . . . . 3.5 Usability of ConDec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Linear Temporal Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 LTL Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.2 Syntax of Linear Temporal Logic . . . . . . . . . . . . . . . . . . . . 3.6.3 Semantics of Linear Temporal Logic . . . . . . . . . . . . . . . . . 3.7 Translating ConDec into Linear Temporal Logic . . . . . . . . . . . . . 3.7.1 The Translation Function . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.2 LTL Entailment as a Compliance Evaluator . . . . . . . . . . . 3.7.3 Linear Temporal Logic and Finite ConDec Traces . . . . .

47 47 48 49 49 50 51 54 56 57 58 58 59 60 63 64 67 68 68 69 70 70 71 72

The CLIMB Rule-Based Language . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 The CLIMB Language in a Nutshell . . . . . . . . . . . . . . . . . . . . . . . 4.2 The CLIMB Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Event Occurrences and Execution Traces . . . . . . . . . . . . . 4.2.2 Constraint Logic Programming . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4 Integrity Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.5 The Static Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . .

77 77 79 79 81 83 85 90

Contents

XVII

4.2.6 SCIFF-lite and Composite Events . . . . . . . . . . . . . . . . . . . 93 4.3 CLIMB Declarative Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 4.3.1 Abduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.3.2 Abductive Logic Programming . . . . . . . . . . . . . . . . . . . . . . 98 4.3.3 Formalizing Interaction Models and Their Executions . . 99 4.3.4 SCIFF-lite Speciﬁcations . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.3.5 CLIMB Abductive Explanations . . . . . . . . . . . . . . . . . . . . 102 4.3.6 On the Formal Deﬁnition of Compliance . . . . . . . . . . . . . . 105 4.4 Formal Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 4.4.1 Equivalence Modulo Compliance . . . . . . . . . . . . . . . . . . . . 109 4.4.2 Compositionality Modulo Compliance . . . . . . . . . . . . . . . . 110 4.4.3 Replaceability of Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5

Translating ConDec into CLIMB . . . . . . . . . . . . . . . . . . . . . . . . . . 115 5.1 Translation of a ConDec Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 5.2 Translation of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.3 Embedding a Qualitative Characterization of Time into a Quantitative Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.3.1 Temporal Contiguity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.3.2 Compact Execution Traces . . . . . . . . . . . . . . . . . . . . . . . . . 119 5.4 Translation of ConDec Constraints . . . . . . . . . . . . . . . . . . . . . . . . 121 5.4.1 Translation of Existence Constraints . . . . . . . . . . . . . . . . . 121 5.4.2 Translation of Choice Constraints . . . . . . . . . . . . . . . . . . . 123 5.4.3 Translation of Relation and Negation Constraints . . . . . 125 5.5 Dealing with Branching ConDec Constraints . . . . . . . . . . . . . . . . 128 5.6 Translation of a ConDec Choreography . . . . . . . . . . . . . . . . . . . . . 130 5.7 Equivalence of ConDec Constraints . . . . . . . . . . . . . . . . . . . . . . . . 130 5.8 Soundness of the Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 5.8.1 Trace Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 5.8.2 Behavioral Equivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.8.3 Soundness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 5.8.4 On the Expressiveness of SCIFF . . . . . . . . . . . . . . . . . . . . 137

6

Extending ConDec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 6.1 Metric Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 6.1.1 Temporal Contiguity in a Quantitative Setting . . . . . . . . 140 6.1.2 Quantitative Formalization of Chain Constraints . . . . . . 141 6.1.3 Init Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 6.1.4 Extending ConDec with Quantitative Temporal Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 6.2 Data Aware Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 6.2.1 Examples of Data Aware Business Constraints . . . . . . . . 145 6.2.2 The MXML Meta Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 . 148 6.2.3 The Life Cycle of Non Atomic Activities in ConDec 6.3 Modeling Data in ConDec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

XVIII Contents

6.3.1 Representing Non Atomic Activities and Data . . . . . . . . 149 6.3.2 Modeling Data Aware Conditions . . . . . . . . . . . . . . . . . . . 150 6.3.3 Modeling the Submit&Review Process Fragment . . . . . . 154 6.4 Formalizing Data Aware Aspects in CLIMB . . . . . . . . . . . . . . . . 155 6.4.1 Formalizing Data and Data Aware Conditions . . . . . . . . 155 6.4.2 Formalizing the Eﬀect of Roles . . . . . . . . . . . . . . . . . . . . . . 156 6.4.3 Formalizing the Activity Life Cycle . . . . . . . . . . . . . . . . . . 159 7

Related Work and Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 7.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 7.1.1 Business Process Management . . . . . . . . . . . . . . . . . . . . . . 163 7.1.2 Clinical Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 7.1.3 Service Oriented Computing . . . . . . . . . . . . . . . . . . . . . . . . 169 7.1.4 Multi-Agent Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 7.2 Summary of the Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Part II Static Veriﬁcation 8

Static Veriﬁcation of Declarative Open Interaction Models 177 8.1 Desiderata for Static Veriﬁcation Technologies . . . . . . . . . . . . . . 177 8.2 Veriﬁcation of a Single Model vs. a Composition of Models . . . 179 8.3 Static Veriﬁcation of Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 8.3.1 Existential vs. Universal Properties . . . . . . . . . . . . . . . . . . 180 8.3.2 General vs. Particular Properties . . . . . . . . . . . . . . . . . . . . 181 8.3.3 On the Safety-Liveness Classiﬁcation . . . . . . . . . . . . . . . . . 182 8.3.4 A ConDec Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 8.4 A-Priori Compliance Veriﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . 186 8.5 Composing ConDec Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 8.5.1 Compatibility between Local Models . . . . . . . . . . . . . . . . . 188 8.5.2 Augmenting ConDec with Roles and Participants . . . . . . 190 8.5.3 From Openness to Semi-Openness . . . . . . . . . . . . . . . . . . . 192 8.6 Conformance with a Choreography . . . . . . . . . . . . . . . . . . . . . . . . 196

9

Proof Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 9.1 The SCIFF Proof Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 9.1.1 Fulﬁlled, Violated and Pending Expectations . . . . . . . . . . 202 9.1.2 Data Structures and Proof Tree . . . . . . . . . . . . . . . . . . . . . 203 9.1.3 Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.2 Formal Properties of the SCIFF Proof Procedure . . . . . . . . . . . . 214 9.2.1 Soundness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 9.2.2 Completeness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 9.2.3 Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 9.2.4 ConDec and Termination of the SCIFF Proof Procedure218 9.3 The g-SCIFF Proof Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Contents

XIX

9.3.1 Generation of Intensional Traces . . . . . . . . . . . . . . . . . . . . 219 9.3.2 Data Structures Revisited . . . . . . . . . . . . . . . . . . . . . . . . . . 220 9.3.3 Transitions Revisited . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 9.3.4 Linking the Proof Procedures . . . . . . . . . . . . . . . . . . . . . . . 222 9.4 Formal Properties of the g-SCIFF Proof Procedure . . . . . . . . . . 223 9.4.1 Soundness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 9.4.2 Completeness Modulo Trace Generation . . . . . . . . . . . . . . 223 9.4.3 Termination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 9.5 Implementation of the Proof Procedures . . . . . . . . . . . . . . . . . . . . 227 10 Static Veriﬁcation of ConDec Models with g-SCIFF . . . . . . . 229 10.1 Existential and Universal Entailment in CLIMB . . . . . . . . . . . . . 229 10.1.1 Speciﬁcation of Properties with ConDec . . . . . . . . . . . . . . 229 10.1.2 Formalizing Existential and Universal Entailment . . . . . . 231 10.2 Veriﬁcation of Existential Properties with g-SCIFF . . . . . . . . . . 232 10.2.1 Conﬂict Detection with g-SCIFF . . . . . . . . . . . . . . . . . . . . 233 10.2.2 Existential Entailment with g-SCIFF . . . . . . . . . . . . . . . . 233 10.3 Veriﬁcation of Universal Properties with g-SCIFF . . . . . . . . . . . 234 10.3.1 Complementation of Integrity Constraints . . . . . . . . . . . . 234 10.3.2 Reducing Universal to Existential Entailment . . . . . . . . . 236 10.4 ConDec Loops and Termination of g-SCIFF . . . . . . . . . . . . . . . . 239 10.4.1 Constraints Reformulation . . . . . . . . . . . . . . . . . . . . . . . . . . 240 10.4.2 Looping ConDec Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 10.5 A Preprocessing Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 11 Experimental Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 11.1 Veriﬁcation Procedure with g-SCIFF . . . . . . . . . . . . . . . . . . . . . . . 251 11.2 Scalability of the g-SCIFF Proof Procedure . . . . . . . . . . . . . . . . . 253 11.2.1 The Branching Responses Benchmark . . . . . . . . . . . . . . . . 253 11.2.2 The Alternate Responses Benchmark . . . . . . . . . . . . . . . . 255 11.2.3 The Chain Responses Benchmark . . . . . . . . . . . . . . . . . . . 258 11.3 Static Veriﬁcation of ConDec Models as Model Checking . . . . . 261 11.3.1 Existential and Universal Entailment of ConDec Properties in LTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 11.3.2 ConDec Properties Veriﬁcation as Satisﬁability and Validity Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 11.3.3 Model Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 11.3.4 Reduction of Validity and Satisﬁability to Model Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 11.3.5 Veriﬁcation Procedure by Model Checking . . . . . . . . . . . . 268 11.4 Comparative Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 11.4.1 The Order&Payment Benchmarks . . . . . . . . . . . . . . . . . . . 269 11.4.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

XX

Contents

12 Related Work and Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 12.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 12.1.1 Veriﬁcation of Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 12.1.2 A-Priori Compliance Veriﬁcation . . . . . . . . . . . . . . . . . . . . 281 12.1.3 Model Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 12.1.4 Interoperability and Choreography Conformance . . . . . . 284 12.2 Summary of the Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Part III Run-Time and A-Posteriori Veriﬁcation 13 Run-Time Veriﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 13.1 The Run-Time Veriﬁcation Task . . . . . . . . . . . . . . . . . . . . . . . . . . . 290 13.2 SCIFF-Based Run-Time Veriﬁcation . . . . . . . . . . . . . . . . . . . . . . . 291 13.2.1 Reactive Behavior of the SCIFF Proof Procedure . . . . . . 292 13.2.2 Open Derivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 13.2.3 Semi-Open Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 13.3 The SOCS-SI Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298 13.4 Speculative Run-Time Veriﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . 300 13.4.1 The Need for Speculative Reasoning . . . . . . . . . . . . . . . . . 300 13.4.2 Speculative Veriﬁcation with the g-SCIFF Proof Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301 13.4.3 Interleaving the Proof Procedures . . . . . . . . . . . . . . . . . . . 303 14 Monitoring and Enactment with Reactive Event Calculus . . 305 14.1 Monitoring Issues and SCIFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 14.2 Event Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 14.2.1 The Event Calculus Ontology . . . . . . . . . . . . . . . . . . . . . . . 308 14.2.2 Domain-Dependent vs. Domain-Independent Axioms . . . 309 14.2.3 Reasoning with Event Calculus . . . . . . . . . . . . . . . . . . . . . . 310 14.3 The Reactive Event Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 14.3.1 Axiomatization of the Reactive Event Calculus . . . . . . . . 312 14.3.2 Monitoring an Event Calculus Speciﬁcation with the SCIFF Proof Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 14.4 REC Illustrated: A Personnel Monitoring Facility . . . . . . . . . . . . 316 14.4.1 Formalizing the Personnel Monitoring Facility in REC . 316 14.4.2 Monitoring a Concrete Instance . . . . . . . . . . . . . . . . . . . . . 318 14.4.3 The Irrevocability Issue . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 14.5 Formal Properties of REC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 14.5.1 Soundness, Completeness, Termination . . . . . . . . . . . . . . . 320 14.5.2 Irrevocability of REC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 14.6 Monitoring Optional ConDec Constraints with REC . . . . . . . . . 324 14.6.1 Representing ConDec Optional Constraints in the Event Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 14.6.2 Identiﬁcation and Reiﬁcation of Violations . . . . . . . . . . . . 328

Contents

XXI

14.6.3 Compensating Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 14.6.4 Monitoring Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 14.7 Enactment of ConDec Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 14.7.1 Showing Temporarily Violated Constraints . . . . . . . . . . . 336 14.7.2 Blocking Non Executable Activities . . . . . . . . . . . . . . . . . . 336 14.7.3 Termination of the Execution . . . . . . . . . . . . . . . . . . . . . . . 339 14.8 jREC: Embedding REC Inside a JAVA-Based Tool . . . . . . . . . . 340 15 Declarative Process Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 15.1 Declarative Process Mining with ProM, SCIFF Checker and DecMiner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 15.2 The SCIFF Checker ProM Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . 346 15.2.1 CLIMB Textual Business Constraints . . . . . . . . . . . . . . . . 347 15.2.2 A Methodology for Building Rules . . . . . . . . . . . . . . . . . . . 348 15.2.3 Speciﬁcation of Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 349 15.2.4 Trace Analysis with Logic Programming . . . . . . . . . . . . . . 350 15.2.5 Embedding SCIFF Checker in ProM . . . . . . . . . . . . . . . . . 351 15.3 Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 15.3.1 The Think3 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 15.3.2 Conformance Veriﬁcation of a Cervical Cancer Screening Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 15.3.3 Quality Assessment in Large Wastewater Treatment Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 15.4 The DecMiner ProM Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 15.4.1 Inductive Logic Programming for Declarative Process Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 15.4.2 Embedding DecMiner into the ProM Framework . . . . . . 362 15.5 The Checking–Discovery Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 16 Related Work and Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 16.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 16.1.1 Run-Time Veriﬁcation and Monitoring . . . . . . . . . . . . . . . 367 16.1.2 Enactment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 16.1.3 Process Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 16.2 Summary of the Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

Part IV Conclusion and Future Work 17 Conclusion and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 17.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 17.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 17.2.1 Termination of Static Veriﬁcation and ConDec Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 17.2.2 Reactive Event Calculus and Operational Support . . . . . 381

XXII

Contents

17.2.3 17.2.4 17.2.5 17.2.6

Integration of Regulative and Constitutive Rules . . . . . . 381 Development of an Editor and Enactment Prototype . . . 382 Service Contracting and Discovery in the Semantic Web 383 Integration of Declarative and Procedural Models . . . . . 383

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

1 Introduction If the only tool you have is a hammer, you tend to see every problem as a nail. — Abraham Maslow

The advent of distributed and heterogeneous systems has laid the foundation for the birth of new architectural paradigms, which enable to attack the complexity of the targeted domain by splitting it up into several interacting components. In the ﬁeld of software engineering, the diﬀerence between these paradigms and the classical centralized and monolithic ones has been identiﬁed since 1975, when DeRemer and Kron conied the two terms of programmingin-the-small vs programming-in-the-large [91]. A non exhaustive list of systems addressed by programming-in-the-large paradigms includes Business Process Management (BPM) [261], Careﬂow Protocols and Clinical Guidelines (CGs) [229], Service Oriented Computing (SOC) [134] and Multi-Agent System (MAS) [260]. For example, BPM systems help organizations in decomposing the work into sub-units, whose execution is then delegated to diﬀerent parties. The behavior of these parties must be disciplined so as to obtain, from their cooperation, the achievement of strategic business goals, such as supplying a service or delivering a product. In all these settings, the focus of the engineering process is on the interaction between the entities composing the system. Modeling and managing the interaction dimension is a challenging task, which has been traditionally tackled by means of procedural speciﬁcation languages, such as BPMN [263] for BPM, Glare [233] for CGs, BPEL [16] for Web Service (WS) orchestration and AUML [33] for Multi-Agent interaction protocols. However, the ongoing challenges posed by the new Internet era require very ﬂexible and adaptable interaction models able to cope with unpredictable, changing and dynamic environments, where the autonomy of interacting entities and the possibility of exploiting new opportunities must be preserved as much as possible [268] and the expertise of workers must be exploited at best [192]. These arguments have been put forward by several key initiatives and challenges of the European Union’s Programme for Research and

M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 1–8, 2010. c Springer-Verlag Berlin Heidelberg 2010

2

1 Introduction

Technological Development, such as the Global Computing 1 and the Internet of Services 2 , attesting their utmost importance. In these contexts, procedural, “closed” approaches show some critical drawbacks with respect to ﬂexibility [243, 73, 30, 118]: they require to explicitly enumerate all the ordering constraints among the activities undertaken by the interacting entities, tending to introduce unnecessary rigidity on the way the system’s subparts coordinate with each other. To overcome these drawbacks, open and declarative approaches are gaining consensus as a way to capture regulations, constraints, policies and best practices involved in the domain under study in a ﬂexible way [268, 246, 192, 8, 173]. They separate logic aspects (inherent to the problem itself) from control aspects (related to one speciﬁc way to solve the problem), as advocated by Kowalski since 1979 [144]. While a procedural style of modeling forces the modeler to produce a rigid scheme deﬁning one ﬁxed algorithm for disciplining the work, ruling out many acceptable possibilities, declarative approaches are more ﬂexible in nature, since they focus on the (minimal) set of constraints that must be guaranteed to successfully interact. In order to enable the eﬀective adoption of such novel modeling techniques, two fundamental requirements must be satisﬁed: • they must provide an appealing, intuitive graphical front-end, for the sake of usability by non-IT savvy; • they must be apt to veriﬁcation, in order to guarantee the trustworthiness and reliability of the developed models, as well as to ensure that the actual executions of the system eﬀectively comply with them. In this book, we characterize the notion of open and declarative interaction models along diﬀerent dimensions, motivating why they are a suitable choice for complementing the closed and procedural nature of current speciﬁcation languages, for the sake of ﬂexibility. To support our claim, we consider several signiﬁcant application domains, namely BPM, SOC, CGs and MASs. We then deeply investigate the use of Computational Logic to formalize and reason upon open declarative interaction models. In particular, we propose an integrated framework, called CLIMB (Computational Logic for the verIﬁcation and Modeling of Business constraints), able to meet both the fundamental requirements of usability and veriﬁability, thanks to the combination of the ConDec graphical language for speciﬁcation and the Computational Logicbased SCIFF framework for veriﬁcation and support. ConDec has been recently proposed by Pesic and van der Aalst [191, 192] for tackling the ﬂexible, declarative and open modeling of Business Processes (BPs). Instead of rigidly deﬁning the ﬂow of interaction, ConDec is able to directly translate business goals, regulations, domain requirements and policies to corresponding constraints between activities, providing a number 1 2

http://cordis.europa.eu/ist/fet/gc.htm http://cordis.europa.eu/fp7/ict/ssai/home_en.html

1.1 Main Contributions of the Book

3

of control-independent abstractions for interconnecting activities, alongside the more traditional ones. The explicit enumeration of the execution traces is avoided, because a ConDec diagram implicitly supports all the execution traces which comply with the modeled constraints. To equip ConDec with a formal semantics and with reasoning and veriﬁcation capabilities, we propose a complete and automatic translation of all its constructs to the CLIMB formal language. The CLIMB notation is a sub-set of the SCIFF language, which has been originally developed for specifying the rules of engagement disciplining Interaction Protocols in open MASs [8]. The language is associated with a clear declarative semantics which formally captures the notion of compliance of the system’s executions with the prescribed rules. The SCIFF framework provides the g-sciff and sciff proof procedures to reason about the developed models during the design phase as well as during and after the system’s executions. We present the peculiar feature of both proof procedures, studying how they can be combined for giving complete support to the targeted systems, from static veriﬁcation to enactment, run-time veriﬁcation&monitoring, a-posteriori veriﬁcation and mining. The feasibility and eﬀectiveness of the approach are investigated spanning from theoretical aspects, like proofs of formal properties and comparison with temporal logics, to practical applications, experimental evaluations, real industrial case studies and concrete tools.

1.1 Main Contributions of the Book The main novel contributions of this monograph in the speciﬁcation and veriﬁcation of interaction models can be grouped into ﬁve categories: • • • • •

speciﬁcation of open declarative interaction models; static veriﬁcation of interaction models; run-time veriﬁcation of interaction models; monitoring and enactment facilities; a-posteriori veriﬁcation and declarative process mining.

1.1.1 Speciﬁcation of Open Declarative Interaction Models In the book, open declarative interaction models are characterized both in an informal and formal way. The abstractions of activity, event, time, compliance, ﬂexibility and openness are introduced, discussing their grounding in several challenging application domains: BPM, SOC, CGs and MASs. The notion of Event-Based System (EBS) is introduced to comprehensively characterize all these domains. A sound and well-founded framework for specifying declarative open interaction models is provided. Declarative open interaction models target EBSs by providing a good balance between compliance and ﬂexibility, overcoming

4

1 Introduction

over-speciﬁcation and over-constraining issues. The framework, called CLIMB, centers around the formalization of the ConDec language in terms of reactive rules, expressed in a fragment of the SCIFF language. The translation has a twofold advantage: on the one hand, non IT-savvy have the possibility of developing speciﬁcations by working at the graphical level of ConDec, avoiding the direct manipulation of rules; on the other hand, ConDec is equipped with an underlying formal semantics, tailored to the notion of compliance. Thanks to the expressiveness of SCIFF, ConDec is then extended along diﬀerent dimensions: data-related aspects, non atomic activities and metric temporal constraints (delays and deadlines). The resulting speciﬁcation framework is compared to the one of propositional Linear Temporal Logic (LTL). The theoretical investigation provides some insights into the qualitative and quantitative characterization of time, shows that the CLIMB-based formalization of ConDec is sound with respect to the LTL-based one, and ultimately points out that SCIFF is strictly more expressive than LTL. 1.1.2 Static Veriﬁcation of Interaction Models Although declarative technologies improve readability and modiﬁability, and help reducing programming errors, what makes systems trustworthy and reliable is formal veriﬁcation. Static veriﬁcation aims at verifying the model during the design phase, before the execution. It provides support for guaranteeing a-priori that the model will behave, during the execution, in a consistent manner, enabling the premature identiﬁcation of errors and undesired situations which, if encountered at run-time, could be costly to repair or could even compromise the entire system. The book identiﬁes several kinds of relevant static veriﬁcation tasks, covering both single interaction models as well as the composition of multiple models, and taking into account also the possible presence of a global choreography model. It then shows how such veriﬁcation tasks can be either undertaken by the g-sciff proof procedure, or reduced to a model checking problem. Being CLIMB formalized on top of a fragment of First Order Logic, it suﬀers from semi-decidability issues, and cannot guarantee termination in the general case. To overcome termination issues, we propose a preprocessing technique which analyzes the ConDec model at hand, detecting the presence of potential sources of non termination, and taking proper countermeasures if it is the case. An extensive quantitative evaluation of g-sciff is carried out, investigating its performance and scalability. Its behavior is compared to the one of state of the art explicit and symbolic model checkers. 1.1.3 Run-Time Veriﬁcation, Monitoring and Enactment Facilities After the design phase, an interaction model is instantiated and executed inside an EBS. Each instance is grounded to a set of concrete interacting

1.1 Main Contributions of the Book

5

entities, whose (unpredictable) behavior must comply with the prescriptions of the model. Two diﬀerent scenarios arise, depending on whether the interacting entities belong to the same system in which the model has been developed or not. If so, they must be supported during the execution, keeping them constantly informed about the impact of their actions on the prescriptions of the model, and about the enabled and forbidden activities. This task is called enactment. If, instead, interacting entities belong to a third party system, or act in a completely autonomous, uncontrollable and possibly untrusted manner, they must be monitored, assessing whether they are eﬀectively behaving as expected and detecting the occurrence of a violation as soon as possible. Run-time veriﬁcation and monitoring deal with this issue. In the book, the sciff and g-sciff proof procedures are combined to deal with run-time veriﬁcation, guaranteeing that possible violations are identiﬁed as soon as possible. Furthermore, a reactive version of the Event Calculus (EC) [146, 218] is axiomatized on top of SCIFF, investigating its formal properties and using it to tackle a number of challenging issues: • modeling of properties that vary over time, and characterization of the eﬀects of activities; • monitoring ConDec (optional) constraints; • prompt detection and reiﬁcation of violations, generating alarm events; • support for compensation mechanisms. It is shown how the joint exploitation of all these reasoning techniques can support the enactment of ConDec models, detecting the execution of activities which would surely lead to eventually encounter a violation, and tracking the status of each constraint. 1.1.4 A-Posteriori Veriﬁcation and Declarative Process Mining A plethora of EBSs store all the events occurred during the execution of their instances, enabling their retrieval and a-posteriori analysis. The set of stored execution traces provides a fundamental insight about the real behavior of the system. It is therefore extremely important to provide suitable technologies for analyzing such execution traces, e.g. to compare the real behavior with the designed models, or to assess whether business goals have been eﬀectively achieved or not. In the BPM ﬁeld, this task is commonly called process mining. Nevertheless, its application is not restricted to business process models, but it can seamlessly target any EBS equipped with logging facilities. The application of the declarative technologies presented in this book gives raise to declarative process mining. In particular, two fully implemented mining techniques are presented in the book. The ﬁrst tool, called SCIFF Checker, veriﬁes whether the collected execution traces comply with (reactive) business rules, speciﬁed using a textual pseudo-natural notation which resembles the CLIMB language. Its application on three concrete and heterogeneous industrial case studies is reported.

6

1 Introduction

The second tool, called DecMiner, is one of the few attempts present in the literature to discover declarative models. In particular DecMiner contains a discovery algorithm which applies Inductive Logic Programming techniques to derive a general declarative speciﬁcation starting from two sets of execution traces, where the ﬁrst set represent correct behaviors, while the second one encompasses the undesired ones. The derived speciﬁcation is expressed either in CLIMB or ConDec, thus providing both a textual and graphical representation of the produced results. Both tools have been fully implemented as part of the ProM framework [238], one of the most popular process mining environments.

1.2 Organization of the Book The book is organized in four parts: I. II. III. IV.

Speciﬁcation; Static Veriﬁcation; Run-Time and A-Posteriori Veriﬁcation; Conclusions and Future Work.

1.2.1 Part I: Speciﬁcation The ﬁrst part of the book focuses on the graphical and formal speciﬁcation of declarative open interaction models. Chapter 2 gives an accessible and precise overview of diﬀerent application domains (Business Process Management, Service Oriented Computing, Clinical Guidelines and Multi-Agent Systems) in which declarativeness and openness are needed to complement the state of the art procedural and closed approaches. In particular, the need for declarative and open approaches is advocated to provide a suitable balance between compliance and ﬂexibility. An informal deﬁnition of open and declarative interaction models is provided, introducing the logical architecture of a desired supporting framework. Chapter 3 provides a critical overview of the ConDec language, originally developed by Pesic and van der Aalst for the ﬂexibile speciﬁcation of Business Processes with a declarative and open ﬂavor. The usability of ConDec is empirically assessed in the light of the cognitive dimensions of notations [122]. The framework of propositional Linear Temporal Logic (LTL) is introduced, sketching how it has been exploited to formalize ConDec. Chapter 4 presents the CLIMB rule-based language, a fragment of the SCIFF Computational Logic-based language, which addresses the formal speciﬁcation of interaction protocols in open Multi-Agent Systems. The syntax and declarative semantics of the language are presented, giving

1.2 Organization of the Book

7

a formal account to the notion of compliance. Finally, some interesting formal properties related to the CLIMB fragment are discussed. Chapter 5 throws a bridge between the CLIMB and the ConDec languages, by proposing an automatic translation of each ConDec construct into a set of CLIMB rules. In this way, ConDec is equipped with a meaningful, declarative semantics. Interaction models can be speciﬁed at the graphical level, automatically obtaining the corresponding formal representation. A theoretical investigation about LTL and CLIMB is provided, assessing the equivalence of the CLIMB-based and the LTL-based representations of ConDec, and comparing their expressiveness. Chapter 6 introduces and studies some very signiﬁcant extensions to ConDec, exploiting the ﬁrst-order nature of the CLIMB language. In particular, ConDec is extended with metric temporal constraints, data-aware conditions, and a non atomic model of activities. It is shown that all the proposed extensions can be expressed in CLIMB, thus guaranteeing that the ConDec-CLIMB mapping is still valid. Chapter 7 concludes this part with a discussion of related work and a summary. 1.2.2 Part II: Static Veriﬁcation The second part of the book deals with the static veriﬁcation of interaction models, providing support during their design phase. Chapter 8 introduces the problem of design-time veriﬁcation in open declarative interaction models. In particular, the existential and universal veriﬁcation of properties are deﬁned, dealing not only with single interaction models, but also with the composition of local models, as well as with their conformance to a global choreography speciﬁcation. Chapter 9 presents two proof-procedures (sciff and g-sciff) to be used for reasoning from CLIMB speciﬁcations, and formally investigates their properties of termination, soundness and completeness. Chapter 10 addresses the static veriﬁcation of ConDec models by means of the g-sciff proof procedure. After having shown how all the veriﬁcation techniques presented in the previous chapter can be tackled by g-sciff, we delve into the problem of non-termination, describing a preprocessing procedure for identifying and treating two critical classes of ConDec models, which could cause the proof procedure to run indeﬁnitely. Chapter 11 conducts an experimental evaluation of the proposed methods, showing that g-sciff is an eﬀective technology for statically verifying ConDec models. It is presented how the static veriﬁcation tasks can be also formulated as a model checking problem, comparing the performance of g-sciff with that of state-of-the-art model checkers. Chapter 12 discusses related work and gives a summary of this second part.

8

1 Introduction

1.2.3 Part III: Run-Time and A-Posteriori Veriﬁcation In the third part of the book, the run-time and a-posteriori veriﬁcation of interaction models is presented, providing support during and after their execution. Chapter 13 introduces the problem of open declarative interaction model run-time veriﬁcation, and discusses the application of the sciff and g-sciff proof-procedures to the run-time veriﬁcation of interacting entities with respect to ConDec models. Chapter 14 discusses the issue of monitoring the interacting entities during the execution. A reactive form of Event Calculus is axiomatized on top of sciff, enabling dynamic reasoning facilities over the eﬀects of actions and the status of each ConDec constraint. These features are exploited to monitor ConDec optional constraints, to catch and reify violations, and to deal with compensation mechanisms. The combination of REC and the two proof procedures is ﬁnally exploited to address the enactment of ConDec models. Chapter 15 presents innovative a-posteriori veriﬁcation techniques based on CLIMB. Such techniques are applied to event logs containing the execution traces of already completed instances of the system under study, towards declarative process mining. In particular, two declarative process mining tools are presented, reporting the experience made in some real case studies. Chapter 16 concludes with related work and summary. 1.2.4 Part IV: Conclusion and Future Work The last part of the book contains the conclusion and a discussion of open challenges and future work.

1.3 Web Site All the veriﬁcation techniques, tools, benchmarks and examples presented in the book can be download from http://www.lia.deis.unibo.it/research/climb/ The web site contains also instructions, errata, papers and any additional information.

Part I

Speciﬁcation

2 Declarative Open Interaction Models The limits of my language mean the limits of my world — Ludwig Wittgenstein

In this Chapter, we provide an informal yet precise characterization of open declarative interaction models along diﬀerent dimensions, namely modeling abstractions, time, compliance, degree of ﬂexibility and degree of openness. We then give an overview of several application domains in which interaction plays a central role: Business Process Management (BPM), Service Oriented Computing (SOC), Clinical Guidelines (CGs) and Multi-Agent Systems (MASs). We discuss the drawbacks of procedural and closed approaches when dealing with such settings, motivating why we claim that they should be complemented with an open and declarative perspective. Finally, we describe a generic framework for managing the life cycle of open declarative interaction models, spanning from their design to their execution, monitoring and a-posteriori veriﬁcation, and propose how to ﬁll its building blocks.

2.1 An Informal Characterization of Interaction Models The complexity of today’s information systems poses important engineering challenges. Thanks to the increasing pervasiveness of networks, computers and communication modalities, this complexity is often faced decomposing them, delegating the execution of their sub-parts to a set of autonomous, distributed and possibly heterogeneous entities. These entities interact and collaborate to the aim of achieving the overall goal of the system. Models developed to describe these systems are called interaction models. 2.1.1 Interaction Abstractions: Activity, Event, Execution Trace An interaction model focuses on the dynamics of a system rather than on its static organization: its purpose is to target the overall behavior that must be guaranteed by the interacting entities towards the fruitful accomplishment of the system’s strategic goals while respecting, at the same time, its requirements and constraints. For example, the items involved in an auction must M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 11–45, 2010. c Springer-Verlag Berlin Heidelberg 2010

12

2 Declarative Open Interaction Models

be sold by adhering to the rules and norms which discipline how oﬀers can be placed by bidders, and how the winner is ﬁnally determined by the auctioneer. The dynamics of a concrete interaction is called instance of the system. An instance grounds the interaction model on a speciﬁc initial contexts and data, and is executed by a concrete set of participants playing the roles involved in the interaction model. E.g., in an emergency ward the sequence of treatments, exams, drug administrations executed by a group of health-care professionals on a single patient constitutes an instance of the “emergency ward management system”. The execution evolves as the interacting entities perform relevant activities, that represent (atomic) units of work, i.e., the steps of the in which the involved actors have to do something. They are the basic abstractions upon interaction models are built. The execution of an activity causes one or more relevant events to occur; each event is associated to a single time point. An activity is said to be atomic if its execution is traced by means of a single event, non atomic otherwise. Each instance is then completely characterized by the ﬁnite set of correlated events which occur during its execution; this set will be referred to as execution trace (or simply trace). In particular, we will use the term partial execution trace if the trace covers only a part of the instance evolution, complete otherwise. The set of complete execution traces characterizing the execution of all the system’s instances is called event log. In the general case, activities encompass actions made by a single participants without involving the other ones (e.g., the revision of a mechanical part) as well as communication between diﬀerent participants (e.g., informing the customer that a given item is out of stock). Example 2.1.1 (Interaction Model). The set of policies and rules, disciplining the executions of an e-commerce payment protocol involving a customer and a seller, is an interaction model, whose (atomic) activities are the set of message templates supported by the protocol. An instance of the protocol is characterized by a sequence of messages following its templates, exchanged between two agents playing the role of customer and seller. For example, supposing that alice is a customer and hatter a seller, the sequence of events • alice sends a payment message to hatter at time 5, referring to item tea; • at time 7, hatter replies to alice informing her that tea is out of stock; could represent the execution trace describing an instance of the protocol. Being the concept of event the core ﬁrst-class object of interaction models, in the remainder of the book we will refer to the targeted systems as Event-Based Systems (EBSs)1 .

1

In the context of this book, the term Event-Based System (EBS) has a broader meaning than in the distributed systems setting, where the focus is on events exchanged by software components at the middleware level [179].

2.1 An Informal Characterization of Interaction Models

13

2.1.2 Characterization of Time Since interaction models focus on the dynamics of a system, the temporal dimension plays a central role in them. Events occur “in time”, and therefore the ontological characterization of time has a deep impact on the nature of interaction models. From a foundational point of view, the time ontology can be characterized along many diﬀerent dimensions, which link atemporal assertions with a temporal reference and provide a meaning to such a temporal reference, denoting its structure and its temporal entities together with their relations [257]. We focus here only on the most relevant aspects for our purposes; the interested reader may refer to [216, 257] for a comprehensive survey on the topic. First of all, it is important to remember that in EBSs the temporal entities correspond to event occurrences. The two temporal primitive candidates for denoting the occurrence of an event are points vs intervals. The point-based temporal primitive associates event occurrences to single instants, whereas the interval-based primitive provides intervals and their durations as ﬁrstclass objects. For example, the sentence “the white rabbit arrived at work at 9:00 o’clock” has a point-based nature, whereas “yesterday the rabbit was not at home” relies on a interval-based approach. Temporal primitives are located in time, and therefore the second step consists in the deﬁnition of the temporal ordering among primitives, i.e., of the structure of time. In particular, a time structure could be: Linear vs. Branching. If the time structure has a linear topology, then each time instant has exactly one predecessor and one successor2; conversely, a branching structure enables multiple precedessors (branching in the past) and/or successors (branching in the future). Bounded vs. Unbounded. A bounded time structure states that there exists an initial (ﬁnal) time point which does not have predecessors (successors); if it is not the case, then time is unbounded. Hybrid approaches combine the two notions, stating that time is bounded with respect to the initial time but not to the ﬁnal time or vice-versa. Finally, temporal entities are connected by means temporal relations. Let us focus on the basic binary relations. They strongly depend on the chosen primitive: in the point-based case, equality (=), inequality (=) and precedence (<) suﬃce, whereas in the interval-based case 13 diﬀerent basic relations exist [11]. These relations express relative positions of event occurrences, and are called qualitative. An example of binary, point-based temporal relation is contained in the following sentence: “the white rabbit arrived at work before Alice”. Basic relations are then combined by means of logical operators, such as conjunction and disjunction, to obtain more complex constraints. However, this is still not enough: quantitative relations can be introduced to predicate 2

If the structure is bounded on the past (future), then the only exception is the initial (ﬁnal) time.

14

2 Declarative Open Interaction Models

upon “distances” between temporal entities [216], expressing the chronological nature of an EBS. Quantitative constraints may be used to express latencies (“the rabbit took 20 minutes to get to work”) and deadlines (“the rabbit should arrive at work before 9:00 o’clock”). In the remainder of this book, we will rely on the following assumptions: Time is point-based. As discussed in Sect. 2.1.1, activities are the basic building blocks of interaction models, and they are represented and traced by one or more corresponding atomic events. In the real world, the event logs storing the execution traces characterizing the executions of an EBS are indeed composed by event occurrences associated to single time points [253]. Time is bounded. Each execution trace has a ﬁxed starting time, corresponding to the time at which the instance is created by the interacting entities, and a ﬁnal time, whose value is not known a-priori, at which the interaction will terminate. Boundedness on the ﬁnal time is needed because interaction models are developed to achieve a desired state of aﬀairs (such as a business goal) in ﬁnite time, or to ﬁnitely detect that such a state of aﬀairs cannot be reached. Time is linear. As pointed out in [255], the debate around linear vs branchingtime frameworks goes back to early 1980s. Each one has its own strengths and weaknesses, and none of them has ultimately dominated the other. We opt for linear time building on [255], where Vardi argues that branchingtime approaches are unintuitive and hard to use, while linear-frameworks are more intuitive and understandable, while maintaining a satisfactory level of expressiveness. Furthermore, it is worth noting that in our setting execution traces are sequences of events [253], and therefore they ﬁt well in a lineartime framework. Obviously, the choice of linear time does not undermine the possibility of accommodating alternatives and decisions during the execution, which is a fundamental requirement towards ﬂexibility: according to Rescher and Urquhart [201], it is the course of interaction which branches in a linear time structure, and therefore we have a “branching in time” instead of a “branching of time”. We do not instead ﬁx whether the temporal relations have a qualitative or a quantitative nature. We leave this choice open discussing its impact on interaction models throughout the book. 2.1.3 Compliance According to Merriam-Webster3 Compliance is the act of conforming, submitting, or adapting (as to a regulation or to another’s wishes) as required or requested. 3

http://www.merriam-webster.com

2.1 An Informal Characterization of Interaction Models

15

In the context of interaction models, such requirements and requests refer to the set of stated rules and regulations concerning any aspect of the targeted system, taking into account internal and external stakeholders. The need for compliance has seen a rapid growth in the last years, due to the outbreak of high-proﬁle ﬁnancial scandals (like Enron and WorldCom in the USA). New legislation, such as the Sarbanes-Oxley Act, has been produced as a response, increasing the investment of companies in corporate governance and in the corresponding tools and methodologies, to support the alignment and monitoring of their BPs with respect to external regulations. In particular, Zhang has estimated that companies are paying a total amount of $1.4 trillion market costs in order to meet the requirements imposed by the Sarbanes-Oxley Act [270]. Under the umbrella of the generic term “compliance rule”, we ﬁnd a plethora of diﬀerent kinds of knowledge, including: • business goals; • internal policies, protocols and best practices; • internal control-ﬂow aspects, deﬁning ordering constraints on the way certain activities must be executed; • business rules, used by the interacting entities to take strategic decisions during the execution; • business contracts, use to regulate the mutual obligations between the system under study and external customers or companies, including for example the negotiated Quality of Service (QoS); • organizational policies and procedures, such as administrative and security policies; • external regulations and norms, referring to jurisdictional and legislative concerns (the Sarbanes-Oxley Act is a notable example). Compliance rules then play a twofold role: on the one hand, they embody the internal knowledge used to guide the behavior of interacting entities, whereas on the other hand they recommend how to act according to the law. They can be therefore perceived as an aspect of the interaction model which introduces centralized (i.e., independent from the single participants) decisions about how to carry out the execution [191]4 . Since the overall eﬀect of compliance rules is to constrain the behavior of the involved parties, restricting the acceptable execution traces, we will refer to them as (business) constraints. A key aspect of business constraints is that they need to be practicable. As pointed out by Ross [204], being practicable means that “a person who knows about a business rule could observe a relevant situation (including his or her own behavior) and decide directly whether or not the business was complying with the business rule”5 . An instance of the targeted system is said to be 4 5

In [191], the term support is adopted in place of compliance. Business rules are a special kind of business constraints, namely business constraints that are under the internal business jurisdiction.

16

2 Declarative Open Interaction Models

correct or compliant with an interaction model if its execution trace adheres to all its business constraints. If an execution trace is compliant with the model, we say that the model supports such a trace. Example 2.1.2 (Business constraints in the medical setting). Let us focus on the medical domain, introducing some business constraints which reﬂect the diﬀerent kinds of knowledge identiﬁed above. • The sequence of steps that must be followed to perform a laboratory analysis on a specimen, constitutes an internal protocol. • The set of regulations governing the privacy of patients is an external legislative concern. • When a person is hospitalized, a business contract is stipulated between the inpatient and the health-care structure; the contract must be then honored by both parties thereafter. • The fact that “each time a patient has an examination, then a corresponding report must be delivered by the health-care structure within one month”, is an example of administrative policy. • The four eyes principle (also called two-man rule) is an internal policy stating that a certain critical action must be performed by two diﬀerent persons; e.g., a report produced from a laboratory analysis must be subject to a double approval, performed by two diﬀerent physicians. A slightly diﬀerent version of the four eyes principle states that two activities cannot be performed by the same entity. As we will see throughout the book, business constraints are of very diﬀerent kinds. Let us provide some examples to attest this variety: • “when the order is successfully committed by the customer, the seller is committed to deliver the order within 7 days at most” is a time-ordered constraint (involving a quantitative time constraint); • “the application form must be sent by e-mail and via fax” is a timeunordered constraint; • “the ATM machine will accept at most three payment attempts” is a cardinality constraint; • “after having closed an order, it is not possible to add further items” is a negative constraint; • “when the customer must pay for the order, she can choose between credit card or cash as suitable payment methods” represents an opaque, non deterministic choice. 2.1.4 Flexibility Roughly speaking, ﬂexibility is the model’s capability of embracing change and promptly adapting to it. A ﬂexible approach leaves the entities as much as possible free of exploiting their own expertise to take strategic decisions,

2.1 An Informal Characterization of Interaction Models

17

evaluate opportunities and ﬁnd the best way to interact. In [215], Schonenberg et al. identify a taxonomy of four distinct types of ﬂexibility, which act on diﬀerent stages of the system’s life cycle, and involve either the modeling language used to specify interaction, or the underlying supporting environment. We brieﬂy recall them in the context of interaction: Flexibility by design. The ability of accommodating ﬂexibility directly at the language level, dealing with it during the design of an interaction model. This requires a speciﬁcation language able to leave many possible alternatives open to the interacting entities, which can then dynamically select the best way of execution. Flexibility by underspeciﬁcation. The ability of the modeling language to support incomplete speciﬁcations, and of the environment to support the “late modeling” of the unspeciﬁed fragments, during the execution. Here, ﬂexibility is guaranteed by the fact that parts of the interaction model can be deﬁned on-the-ﬂy. Flexibility by deviation. The ability of the support system of accommodating (occasional) deviations from the “ﬁxed” prescriptions contained in the model, which is not required to be ﬂexibility-oriented. Flexibility by change. The ability of the environment to handle both occasional and permanent unforeseen behaviors, enabling, for the latter situation, the possibility of changing the interaction model. In this book, we will mainly focus on ﬂexibility by design, towards the development of ﬂexible models starting from their creation and along their whole life cycle. While the other types of ﬂexibility mainly focus on the execution phase, i.e., the interacting entities are supported in the resolution of ﬂexibility issues at run-time, the purpose of ﬂexibility by design is to equip the modeler with suitable abstractions for accounting with such issues. When it comes to the characterization of the “ﬂexibility by design” dimension, at the two opposite sides we ﬁnd procedural approaches versus declarative ones. Given a problem to be solved, the diﬀerence between these two perspectives can be roughly summarized as follows: • a procedural approach aims at deﬁning a rigid, speciﬁc solution to the problem; • a declarative approach focuses instead on the problem itself, aiming at the identiﬁcation of its requirements, features and constraints, and delegating the synthesis of a solution to a general-purpose algorithm. Declarative approaches separate logic aspects (what should be accomplished) from control aspects (how to accomplish it), in the spirit of the well-known Kowalski’s pseudo-equation [144]: ALGORIT HM = LOGIC + CON T ROL In other words, declarative models specify what should be done without being concerned with how it should be done.

18

2 Declarative Open Interaction Models

In the context of interaction models, a procedural speciﬁcation is a complete description of the allowed ﬂows of activities, that must be strictly followed when executing an instance (low degree of ﬂexibility), whereas a declarative speciﬁcation focuses on the (minimal) set of business constraints that must be guaranteed in order to correctly interact (high degree of ﬂexibility). Example 2.1.3 (Flattening of a list). To concretely show the diﬀerence between a declarative and a procedural style of modeling, let us present a simple case study focused on programming languages. In particular, let us consider the problem of ﬂattening a list: given a list of lists In, devise and implement an algorithm which returns a list corresponding to the ﬂattening of In. If In is a simple element, then the result should be a list containing that element. For example, when applied to the list [f, [l, a, [t]], [m, e]], the algorithm must produce the ﬂattened list [f, l, a, t, m, e] as result. When the modeler faces the problem by adopting a declarative perspective, she must focus on the inherent characteristics of the problem, i.e., on the definition of “ﬂattening”, trying to reformulate it in a clear and precise manner. An unambiguous deﬁnition is: • the ﬂattening of the empty list is the empty list; • the ﬂattening of a simple element is the list containing that element; • the ﬂattening of a non-empty list L corresponds to the concatenation of the lists obtained by ﬂattening the head and the tail of L. This deﬁnition can be directly represented using the Prolog declarative language [49, 227]: flatten([],[]). flatten(El,[El]):- atom(El). flatten([H|T],Lout):flatten(H,Hout), flatten(T,Tout), append(Hout,Tout,Lout). This program expresses the logic part of the algorithm, whereas control is provided by the general purpose Prolog engine, based on SLD(NF)-resolution [143]. Diﬀerently from declarative programming, a procedural/imperative programming style would instead require to synthesize a speciﬁc ﬂow of instructions to solve the problem. Listing 1 reports a possible solution in pseudo-code, where a Lisp-style terminology is used for lists.

2.1 An Informal Characterization of Interaction Models

1 2 3 4 5 6 7 8 9 10 11

19

function: flatten(In, the list to be ﬂattened) returns : Out, the ﬂattened version of In begin if empty(In) then return emptyList(); else if atom(In) then return cons(In,emptyList()); else Hout ← flatten(head(In)); Tout ← flatten(tail(In)); return append(Hout ,Tout ); end end

Algorithm 1: ﬂatten(In)

2.1.5 Openness An interaction model contains a ﬁnite number of activities and (ﬂow) constraints. A question then arises: how does the interaction model relates with the information that has not been explicitly captured? Again, there are two opposite extremes: • a closed interaction model makes the assumption that all the behaviors which have not been explicitly enumerated in the model are forbidden; • an open interaction model makes the opposite hypothesis, leaving the behavior of interacting entities unconstrained unless explicitly speciﬁed. An open interaction model is therefore suitable for dealing with open system, i.e. systems in which “the behavior of the members and their interactions cannot be predicted in advance” [132]. Semi-open approaches mediate between these two extremes, supporting the development of closed models which partially embrace unpredicted events and executions, e.g. when certain (exceptional) conditions arise, or when certain “special” events are involved. Example 2.1.4 (closure vs openness). Let us consider the following business constraints: “you have to do a, then b, and then c”. Under a closed interpretation of these business constraints, the word “then” is considered as a very strict ordering relationship, and thus only the execution trace containing the exact sequence a → b → c would be supported by the model. Conversely, by adopting an open perspective the word “then” can be interpreted in diﬀerent ways, ranging from a completely closed interpretation to a completely open one. This latter interpretation only imposes that the execution trace contains a, b and c in the requested order, but other activities can be performed as well, in an arbitrary order, number and position with respect to a, b and c.

20

2 Declarative Open Interaction Models

Therefore, inﬁnite compliant traces can be produced . For example, the execution trace b → a → d → b → c → e would be accepted; the execution trace b → a → d → c → b → e would be instead rejected, because after the execution of b no activity c is executed, contradicting one of the required business constraints. With an open perspective, the mere presence of positive business constraints, i.e., constraints stating what should be done under certain circumstances, expressing the mandatory behaviors, is not suﬃcient to capture the complexity of EBSs. In fact, each open interaction model would always support an inﬁnite number of execution traces, provided that they at least satisfy the mandatory behavior requested by the business constraints. To overcome this limit, an open modeling language should support also negative business constraints, to state what cannot be done under certain circumstances, expressing the forbidden behaviors. The combination of positive and negative constraints makes it possible to cover a variety of cases, and even to partially close the model, as attested by the following example. Example 2.1.5 (negative business constraint). Let us consider the following business constraint: “when a payment request is received by the bank, then the bank must immediately update the account of the requestor”. Here, the term “immediately” suggests that the ordering relation between the reception of the payment and the account update must be interpreted in a strict, closed manner. To deal with such a constraint in an open setting, a combination of two diﬀerent rules could be adopted: • a ﬁrst positive constraint expresses the ordering between the two activities, i.e., that after a payment reception, the account must be updated; • a second negative constraint expresses that the two activities must be executed next to each other, namely that no further activity can occur in between. It is worth noting that openness and ﬂexibility are tightly related. An open modeling language is apt to ﬂexibility by design: the ability of accommodating the execution of unforeseen activities, which is an essential feature of open approaches, is the ﬁrst step towards embracing change.

2.2 Business Process Management Companies can reach their business goals and produce a speciﬁc service or product that is of value to the customer only if all the involved participants and activities are well coordinated and regulated. To achieve this goal, a collection of related activities aimed at ﬁnalizing a service or product is organized in a Business Process (BP). As deﬁned in [261]:

2.2 Business Process Management

execution traces

21

diagnosis

on uti ec ex

de sig n

feedback

Business Process life cycle

Business Process

Fig. 2.1. The Business Process life cycle

A Business Process consists of a set of activities that are performed in coordination in an organizational and technical environments. These activities jointly realize a business goal. Each Business Process is enacted by a single organization, but it may interact with BPs performed by other organizations. Business Process Management (BPM) is a collection of methods and techniques for assisting business practitioners, employees and the technical staﬀ in the management of BPs along their entire life cycle [97], depicted in Fig. 2.1. The ﬁrst phase of the BPM life cycle is the design stage, in which the BPs of the company are analyzed and modeled. To develop a BP model, process modeling languages are employed. Such languages typically provide a graphical notation, for the sake of readability and user-friendliness. The obtained model is then implemented in a BPM system, an information system acting as an engine for the execution of process models. The execution engine guides the work of the involved participants, supporting the enactment of diﬀerent process instances. Each performed activity is tracked inside the information system, storing all the generated execution traces. In the last diagnosis phase, the information recorded in the collected traces is analyzed to evaluate whether business goals have been eﬀectively achieved, exploiting the outcome of this analysis to take new strategic decisions. The outcome of the diagnosis stage is then used as a feedback for the original BP models, in order to improve them and better align them with the internal expected outcome and the needs of external stakeholders.

22

2 Declarative Open Interaction Models

A start event

A task

Identify Payment Method

Cash

An end event Accept Cash

Payment method?

A sequence flow Credit Card

Prepare Package for Customer

Process Credit Card

A gateway "decision"

Fig. 2.2. A simple Business Process (BP) modeled in BPMN (adapted from [262])

2.2.1 Modeling Business Processes In the last years, a huge number of BP modeling languages have been proposed by industry and academia. Some notable examples are BPMN [184], YAWL [231], XPDL [265] and BPEL [183]6 . Despite their graphical diﬀerences and speciﬁc peculiarities, all these languages mainly focus on the control-ﬂow perspective of BPs, i.e., on deﬁning the possible orderings in which activities can be executed over time. Concerning control-ﬂow aspects, they all rely on three abstraction types: activity, the atomic unit of work; sequence ﬂow, the basic connection deﬁning a strict ordering relation between two activities, i.e., that they must be performed next to each other; gateway, a point in the process where the ﬂow splits into multiple ﬂows, or multiple ﬂows are merged into a single ﬂow. Example 2.2.1 (A BPMN model). Fig. 2.2 shows a simple BP represented in BPMN. The ﬁrst activity that must be performed when executing an instance of the BP is the Identify Payment Method activity, used to identify which kind of payment is preferred by the customer. Then, depending on the preferred payment, one between the Accept Cash activity and the Process Credit Card is chosen (the decision is represented by a diamond-shaped gateway). Finally, a package is prepared for the customer, leading the instance to its conclusion. As shown in Example 2.2.1, speciﬁcation languages following the “sequence ﬂows&gateways” paradigm lead to produce procedural and closed models. They are procedural because the language imposes to explicitly tackle all the ordering constraints among activities, synthesizing a set of pre-deﬁned ways 6

A comprehensive pattern-oriented evaluation of the major BPM modeling languages, including standards, open-source and commercial solutions, is being carried out by the Workﬂow Patterns [239] initiative. Check it out at http://www.workflowpatterns.com

2.2 Business Process Management

23

for accomplishing the business goal (in the example, receiving the payment and preparing the package); BPs then become a rigid scheme representing one ﬁxed algorithm for orchestrating the work. They are closed because the execution of each activity is allowed and mandatory at a given time only if the ﬂow has currently reached that activity; by considering Fig. 2.2, the person responsible for packages can and must begin to prepare a package only after the cash has been accepted or the credit card has been processed. Example 2.2.2 (Execution traces compliant with a BPMN model). Let us again focus on the Business Process Modeling Notation (BPMN) model depicted in Fig. 2.2. Due to the closure of Business Process Modeling Notation (BPMN), the model supports only two execution traces: • the sequence start → Identify Payment Method → Accept Cash → Prepare Package for Customer → end, when the customer chooses to pay by cash; • the sequence start → Identify Payment Method → Process Credit Card → Prepare Package for Customer → end, when the customer chooses to pay by credit card. 2.2.2 Limits of Procedural Business Process Modeling A procedural and closed perspective in BPs modeling is suitable when the domain under study presents a high degree of predictability and repetitiveness. This is the case of production workﬂows [152]). Such workﬂows have an intrinsic rigid nature: they aim at providing full support for well-structured BPs, imposing the explicit deﬁnition of all the allowed pathways. There are application domains in which such a rigidness is not only preferable, but is a mandatory requirement: just think to e-banking transactions. However, there are also a plenty of situations where BPs are unpredictable and frequently changing. Processes in Small and Medium Enterprises, medical treatments, groupware systems, disaster recovery procedures are examples of domains characterized by diﬀerent degrees of autonomy, unpredictability and turbulence, where the ability of adapting to environmental changes and to the acquisition of new knowledge is a key requirement. In all these cases, the experience, knowledge, imagination and creativity of domain experts play a vital role, and should not be clipped by the rigidity of closed, procedural approaches. A procedural style of modeling clashes with the unstructured declarative knowledge of business practitioners, who perceive each BP as a “container” of many diﬀerent aspects, including business goals, business rules, external regulations, internal policies and best practices (see Sect. 2.1.3). To ﬁll this gap, the connection between business experts and BP models is mediated by the presence of a technical person, whose assignment is to extract all the relevant business constraints from the experts, trying to combine the whole set of constraints towards the synthesis of a compliant procedural speciﬁcation (see Fig. 2.3).

24

2 Declarative Open Interaction Models business constraints

policies

knowledge level

declarative model

design level

procedural model

business rules

regulations

legislation

Fig. 2.3. Procedural vs declarative perspective in Business Process modeling

The limits of procedural and closed BP modeling languages have been put forward by many authors [241, 259, 249], who argue that to be successfully adopted, BPM technologies must make a trade-oﬀ between controlling the way workers do their business (compliance) and turning them loose to exploit their expertise during the execution (ﬂexibility). Stemming from this observation, diﬀerent BP modeling languages and management systems have been developed to accommodate the types of ﬂexibility discussed in Sect. 2.1.4, like for example Adept2 [84], Flower [39] and ConDec [192, 193]. In her PhD dissertation [191], Pesic carries out a deep investigation of these limits, pointing out that the procedural nature of contemporary BPM approaches tends to determine the way companies organize work, forcing them to adjust their BPs to the underlying management system. This fact has a twofold impact: • people perceive the system as an obstacle, performing their concrete work outside the system and recording what has been done in a separate moment; • due to the gap between people’s preferred way of work and the system’s way of work, the risk of designing inappropriate BPs increases. In particular, the modeler could both incur in the risk of introducing noncompliant undesired behaviors, as well as of loosing acceptable executions. Furthermore, there is also an intrinsic diﬃculty related to the translation of the business constraints into corresponding execution ﬂows. This last issue will be discussed in Sect. 2.3.3 for the case of service choreographies, which are subject to the same problems when trying to derive a procedural speciﬁcation starting from a set of declarative business constraints.

2.3 Service Oriented Computing

25

Service Registry find

publish

network Service Consumer

interact

Service Provider

Contract

Fig. 2.4. Service Oriented Architecture

2.3 Service Oriented Computing Service Oriented Computing (SOC) is an emerging computing paradigm which employs services as the basic components towards the development of largescaled distributed applications in heterogeneous environments. Its underlying enabling technologies and languages are reaching a good level of maturity and a widespread adoption, drawing the interest of both software vendors and scientists [243]. As stated in [187]: The visionary promise of SOC is a world of cooperating services where application components are assembled with little eﬀort into a network of services that can be loosely coupled to create ﬂexible dynamic business processes and agile applications that may span organizations and computing platforms. Roughly speaking, services are self-contained software components which incapsulate computing functionalities, exposing their core business competencies over a network in the form of an usage contract/interface. Third-parties may utilize an exposed functionality by means of standardized languages and protocols, without a direct access to its concrete implementation. 2.3.1 Service Oriented Architecture The basic Service Oriented Architecture (SOA) is depicted in Fig. 2.4. The architecture involves three roles and three fundamental operations: • The service registry maintains a list of known service contracts together with their location, and provides support for searching a certain functionality, returning the location of a service able to accomplish it. • The service provider encapsulates a business function (or a set of business functions), exposing a corresponding usage contract, which can be sent to a service registry for publishing it.

26

2 Declarative Open Interaction Models

• The service consumer is the participant which requires a given functionality. If it is not aware of services able to accomplish the requested functionality, it has the possibility to consult the service registry in order to ﬁnd a suitable service. After having retrieved the contract and location of a suitable service, the consumer can ﬁnally interact with the provider by invoking the desired functionality as described in the contract. Heterogeneous service providers and consumers can eﬀectively interact only if the three operations of publishing, ﬁnding and interacting as well as the service contracts rely on standardized languages and protocols. Each concrete SOA implementation must then ﬁx its standards and protocols, tailored to the underlying network in which the implementation is deployed. Thanks to the widespread diﬀusion of the Internet, the web implementation of SOA is nowadays the most popular. In the web implementation, the functionalities provided by business applications are encapsulated within Web Services, whose usage contracts can be retrieved and used by consumers through a stack of Internet standards including: • HTTP for the transmission of messages. • XML for the representation of the messages content, and as the basis upon which the WS-speciﬁc languages are built; • SOAP [124] as an XML-based lightweight communication protocol intended for exchanging structured information, deﬁning the format of messages. • WSDL [68], an XML format for describing the usage contracts (also called interfaces) of services; each service is characterized as an endpoint operating on messages, providing at the same time an abstract deﬁnition of the supported operations and messages, and a concrete binding to an underlying network protocol and message format. • UDDI [236], a registry that stores services usage contracts and supports a set of standardized, publicly accessible XML-based APIs for publishing WSDL descriptions to the repository and querying the repository in diﬀerent ways. 2.3.2 Orchestration and Choreography The role of service consumer could be played by a human user but also by another service provider; in this way, the functionalities realized by single services can be composed, giving birth to complex collaborative distributed business applications. Organizations can mutually beneﬁt from each other by exposing their own functionalities and exploiting third-party services. The focus shifts from a functional view of services as business units oﬀering “atomic” operations, to the (distributed) BPs regulating the interaction inside a service composition. Two diﬀerent complementary approaches can be followed to realize/perceive a service composition [190]: orchestration and choreography (see Fig. 2.5).

2.3 Service Oriented Computing Company A Orchestration

27

Company B Choreography

Orchestration

Internal Service

Fig. 2.5. Orchestration and choreography

Orchestration perceives the collaboration by the point of view of a single participant. The party synthesizes an executable BP which can interact with internal and external services, delegating the realization of some activities to such services. Under this perspective, the execution is driven by the single party as well: it acts as an orchestrator, coordinating the other services and correlating the results obtained from them. The invoked external services are unaware that they are participating in a collaboration: the interaction state is handled by the orchestrator, while the orchestrated services perceive the interaction in a stateless manner. The orchestrator itself could be exposed as a single service, making it possible to realize even more complex “nested” orchestrations. BPEL is the current de-facto standard for developing service orchestrations; it provides an XML-based language for modeling the (procedural) BP describing the ﬂow of orchestration, and binding the involved activities to external WSDL interfaces. A BPEL engine drives the execution of the BPEL process instances, taking care of invoking the external service when needed. Example 2.3.1 (Orchestration). A company is interested in entering the ecommerce market by realizing a Business-To-Consumer (B2C) web portal selling books. Through the e-bookshop portal, the user can perform the following operations: • browsing and searching a book catalogue, obtained by merging two distinct already available catalogues – when a book is contained in both catalogues, the minimum price is shown; • buying the selected books by credit card, activating a corresponding physical delivery service. Although the perception of the user is of a single e-bookshop service, it is internally implemented as a workﬂow coordinating four diﬀerent external services: the two “real” catalogues for obtaining the informations about the books, a certiﬁed e-banking service for handling payment transactions in a secure manner, and a delivery courier service to manage the concrete dispatch of books.

28

2 Declarative Open Interaction Models 1st catalogue

seller

2nd catalogue e-bookshop Consumer

Provider (Orchestrator)

Choreography

e-banking

customer delivery service

Fig. 2.6a. Topology of a service orchestration

warehouse

Fig. 2.6b. Topology of a service choreography

When the user buys a book, the e-bookshop interacts with the e-banking service to check the validity of the received credit card, returning an error message to the customer or triggering a payment transaction. If the transaction is correctly completed by the e-banking service, the e-bookshop sends a message to the delivery service by providing the address of the customer, as well as the information about the book to be delivered. As shown in Fig. 2.6a, the e-bookshop is therefore responsible for the orchestration of these four services, guiding the interaction as a centralized controller. Diﬀerently from orchestration, choreography models the collaboration from a global, objective point of view, independently from the perception of the single interacting services. Its focus is not on executability, but rather on capturing the public multi-party contract which provides the necessary rules of engagement for making all the interacting entities correctly collaborate. The choreography vs orchestration perspective in a service composition is shown in Fig. 2.5. They are complementary; while orchestration focuses on the viewpoint of a single party, choreography is super partes: it abstracts away from the internals of participants and takes into account their mutual requirements and business constraints without assuming a unique center of control. The internal implementation of participants (i.e., the local BPs/orchestrations) can be seamlessly changed as long as their external observable behavior complies with the choreography constraints. This makes choreography especially suited for Business-To-Business (B2B) environments. In a B2B setting, several organizations share their own services to mutually beneﬁt from each other, trying to jointly accomplish a complex goal, impossible to be pursued alone. In this context, it is often impossible to make the assumption that one of the involved organizations will take the lead during the interaction, acting as a global orchestrator for the whole system. As pointed out in the WS-CDL speciﬁcation [141]: In real-world scenarios, corporate entities are often unwilling to delegate control of their BPs to their integration partners. Choreography oﬀers a means by which the rules of participation within a

2.3 Service Oriented Computing

29

collaboration can be clearly deﬁned and agreed to, jointly. Each entity may then implement its portion of the choreography as determined by the common or global view. Example 2.3.2 (Choreography). Three organizations wish to integrate their services in order to facilitate the purchase and delivery of mechanical parts. The ﬁrst company needs the mechanical parts, i.e., it plays the role of customer. The second company builds and sells the mechanical items, and exploits the facilities oﬀered by the third company, a warehouse, for storing them. In order to coordinate their services, the three companies jointly deﬁne a contract containing the business constraints that must be satisﬁed during the interaction, i.e., they model a purchase choreography. Fig. 2.6b sketches its topology, showing that, diﬀerently from orchestration, all the interacting services are equally responsible for carrying out the collaboration, and there is no global coordinator. Let us focus on a fragment of the choreography, regulating the decision taken by the seller after having received an order from the customer; the seller could freely decide whether to conﬁrm or refuse the order, but it must obey to the following constraints: • if the warehouse cannot ship the order, then the seller must refuse it; • the seller can accept the order only if the warehouse has previously accepted its shipment; • both the seller and the warehouse cannot accept and reject the same order, i.e., answers are mutually exclusive. 2.3.3 Limits of Procedural Choreography Modeling Modeling a service choreography is a hard task. On the one hand, its purpose is to constrain interacting services so as to ensure that their actual behavior complies with the agreed business constraints. On the other hand, it is of key importance to guarantee the autonomy of each party, turning it as much as possible loose to choose the internal BPs used to realize its part of the choreography, for the sake of service interoperability and replaceability. Autonomy, in turn, is preserved only if the choreography modeling language is ﬂexible. As pointed out in [30, 246], while the technologies for implementing and interconnecting basic services are reaching a good level of maturity, modeling service interaction from a global viewpoint, i.e., representing service choreographies, is still an open challenge: the leading current proposals, such as BPEL [183] and WS-CDL [141], fail to tackle the right balance between compliance and ﬂexibility. The main problem is that, despite the complementarity of choreography and orchestration, current mainstream approaches propose very similar languages and methodologies to model them both. They impose to completely specify the control and message ﬂow of the interacting services, forcing the user to adopt a procedural and closed style of modeling. We claim instead that choreography contracts constitute a form of declarative and open

30

2 Declarative Open Interaction Models

knowledge, which states what is forbidden and mandatory in services without giving details about how to carry out the interaction, nor making the unreasonable assumption that all the allowed behaviors can be explicitly captured. To illustrate the diﬃculty of handling even simple choreographies with classical procedural approaches, let us consider the business constraints introduced in Example 2.3.2. They leave many open possibilities to the concrete services which realize the collaboration. For example, when and how the warehouse is contacted is not speciﬁed in the contract, and there could be several choreography executions in which the warehouse is not contacted at all: an execution in which the seller autonomously decides to reject the order, without asking the opinion of the warehouse, is supported by the choreography. This example clearly shows that compliant executions are not explicitly enumerated in the choreography, but are instead implicitly supported, attesting that the choreography follows an open paradigm (see Sect. 2.1.5). When the modeler tries to encode this kind of knowledge using a classical procedural speciﬁcation language such as BPEL or WS-CDL, she is forced to explicitly enumerate all the implicitly supported executions, and to introduce further unnecessary details. Consider for example the adoption of BPMN collaborative diagrams to graphically capture the fragment of the purchase choreography. For simplicity, we do not consider the customer role, but focus on the interaction between the seller and the warehouse after having received the customer’s order. All candidate diagrams will surely contain two separated pools, one for the seller and one for the warehouse, each one containing the set of activities pertaining to the corresponding role. The problems arise when the modeler interconnects these activities by means of control and message ﬂows, trying to answer to the following questions: • Which activities must be executed in sequence? • How to deal with negative information such as “the seller cannot accept and reject the same order”? • How to model non-ordered constraints, like “if the warehouse refuses the order, then the seller must also refuse (or have refused) it”? • Who is in charge of contacting the warehouse? And when? The diﬃculty of providing an answer to these question by adopting procedural and closed approaches can be ascribed to three main causes [173]. First, they have a lack of proper abstractions. Activities can be interconnected only by means of positive temporally-ordered sequence relationships and gateways. Modeling other kind of constraints has the eﬀect of deviating from the business constraints or complicating the choreography. For example, capturing temporally-unordered relationships leads either to choose one ordering and impose it in the model, compromising ﬂexibility, or to explicitly capture all the possible orderings, introducing ambiguous decision points to combine them. An example of this issue is shown in Fig. 2.7, where a positive “coexistence” constraint is modeled in BPMN. Such a constraint does not impose any ordering between the involved activities, but simply states that if one of them

...

refuse shipment

...

Warehouse

Warehouse

2.3 Service Oriented Computing

31

refuse shipment ...

... refuse shipment

...

refuse order

...

Seller

Seller

refuse order ...

?

decision driven by the seller

... refuse order

Fig. 2.7. Two possible compliant ways for modeling the business constraint “if the warehouse refuses the order, then the seller must also refuse (or have refused) it” in BPMN

is executed, then the other must be executed as well. The diagram on the left imposes one ﬁxed ordering: there is no support for the inverse ordering of activities (ﬁrst an order refusal and then a shipment refusal) nor their parallel execution, although they are both in accordance with the coexistence constraint. The diagram is therefore an example of over-constrained model. Conversely, the diagram on the right is less constrained, but it introduces unnecessary further elements, such as decision gateways and intermediate messages. In particular, it assumes that the seller takes care of deciding which order must be chosen, but it is not clear how the seller could undertake this decision. It is therefore an over-speciﬁed diagram. The second issue is the closed nature of contemporary choreography modeling languages, which forces to enumerate all the allowed executions. This is especially diﬃcult when the business constraint is negative, as the third rule of Example 2.3.2. The rule states that the order/shipment acceptance and rejection are mutually exclusive. The diﬃculty of modeling this kind of rule comes from the fact that negative information cannot be directly represented by the language, and it is under the responsibility of the user to check that it is implicitly entailed by the designed model. By considering again Example 2.3.2, this would imply that the modeler must analyze each possible course of interaction supported by the designed choreography model, verifying whether it is guaranteed that two opposite answers are never sent. This task must be repeated for each negative constraint contained in the global contract, and becomes unreasonable as the complexity of the model increases. The third disadvantage, brought by the lack of proper abstractions and the closed nature of ﬂow-oriented languages, is called premature commitment. Premature commitment refers to the fact that the modeler is forced to prematurely take decisions and make assumptions about the interaction. For example, even if the choreography fragment listed in Example 2.3.2 does not specify when, by whom and how the warehouse must be contacted, a choice must indeed be taken during the modeling phase.

7 CartaoCidadaoException (complete) 64

SICCSException (complete) 32

SIPSCFatalRemoteCallException (complete) 3

AssinaturaNaoIncluidaException (complete) 1

ConcurrentModificationException (complete) 5

The ConDec notation will be extensively described in Chap. 3. SVIBusinessUserException (complete) 18

DESException (complete) 135

AFBusinessException (complete) 64

GREJBConcurrencyException (complete) 15

GRConcurrencyException (complete) 8

PessoaSingularNotFoundException (complete) 138

SVIBusinessException (complete) 1

PASException (complete) 2

ValidationException (complete) 31

NullPointerException (complete) 104

ITPTServerException (complete) 21

GREJBBusinessException (complete) 45

PesquisaAmbiguaException (complete) 6

TooManyRowsException (complete) 112

LimiteTemporalException (complete) 4

GILBusinessException (complete) 14

IOException (complete) 27

AFException (complete) 1

ServerException (complete) 132

SQLException (complete) 9

SICCLException (complete) 175

CSIBusinessException (complete) 14

RSIValidationException (complete) 25

CSIPersistencyException (complete) 3

MoradaPortuguesaNotFoundException (complete) 1

COOPException (complete) 4

PGWSException (complete) 168

SIPSCFatalException (complete) 20

PessoaColectivaNotFoundException (complete) 23

ServiceDelegateRemoteException (complete) 3

CPFBusinessException (complete) 3

GRServicesException (complete) 7

GREJBPersistencyException (complete) 179

PGException (complete) 6

RSISystemException (complete) 28

RSIException (complete) 1

BasicSystemException (complete) 16

SOAPException (complete) 22

BusinessLogicException (complete) 183

SIPSCRemoteBusinessException (complete) 51

GILConcurrencyException (complete) 1

InvalidNISSException (complete) 14

ConcorrenciaException (complete) 5

CDFBusinessException (complete) 6

ParametrizedBusinessException (complete) 2

SIPSCException (complete) 27

SIPSCDatabaseException (complete) 1

BusinessException (complete) 159

SAFBusinessException (complete) 115

SSNServiceException (complete) 1

RPCException (complete) 1

DESWSException (complete) 14

EstabelecimentoNotFoundException (complete) 187

GREJBRemoteServiceException (complete) 34

CSIRemoteException (complete) 3

GDServicesException (complete) 4

ADOPMessageException (complete) 3

FileNotFoundException (complete) 31

NaoExistemRegistosException (complete) 143

ContribuinteRegionalNotFoundException (complete) 63

SIPSCNoRecordsFoundException (complete) 160

ADOPUserChoiceException (complete) 1

JDOFatalUserException (complete) 124

RPCBusinessException (complete) 38

LayoffException (complete) 1

RSIPersistenceException (complete) 24

QgenMIParametrizedBusinessException (complete) 1

CMPException (complete) 1

ReportException (complete) 5

ADOPException (complete) 6

ITPTExternalServiceException (complete) 183

Exception (complete) 187

32 2 Declarative Open Interaction Models

Fig. 2.8. A spaghetti-like model illustrating the real behavior of a J2EE application server [256]

The combination of these drawbacks has the eﬀect that choreographies become

• over-speciﬁed, because unnecessary activities, messages exchange and constraints are introduced, even if they do not appear in the business-level choreography contract; • over-constrained, because acceptable interactions, supported by the choreography contract, are dropped out.

As a consequence, while compliance is respected, ﬂexibility becomes sacriﬁced: potential partners are discarded and fruitful interactions are rejected. This attests the huge gap between the choreography contract and the produced model. Furthermore, when the modeler tries to get back ﬂexibility by relaxing the imposed constraints and reducing premature commitments, overspeciﬁcation is even more stressed. The resulting choreography tends then to become a tangled, unintelligible spaghetti-like model [85] (such as the one depicted in Fig. 2.8), and, at the same time, the risk of supporting undesirable behaviors increases. Fig. 2.9 shows how the purchase choreography fragment described in Example 2.3.2 can be easily speciﬁed with a declarative constraint-based language such as ConDec7 . Fig. 2.10 depicts instead two possible BPMN collaborative diagrams which try to model the whole set of business constraints by mediating between compliance and ﬂexibility. The over-constraining and

2.3 Service Oriented Computing

confirm order

33

refuse order answers are mutually exclusive

the seller can accept the order only if the warehouse has previously accepted its shipment

if the warehouse cannot ship the order, then the seller must refuse it

confirm shipment

refuse shipment

Fig. 2.9. Fragment of a purchase choreography modeled in ConDec seller

warehouse

...

seller

warehouse

...

...

request for shipment

...

request for shipment

cancel request refuse order

refuse shipment

refuse shipment

...

... accept order

...

confirm shipment

...

confirm shipment accept order

refuse order

...

...

cancel request

...

...

Fig. 2.10. Two possible BPMN diagrams modeling the same choreography fragment targeted in Fig. 2.9 [173]

over-speciﬁcation issues become here apparent: to produce correct BPMN models, further elements must be introduced even if they are not mentioned in the contract (see e.g. the contact warehouse activity), while at the same time some acceptable execution traces are not supported. For example, both diagrams do not foresee a shipment refusal sent by the warehouse after the refusal of the seller; even if the refusal of the warehouse seems to be, in this case, insigniﬁcant, it could be involved in other constraints of the choreography, and should therefore be supported. As shown in Figure 2.7, adding this behavior would require to complicate the model, introducing an ambiguous decision point. Last but not least, handling this issue would be even more difﬁcult when the modeled fragment has to be composed with other constraints to capture the whole choreography.

34

2 Declarative Open Interaction Models

2.4 Multi-Agent Systems The issue about what information should be captured or left out by the global view of interaction has been (and is still) matter of discussion also in the MultiAgent System (MAS) research community. According to Wooldridge [264]: An agent is a computer system that is capable of independent actions on behalf of its user or owner. In other words, an agent can ﬁgure out for itself what it needs to do in order to satisfy its design objectives, rather than having to be told explicitly what to do at any given moment. A MAS is one that consists of a number of agents, which interact with one another, typically by exchanging messages through some computer network infrastructure. The deﬁnition points out two main fundamental properties that characterize the notion of agency: autonomy and social ability. Beside these, there is a broad consensus about two further properties that must be enjoyed by agents: reactivity and pro-activeness. Reactivity refers to the ability of perceiving and timely responding to stimuli coming from the environment in which the agent operates. Pro-activeness refers instead to the ability of going beyond reactivity, exhibiting a goal-directed behavior, taking the initiative and autonomously taking decisions. Similarly to the case of services, agents interact in order to achieve complex goals. Due to their autonomy and pro-activeness, however, they can engage in diﬀerent interaction modalities, ranging from cooperation and collaboration to negotiation and competition. Furthermore, in many application domains two important assumptions are made [221]. First, agents are heterogeneous, for example because they are realized by diﬀerent vendors or because they also interact with services, software applications and human users. Second, they can dynamically take part to and leave the interaction. These two additional features characterize the so-called open MASs [20]. Constraining the agents behavior so as to deﬁne the acceptable, compliant interactions while guaranteeing at the same time ﬂexibility, is in this situation even more important than in the case of SOC. Here, the concept of choreography is referred to as interaction protocol . Since open MASs consider agents as black boxes, focusing only on their external behavior, i.e., on the observable events generated in response of their actions and interactions, they can be considered as a particular kind of EBS. In particular, agents communicate via message exchange, and therefore it is not surprising that open MASs and Service-Oriented systems share many similarities [134, 23]; Table 2.1 brieﬂy summarizes some of their correspondences8. 8

In SOC, the term behavioral interface refers to the external, observable behavior of a service; it is therefore an abstract version of the internal orchestration, focusing on the messages exchanged by the service and omitting the internal activities, data manipulation and choices.

2.4 Multi-Agent Systems

35

Table 2.1. Correspondences between Multi-Agent and Service-Oriented Systems

interacting entities communication local view of interaction global view of interaction

MAS

SOC

agents

services

message

message

agent external policy

behavioral interface

interaction protocol

choreography

Example 2.4.1 (Multi-Agent English Auction). An e-commerce english auction involves a set of software agents, one auctioneer and several bidders. Each bidder agent is owned by a human user, and is initially instructed by its owner concerning her desired items and the maximum amount of money that can be spent. Bidders can freely enter and leave the auction, and autonomously decide whether to place an oﬀer or not, taking into account the preferences initially set by their owner. The auctioneer is instead in charge of collecting the oﬀers and determining the ﬁnal winner at the auction’s ﬁnal time. In this open context, the agents behavior cannot be controlled, and therefore a global interaction protocol is needed to check whether oﬀers are correctly placed by the bidder agents, and whether the ﬁnal winner is correctly selected by the auctioneer. The protocol relies upon the possible messages that can be exchanged among the agents (such as “place oﬀer”), and cannot make any assumption about the internals of participants. The problem of modeling interaction protocols in open MASs is two-faced: on the one hand, there is the need of a formal semantics for messages and protocols, in order to describe them in an unambiguous way and enable the investigation of their formal properties, on the other hand it is necessary to constrain the agents behavior in a ﬂexible manner, to the aim of preserving their autonomy and heterogeneity. Again, the proposals advanced in the literature can be grouped into two complementary modeling styles: procedural and closed approaches vs declarative and open ones. In particular, approaches like AUML [33] aim at exactly specifying the allowed sequences of messages that can be exchanged by the interacting agents, limiting the autonomy of agents and sacriﬁcing ﬂexibility for the sake of control and compliance. Conversely, social approaches [56, 221, 82, 8] consider MASs as truly open societies, and interaction protocols as a form of declarative knowledge used to represent conventions and rules of engagement which characterize the agents community as a whole. Such conventions and rules do not prescribe a speciﬁc pre-deﬁned way of executing interaction protocols: “the agents can act as they please provided they obey the restrictions of the societies they belong to and the protocols they follow” [221].

36

2 Declarative Open Interaction Models

The SCIFF framework [8], which will be extensively exploited in this book, is a notable example of social approach for modeling, formalizing and verifying the interaction dimension in open MASs.

2.5 Clinical Guidelines The Clinical Guideline (CG) setting constitutes a representative example of application domains in which a synergy and complementation between procedural, closed approaches and declarative, open ones is not only desirable, but necessary. As deﬁned by the USA Institute of Medicine [102]: CGs are systematically developed statements to assist practitioner and patient decisions about appropriate health care for speciﬁc clinical circumstances. They enforce evidence-based medicine, collect consensus-derived recommendations, and can be used to promote high-quality treatments, diagnosis and cost optimization, as well as to evaluate the quality and organization of the health service over a territory. One of the main goals of CGs is to put evidence into practice. However, there is a gap between the prescriptions of a guideline and their actual application on a patient. Indeed, evidence is essentially a form of statistical knowledge, capturing the generalities of classes of similar patients, instead of facing with the peculiarities of each speciﬁc patient. Furthermore, it is unreasonable to assume that an expert committee will precisely characterize each possible execution of the CG under study on all possible patients in any possible clinical circumstance. Therefore, a number of implicit conditions, such as ideality of context and patients, are usually assumed when building a CG. Ideality of context means that the health-care structure executing the guideline will be able to provide all the necessary resources, and is needed because CGs are developed at an abstract level and for a general audience, without focusing on a concrete execution setting. Ideality of patients assumes that the CG will be applied on patients experiencing only the targeted disease, without taking into account the possible interplay with other CGs. It is needed because the variety of patients is potentially inﬁnite. To eﬀectively apply a given CG on a speciﬁc patient, healthcare professionals implicitly employ their Basic Medical Knowledge (BMK) in order to adapt the generic prescription to her particular situation [47]. The BMK is for example employed by a physician when an alternative medicine must be found because the patient is allergic to the one mentioned in the guideline speciﬁcation, or when a critical situation, treating the life of the patient, suddenly arises. As we will see in the next Section, the proper combination of these two kinds of knowledge is a challenging task, which however we deem as necessary towards the realization of software systems able to truly support the sanitary staﬀ during the speciﬁcation and application of CGs.

2.5 Clinical Guidelines

37

Fig. 2.11. Fragment of a chronic cough treatment guideline modeled in GLARE (from [48])

2.5.1 Basic Medical Knowledge and Clinical Guidelines In the last decade, many diﬀerent research projects have been carried out to create domain-independent computer-assisted languages and tools for managing, acquiring, representing and executing CGs [109, 189, 229, 48]. All the proposed languages rely on the same “sequence ﬂows&gateways” abstractions employed in the BPM ﬁeld (see Section 2.2.1). They explicitly capture the ﬂows of administrative, clinical and therapeutic actions that must be executed for each patient, in accordance with the prescriptions contained in the CG’s description document. For example, Fig. 2.11 depicts a fragment of a CG speciﬁed using the Glare language [232]. As far as now, all these proposals presume that the modeled CG must be strictly followed, making the assumption that the involved actions are interpreted as “must do” actions, and that all the possible treatments are explicitly foreseen in the model. However, when the BMK comes into play, these two assumptions are relaxed by the healthcare professionals: the actions recommended by the CG could be prohibited by the BMK, or conversely the CG could enforce some actions event if they are discouraged by the BMK. Table 2.2 summarizes some real examples in which the complex interplay between the CG and the BMK gives raise to diﬀerent hybrid situations, showing that the CG cannot be always interpreted as a strict, normative procedure.

38

2 Declarative Open Interaction Models

Table 2.2. Examples of clinical behaviors determined by the interplay between the prescriptions of a Clinical Guideline and the Basic Medical Knowledge (from [47]) Basic Medical Knowledge

CG+BMK

a. Patients suﬀering from bacterial pneumonia must be treated with penicillin or macrolid.

Do not administer drugs to which a patient is allergic.

Admister macrolid to a patient with bacterial pneumonia if she is allergic to penicillin.

b. Patients with posthemorragic shock require blood transfusion.

Do not apply therapies that are not accepted by patients.

If the patient refuses blood transfusion, in case of posthemorragic shock treat her with plasma expander.

c. In patients aﬀected by unstable angina, coronary angiography is mandatory.

A patient aﬀected by advanced predialytic renal failure should not be subject to coronary angioraphy, because the contrast media may cause a further deterioration of the renal functions.

Clinical Guideline

Plasma expander is a valid alternative to blood transfusion, provided that . . . (omitted)

Even in case of a predialytic renal failure, perform coronary angiography if the patient is aﬀected by unstable angina.

In particular, the examples points out three diﬀerent integration modalities between the two kinds of knowledge: (Table 2.2) a. The CG supports the possibility of choosing among two different treatments, and the BMK acts as a business rule which helps in determining which route must (not) be taken when certain circumstances hold. (Table 2.2) b. The BMK emends the CG, suggesting a suitable way for (temporarily) substituting the guideline when its prescriptions are not applicable. (Table 2.2) c. The CG defeats the BMK, imposing the prompt execution of an action even if, according to the BMK, it could be dangerous for the patient.

2.5.2 Semi-Openness of Clinical Guidelines We have seen that CGs are developed by hypothesizing their application on “ideal” patients, while the BMK is used by healthcare professionals to bridge the gap between ideal and actual cases. Unfortunately, the contemporary guideline management systems only focus on the ﬁrst kind of knowledge, and completely omit the second. The result is that they are very useful for the

2.6 Lesson Learnt: Compliance vs. Flexibility

39

parts of the CGs dealing with strict procedures and protocols, such as administrative or laboratory procedures, while they lack in supporting healthcare professionals for all the phases in which their expertise and knowledge is effectively employed to drive the execution. However, as clearly attested by the examples shown in Table 2.2, the integration between these two kinds of knowledge is extremely diﬃcult. From a foundational point of view, such diﬃculty can be ascribed to the complementarity of their nature: while CGs are procedural and closed, the BMK is declarative and open. In particular, the BMK is declarative because it does not aim at deﬁning rigid procedures that must be followed by health-care professionals, but is rather focused on capturing their best practices and expertise, as well as (part of) the underlying common medical knowledge they rely upon. The BMK is open because it restricts the behavior of the involved parties by means of positive and negative constraints, and because it is essentially a form of incomplete knowledge: it is unreasonable to assume that the whole knowledge of health-care professionals can be completely captured, and consequently it must not preclude unforeseen actions and decisions. The integration between a CG and the BMK gives therefore raise to a hybrid semi-open knowledge, where the guideline must partially support the execution of unpredicted activities, as well as the deviation from its prescriptions, while the BMK must acknowledge the possibility of being defeated, and honor the motto: “domain experts always get the last word”. A deep understanding concerning the nature of this hybrid knowledge, and how its building components actually interact, is still far to be reached. Anyway, a ﬁrst necessary step towards such an understanding is to ﬁnd suitable speciﬁcation languages and eﬀective technologies for capturing the BMK, a topic which has been rarely studied so far. We hope that this book could actively contribute to the investigation of such a ﬁrst step.

2.6 Lesson Learnt: Compliance vs. Flexibility Business process speciﬁcations, service choreographies, multi-agent interaction protocols and clinical guidelines can be all considered as interaction models, diﬀering for what concerns the nature of participants and the relevant events occurring during the executions of the system (see Table 2.3). By abstracting away from the speciﬁc features of each discussed domain, we can identify two complementary aspects which need to be suitably captured and balanced by a modeling framework [116, 191]: Compliance (also called support ) aims at restricting the behavior of interacting entities so as to guarantee that all the targeted business constraints are met. Flexibility aims at leaving the behavior of interacting entities as unconstrained as possible, allowing them to take strategic decisions and evaluate the best ways for interacting with each other.

40

2 Declarative Open Interaction Models

Table 2.3. Examples of interaction models interacting entities

events

interaction model

Employees, stakeholders, Starting and completion of Business Process customers, devices, . . . business activities Services

Exchanged messages

Service Choreography

Agents, other interacting Exchanged messages, ac- (open) Multi-Agent Sysentities tions on the environment tem Healthcare professionals, Starting/completion of ad- Clinical Guideline + Basic patients, admin. staﬀ, . . . min. and clinical actions Medical Knowledge

Universe of traces

Supported traces

Fig. 2.12. Compliance (red dashed arrows) and ﬂexibility (green solid arrows) as contrasting forces in the space of execution traces

If we refer these two complementary concepts to the space of the possible execution traces which can be generated by the interacting entities, we will perceive them as two contrasting forces. On the one hand, compliance tends to restrict the number of allowed traces, forbidding all the (mis)behaviors that would lead to violate one of the imposed business constraint. On the other hand, ﬂexibility tends to widen the number of allowed traces, trying to include many diﬀerent possibilities among which participants can choose. As we have seen, ﬁnding the right balance between such contrasting forces is of key importance, and the right balance, in turn, depends on the ability of the modeler but also rely on the chosen interaction modeling language. In this respect, procedural and closed approaches provide good support for ensuring that compliance is guaranteed9, but they sacriﬁce ﬂexibility, being prone to over-constraining and over-speciﬁcation issues. Declarative and open approaches, instead, focus on the elicitation of the business constraints imposed by the domain under study, and avoid the insertion of further unnecessary constraints, preserving both compliance and ﬂexibility. Fig. 2.13 gives an intuitive idea of this diﬀerence in the space of execution traces. Focusing on traces, the eﬀect of the problem’s business constraints is to identify 9

Even though the management of negative constraints is diﬃcult, as pointed out in Sect. 2.3.3.

2.7 Desiderata for a Supporting Framework

41

Universe of traces

Universe of traces

Universe of traces

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ______________ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX __________________ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX _ _ _ _ _ _ _ _SSSS ____________ _XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX _ _ _ _ _ _ _ _ _ SSSSSSS _______________ _XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX _ _ _ _ _ _ _ _ _SSSSSSSSS _______________ _XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX _ _ _ _ _ _ _ SSSSSSSSSSSSS _________________ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX _ _ _ _ _ _ _ SSSSSSSSSSSSSS _________________ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX _ _ _ _ _ _ _SSSSSSSSSSSSSS _________________ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX _ _ _ _ _ SSSSSSSSSSSS ________________ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX _ _ _ _ _ _SSSSSS ______________ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ___________________ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX _________________ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SSSSSSSSSSSSSS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SSSSSSSSSSSSSSSSSSSSS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SSSSSSSSSSSSSSSSSSSSSSSSS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SSSSSSSSSSSSSSSSSSSSSSSSSSSSS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SSSSSSSSSSSSSSSSSSSSSSSSSSSSSS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SSSSSSSSSSSSSSSSSSSSSSSSSSSSSS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SSSSSSSSSSSSSSSSSSSSSSSSSSS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SSSSSSSSSSSSSSSSSSSSSSSSS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SSSSSSSSSSSSSSSSSSSSSSS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SSSSSSSSSSSSSSSSSSSSSS XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX SSSSSSSSSSSSSSSSSSS

Problem's constraints

Procedural closed approach

Declarative open approach

Fig. 2.13. Business constraints as forbidden (red area - ‘X’ ) and mandatory (dark green - no symbol ) behaviors in the space of execution traces, and comparison of closed procedural approaches vs open declarative ones, showing the allowed supported traces (light green - ‘S’ ) and the allowed but unsupported ones (white - ‘–’ )

forbidden and mandatory behaviors, i.e., the sets of event occurrences that must be respectively avoided or generated. Procedural and closed models provide support for covering the mandatory behaviors and avoiding the forbidden ones, but drop out many courses of interaction which are not forbidden nor mandatory, and are therefore allowed. Declarative and open approaches are instead able of supporting also these cases, for the sake of ﬂexibility.

2.7 Desiderata for a Supporting Framework We have pointed out the need of complementing closed procedural interaction models with open declarative ones. The adoption of declarative open interaction models call for suitable frameworks, able to provide support for their entire life cycle. Such frameworks must be able to formally verify the developed models and their executions, to ensure their trustworthiness and reliability. Thanks to formal veriﬁcation, it is possible to guarantee the correctness and consistency of the designed models, as well as eﬀectively establishing whether the actual behavior of interacting entities actually complies with their constraints. Fig. 2.14 (top) shows the types of veriﬁcation and support needed along the phases of the life cycle. The life cycle is inspired from the BPM one (see p. 21), and is composed by the three main stages of design, execution and diagnosis. As pointed out in Fig. 2.14 (bottom), an open declarative interaction model could also take part to a third party life cycle, giving rise to another series of veriﬁcation tasks. For example, the internal life cycle could be focused on the development of a choreography model, which is then not enacted, but it is rather used to verify if a set of local models of services, developed by thirdparty organizations, could be successfully employed to concretely realize the choreography. Let us brieﬂy review these veriﬁcation capabilities in the two settings.

42

2 Declarative Open Interaction Models

a-posteriori verification

properties verification

de sig n

internal life cycle

de sig n

third party life cycle

is os gn dia

a-priori compliance verification

interaction model

on-the-fly compliance verification

trace analysis a-posteriori compliance verification

a-posteriori verification

model discovery

composition

static verification

a-priori compliance verification

open declarative interaction model

static verification

enactment

trace analysis

diagnosis

on uti ec ex

runtime verification

model discovery

execution monitoring

runtime verification

Fig. 2.14. Life cycle of a declarative open interaction model, and its usage inside a third-party life cycle

2.7.1 Internal Life Cycle During the design phase, the framework must provide suitable novel speciﬁcation languages, to the aim of modeling the Event-Based System (EBS) under study with a declarative and open ﬂavor. Static veriﬁcation comes here into play to guarantee that the designed model meets certain desired properties, and complies by construction with external regulations and internal policies. These two tasks are called properties veriﬁcation and a-priori compliance veriﬁcation. When the design of the interaction model is completed, and all the static veriﬁcation tasks have been successfully passed, the model can be used to provide execution support. More speciﬁcally, the interaction model is enacted , guiding the interacting entities towards the correct execution of the model.

2.7 Desiderata for a Supporting Framework

43

While the enactment of closed procedural interaction models can take advantage from their ﬂow-oriented structure, showing at each moment what are the next steps to be done (the so-called worklist), declarative open ones are enacted by presenting, instant by instant, what are the expected and forbidden behaviors. In the last diagnosis phase, relevant informations are extracted from the event log containing the traces associated to the already completed system’s instances, in order to understand the real behavior exhibited by the actual interacting entities (a-posteriori veriﬁcation). In particular, traces are analyzed to study whether the business goals have been eﬀectively achieved and to assess the real trends of the system with respect to the desired ones, or used to discover a new model, able to precisely describe reality. In the BPM community, the extraction of new informations from event logs is referred to as process mining [244]. 2.7.2 Participation to an External Life Cycle An open declarative interaction model (I) can be also exploited to assist the development of an external, third-party interaction model (E). In particular, during the design of E, E could be statically veriﬁed to check whether it complies with I, which plays the role of a choreography or a regulatory/prescriptive model. A diﬀerent case is the one in which I and E represent local interaction models, which must be suitably combined in order to realize a more complex, joint model; model composition, as well as the properties veriﬁcation of the composed model, must be suitably tackled by our supporting framework. Let us now suppose that E is unknown, unaccessible, or untrusted. This is for example the case of service interaction, where each local service may expose a behavioral interface which describes its external behavior, hiding at the same time its complete internal implementation. Since there is no guarantee that the exposed behavioral interface eﬀectively matches with the internal implementation, the service may produce undesired courses of interaction, and must be therefore veriﬁed during the execution. In this situation, veriﬁcation can be accomplished by looking at the actual, ongoing execution of the external system, checking if the involved interacting entities are behaving as prescribed by I and reporting possible violations as soon as possible. In other words, monitoring and run-time veriﬁcation facilities must be provided by our framework. Finally, the same tasks carried out during the diagnosis phase of an open interaction model can be seamlessly applied to the diagnosis of an external, unknown systems, provided that the event log resulting from its diﬀerent executions is collected and made available. In particular, I could be used to analyze and classify third-party execution traces, addressing conformance checking issues. Model discovery, instead, could be applied to extract an open declarative interaction model from the real behavior of an external system.

44

2 Declarative Open Interaction Models

system

GRAPHICAL MODELING

a

b

(extended) ConDec

c

Translation

formal specification

REASONING CAPABILITIES

CLIMB

1

event log

SCIFF Framework

STATIC reasoning capabilities 2

RUN-TIME and A-POSTERIORI reasoning capabilities 3

Fig. 2.15. The CLIMB framework (numbers identify the parts of the book covering the corresponding portion of the schema)

This latter task is especially interesting when the traces of such an external system are produced by following a procedural, closed model: the declarativeness and openness of the discovered model could be exploited to explain the behavior exhibited by system in a more concise and readable way.

2.8 The CLIMB Framework In this book, the general framework described in Sect. 8.1 will be concretely addressed by integrating languages and technologies coming from two research areas, namely Business Process Management and Multi-Agent Systems. In particular, the management of open declarative interaction models will be faced by combining the constraint -based ConDec language [192, 191] with the Computational Logic-based SCIFF formal framework [8]. The resulting framework is therefore called CLIMB (Computational Logic for the verIﬁcation and Modeling of Business constraints). ConDec is a graphical, constraint-based language which has been proposed by Pesic and van der Aalst for modeling Business Processes (BPs) in a declarative and open way, addressing ﬂexibility issues. SCIFF is a framework based on Computational Logic, and in particular on Abuctive Logic Programming (ALP), originally thought for the speciﬁcation and veriﬁcation

2.8 The CLIMB Framework

45

of open Multi-Agent Systems. It features a rule-based language, with a clear underlying declarative semantics, for specifying interaction models; its operational counterpart, constituted by two proof procedures, supports static as well as dynamic reasoning capabilities. The logical architecture of the CLIMB framework is depicted in Fig. 2.15. The numbers show the correspondences between the portions of the schema and the parts of the book. In particular, in the remainder of Part 1 we will describe the ConDec notation and introduce the CLIMB language, a sub-set of the SCIFF one; then, we will show how all the ConDec constructs can be formalized by means of CLIMB rules, and discuss how the expressiveness of CLIMB can be exploited to extend ConDec with new interesting features, such as quantitative temporal constraints and data-aware conditions. Part 2 and Part 3 will instead focus on the diﬀerent static and run-time/a-posteriori veriﬁcation tasks, showing how the SCIFF proof procedures can be jointly adopted to accomplish all the desiderata introduced in Sect. 8.1.

3 The ConDec Language

ConDec is a graphical language proposed by Pesic and van der Aalst for the declarative and open modeling of Business Processes (BPs)[192, 191]. It ﬁts with complex, unpredictable processes, where a good balance between support and ﬂexibility must be found. Two variants of ConDec have been proposed for specifying service ﬂows [242], as well as for dealing with Clinical Guidelines (CGs) [181]. In this Chapter, we present a critical overview of the language and recall its constructs. We show its application on a representative case study, and discuss its style of modeling in the light of the cognitive dimensions framework [122]. We then introduce the framework of propositional Linear Temporal Logic (LTL) [99], summarizing how it has been exploited in [192, 191, 173] to provide the ﬁrst formalization of the ConDec constructs.

3.1 ConDec in a Nutshell The term “ConDec” stands at the intersection of the words constraint and declarative. ConDec is a constraint-based and declarative language because, instead of rigidly deﬁning the ﬂow of interaction, it directly focuses on the (minimal) set of rules which must be satisﬁed in order to correctly carry out the collaboration. Since rules constrain the way activities can be executed, they are referred to as (business) constraints. Business constraints reﬂect different kind of business knowledge: external regulations and norms, business objectives, internal policies and best practices, to cite some (see Sect. 2.1.3). Diﬀerently from procedural speciﬁcations, in which activities can be interconnected only by means of sequence patterns, mixed with constructs supporting the splitting and merging of control ﬂows, the ConDec language provides a number of control-independent abstractions to constrain activities, alongside the more traditional ones. It is possible to insert past-oriented constraints, as well as constraints that do not impose any ordering among activities.

M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 47–75, 2010. c Springer-Verlag Berlin Heidelberg 2010

48

3 The ConDec Language

Furthermore, ConDec models are open: activities can be freely executed, unless they are subject to constraints. This choice has a twofold impact. First, a ConDec model typically accommodates many possible executions, improving ﬂexibility. Second, the language provides abstractions to explicitly capture not only what is indispensable, but also what is forbidden, i.e., negative business constraints. In this way, the set of possible executions does not need to be expressed extensionally and models remain compact: models specify the desired and undesired events, leaving unconstrained all the courses of interaction that are neither desired nor undesired.

3.2 ConDec Models A ConDec model is composed by a set of activities, interconnected by means of business constraints. Activities represent atomic units of work (i.e., units of work associated to single time points1 ), and are therefore traced by means of single events occurring during the execution of a system’s instance. Business constraints restricts the possible ways of executing activities. Optional constraints are also supported, to express preferable courses of interaction, but allowing the possibility to deviate from them. Deﬁnition 3.2.1 (ConDec model). A ConDec model is a triple A, Cm , Co , where: • A is a set of activities; • Cm is a set of mandatory constraints; • Co is a set of optional constraints. Given a ConDec model CM, notations A(CM), Cm (CM) and Co (CM) respectively denote the set of activities, mandatory and optional constraints of CM. Activities are graphically represented as boxes containing their name. E.g., the activity commit order is represented as commit order A ConDec model is mainly designed in two steps: 1. The relevant activities of the system are identiﬁed and placed in the model. At this stage, the model is completely unconstrained, and therefore the activities can be performed an arbitrary number of times, in whatever order. 1

In [191], a non atomic model of activities is presented. However, it cannot be fully formalized by means of LTL [191]. We therefore make the assumption that the basic version of the language deals only with atomic activities, delegating the discussion about non atomic ones in Sects. 6.3.1 and 6.4.3.

3.3 Constraints

49

2. ConDec constraints are added to reﬂect the business constraints of the system, restricting the set of supported execution traces. The scope of constraints is thus delimited to each instance of the system, i.e., constraints do not span across multiple executions. Constraints must be eﬀectively enforced by the event occurrences contained in the traces, where each event occurrence represents the execution of an activity. A trace is supported by an entire ConDec model if and only if each mandatory constraint of the model is respected. Deﬁnition 3.2.2 (Supported execution trace). Given an execution trace T and a ConDec model CM, T is supported by CM iﬀ T complies with each constraint belonging to Cm (CM).

3.3 Constraints ConDec constraints are grouped into four families: Existence constraints are unary cardinality constraints expressing how many times an activity can or must be executed; Choice constraints are n-ary constraints expressing the need of executing some activities belonging to a set of possible choices, independently of the other constraints; Relation constraints are binary constraints which impose the presence of a certain activity when some other activity is performed, possibly imposing also qualitative temporal constraints between them; Negation constraints are the negative version of relation constraints, and are employed to explicitly forbid the execution of a certain activity when some other activity is performed. Note that ConDec relies on a qualitative notion of time (see Sect. 2.1.2): temporal constraints could express the required relative positions among two event occurrences, but they are not equipped with metric distances. 3.3.1 Existence Constraints Existence constraints are unary cardinality constraints predicating on the number of possible executions of an activity. They graphically resemble the well known multiplicity constraints of the Uniﬁed Modeling Language (UML) [185], and represent either the minimal, the exact or the maximum required executions of activities. The init constraint has a slightly diﬀerent meaning: it is used to identify the ﬁrst, starting activity of the model. Table 3.1 summarizes the types of existence constraints, showing their graphical representation and informal meaning. An existenceN constraint could be employed to state that at least one item must be ordered by the customer during the interaction:

50

3 The ConDec Language

Table 3.1. ConDec existence constraints name

graphical

meaning

0

absence(a)

a 0..n

absence(n+1,a)

a

Activity a cannot be executed Activity a can be executed at most n times, i.e., the execution trace cannot contain n + 1 occurrences of a

n..∗

existence(n,a)

a

Activity a must be executed at least n times

n

exactly(n,a)

a

Activity a must be executed exactly n times

init

init(a)

a

Activity a must be the ﬁrst executed activity

1..∗

order item On the contrary, an absenceN constraint could be used to state that at most three payment attempts can be made by the customer: 0..3

pay 3.3.2 Choice Constraints Choice constraints are shown in Table 3.2. They are n-ary constraints asserting that the interacting entities must necessarily perform some activities, selecting them inside a set of possible choices. They can be therefore seen as an extension of the existence n and exactly n constraints, replacing a single activity with a set of activities. Choice constraints are especially useful when the model contains several activities having the same eﬀect or accomplishing the same business goal, because they leave interacting entities free to choose the most suitable on their own. Indeed, a ConDec choice corresponds to a deferred choice [239]: the decision is not driven by an explicit choice, but is instead delegated to the interacting entities, which take it by executing one of the interconnected tasks. A 1 of 2 -choice could be used to state that a contributing author must submit her paper either by uploading it through the web site of the conference or by sending it via e-mail2 : ♦

upload paper − − − − e-mail paper 2

We suppose that the “n of m” notation is optional when n = 1.

3.3 Constraints

51

Table 3.2. ConDec choice constraints name

graphical

choice(n of m,[a1 ,...,am ])

a1 am

ex choice(n of m,[a1 ,...,am ])

a1 am

n of m

a2

At least n distinct activities among a1 ,. . . ,am must be executed

a2

Exactly n distinct activities among a1 ,. . . ,am must be executed

... n of m

...

meaning

Note that the constraint supports an execution trace containing three submissions of the paper (via e-mail and/or by using the web site), while it evaluates a trace without submissions as noncompliant. A 1 of 2 -exclusive choice can be instead adopted to model the existence between two alternatives that exclude each other. For example, it could be used to state that, within an instance of the system, the customer commits herself to cancel or successfully close the order, but not both:

cancel order − − − − close order It is worth noting that choice constraints, together with the existenceN and exactlyN ones, constitute a family of goal-oriented constructs. Indeed, they impose the mandatory presence of (some of) the involved activities in any possible execution trace supported by the model, independently of the other constraints and of the speciﬁc courses of interaction. 3.3.3 Relation Constraints Diﬀerently from goal-oriented constraints, relation constraints express positive dependencies among activities; in their simplest form, they interconnect two activities (the generalized case will be discussed in Sect. 3.3.5). As shown in Table 3.3, the graphical representation of each relationship coherently communicates the meaning of the relationship: • the number of lines used to interconnect the two activities indicates how much tight is the dependency; • the position of the “•” element determines which activity has the ability of triggering the dependency; • the presence of an arrow and its relative position with respect to the “•” element denote the qualitative temporal constraint associated to the relation. In particular, when a relation constraint is connected to an activity through a “•” element, such an activity is called source of the constraint, and has

52

3 The ConDec Language

Table 3.3. ConDec relation constraints name

graphical

meaning

resp existence([a], [b])

a •−−−− b

If a is executed, then b must be executed before or after a

coexistence([a],[b])

a •−−−• b

Neither a nor b is executed, or they are both executed

response([a],[b])

a •−−− b

If a is executed, then b must be executed thereafter

precedence([a],[b])

a −−−• b

b can be executed only if a has been previously executed

succession([a],[b])

a •−−• b

a and b must be executed in succession, i.e. b must follow a and a must precede b

alt response([a],[b])

a •=== b

b is response of a and between every two executions of a, b must be executed at least once

alt precedence([a],[b])

a ===• b

a is precedence of b and between every two executions of b, a must be executed at least once

alt succession([a],[b])

a •==• b

b is alternate response of a, and a is alternate precedence of b

chain response([a],[b])

a •= −= −= − b

If a is executed, then b must be executed next (immediately after a)

chain precedence([a],[b])

a = −= −= −• b

If b is executed, then a must have been executed immediately before b

chain succession([a],[b])

a •= −= −• b

a and b must be executed in sequence (next to each other)

the ability to trigger it. When the constraint triggers, then also the target activity, connected to the other side of the relation, must be executed. Relation constraints are therefore reactive. Starting from this basic schema, each relation constraint diﬀers from the others for what concerns when the occurrence of the target is expected to happen as the constraint triggers. The responded existence and coexistence relation constraints do not impose any temporal ordering, but rather leave the interacting entities completely free to decide when the execution of the target is placed. Example 3.3.1 (Unordered business constraint). Let us consider an interaction model regulating the messages exchange between a seller and a warehouse, which stores the goods of the seller. When the warehouse ships a good, then

3.3 Constraints

53

it must also notify the seller that the amount of stored goods has changed; the notiﬁcation could be sent either before or after the shipment. In ConDec, such a ﬂexible business constraint can be directly modeled by means of a responded existence relation, interconnecting the shipment and the notiﬁcation activities: ship good •−−−− notify seller When the good is shipped, if the seller has been already notiﬁed, then the constraint is automatically fulﬁlled, otherwise it “waits” for the notiﬁcation. Thus, the empty execution trace, as well as an execution trace containing three notiﬁcations, are both supported by the constraint, because they do not make it trigger. An execution trace in which two shipments are delivered, and a unique notiﬁcation is sent to the seller, is seamlessly supported as well: both shipments need a notiﬁcation, which eventually arrives. Conversely, all the execution traces which contain at least one shipment, but no notiﬁcation, are all considered as noncompliant. The response and precedence constraint types extend the responded existence one by introducing the the two fundamental qualitative temporal orderings of after and before. To determine the eﬀective time window inside which the target activity is expected to occur when the source happens, such temporal orderings combine themselves with the constraint’s tightness. For example, the basic response connects the two involved activities in a weak, loosely coupled way: when the source occurs, then the target must occur in the future, but other activities can be seamlessly executed in between. The alternate response places a further constraint, namely that when the source is executed, it cannot be executed again unless the target activity is executed. The chain response is even more tight, and states that the target must be the ﬁrst activity that is executed after the source, resembling the sequence connection of classical procedural languages. This plethora of relation constraints can be then used to model diﬀerent positive relationships between activities, ranging from a completely open to a completely closed perspective. Example 3.3.2 (Compliance with relation constraints). Let us separately consider the following ConDec constraints: C1 = a •−−− b C2 = a •=== b C3 = a •= −= −= − b and the following execution traces

54

3 The ConDec Language

T1 = a → b → a → c T2 = a → c → a → b T3 = a → c → b → a → b T4 = a → b → c → a → b T1 is not compliant with C1 , and therefore, nor with C2 and C3 , because the second execution of activity a is not followed by an execution of b. Note that a •−−−− b . T2 is supported by C1 , it would instead be compliant with because the two executions of a are eventually followed by b, but it is not compliant with C2 , because the alternation a–b–a is not respected (only c is executed in between); all the more so, it is neither compliant with C3 . T3 is compliant with C2 (and therefore also with C1 ), because each a is followed by a b, and that b always occur before a further execution of a. It is however not compliant with C3 , because the ﬁrst a has c as immediate successor, instead of b. Finally, T4 is an example of execution trace supported byC3 , and hence supported also by the other two constraints. Let us ﬁnally brieﬂy focus on the succession constraints. Each succession constraint is a shortcut in place of the combination between the corresponding response and precedence relations, as clearly shown by the graphical notation. Both the interconnected activities have the power of triggering the constraint, i.e., acting as source or target depending on the circumstance. For example, a basic succession constraint could be employed to state that when the customer pays for a good, then the warehouse must eventually deliver that good and, conversely, the warehouse will ship the good only if a payment has been previously carried out: receive payment •−−• ship good Since the succession constraint imposes a loosely coupled temporal relation between the payment and the shipment, other intermediate activities can be performed by the warehouse and the customer. 3.3.4 Negation Constraints As shown in Table 3.4, negation constraints are specular to relation constraints: when a negation constraint is triggered by its source activity, then it forbids the execution of the target activity inside certain time bounds, determined by the the speciﬁc constraint. Therefore, also the “degree of openness” characterizing each relation constraint is mirrored: while responded existence and chain succession constraints are respectively the most open and closed relation constraints, responded absence and negation chain succession are the most closed and open negation ones.

3.3 Constraints

55

Table 3.4. ConDec negation constraints name

graphical

meaning

resp absence([a],[b])

a •−− −− b

If a is executed, then b can never be executed

not coexistence([a],[b])

a •−− −• b

a and b exclude each other

neg response([a],[b])

a •−− − b

b cannot be executed after a

neg precedence([a],[b])

a −−− • b

a cannot be executed before b

neg succession([a],[b])

a •−− • b

a and b cannot be executed in succession

neg alt response([a],[b])

a •== = b

b cannot be executed between any two occurrences of a

neg alt precedence([a],[b])

a === • b

a cannot be executed between any two bs

neg alt succession([a],[b])

a •== • b

b cannot be executed between any two as and viceversa

neg chain response([a],[b])

a •= −= −= − b

b cannot be executed next to a

neg chain precedence([a],[b])

a = −= −= − • b

a cannot be executed immediately before b

neg chain succession([a],[b])

a •= −= − • b

a and b cannot be executed in sequence

Indeed, a •= −= −= − b states that when activity a is executed, b can be executed if at least one intermediate occurrence of another activity exists; on the contrary, a •−− −− b forbids the presence of b along the whole instance, if a is performed inside that instance. Negation constraints are peculiar of open approaches, where by default all activities can be executed in any order. In this respect, it would be unfeasible to assume that “positive” constraints are suﬃcient for expressing signiﬁcant interaction models. Furthermore it is sometime much more eﬀective and compact to model the undesired behaviors rather than the allowed ones. For example, the not coexistence constraint could be directly employed in a ConDec model to express that two activities are incompatible, e.g., that the seller cannot accept and reject an incoming order when interacting with a customer: accept order •−− −• reject order

56

3 The ConDec Language

Example 3.3.3 (Compliance with negation constraints). Let us separately consider the following ConDec constraints: C1 = a •−− − b C2 = a •== = b C3 = a •= −= −= − b and the following execution traces T1 = c → b → a T2 = a → c → a → b T3 = a → c → b → a T4 = a → b → c T1 is supported by all the three constraints, being a followed by no occurrence of b. Due to the presence of a previous b, it would instead violate a •−− −− b . T2 violates C1 , because there exists a b executed after (two occurrences of) a. It also violates C3 , because the second occurrence of a has b as immediate successor. T2 instead complies with C2 , thanks to the absence of b between the two occurrences of a. T3 is not compliant with C2 , because between the two executions of a there is one b; all the more so, it violates also C1 , due to the presence of b after the ﬁrst execution of a. It is instead supported by C3 , because a is never immediately followed by b (the ﬁrst execution is followed by c, while the second has no successor). Finally, T4 is only supported by C2 , because it only contains one occurrence of a. It instead violates C3 (and consequently C1 ), being such an occurrence immediately followed by b. 3.3.5 Branching Constraints As far as now, we have considered only relation and negation constraints involving two activities. However, in the general case they can branch, involving a multiplicity of activities. When a constraint branches on multiple activities, the intended interpretation is disjunctive: • In case of multiple sources, the constraint is triggered by each occurrence of one of the source activities; it therefore represents a shortcut for applying the same constraint on each source activity. • In case of multiple targets, when the relation (negation) constraint is triggered, it becomes satisﬁed by executing (by avoiding the execution of) one of the target activities.

3.4 ConDec at Work

57

Succession constraints maintain their decomposition into a response and precedence part; for example, in the following branching succession constraint a

c d

b

e

a plays the role of a disjunctive source regarding the response part of the succession, and it plays the role of a disjunctive target concerning its precedence part. The only exception is constituted by the coexistence constraint, because sources and targets cannot be distinguished by looking at its graphical representation: a1 a2

an

...

The interpretation of this constraint in the branching case is then: whenever one among the n interconnected activities occur, then at least one of the other n − 1 interconnected activities must be executed as well. In conclusion, branching constraints combine the reactive nature of relation and negation constraints with the ﬂexibility of choice constraints.

3.4 ConDec at Work We illustrate the potentialities of ConDec by considering a simple yet signiﬁcant case study: a three-party service choreography. The choreography deals with the creation, conﬁrmation and payment of an order, composed by a set of items. The choreography includes three diﬀerent roles: • a customer, interested in purchasing items; • a seller, which oﬀers a list of items and takes care of maintaining the order’s status, as well as of delivering a ﬁnal receipt when the customer pays; • a warehouse, which physically stores the items and therefore knows their availability. An instance of the choreography centers around a single order. Since the seller and the warehouse could be involved at the same time in several instances of the choreographies, interacting with diﬀerent customers for selling diﬀerent orders, we make the assumption that each order is associated to a unique identiﬁer, which can be also used as an instance identiﬁer. Such an instance identiﬁer is attached to each exchanged message, and can therefore be exploited to correlate all the event occurrences related to the same order, separating them from the other execution traces.

58

3 The ConDec Language

3.4.1 The Order Management Choreography in Natural Language Let us now informally describe the choreography constraints, using natural language statements, as they would be collected after a series of meetings with the domain experts. An instance of the choreography centers around a single order. Each order is implicitly created as soon as an instance of the choreography begins. The order must be eventually managed by the customer, either by closing or canceling it (but not both). Before taking this decision, the customer is in charge of ﬁlling the order, by choosing a series of items from the seller’s list. If the order is closed or canceled the order, no further items can be added to the order. After having closed the order, the customer expects a positive or negative answer from the seller, which decides whether to conﬁrm or refuse it. The seller can send an answer to the customer only if the order has already been closed. The decision of the seller is sometime inﬂuenced by the warehouse, which knows if the order can be concretely delivered. In particular, the seller is bound to refuse the order if the seller communicates the impossibility of shipping it, and can send a positive response to the customer only if the warehouse has previously given its acknowledgment. The warehouse must behave in a consistent way, i.e., it cannot emit both an acceptance and a refusal concerning the shipment of an order. The seller has instead the possibility of refusing an already accepted order, but not the other way around. If the seller sends a conﬁrmation, the customer gets the last word: it can simply give up, or ﬁnalize the order by paying it. The payment can be done only if the seller has previously sent the conﬁrmation message, and it is incompatible with the seller’s refusal. When the payment is carried out, the seller is in charge of delivering a single ﬁnal receipt. The seller will emit a receipt only after the payment has taken place.

3.4.2 The Order Management Choreography as a Contract The ﬁrst step in modeling the choreography with ConDec consists in the separation of the natural language sentences, towards the identiﬁcation of all the explicit and implicit business constraints. We therefore restructure the description made in Sect. 3.4.1, obtaining a “contractual” version of the choreography. 1. Order creation phase a) The order is implicitly created as soon as an instance of the choreography begins. b) The customer must either close or cancel the order (but not both). c) Before closing or canceling the order, the customer must choose a series of items from the seller’s list. d) If the order is closed or canceled, then no further items can be added to the order. e) After having closed the order, the customer expects a positive or negative answer from the seller. f) The seller can send an answer to the customer only if the order has already been closed.

3.4 ConDec at Work

59

2. Order conﬁrmation or refusal a) The seller is bound to refuse the order if the seller communicates the impossibility of shipping it. b) The seller can send a conﬁrmation to the customer only if the warehouse has previously given its acknowledgment. c) The warehouse cannot emit both an acceptance and a refusal concerning the shipment of an order. d) The seller has the possibility of refusing an already accepted order. e) The seller cannot accept an order if it has already refused that order. 3. Order ﬁnalization a) If the seller sends a conﬁrmation, the customer can (but is not forced to) pay the order. b) The payment can be done only if the seller has previously sent the conﬁrmation message. c) The payment is incompatible with seller’s refusal. d) When the payment is carried out, the seller is in charge of delivering a single ﬁnal receipt. e) The seller will emit a receipt only after the payment has taken place.

3.4.3 Identiﬁcation of Activities As a second step, we analyze the choreography contract described in Sect. 3.4.2 trying to identify all the involved activities. The same contract is rewritten in the following, by highlighting all the activities in bold face. 1. Order creation phase a) The order is implicitly created as soon as an instance of the choreography begins. b) The customer must either close or cancel the order (but not both). c) Before closing or canceling the order, the customer must choose a series of items from the seller’s list. d) If the order is closed or canceled, then no further items can be added to the order. e) After having closed the order, the customer expects a positive or negative answer from the seller. f) The seller can send an answer to the customer only if the order has already been closed. 2. Order conﬁrmation or refusal a) The seller is bound to refuse the order if the seller communicates the impossibility of shipping it. b) The seller can send a conﬁrmation to the customer only if the warehouse has previously given its acknowledgment. c) The warehouse cannot emit both an acceptance and a refusal concerning the shipment of an order. d) The seller has the possibility of refusing an already accepted order. e) The seller cannot accept an order if it has already refused that order. 3. Order ﬁnalization

60

3 The ConDec Language

Table 3.5. Activities identiﬁcation in the order management choreography activity choose item cancel order close order refuse order accept order refuse shipment accept shipment pay deliver receipt

synonyms add item

negative answer positive answer, send conﬁrmation impossible shipment give acknowledgement do payment

clause

responsible

1c, 1d 1b, 1c, 1d 1b, 1c, 1d, 1e, 1f 1e, 1f, 2a, 2d, 2e, 3c 1e, 1f, 2b, 2d, 2e, 3a, 3b

customer customer customer seller seller

2a, 2c 2b, 2c 3a, 3b, 3c, 3d, 3e 3d, 3e

warehouse warehouse customer seller

a) If the seller sends a conﬁrmation, the customer can (but is not forced to) pay the order. b) The payment can be done only if the seller has previously sent the conﬁrmation message. c) The payment is incompatible with seller’s refusal. d) When the payment is carried out, the seller is in charge of delivering a single ﬁnal receipt. e) The seller will emit a receipt only after the payment has taken place.

Table 3.5 summarizes the results of the activities identiﬁcation task, also disambiguating distinct terms which indeed refer to the same activity. 3.4.4 Elicitation of Business Constraints Similarly to what we have done in Sect. 3.4.3 for identifying the activities, we now present the choreography contract again, but by highlighting all the prescriptive parts and keywords, as well as the temporal aspects, inside its clauses. 1. Order creation phase a) The order is implicitly created as soon as an instance of the choreography begins. b) The customer must either close or cancel the order (but not both). c) Before closing or canceling the order, the customer must choose a series of items from the seller’s list. d) If the order is closed or canceled, then no more items can be added to the order. e) After having closed the order, the customer expects a positive or negative answer from the seller. f) The seller can send an answer to the customer only if the order has already been closed.

3.4 ConDec at Work

61

2. Order conﬁrmation or refusal a) The seller is bound to refuse the order if the seller communicates the impossibility of shipping it. b) The seller can send a conﬁrmation to the customer only if the warehouse has previously given its acknowledgment. c) The warehouse cannot emit both an acceptance and a refusal concerning the shipment of an order. d) The seller has the possibility of refusing an already accepted order. e) The seller cannot accept an order if it has already refused that order. 3. Order ﬁnalization a) If the seller sends a conﬁrmation, the customer can (but is not forced to) pay the order. b) The payment can be done only if the seller has previously sent the conﬁrmation message. c) The payment is incompatible with seller’s refusal. d) When the payment is carried out, the seller is in charge of delivering a single ﬁnal receipt. e) The seller will emit a receipt only after the payment has taken place.

Starting from the highlighted keywords, the business constraints mentioned in the contract can be made explicit. Table 3.6 illustrates a possible methodology to isolate them. For all the contract clauses, we enumerate the highlighted keywords. Then, each keyword is bound to the set of involved activities, trying to make also explicit when such activities act as sources or targets inside the clause, i.e., trying to identify whether they trigger the prescriptions contained in the clause or rather are involved in the eﬀects of such prescriptions. Finally, each prescription is compared with the tables illustrating the ConDec constraints (Tables 3.1, 3.2, 3.3 and 3.4), to the aim of recognizing which kind of constraint (or combination of constraints) can be applied to the involved activities, so as to properly represent the prescription. It is worth noting that some of the contract clauses are not translated into ConDec constraints, either because they are not prescriptive (this is the case of clause 1a), or because they focus on the possibility of doing something (see clauses 2d and 3a), which is by default guaranteed when adopting an open language such as ConDec. The latter kind of clause comes into help for determining the exact type of constraint that must be used to model another prescriptive clause, focused on the same activities. For example, in the order management choreography we have an asymmetry between the treatment of the order rejection vs acceptance by the warehouse and by the seller: in the ﬁrst case, a not coexistence constraint is used to bind the two answers, whereas in the second case a weaker negation response is employed. Clause 2d can be considered, in this setting, as a further evidence attesting that choosing a not coexistence constraint also for the seller’s answers would be too restrictive. A similar discussion can be made for clause 3a. Indeed, it helps in the identiﬁcation of the right constraint used to relate the order acceptance

62

3 The ConDec Language

Table 3.6. Elicitation of ConDec constraints in the order management choreography clause keywords

affected activities

constraint

1a – 1b must 1c before must (at least one)

close ex-or cancel order (sources) close or cancel order (target) choose item

ex choice precedence

1d if then no more

(sources) close or cancel order (target) choose item

neg response

1e after expects

(source) close order (targets) conﬁrm or refuse order

response

1f can if already

(sources) conﬁrm or refuse order (target) close order

precedence

2a if (seller) is bound to

(source) refuse shipment (target) refuse order

resp existence

2b can only if previously

(source) accept order (target) accept shipment

precedence

2c cannot emit both

conﬁrm and refuse ship- not coexistence ment

2d (if) already has the possibility of

accept order refuse order

2e if already cannot 3a if can 3b can only if previously 3c incompatible 3d when in charge of 3d single 3e will emit only after

(source) refuse order (target) accept order accept order pay (source) pay (target) accept order

– (openness) neg response – (openness) precedence

pay and accept shipment not coexistence (source) pay (target) deliver receipt deliver receipt (source) deliver receipt (target) pay

response absence 2 precedence

with the payment, reinforcing the content of clause 3b, i.e., attesting that a precedence suﬃces. After having completed the table, a draft of the ConDec model can be drawn. It is shown in Fig. 3.1. It is worth noting that the branching negation response constraint due to clause 1d has been represented as two distinct

3.4 ConDec at Work choose C item

(1d)

refuse order

(1d)

S

cancel order

C

(1b)

(3c) close order

C

(3d) 0..1 C

pay (1e)

refuse W shipment

(2a)

(1c)

(2e)

63

(3d)+(3e)

deliver receipt

S

(2c)

(3b)

accept order

S

(2b)

accept W shipment

Fig. 3.1. Draft of a ConDec model capturing the order management choreography; for the sake of readability, constraints are decorated with the corresponding clause in the choreography contract, and activities are associated to the corresponding responsible role (customer: C – pink; seller: S – blue; warehouse: W – yellow )

relations (which is equivalent, because the constraint branches on the source side – see Sect. 3.3.5); furthermore, the response and precedence constraints derived from clauses 3d and 3e have been combined into a single succession constraint. 3.4.5 Completing the ConDec Model In the real world, the steps followed in Sects. 3.4.1, 3.4.2, 3.4.3 and 3.4.4 would obviously be subject to many iterations, and would be interleaved by several meetings and interviews with domain experts. Here we consider only one iteration, aimed at analyzing the draft model produced so far (see Fig. 3.1), revising and extending it if needed. As we will see in Part 2 and 3 of the book, static veriﬁcation of properties and enactment help the modeler in the assessment of ConDec diagrams. In our case study, such an assessment would surely point out a potential weakness. In particular, the model supports the possibility of closing the order multiple times. Each time the order is closed, an answer must be eventually sent by the seller, even if it has already been produced. This potential misbehavior can be eliminated by imposing that the order can be closed at most one time, i.e., by associating a absence 2 constraint to the close order activity. This perfectly ﬁts with the other choreography clauses, and probably it has been forgotten when the choreography description was wrote down. Indeed, each choreography instance centers around a single order, and, as attested by clause 1d, after having closed the order, no further items can be added to it; hence, introducing the absence 2 constraint seems to be completely justiﬁed, without sacriﬁcing ﬂexibility. Fig. 3.2 depicts the ﬁnal ConDec model, obtained by extending the draft of Fig. 3.1 with the cardinality constraint associated to the close order activity.

64

3 The ConDec Language choose C item

refuse order

S

refuse W shipment

0..1 cancel order

C

close order

0..1 C

C

pay

accept order

deliver receipt

S

S

accept W shipment

Fig. 3.2. Complete ConDec model capturing the order management choreography Table 3.7. Some cognitive dimensions closeness of mapping Closeness of representation to domain abstraction Types and availability of abstraction mechanisms consistency Similar semantics are expressed in similar syntactic forms hidden dependencies Important links between entities are not visible premature commitment Constraints on the order of doing things progressive evaluation Work-to-date can be checked at any time

3.5 Usability of ConDec Although a deep and extensive analysis of the ConDec notation from the endusers viewpoint has not yet been carried out [191], we try to brieﬂy assess its usability by commenting on its cognitively-relevant aspects. The discussion relies on the cognitive dimensions framework , initially developed by Green in the late 80’s [122]. Cognitive dimensions are a useful tool for subjectively evaluating the usability of languages and notations in an easy-to-comprehend way. They have been applied to a broad range of programming languages, environments and editors, and also to visual notations [123]. Table 3.7 introduces the subset of the cognitive dimensions that will be matter of our discussion. The main strength of ConDec is the closeness of mapping between the notation and the business constraints contained into a requirements speciﬁcation document, expressed in natural language. This advantage comes from the declarative and open nature of ConDec: it provides a wide range of abstractions to constrain activities in many diﬀerent ways, covering multiplicity aspects, choices, time-ordered and unordered interconnections, as well as negative relationships. ConDec diagrams can range from closed procedural models, in which only chain succession constraints are used, to loosely coupled

3.5 Usability of ConDec

65

Table 3.8. Basic visual constitutive elements of ConDec’s constraints notation

existence constraints

0..N, M..*, K (a l´ a UML)

choice

♦

concept

/

(a l´ a decision gateway in BP modeling notations)

binary constraints

− (normal) = (alternate) ≡ (chain)

source of binary constraints • negation

temporal ordering

−−

succession representation

response + precedence part (e.g. •−−• = •−−− + −−−•)

ones. As attested by the case study presented in Sect. 3.4, a variety of natural language statements can be directly represented in ConDec, facilitating the design task and making it simpler to maintain a link between the model and the requirements speciﬁcation document, keeping track of which requirements have been covered so far. The declarative and open nature of ConDec has also a positive impact on the premature commitment dimension, a topic which has been already discussed in Sect. 2.3.3 – p. 31. Indeed, by focusing on the “what” without stating the “how”, a ConDec model is close to the business constraints introduced by the domain under study, avoiding over-speciﬁcation and over-constraining issues and delaying as much as possible the choice about the “order of doing things”, postponing it until the execution takes place. While the presence of several abstractions is desired to properly capture the complexity of the outer world, it raises a potential usability issue, because a long learning curve is needed to become familiar with the whole notation. ConDec mitigates this problem by paying great attention to the consistency of the graphical notation. In particular, constraints are represented by coherently combining the small set of basic visual elements shown in Table 3.8. For example, the semantics of each succession relation, as well as its graphical representation, is determined by combining the semantics/representation of its response and precedence part. Furthermore, existence and choice constraints employ familiar symbols, taken from UML and from the mainstream BP modeling languages. Even though ConDec combines simple concepts, rendered in a consistent way, as the complexity of the designed models grows the models tend to loose their readability. Indeed, ConDec is not a ﬂow-oriented language, but it is instead a constraint-based language, and thus drives the modeler towards the adoption of an unstructured approach to design. A ConDec diagram is a “ﬂat”

66

3 The ConDec Language 0..1 a

b

c

Fig. 3.3. Presence of non trivial hidden dependencies inside a ConDec model (hidden dependencies are shown as dashed gray connections)

container of all the business constraints reﬂecting the domain under study, and their combination tends to reduce the clarity of the entire model. This drawback does not only refer to the graphical representation of the model, but also on its overall meaning: the interplay of constraints leads to implicitly introduce a plethora of hidden dependencies among the activities. In ConDec, hidden dependencies take the form of further, implied constraints. Certain hidden dependencies are trivial, others are not. The following example points out this issue by considering a simple concrete case. Example 3.5.1 (Hidden dependencies in ConDec). Let us consider the ConDec diagram shown in Fig. 3.3. The diagram implicitly contains two kinds of hidden dependencies. The ﬁrst one is trivial. Since activity b is response of a, and in turn c is response of b, then also the following redundant response is contained in the model: a •−−− c Such a hidden dependency is caused by the transitivity of the response constraint. A second non-trivial hidden dependency is instead caused by the interplay between the 0..1 cardinality constraint and the response ones. Let us illustrate a possible execution of the model to point out such a hidden dependency. 0..1

Suppose that activity c is executed; constraint c forbids further executions of c within the same instance. This prohibition has an indirect eﬀect also on the possibility of executing activities a and b. In fact, the response constraints contained in the model state that the execution of a or b imposes a consequent execution of c, which however would lead to violate the cardinality constraint. Therefore, upon the execution of activity c also a and b become forbidden. In other words, the interplay between the absence 2 and response constraints introduces two hidden negation responses relating activity c with a and b. In complex cases, the presence of many non-trivial hidden dependencies could lead to produce inconsistent or incorrect models. In this respect, ConDec models demand a constant computer aided support, for statically verifying and simulating (the enactment of) models during the design phase. Static

3.6 Linear Temporal Logic

67

veriﬁcation supports the discovery of errors inside a model, whereas simulation can be used to see how the eﬀects of business constraints evolve in response to (simulated) event occurrences, and thus helps in making hidden dependencies explicit. In other words, the issues raised by hidden dependencies can be handled only if the progressive evaluation of ConDec models is supported. Part 2 and 3 of the book will be speciﬁcally devoted to discuss a Computational Logic-based framework which constitutes the enabling technology for carrying out a progressive evaluation. Progressive evaluation facilities and support along the whole life cycle of ConDec speciﬁcations, in turn, require an underlying formal framework and its reasoning capabilities. As we have sketched in Fig. 2.15 – p. 44, a given formal framework can be eﬀectively exploited only if a complete translation of all the ConDec constructs into its representation language. The remainder of the ﬁrst part of the book is focused on this issue: in the next sections, we discuss the use of propositional Linear Temporal Logic, the ﬁrst logic-based language onto which ConDec has been completely mapped; in Chaps. 5 and 6, instead, we will focus on the adoption of CLIMB to accomplish this task. CLIMB shows unique capabilities, both in terms of the language expressiveness and on the power of its corresponding reasoning techniques.

3.6 Linear Temporal Logic In this section, we provide a broad introduction to the framework of propositional Linear Temporal Logic (LTL), which has been exploited by Pesic and van der Aalst for developing the ﬁrst formalization of ConDec [191, 192]. Temporal logics are a special class of modal logics where modalities are interpreted as temporal operators, used to describe and reason about how the truth values of assertions vary with time [99]. According to [99], temporal logics can be classiﬁed along a number of axes, as we have done in Sect. 2.1.2 for characterizing the notion of time in interaction models. In particular, temporal logics can be: • • • • • •

propositional vs ﬁrst-order linear vs branching point vs interval-based discrete vs continuous past vs tense qualitative vs metric

Where not explicitly stated, in this book we will focus on the propositional Linear Temporal Logic (LTL) with future-tense operators only. More speciﬁcally, we consider LTL as being: propositional. Constraints are built up from atomic propositions, whose truth values change over time.

68

3 The ConDec Language

linear. Each situation has a single next future moment, and temporal modalities therefore predicate on the truth of propositions along a single timeline; alternatives are modeled as “branches in time” instead of “branches of time” [201]. qualitative. Temporal operators are used to express qualitative time relations between propositions. Metric distances are not part of the logic. point-based. Temporal operators and propositions are evaluated over points in time. discrete. Time is discrete; the present moment correspond to the current state of the system and the next moment to the immediate successor state (typically corresponding to the ﬁrst following moment at which some further event occur, causing the system to evolve). future-tense. Temporal operators are predicate on the occurrence of events in the future. This is reasonable for systems which have a deﬁnite starting time, and all the systems considered in this book exhibit this feature (see Sect. 2.1.2). 3.6.1 LTL Models In accordance with the outlined properties, the LTL time structure F , also called frame, models a single, linear timeline; formally, F is a totally ordered set (S, ≺). Let P be the set of all atomic propositions in the system. An LTL model M is a triple (S, ≺, v) where v : P → 2S is a valuation function which maps each proposition in P to the set of time instances at which the proposition holds. In the ConDec setting, each proposition represents a possible event that may occur during an instance of the system. More speciﬁcally, a proposition e ∈ P is true in a certain state if at that state the event denoted by e occurs. Under this interpretation, LTL models correspond to execution traces. Deﬁnition 3.6.1 (LTL execution trace). Given a set E representing all the events that can potentially occur during the executions of the system under study, an LTL execution trace TL is an LTL model having N as time structure and E as the set of atomic propositions. In particular, TL = (N, <, vocc ), where vocc : E → 2N is a valuation function mapping each event e ∈ E to the set of all timestamps at which e occurred. For convenience, we will sometime use the following abbreviations: TL (i) will denote the i − th state of TL , and e ∈ TL (i) will be adopted as a shortcut for i ∈ vocc (e). 3.6.2 Syntax of Linear Temporal Logic LTL formulae are deﬁned by using:

3.6 Linear Temporal Logic

69

Table 3.9. LTL temporal operators op.

name

meaning

intuition current state

φ (Next time) φ will hold in the next state

♦φ (Eventually) φ will hold sometimes in the future φ ψUφ

(Globally) φ will always hold in the future (Until) φ will hold in a future moment, ψ will always hold until that moment

• atomic propositions, i.e., events, together with the two special constants true and f alse; • classical propositional connectives, i.e., ¬, ∧, ∧ and ⇒; • temporal operators, i.e., (next time), U (until), ♦ (eventually), (globally) and W (weak until). Starting from these constitutive elements, an LTL formula is recursively deﬁned as follows: • • • • •

each event e ∈ E is a formula; if φ is a formula, then ¬φ is a formula; if φ and ψ are formulae, then φ ∧ ψ is a formula; if ψ is a formula, then ψ is a formula; if φ and ψ are formulae, then φUψ is a formula.

Other LTL formulae can be deﬁned as abbreviations: • φ ∨ ψ ¬(¬φ ∧ ¬ψ) and φ ⇒ ψ ¬φ ∨ ψ; • true ¬φ ∨ φ and f alse ¬true; • ♦φ trueUφ, φ ¬♦¬φ and ψWφ ψUφ ∨ ψ. When parentheses are omitted, the following priority of operators holds: ﬁrst all the temporal operators, then ¬, ∧, ∨ and ﬁnally ⇒. 3.6.3 Semantics of Linear Temporal Logic The semantics of LTL is given w.r.t. an LTL model, in a speciﬁc state. In other words, the truth of formulae is evaluated inside a given state. We will use |=L to denote the logical entailment in the LTL setting. M, i |=L φ means that φ is true at time i in M. The intuitive semantics of each temporal operator is sketched in Table 3.9. The W operator relaxes U by removing the requirement that φ must eventually hold in a future moment, and by stating that in this case ψ must hold in all the future states.

70

3 The ConDec Language

|=L is deﬁned by induction on the structure of the formulae3 : • • • • • • • • • • •

(TL |=L φ) iﬀ (TL , 0 |=L φ); (TL , i |=L e) iﬀ e ∈ TL (i) (i.e., i ∈ vocc (e)); (TL , i |=L e) iﬀ e ∈ TL (i); (TL , i |=L φ ∧ ψ) iﬀ (TL , i |=L φ) and (TL , i |=L ψ); (TL , i |=L φ ∨ ψ) iﬀ (TL , i |=L φ) or (TL , i |=L ψ); (TL , i |=L φ ⇒ ψ) iﬀ (TL , i |=L φ) or (TL , i |=L ψ); (TL , i |=L φ) iﬀ (TL , i + 1 |=L φ); (TL , i |=L ψUφ) iﬀ ∃k ≥ i s.t. (TL , k |=L φ) and ∀i ≤ j < k (TL , j |=L ψ); (TL , i |=L ♦φ) iﬀ ∃j ≥ i s.t. (TL , j |=L φ); (TL , i |=L φ) iﬀ ∀j ≥ i (TL , j |=L φ); (TL , i |=L ψWφ) iﬀ either ∃k ≥ i s.t. (TL , k |=L φ) and ∀i ≤ j < k (TL , j |=L ψ), or ∀j ≥ i (TL , j |=L φ).

3.7 Translating ConDec into Linear Temporal Logic LTL can be successfully employed to formalize all the ConDec constraints, providing a temporal logic-based semantics to the graphical notation. The ConDec language itself has been developed starting from the work of Dwyer et al. [98], in which the authors present a pattern-based analysis of the most diﬀused LTL formulae in the speciﬁcation of concurrent reactive systems. In this light, ConDec can be considered as a graphical front-end, supporting non-IT savvy in the rigorous formal speciﬁcation of interaction models, while avoiding the direct manipulation of temporal logical formulae. 3.7.1 The Translation Function We suppose that the translation of an arbitrary ConDec model into the underlying LTL formalization is embedded in a translation function called tLTL . Deﬁnition 3.7.1 (ConDec to LTL translation). tLTL is a function which translates a ConDec model CM = A, Cm , Co into an LTL conjunction formula as follows: tLTL (Ci ) tLTL : CM −→ tLTL (CM) = Ci | Ci ∈Cm

where tLTL (Ci ), i.e., the application of tLTL to a ConDec mandatory constraint, follows the guidelines provided in [191, 173].

3

For the sake of readability, we explicitly denote the semantics of ♦, and W, even if their meaning can be obtained from the semantics of U.

3.7 Translating ConDec into Linear Temporal Logic

71

Example 3.7.1 (LTL representation of a ConDec model). Let us consider a portion of the ConDec model shown in Fig. 3.2, namely: 0..1

refuse order •−− −• pay •−−• deliver receipt Its LTL representation is: ⎛

0..1

⎞

−• pay •−−• deliver receipt ⎠ = tLTL ⎝ refuse order •−− tLTL tLTL

refuse order •−− −• pay

(Def. 3.7.1)

∧

pay •−−• deliver receipt ∧ ⎛ ⎞ 0..1

tLTL ⎝ deliver receipt ⎠

=

([191, 173])

[♦ref use order ⇒ ¬♦pay ∧ ♦pay ⇒ ¬♦ref use order] ∧ [(pay ⇒ ♦deliver receipt) ∧ (¬deliver receipt)Wpay] ∧ [¬(♦(deliver receipt ∧ ♦deliver receipt))] Indeed, the translation of the whole model corresponds to the conjunction of the formulae translating each one of the three constraints. The not coexistence constraint is represented in LTL by stating that if refuse order is eventually executed, then the execution of the pay activity is always forbidden4 , and vice versa. The succession constraint is translated as the conjunction of the translations of its response and precedence parts. Response expresses that every time a payment is done, then a receipt will be eventually delivered. Conversely, the precedence part is formalized by means of the weak until operator: deliver receipt cannot be executed until the payment is done, or it cannot be executed at all if the payment is never done. Finally, the absence 2 constraint is formalized by forbidding a double execution of deliver receipt. To model the double occurrence of deliver receipt, in turn, we combine the ♦ and operators: the receipt must be eventually delivered, and from the state immediately following such a delivery a second receipt must be eventually delivered again. 3.7.2 LTL Entailment as a Compliance Evaluator Thanks to Defs. 3.6.1 and 3.7.1, we have established a link between execution traces and LTL models, and between ConDec models and LTL formulae. Under this perspective, LTL entailment provides a formal account to the notion 4

Remember that ¬♦pay ¬pay.

72

3 The ConDec Language

of compliance, and it therefore denotes the set of execution traces supported by a ConDec model (see Def. 3.2.2). Deﬁnition 3.7.2 (Execution trace support in the LTL setting). Given an LTL execution trace TL and a ConDec model CM, TL is supported by CM (i.e., TL is compliant with CM) if and only if TL |=L tLTL (CM). Example 3.7.2 (Compliance as LTL entailment). Let us consider a ConDec model CM containing only a single response constraint between the query and inform activities. As we have seen in Example 3.7.1, the LTL translation of CM is: (query ⇒ ♦inf orm) tLTL (CM) tLTL query •−−− inform By applying Def. 3.7.2 together with the LTL declarative semantics reported in Sect. 3.6.3, we have that an LTL execution trace TL is then supported by CM if and only if: TL |=L (query ⇒ ♦inf orm) ⇔∀ i ≥ 0, (TL , i |=L query ⇒ ♦inf orm) ⇔∀ i ≥ 0, query ∈ TL (i) ∨ (TL , i |=L ♦inf orm) ⇔∀ i ≥ 0, query ∈ TL (i) ∨ (∃ j ≥ i, inf orm ∈ TL (j)) Therefore, it holds that: • The empty trace is supported by CM, because all its states do not contain the execution of the query activity. • Because of the same reason, also a trace containing only occurrences of “external” activities (i.e., activities diﬀerent than query and inform) is supported, for the sake of the openness (note that, anyway, such external activities must appear as part of A(CM)). • The trace described by vocc (query) = {0} is not supported, because the response constraint requires the presence of an inform in at least one state ≥ 0. • The trace described by vocc (query) = {0, 1}, vocc (inf orm) = {2} is supported, because both i = 0 and i = 1 have a following j (j = 2 in particular) belonging to the valuation set of the inform activity. 3.7.3 Linear Temporal Logic and Finite ConDec Traces In Sect. 2.1.2, we have discussed that the temporal dimension in interaction models is bounded, and therefore their execution traces are always ﬁnite. We formulate this feature in the LTL setting, introducing the notion of ﬁnite LTL trace.

3.7 Translating ConDec into Linear Temporal Logic

73

Deﬁnition 3.7.3 (ﬁnite LTL trace). An LTL execution trace TL is ﬁnite if and only if there exists a state n such that all the states belonging to its inﬁnite suﬃx do not appear in the valuation function of any event, i.e.: ∃ n ∈ N s.t. TL (n) = ∅ ∧ ∀ i > n, TL (i) = ∅ n represents the length of the trace, namely length(TL ) n. The problem is that the LTL semantics is given for general LTL traces, and has N as the underlying (inﬁnite) time structure. To reconcile the logic with the intended “ﬁnite” semantics, two possible solutions can be investigated: • a further LTL formula, formalizing the “ﬁnitness requirement”, is added to the conjunction formula produced by the application of the translation function tLTL on a ConDec model; • LTL models are redeﬁned as sequences of ﬁnite length, and the semantics of the logic is revised accordingly. Let us brieﬂy discuss both solutions. The ﬁrst solution is conservative: it tries to introduce the ﬁnitness requirement inside the logic, without modifying its semantics. This approach has the great advantage that the huge amount of computer aided veriﬁcation tools, developed in the literature for reasoning upon LTL speciﬁcations, can be seamlessly applied to ConDec as well (see Chapt. 11). To formalize the ﬁnitness requirement in LTL, the following termination property can be employed. Deﬁnition 3.7.4 (ConDec termination property). Given a ConDec model CM, the LTL termination property of CM, denoted by term(CM), states that there must eventually be a state starting from which no event will occur: ⎞ ⎛ ¬a⎠ term(CM) ♦ ⎝ ∀a∈A(CM)

The notion of compliance (support) relating a ﬁnite execution trace with a speciﬁc model must then be properly revised, taking into account also the termination property. In particular, compliance must be assessed by considering the LTL formalization of the model, augmented with the termination property. We denote this kind of support as ﬁnite support. Deﬁnition 3.7.5 (Finite support in the LTL setting). Given a ﬁnite LTL execution trace TLf and a ConDec model CM, TLf is ﬁnitely supported by CM (i.e., is ﬁnitely compliant with CM), if and only if: TLf |=L tLTL (CM) ∧ term(CM) Sometime, it is assumed that the execution traces of the system are not only ﬁnite, but also totally ordered: at a given time, at most one event may

74

3 The ConDec Language

happen. This is for example the approach followed by the original formalization of van der Aalst and Pesic [192, 191, 195]. Under this assumption, the termination property can be rewritten introducing a special “end” event, which must eventually be executed, then inﬁnitely repeating its execution in each following state: ♦end5 . In other words, a state must be eventually reached, starting from which the “end” event will saturate the trace, excluding the possibility of executing other activities6 . In this book we do not make the assumption that traces are totally ordered, and thus we rely on the general termination property introduced in Def. 3.7.4. Indeed, after having introduced the CLIMB framework, we will discuss the impact of switching to a quantitative notion of time, and of introducing quantitative time constraints. When it comes to a quantitative notion of time, the granularity plays a central role: event occurrences are bound to time units, whose order of magnitude depends on the domain under study. While the total ordering assumption is reasonable when a granularity of milliseconds is chosen, it becomes questionable when shifting to a magnitude of hours or days. The second possibility for dealing with the gap between LTL and ﬁnite traces, is to directly consider ﬁnite LTL traces as the only possible models for the logic, revising the semantics of temporal operators accordingly. A plethora of ﬁnite trace semantics for LTL have been proposed in the literature; the reader may refer to [32] for a comprehensive survey on the topic. For example, the original semantics of ConDec has been deﬁned in terms of the ﬁnite trace semantics introduced in [131, 115]. The semantics relies on ﬁnite execution traces, which either represent the observed portion of a system’s execution or a complete, ﬁnite run. In this setting, the semantics of LTL temporal operators is revised by limiting their scope to the (ﬁnite) set of states contained in the trace, i.e., taking into account only the states between 0 and the length of the trace. Hence, the semantics of formulae inolving U, ♦ and is redeﬁned as follows: • (TLf , i |=L ψUφ) iﬀ ∃k, i ≤ k ≤ length(TLf ) s.t. (TLf , k |=L φ) and ∀i ≤ j < k (TL , j |=L ψ); • (TLf , i |=L ♦φ) iﬀ ∃j, i ≤ j ≤ length(TLf ) s.t. (TLf , j |=L φ); 5 6

This property is usually represented in the literature as ♦end ∧ (end ⇒ end). This approach requires a completion of each considered ﬁnite LTL trace, extending it with an inﬁnite suﬃx constituted by “end” events. Formally, given a ﬁnite LTL trace TLf with valuation function vocc : E → 2N , its completion extends TLf by introducing the special end event, and stating that its valuation function corresponds to the inﬁnite suﬃx following the length of TLf : completion(TLf ) = (N, <, vocc ), where vocc (e) vocc (e) ∀ e ∈ E N vocc : E ∪ {end} → 2 and vocc (end) {i | i > length(TLf )}

3.7 Translating ConDec into Linear Temporal Logic

75

• (TLf , i |=L φ) iﬀ ∀j, i ≤ j ≤ length(TLf ) (TLf , j |=L φ). The main advantage of opting for a ﬁnite trace semantics, is that it is directly able to capture the ﬁnite nature of the domain under study. Furthermore, while the veriﬁcation techniques developed for the general LTL cannot be employed anymore, it is possible to devise new eﬃcient tools speciﬁcally thought for reasoning upon ﬁnite traces.

4 The CLIMB Rule-Based Language

The CLIMB (Computational Logic for the verIﬁcation and Modeling of Business constraints) language is a declarative rule-based language for the speciﬁcation of interaction models. This chapter describes syntax and features of the language, showing how it can suitably deal with static as well as dynamic aspects of EBSs; the declarative semantics of the language is presented, providing a formal characterization of compliance; ﬁnally, some interesting properties, such as compositionality of CLIMB speciﬁcations, are investigated. The CLIMB language is a ﬁrst-order logic-based language; quantiﬁcation is left implicit in the language, in order to facilitate readability and usability. We will brieﬂy discuss in an informal way and by means of examples how variables are quantiﬁed. For an exhaustive description concerning the quantiﬁcation of variables and the restrictions imposed on the language the interested reader may refer to [8, 58]. In the remainder of the book, we will assume that the reader is familiar with First Order Logic (FOL), Logic Programming (LP) and Prolog. A good introduction to LP is the book by Lloyd [154]; good introductions to Prolog are the books by Sterling and Shapiro [227] and by Bratko [49].

4.1 The CLIMB Language in a Nutshell As shown in Fig. 4.1, the CLIMB language is a subset of the SCIFF language [8], which has been developed in the context of the SOCS European Project1 . The purpose of the SOCS EU Project, carried out inside the Global Computing initiative, was to devise a logic-based framework for the speciﬁcation and veriﬁcation of open and heterogeneous Multi-Agent System (MAS) 1

Societies Of ComputeeS (SOCS): a Computational Logic model for the description, analysis and veriﬁcation of global and open societies of heterogeneous computees. IST-2001-32530, 2002-2005. Web-page: http://lia.deis.unibo.it/research/socs/

M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 77–114, 2010. c Springer-Verlag Berlin Heidelberg 2010

78

4 The CLIMB Rule-Based Language SCIFF SCIFF-lite CLIMB

Fig. 4.1. Variants of the SCIFF language and their expressiveness

ABSTRACTION (events)

SYSTEM EXECUTION

ABSTRACTION (events)

SYSTEM EXECUTION

Fig. 4.2. Abstraction of a system execution in terms of event occurrences

(see Sect. 7.1.4), ranging from the implementation of autonomous intelligent agents (called computees) to the engineering of their interaction. A large part of the project was indeed focused on the inter-agent perspective, i.e., on the interaction protocols regulating the messages exchange between computees and also external, unknown entities. Being these systems open and heterogeneous, it is impossible to make any assumption about the number and the internal implementation of interacting agents. Hence, the problem of specifying and verifying interaction requires an abstraction step, to identify what pieces of information could be eﬀectively observed and, consequently, targeted by the speciﬁcation language. In line with the general discussion made in Sect. 2.1.1, the idea developed within SOCS was to characterize each instance of an open MAS in terms of the events that are generated by the involved entities when acting on the environment or interacting with each other (see Fig. 4.2). Thus, SCIFF can be applied to any dynamic context whose executions can be described in terms of events. In particular, we think of CLIMB as a rule-based language for the declarative and open speciﬁcation of interaction models. CLIMB speciﬁcations are mainly composed by two parts: 1. a set of rules which relate event occurrences with expectations about other event occurrences, which are used to characterize the ideal dynamics of the system; 2. a knowledge base formalizing the static aspects of the system, i.e. the background knowledge independent of the speciﬁc executions of the system.

4.2 The CLIMB Language

79

4.2 The CLIMB Language We present the CLIMB syntax in a bottom-up manner, starting from the basic building components of the language, i.e., event occurrences, traces and expectations, and then discussing how they are jointly combined in rules and clauses of the knowledge base. 4.2.1 Event Occurrences and Execution Traces Deciding what has to be considered an event strictly depends on the application domain. In a service-oriented setting, events may represent messages exchange, whereas in BPM an event may represent the fact that a certain activity has been started, completed, or reassigned. Furthermore, even if the application domain is ﬁxed, there could be several diﬀerent notions of events, because of the assumed perspective, the granularity, and so on. For example, one could adopt a coarse-grained approach by considering that each activity in a Business Process is atomic, thus linking the concept of event to the generic one of “activity execution”. This is the approach taken by the ConDec language, as we have introduced it in Chap. 3. Events are represented in CLIMB as LP terms. In this way, the language completely abstracts away from the problem of deciding “what an event is”, and rather lets the developers decide which are the important events for modeling the domain, at the desired abstraction level. For example, the delivery of a message sent by a web service ws1 to another web service ws2 , with a certain content can be simply denoted by send(ws1 , ws2 , content(. . .)). It is worth noting that, diﬀerently from propositional LTL, CLIMB is a ﬁrstorder language, and therefore variables can be seamlessly used inside events in place of constant values. For example, send(Sender, Receiver, content(C)) could represent a message exchange between two unknown web services, and referring to an unknown content. The instances of the system under study are characterized by the set of events occurring when entities act and interact with each other. Hence, a symbol denoting the occurrence of an event at a certain time must be provided by the language. Diﬀerently from temporal logics, which implicitly embed time inside modal, qualitative operators, CLIMB adopts an explicit and quantitative notion of time: happened events are associated to a time variable or numerical timestamp. More speciﬁcally, the occurrence (Happening) of an event Ev at a (discrete) time point T is denoted by the atom H(Ev, T ) where Ev is a term and T is a numerical variable, which ranges over different domains, depending on the chosen underlying time structure. In fact, CLIMB can likewise adopt either a discrete (i.e., (N, <) or (Z, <)) or dense (i.e., (R, <)) time structure. In order to maintain the discussion general, we

80

4 The CLIMB Rule-Based Language

will therefore abstract away from the speciﬁc time structure, using T as a generic placeholder. Happened events may have a variable time and/or contain variables in their event part, or they can be completely ground. In the ﬁrst case, they refer to classes of concrete event occurrences, whereas in the latter case they represent a speciﬁc occurrence of the involved event, at the speciﬁed time. Therefore, in CLIMB an execution trace is simply deﬁned as a (ﬁnite) set of ground happened events. Deﬁnition 4.2.1 (Herbrand base of traces). The Herbrand base of traces BH is the Herbrand base built upon CLIMB happened events: BH = {H(e, t)|e ∈ U, t ∈ T} where U is the Herbrand universe of events. Deﬁnition 4.2.2 (CLIMB execution trace). A CLIMB execution trace T is a ﬁnite set of ground happened events: T ⊆ BH . As we have sketched above, partially speciﬁed happened events, namely happened events containing non-ground variables, are used to identify and match with “classes” of concrete ground events. If the variables contained in a happened event are completely free (e.g., H(E, T )), then such a happened event will denote any occurrence of any event in the execution trace (i.e. it will match with all events in the trace); variables can then be subject to constraints in order to restrict the corresponding matching class. In particular, variables can be constrained by means of CLP constraints (see Sect. 4.2.2) or Prolog predicates. The following example introduces some ground and non-ground happened events, discussing their meaning. Example 4.2.1 (Happened events). Let us consider some examples of happened events in the context of a loan process. It is assumed that the handling of a loan is a non atomic activity, and is therefore is associated to a set of events, representing the evolution of its executions. For the sake of simplicity, we consider only the start and complete events, used to respectively denote the initiation and termination of the management of loans. Each loan is associated to a unique identiﬁer. Thus, the fact that the employee Emp starts (completes) the management of a loan identiﬁed by Loanid can be represented by the term event(T ype, handle loan, Emp, Loanid ), where T ype/start (T ype/complete). For example, H(event(start, handle loan, alice, l 09 2008), 14164)

(†)

represents a ground event occurrence, stating that Alice started to handle the loan identiﬁed by l 09 2008 on October 13th 2008, making the assumption that times are represented by the number of days from January 1st, 1970. Let us now introduce some examples of non ground event occurrences, discussing whether they match with † or not.

4.2 The CLIMB Language

81

H(Ev, T ) represents the occurrence of some event at an unspeciﬁed time, and therefore it matches with any event occurrence. For example, it matches with (†), under the substitutions • Ev/event(start, handle loan, alice, l 09 2008) • T /14164 H(event(T ype, handle loan,O,Id),T )∧member(T ype,[start, complete]) 2 represents the initiation or termination of a loan handling activity. It matches with any speciﬁc loan management initiation or termination, hence also with (†), with bindings T ype/start, O/alice, Id/l 09 2008 and T /14164. H(event(start, handle loan, O, Id), T ) ∧ T ≤ 13966 states that the handling of a loan has been started by someone before the end of February 2008 (again, supposing that times are represented by the number of days from January 1st, 1970). T ≤ 13966 is an example of CLP constraint. This happened event does not match with (†), because 14164 is greater than 13966. H(event(start, handle loan, O, Id), T ) ∧ level(O, 1) denotes that a ﬁrst-level employee has started the handling a loan, supposing that level(O, L) is a Prolog predicate denoting that employee O belongs to level L. This partially speciﬁed happened event matches with (†) only if Alice is a ﬁrstlevel employee. As we will see in Sect. 4.2.5, this kind of information can be modeled inside the CLIMB knowledge base. H(event(complete, handle loan, alice, Id),T )∧price(Id, P ) ∧ P > 106 models that Alice has completed the management a loan involving an amount of at least 1K e(expressed by the CLP constraint P > 106 ), where that price(Id, P ) is a Prolog predicate used to denote that the loan identiﬁed by Id involves a price P . This happened event matches with (†) only if loan l 09 2008 is of at least 1K e. 4.2.2 Constraint Logic Programming In LP, symbols are not interpreted. As a consequence, a numerical expression such as “two plus three”, represented in LP as term 2 + 3, does not mean 5, but simply a structure whose functor is + and whose terms are 2 and 3 (2 + 3 +(2, 3)). Moreover, uniﬁcation is a syntactic operation. Thus, term 5 does not unify with 3 + 2. Similarly goal 5 = 3 + 2 fails, and so does 5 = X + 2. However, diﬀerently from domain-dependent terms and clauses, inside the head of the modeler these kinds of expressions carry on a clear, domainindependent meaning, bound to mathematics and algebraic structures. In the light of this, 5 = X + 2 would be interpreted as “ﬁve is equal to X plus two”, leading to infer that “X is equal to three”. Constraint Logic Programming (CLP) [135] aims at overcoming this issue. It is a class of programming languages that combines the advantages of LP 2

Member is a Prolog predicate, built-in inside all the major Prolog implementations, for testing whether an element belongs to a list or not. In particular, member(E, L) is true if and only if E is an element of list L.

82

4 The CLIMB Rule-Based Language

with the eﬃciency of constraint solving. In particular, CLP interprets some of the symbols contained in a logic program, treating them separately from the other ones. In this way, the declarativeness of LP is combined with domainspeciﬁc, eﬃcient computational mechanisms. It is deﬁned as a general scheme which can be specialized over particular domains. Each language of the CLP class is identiﬁed by: • a domain, representing the set of values that can be assumed by an interpreted variable; • the set of interpreted atoms, called constraints; • the set of interpreted symbols. For example, CLP(R) [136] is the instance of CLP which focuses on the R algebraic structure; this means that CLP(R) variables range over the real domain, and they are subject to constraints on the reals. Current implementations typically employ the simplex algorithm as constraint solver and feature a complete propagation of linear constraints. CLP(F D) is instead is the specialization of CLP on the Finite Domains [95]. These two CLP languages give an interpretation to numbers (real and integer respectively), their relation symbols (<, ≤, =, . . . ) and operations (+, −, ×, : ). For example, in CLP(R) the 5 symbol stands for the real number “ﬁve”, while + denotes the “addition” operation. For all the interpreted symbols, CLP replaces uniﬁcation with a more powerful constraint solving mechanism. For example, when the constraint 5 = X + 2 is encountered, it succeeds, producing the answer X = 2. This behavior is obtained by performing a syntactic identiﬁcation of the interpreted atoms (called constraints), inserting them in a constraint store and delegating their evaluation to a constraint solver instead of applying classical resolution. A store is needed because, in the general case, it is not always possible to immediately evaluate a constraint. For example, constraint T ≤ 13966 (cited in Example 4.2.1) is not satisﬁed nor violated when it is encountered, but has only the eﬀect of restricting the domain of the involved variable: by adopting a dense time-structure, its eﬀect would be to restrict the domain of T from R to (−∞, 13966]. The constraint solver takes care of processing constraints, pruning the domain of the interpreted variables when they are encountered, and propagating this information to the other constraints contained in the constraint store. The possible eﬀect of this propagation is to restrict the domain of other variables, which in turn recursively trigger new propagations. In this way, the constraint solver eﬃciently infers which are the possible consistent values that can be assumed by interpreted variables, or detects a violation as soon as possible. A plethora of languages and eﬃcient solvers have been developed to describe and manage constraints, such as for example ECLi PSe3 and SICStus4 . 3 4

http://www.eclipse-clp.org/ http://www.sics.se/isl/sicstuswww/site/

4.2 The CLIMB Language

83

Such frameworks have been successfully exploited for hard combinatorial problems in many diﬀerent application domains, like scheduling, planning, temporal reasoning and bioinformatics. In the context of CLIMB, CLP constraints are extensively applied to the time variables, in order to model qualitative and quantitative temporal constraints. For example: • T2 > T1 is a qualitative time constraint, modeling that T2 is after T1 ; • T ≤ 13966 is an absolute time constraint, specifying that T is before the absolute timestamp of 13966; • T2 < T1 + 5 is a relative time constraint, stating that T2 is before T1 plus 5 time units. 4.2.3 Expectations The most important aspect of CLIMB is that it focuses on the dynamics of the EBS under study, which we deemed to be an essential feature of interaction models. In particular, beside the representation of “what” happened and “when” (through the use of H atoms), the language explicitly supports the representation of “what” is expected (not) to happen, and “when”. As argued in [235], expectations are abstract entities that captures the possible events that would make a system conform to its requirements. A set of expectations represents a possible evolution of the system towards a correct situation, pointing out, at every time point, the desired and undesired courses of interaction. The fact that both desired and undesired courses of interaction are tackled is due to the openness requirement. In this respect, not only positive expectations, but also negative expectations, are supported by the language. A positive expectation is used to express that a certain event Ev is Expected to happen at a given time T , and is represented by E(Ev, T ) Conversely, if event Ev is Expected Not to happen (i.e., is forbidden) at time T , then a negative expectation is employed: EN(Ev, T ) As for happened events, expectations can be completely speciﬁed or not. The possibility of leaving some of their parts variable is of great importance. Indeed, they could refer to events which have not yet occurred, and it is therefore unreasonable to assume that all their parts can be ﬁxed a-priori. For example, in the context of a service choreography, an expectation stating that service s1 is waiting for a query message from some other service, demands to leave the sender of the event, as well as the actual occurrence time, unspeciﬁed: E(msg(Sender, s1 , query), Tq ). However, it is as much important to provide the ability of placing requirements on expectations, in order to restrict the

84

4 The CLIMB Rule-Based Language

range of variables. For example, the aforementioned expectation could be restricted to express that the query message is expected to be received from a service playing the role of customer, or it is expected to happen before a certain deadline. Technically, this is again done by means of CLP constraints and Prolog predicates. Positive and negative expectations diﬀer in the quantiﬁcation applied to the involved variables. Quantiﬁcation strictly resembles the intuitive characterization of expectations: • a positive expectation predicates on the existence of at least one corresponding event occurrence, and it is therefore existentially quantiﬁed; • a negative expectation forbids the presence of any possible corresponding event occurrence, and it is therefore universally quantiﬁed. The following example clariﬁes this diﬀerence, grounding the discussion on some concrete cases. Example 4.2.2 (Requirements on expectations). A business manager working for a loan company wants to specify that: • someone must start to handle the loan l 01 2008 by the end of February 2008; • ﬁrst-level employees cannot handle loans involving an amount greater than 1K e. Being workers autonomous, these requirements cannot be enforced, but they can be instead formulated as expectations placed on employees. In particular, the ﬁrst requirement is a positive expectation, whereas the second one is a negative expectation: they respectively represent a desired and undesired situation. Following the approach of Example 4.2.1, we assume that an event concerning the handling of a loan is represented by event(T ype, handle loan, O, Id), where T ype is the event type (start or complete), O is the worker who handles the loan and Id is the loan identiﬁer. Furthermore, we use the Prolog predicate price(Id, P ) to specify that the loan identiﬁed by Id is of an amount P , and predicate level(O, L) to state that employee O belongs to level L. Under these assumptions, we the ﬁrst statement can be formalized by means of the following positive expectation: E(event(start, handle loan, O,l 01 2008), T ) ∧ T ≤ 13966 The expectation states that there must exist a worker O and a time T ≤ 13966 at which O starts to handle the loan l 01 2008. Indeed, O and T are existentially quantiﬁed. We can express the second statement with the following negative expectation:

4.2 The CLIMB Language

85

EN(event(T ype, handle loan, O, Id), T ) ∧ level(O, 1) ∧ price(Id, P ) ∧ P > 106 The expectation states that it should never happen that a ﬁrst-level employee O is responsible of an event related to loans of more than 1K e. In other words, all loans involving an amount of at least 1K e cannot never be managed by ﬁrst-level employees. In this respect, T ype and T are universally quantiﬁed over their whole domains, O is universally quantiﬁed over the domain of ﬁrstlevel employees, and Id is universally quantiﬁed on the domain of identiﬁers representing loans of at least 1K e). 4.2.4 Integrity Constraints The combination of happened events and expectations is the core of the CLIMB language, which supports the modeler in the intuitive characterization of interaction models in terms of rules following the form: “if e1 happened, then e2 is expected (not) to happen”. They relate the achievement of a given state of aﬀairs, represented by means of happened events, with the expected or forbidden behavior towards a correct evolution of interaction. In the SCIFF setting, these rules are called (social) integrity constraints, because they constrain the courses of interaction so as to ensure their integrity and compliance with interaction protocols, and because such interaction protocols are speciﬁed adopting a global viewpoint, i.e., at the social level of the MAS. Similarly, in CLIMB they are used to express the overall “interaction contract”, composed by all the business constraints that must be respected by the interacting entities. Integrity constraints are represented as rules of the form Body → Head. Their syntax has a fragment common to all the three variants of SCIFF (CLIMB, SCIFF-lite and full SCIFF – see Fig. 4.1, p. 78). The EBNF grammar of such a common part is reported in Table 4.1, where the non-terminal symbols of Atom, T erm, V ariable and N umber have the same structure as in LP and CLP, while “not” denotes Negation As Failure (NAF) [77]. Roughly speaking, the grammar states that the body of each integrity constraint is a conjunction of BConjunct symbols, whereas the head is a disjunction of conjunctions of HConjunct symbols. Thus, an integrity constraint follows the structure

BConjuncti → HConjunctj,k i

j

k

The BConjunct and HConjunct non-terminal symbols, which constitute the two basic elements of integrity constraints, are instead deﬁned in diﬀerent ways by the three SCIFF variants. In particular, the CLIMB language deﬁnes integrity constraints as Body → Head rules where:

86

4 The CLIMB Rule-Based Language

Table 4.1. Common syntax of SCIFF integrity constraints; the deﬁnition of the BConjunct and HConjunct non-terminal symbols is deferred to each variant of the language (CLIMB, SCIFF-lite, full SCIFF) IC ::= {IC} IC ::= Body “ → ” Head “.” ::= ::= ::= ::= ::=

“true” | BConjunction BConjunct { “ ∧ ” BConjunct } “⊥” | HDisjunction HDisjunct { “ ∨ ” HDisjunct } HConjunct { “ ∧ ” HConjunct }

HEvent ::= Expectation ::= ExpT ype ::= Event ::= T ime ::= Literal ::=

“H(” Event “, ” T ime “)” ExpT ype “(” Event “, ” T ime “)” “E” | “EN” T erm N umber | V ariable [“ not ”]Atom

Body BConjunction Head HDisjunction HDisjunct

Table 4.2. CLIMB specialization of the integrity constraints syntax reported in Table 4.1 BConjunct ::= HEvent | Literal HConjunct ::= Expectation | Literal

• Body contains (a conjunction of) happened events, together with constraints on their variables, as well as Prolog predicates; • Head contains (a disjunction of conjunctions of) positive and negative expectations, together with constraints and Prolog predicates, applied on their variables and/or on variables contained in the Body. The completion of the general grammar, following these guidelines, is reported in Table 4.2. Each CLIMB rule formalizes a business constraint aﬀecting a speciﬁc behavioral aspect of the system. The set of all integrity constraints (which will be usually denoted by IC) represents the complete regulatory interaction model of the system. The following example illustrates three diﬀerent kinds of business constraints, that can be seamlessly described in CLIMB. Example 4.2.3 (Integrity constraints). Let us consider the following business constraints: (Br1) The person who takes the ﬁnal decision about the acceptance or rejection of a paper cannot review that paper. (Br2) If a customer has closed an order and the shop has consequently accepted it, then the customer is bound to execute the corresponding payment.

4.2 The CLIMB Language

87

(Br3) If a premium customer pays for an order by credit card, then the seller should answer within 10 time units by delivering a corresponding receipt, or by communicating a payment failure. We adopt an atomic model for activities, i.e., map their execution to single events. Sentence (Br1) is an example of four eyes principle, which states that two diﬀerent activities cannot be executed by the same person. It can be represented by means of the following CLIMB integrity constraint: H(emit decision(P erson, P aper, Decision), Te) →EN(review(P erson, P aper), Tr ).

(Br1-CLIMB)

It is worth noting that the P erson and P aper variables are shared between the negative expectation and the happened event, while execution times are not; therefore, the rule expresses that every time a person takes a decision concerning a paper, then that person cannot never review the same paper. Sentence (Br2) describes a rules which is triggered only when two diﬀerent events (order closing and order acceptance) occur in the speciﬁed order; only if such a state of aﬀairs is reached, the payment is expected: H(close order(Customer, Shop, Order), Tc ) ∧ H(accept order(Shop, Customer, Order), Ta ) ∧ Ta > Tc

(Br2-CLIMB)

→E(pay(Customer, Shop, Order, M ethod), Tp ) ∧ Tp > Ta . The CLP constraint Ta > Tc is used to identify a “legal” ordering among the happened events: the payment expectation is placed only if the shop has accepted an order after that the customer has closed it. If the ordering is not respected, then something was probably wrong, and the expectation about the payment is not enforced. The second constraint (Tp > Ta ) is instead used to identify the time range inside which the customer is bound to pay when the order has been closed and then accepted. In particular, the customer must pay after both the events in the body have already occurred. Sentence (Br3) is an example of disjunctive rule: it speciﬁes that when a certain event happen, so that a corresponding requirement is satisﬁed (the customer is a premium one), one among two possible behaviors is expected. This can be captured in CLIMB by employing a disjunction in the head of the rule:

88

4 The CLIMB Rule-Based Language

H(pay(Customer, Shop, Order, credit card), Tp ) ∧ premium customer(Customer, Shop) →E(deliver(Shop, Customer, receipt(Order, Inf o)), Td ) ∧ Td > Tp ∧ Td < Tp + 10 ∨E(tell(Seller, Customer, f ailure, Reason), Tf )

(Br3-CLIMB)

∧ Tf > Tp ∧ Tf < Tp + 10. The concept of “being a premium customer” is formalized by means of the premium customer/2 Prolog predicate, assuming that premium customer(C, S) is true if and only if shop S considers customer C as a premium one. To express mutual exclusion between the receipt delivery and the failure communication, we could also add a second rule like H(deliver(Seller, Customer, receipt(Item, Inf o)), Td) →EN(tell(Seller, Customer, f ailure, Reason), Tf ). and viceversa. An interesting aspect of sentence (Br3) is the presence of a deadline, i.e., of a maximum time delay by which an event (the delivery of a receipt or the communication of a failure) is expected to occur. Deadlines and other quantitative time constraints are dealt with by imposing CLP constraints on time variables. For example, the fact that a receipt must be delivered no later than 10 time units after the payment is rephrased by stating that the delivery time must be lower than the payment time plus 10 time units. Integrity constraints are operationally interpreted in a forward, reactive manner. The event occurrences characterizing the evolution of an instance match with the happened events contained in the body of integrity constraints, binding their variables to actual values. When the entire body of an integrity constraint becomes true, then the integrity constraint triggers, and the head must also be true. As we will see, this leads to the generation of the expectations contained in the head; if the head is a disjunction, a choice point is opened. Variables contained in the body of integrity constraints are universally quantiﬁed with scope the entire integrity constraint: in this way, each integrity constraint is instantiated every time an event matching with a part of its body happens, and it triggers for any possible actual conﬁguration making its body true. Example 4.2.4 (Triggering of integrity constraints). Let us consider the integrity constraint (Br2-CLIMB) of Example 4.2.3 and the following integrity constraint, which formalizes that a customer has the possibility to close at

4.2 The CLIMB Language

89

most one order by the same shop5 : H(close order(Customer, Shop, OrderA ), Tc ) →EN(close order(Customer, Shop, OrderB ), Tc2 )

(Br4-CLIMB)

∧ Tc2 = Tc . Let us now consider the following execution trace, and discuss how it triggers rules (Br2-CLIMB) and (Br4-CLIMB). (h1 ) H(close order(alice, bookShop, order 1), 2). (h2 ) H(accept order(bookShop, alice, order 1), 3). (h3 ) H(accept order(bookShop, lewis, order 2), 5). (h4 ) H(close order(lewis, bookShp, order 2), 8). (h5 ) H(close order(lewis, bookShop, order 2), 13). (h6 ) H(accept order(bookShop, lewis, order 2), 21). Being the body of integrity constraints universally quantiﬁed with scope the entire rule, every time a group of event occurrences makes its body true, then the rule triggers, generating the expectations contained in the head. In this case: • (h1 ) and (h2 ) unify with the two happened events contained in the body of (Br2-CLIMB), under the substitutions Customer/ alice, Shop/bookShop, Order/order 1, Tc /2 and Ta /3. Since 3 > 2, the temporal constraint contained in the body is evaluated to true by the CLP solver, and thus the following actual expectation is generated: E(pay(alice, bookShop, order 1, M ethod), T1 ) ∧ T1 > 3 The variables contained in the expectation, namely M ethod and T1 , are existentially quantiﬁed, and therefore the expectation means that alice is expected to eventually pay bookShop for order 1, at a time greater than 3 and by freely choosing a payment method. • (h4 ) uniﬁes with the ﬁrst happened event contained in the body of (Br2-CLIMB), with substitution Shop/bookShp; the substitution also propagates itself to the second happened event (the two events share the same variable), but the execution trace does not contain any order acceptance executed by a shop called bookShp. Therefore, this rule’s instance will not trigger. • (h3 ) and (h5 ) unify with the two happened events contained in the body of (Br2-CLIMB), but no triggering occurs, because the two substitutions Tc /5 and Ta /3 violate constraint Ta > Tc (the ordering of the actual happened events is the inverse of the ordering contained in the rule). 5

The Tc2 = Tc temporal constraint is needed to state that the two close order activities are not the same. Otherwise, the negative expectation would prohibit also the event that matched with the body of the integrity constraint, leading to an unintened violation.

90

4 The CLIMB Rule-Based Language

• (h5 ) and (h6 ) unify with the two happened events contained in the body of (Br2-CLIMB), satisfying the ordering constraint as well. The following expectation is then generated: E(pay(lewis, bookShop, order 2, M ethod), T2 ) ∧ T2 > 21 • each one of (h1 ), (h4 ) and (h5 ) matches with the body of (Br4-CLIMB), leading respectively to the generation of the following negative expectations: EN(close order(alice, bookShop, ), T3 ) ∧ T3 = 2 EN(close order(alice, bookShp, ), T4 ) ∧ T4 = 8 EN(close order(alice, bookShop, ), T5 ) ∧ T5 = 13 4.2.5 The Static Knowledge Base As far as now, we have focused on the dynamics of an EBS, which is captured in CLIMB by means of integrity constraints relating event occurrences with expectations. However, there is a strong intertwining between such dynamic aspects and the static domain knowledge, i.e., the pieces of information that will not change during the course of interaction. This latter background knowledge covers both extensional and intensional informations. Extensional (or assertional) knowledge is speciﬁc to the individuals of the domain of discourse, and explicitly captures all the known elementary facts characterizing the system. Examples of extensional knowledge are the fact that Alice is a ﬁrst-level employee, or that item i 112 358 costs 13 e. Intensional knowledge is instead related to the elicitation of deﬁnitional rules [204], which provide terminological declarations of the implicit properties characterizing business concerns and domain concepts, and enabling the derivation of new knowledge starting from the actual assertional informations. E.g., a computation rule, used to determine the total price of an order starting from its composing items and taking into account taxes, is a special kind of deﬁnitional rule. Deﬁnitional rules and explicit facts are relevant during the evaluation of behavioral business constraints. In the speciﬁc case of CLIMB, they are used to provide a deﬁnition to each Prolog predicate recalled in the integrity constraints. Some concrete cases have been discussed in Examples 4.2.3 and 4.2.2, where evaluating if a customer is a premium one, and obtaining the price of an order or the status level of an employee, have been delegated to Prolog predicates. In order to characterize the static domain knowledge, i.e., to deﬁne Prolog predicates, CLIMB introduces a Prolog knowledge base (that will be usually identiﬁed by KB hereafter). Inside KB, the modeler can formalize all the background knowledge about the system, complementing integrity constraints with roles descriptions, relationships between business objects, complex conditions and criterions involving data, databases, and so on.

4.2 The CLIMB Language

91

Table 4.3. Common syntax of a SCIFF knowledge base; CBAtom is a non-terminal symbol whose deﬁnition depends on the chosen variant (CLIMB, SCIFF-lite, full SCIFF) KB Clause CBody CHead

::= ::= ::= ::=

{Clause} CHead [“ ← ” CBody] “.” CBAtom {“ ∧ ”CBAtom} Atom

Table 4.4. CLIMB specialization of the knowledge base syntax reported in Table 4.3 CBAtom ::= Literal Literal ::= [“ not ”]Atom

As for integrity constraints, the syntax of a CLIMB knowledge base is a subset of the SCIFF one. According to the common syntax, in all the three variants of SCIFF, KB is a logic program, i.e., a set of clauses. Table 4.3 reports such a common syntax, where Atom has the same form as in LP. The three variants of SCIFF provide diﬀerent possibilities in the body of clauses, hence the CBAtom non-terminal symbol is left unspeciﬁed in the common syntax. In the speciﬁc CLIMB setting, the elements constituting the body of clauses are simply literals. This means that happened events and expectations cannot be employed in the knowledge base. The syntax is speciﬁed in Table 4.4. We illustrate the potentialities provided by a knowledge base concerning the speciﬁcation of the static background knowledge, by means of the following example. Example 4.2.5 (A knowledge base modeling the roles in a company). Let us consider the characterization of the concept of level associated to each employee inside a company. This concept has been recalled in Examples 4.2.1 and 4.2.2; now we focus on its deﬁnition. The company states that: • each employee can play diﬀerent roles, but has a unique “primary” role, used to determine her level; • roles are organized in a hierarchy; • the level of a role is the maximum depth of the role inside the hierarchy, starting from the leaves. This kind of knowledge is static: it does not depend on the dynamics of the system, but only on its structural organization. Therefore, it can be suitably modeled by means of a knowledge base. This knowledge base is typically constituted by two parts: • the formalization of the criterion used to evaluate the level of an employee (intensional part);

92

4 The CLIMB Rule-Based Language

supervisor

level 3

technical leader

analyst

level 2

secretary

level 1

programmer

Fig. 4.3. Hierarchy of roles

• the database of all employees together with their corresponding roles and primary roles (extensional part). We assume that role(E, R) and primary role(E, P R) respectively identify the role(s) R and the primary role P R played by employee E. Furthermore, we model the hierarchy of roles with predicate sub(R, SubRoles), which identiﬁes the list SubRoles of roles that are children of role R. Leaf roles do not have children. Under this assumptions, the intensional knowledge deﬁning the concept of level, where level(E, L) states that L is the level of E, can be expressed in a simple and compact way: level(E, L) ← r level(R, L) ←

primary role(E, P R) ∧ r level(P R, L). get subroles(R, C) ∧ r levels(C, Levels)

get subroles(R, C) ←

∧ max(Lmax , Levels) ∧ L is Lmax + 1. sub(R, C).

get subroles(R, []) ←

not(sub(R, C)).

r levels([R|Rs], [L|Ls]) ← r levels([], [0]).

r level(R, L) ∧ r levels(Rs, Ls).

where max(M, L) is true if and only if M is the maximum element of list L.A possible extensional knowledge base could be sub(supervisor, [technical leader, secretary]). sub(technical leader, [programmer, analyst]). primary role(alice, programmer). primary role(hatter, technical leader). primary role(lewis, supervisor). role(lewis, analyst).

4.2 The CLIMB Language

93

Table 4.5. SCIFF-lite specialization of the syntax reported in Tables 4.1 and 4.3 HConjunct ::= HEvent | Expectation | Literal BConjunct ::= HEvent | Expectation | Literal CBAtom ::= HEvent | Expectation | Literal

A graphical representation of the extensional knowledge base is provided in Fig. 4.3. According to the whole knowledge base (composed by the union of the intensional and extensional ones), the level of Lewis is 3, the level of Hatter is 2, and the level of Alice is 1. The clauses of a knowledge base are operationally treated in a backward, goal-oriented manner, recursively reducing goals to sub-goals until no further reduction is possible. This treatment comes from the procedural interpretation of Horn clauses by Kowalski [143]. In particular, Kowalski was the ﬁrst author who proposed to interpret a clause H ← B1 ∧ . . . ∧ Bn as a procedure of the kind “to show (solve) H, show (solve) B1 and . . . and Bn ”. More speciﬁcally, Prolog adopts the SLD(NF) resolution [143, 78, 18] as the basic backward inference rule to reason upon logic programs. Thanks to the integration between integrity constraints and logic programs provided by SCIFF, CLIMB exploits a reasoning paradigm that combines backward, goal-oriented reasoning with forward, reactive reasoning [8]: two aspects that are usually treated separately from each other. In particular, forward reasoning is used to react to occurring events, matching them against integrity constraints and handling the generation of expectations, while each time a Prolog clause is encountered, it is resolved following a backward, goaloriented strategy. 4.2.6 SCIFF-lite and Composite Events As depicted in Fig. 4.1 – p. 78), CLIMB is a subset of more expressive languages, namely SCIFF-lite and SCIFF in order of expressiveness. Here we introduce how the syntax of CLIMB is extended by SCIFF-lite. The syntax of full SCIFF is outside of the scope of this book; the interested reader may refer to [8, 58]. From the syntactic point of view, SCIFF-lite provides three extensions to the CLIMB language: • the head of integrity constraints can contain happened events; • the body of integrity constraints can contain expectations; • the deﬁnition of clauses in the knowledge base can contain happened events and expectations. The extended syntax is reported in Table 4.5.

94

4 The CLIMB Rule-Based Language

Happened events contained in the head of integrity constraints represent ﬁctitious, internal events that are generated by rules themselves; in this way, the achievement of complex state of aﬀairs, composed by a plethora of happened events, can be aggregated into a single composite event, as it is called in the Complex Event Processing (CEP) ﬁeld [156]. Indeed, composite events are complex events that do not concretely take place during the execution, but that are instead determined as a combination of concrete events, when certain circumstances are met. In this respect, they can ease the deﬁnition of rules, managing and combining rules belonging to diﬀerent levels of abstraction inside a unique speciﬁcation, as attested by the following example. Example 4.2.6 (Composite Events). Let us consider the following business constraints, involving a composite event: • if the device encounters a connection problem, then an alert must be communicated to the user immediately (i.e., at the following moment); • if the user enters wrong credentials or the cable status is “oﬀ” for two consecutive detections, then a connection problem is encountered. The only concrete events handled by the device are the acceptance/rejection of the credentials provided by the user, and the detection of the cable status. Under this assumption, the “connection problem encountered” event is not directly provided by the device, but rather must be inferred from the occurrence of the aforementioned base-level events. Therefore, it is not possible to directly model the ﬁrst business constraint as a CLIMB rule. The only possibility is to replicate the rule, considering all the possible concrete situations leading to encountering a connection problem. Contrariwise, SCIFF-lite is able to bridge the gap between the actual event occurrences and the abstract occurrence of a connection problem. The ﬁrst requirement can now be directly mapped onto an integrity constraint which includes the detection of a connection problem as a basic, concrete event: H(connection problem, Tp ) → E(generate alert, Ta ) ∧ Ta = Tp + 1. The temporal constraint Ta = Tp +1 is adopted to state that Tp corresponds to the ﬁrst moment next to Ta . Then, further integrity constraints are modeled to express the second requirement, which is focused on the characterization of the “abstract” (composite) occurrence of a connection problem detection, in terms of a proper combination relating the base-level events. These integrity constraints will contain the occurrence of a problem detection in their head. The ﬁrst rule links the detection of wrong credentials with the detection of a connection problem: H(wrong credentials, T ) → H(connection problem, T ). A second rule is instead employed to state that a problem is encountered if two consecutive “oﬀ” cable status are detected:

4.3 CLIMB Declarative Semantics

95

H(status(cable, of f ), T1) ∧ ∧

H(status(cable, of f ), T2) T2 > T1

→E(status(cable, S), T3) ∧ T3 > T1 ∧ T3 < T2 ∨EN(status(cable, S), T3) ∧ T3 > T1 ∧ T3 < T2 ∧ H(connection problem, T2 ).

The body of the integrity constraint contains the occurrence of two diﬀerent “oﬀ” status detections. The head is instead modeled by considering the two possible alternatives that may arise: • The two “oﬀ” detections are not consecutive; this situation arises if another detection interposes between them, and does not imply any eﬀect on the execution. • The two “oﬀ” detections are consecutive, and thus a problem is encountered; this situation happens if no further detection occurs between T1 and T2 , and leads to generate the composite connection problem event.

4.3 CLIMB Declarative Semantics The formal semantics of CLIMB is inherited from SCIFF [8]. It is based on abduction, one of the fundamental forms of inference identiﬁed by Peirce [130], and embedded in LP as Abuctive Logic Programming (ALP) [140]. An abductive logic program contains predicates without deﬁnition, i.e., whose truth cannot be proven, but only hypothesized. Hence, it is a reasoning paradigm especially suited to deal with incomplete knowledge; this feature perfectly ﬁts with open and heterogeneous EBSs, in which unpredictable events and courses of interaction dynamically occur over time. As stated in [235]: The main idea of expectation-based semantics is that in open and dynamic MAS6 , a large share of information is unknown: either because it is not speciﬁed or it is private knowledge, or – especially in the case of events – because it has not (yet) been observed by anyone or is still to occur. To capture the unknown, the reasoning conducted to manipulate expectations is intrinsically hypothetical, and the social semantics of expectations is based on abductive reasoning. In this respect, expectations are interpreted as hypotheses (i.e., abducibles) on the possible correct evolutions of the system. Such hypotheses are dynamically generated during the execution of the system’s instances. Obviously, the 6

In their work [235], Torroni et al. focus on Multi-Agent interaction protocols, but their discussion seamlessly apply to the general case of interaction models and EBSs.

96

4 The CLIMB Rule-Based Language

generation of hypotheses should be driven by the actual event occurrences, and also take into account that, depending on the domain under study, some combinations of hypotheses should be forbidden, e.g., because they contradict each other. CLIMB rules come into play to accomplish this task: the are mapped onto ALP integrity constraints, whose purpose is to restrict the acceptable combinations of abduced predicates. The SCIFF declarative semantics does not only provide an abductive interpretation to expectations. It goes further, by establishing a formal relationship between expectations and happened events, through the notion of fulﬁllment. Indeed, alongside the generation of hypotheses about the correct courses of interaction as integrity constraints trigger, an hypotheses-conﬁrmation step is performed, to check if the actual execution trace of the system eﬀectively adheres to the generated expectations. This constitutes the basis for giving a formal account to the notion of compliance of an execution trace with a CLIMB interaction model, which in turn enables the characterization of the traces supported by it. In this section, we discuss all the issues, starting from the general setting of ALP, then showing how a CLIMB model can be interpreted as an abductive logic program, and how the notion of compliance can be formally accommodated inside the resulting framework. Finally, some interesting formal properties of CLIMB are investigated in the light of its abductive-based semantics. 4.3.1 Abduction The notion of abduction has been ﬁrst introduced by Peirce [130], who diﬀerentiated the genus of reasoning into three species of inference: Deduction, an analytic process where a general rule is applied to a particular case, inferring a speciﬁc result; Induction, a synthetic process which infers the general rule from a particular case and result; Abduction, a synthetic process which infers a case (a possible explanation/cause) from a particular result and the rule. Abductive reasoning focuses on the probational adoption of a hypothesis as a possible explanation for observed facts (results), according to known laws [140]. It is a form of incorrect reasoning: as stated by Peirce, “we cannot say that we believe in the truth of the explanation, by only that it may be true” [130]. To show how abductive reasoning is exploited in our everyday life, a well-known introductory example [188, 140] is illustrated. Example 4.3.1 (Abductive reasoning). Let us consider the following set of sentences (constituting a theory), known by an agent: • If the grass is wet, then my shoes are wet as well. • If the last night it rained, then the grass is wet.

4.3 CLIMB Declarative Semantics

97

• If the sprinkler was on, then the grass is wet. The agent observes that her shoes are wet and she wants to know why. To ﬁnd a (possible) answer, she performs abductive reasoning, trying to ﬁnd a possible explanation for the observation, namely a set of hypotheses which, together with the known sentences, implies (i.e., justiﬁes) the observation. To do so, she employs the ﬁrst sentence, hypothesizing that the grass is wet; this hypothesis, in turn, can be explained in several ways, by exploiting the second and the third sentences: it could be the case that the sprinkler was on, that it rained, or both. Example 4.3.1 illustrates that abductive reasoning is suitable to deal with situations in which the agent’s knowledge is incomplete: the agent observes the world (i.e., the eﬀects of unknown causes) and exploits her own knowledge to hypothesize possible explanations for what that observations. Obviously, not all explanations are satisfactory for the agent; for example, it would be desirable to explain an eﬀect in terms of a cause and not in terms of another eﬀect, i.e., to take into account only basic explanations [140]. In Example 4.3.1, “sprinkler was on” is a basic explanation, whereas “the grass is wet” is not. More generally, it is important to distinguish between sentences that are known to the agent (sentences whose truth value can be established by the agent) and sentences whose validity is unknown by the agent; the latter are hypothesized when trying to ﬁnd (basic) explanations for what is being observed. For this reason, explanations are built upon sentences that must belong to a special domain-dependent class called abducibles. When performing abductive reasoning, an agent does not only exploit the observations and the known laws, but it also relies on rules stating whether the formulated explanations are acceptable. Such rules are employed to characterize the legal states of knowledge, rejecting unintended abductive explanations. In other words, they ensure the integrity of abductive explanations, and are therefore called integrity constraints 7 . Example 4.3.2 (Abductive reasoning with integrity constraints). Let us extend Example 4.3.1 with the following integrity constraint: • It is impossible that it rained last night if the moon was shining. This integrity constraint is a typical example of denial , because it explicitly reject an illegal state of knowledge. In particular, it forces the rejection of “it rained” as a possible explanation for having wet shoes, if the agent knows that the moon was shining. If it is the case, the only basic abductive explanation for having wet shoes is that the sprinkler was on.

7

The term is taken from the Database research ﬁeld, in which integrity constraints are used to ensure the accuracy and consistency of data.

98

4 The CLIMB Rule-Based Language

4.3.2 Abductive Logic Programming Abuctive Logic Programming (ALP) is the extension of LP to support abduction [140]. Deﬁnition 4.3.1 (Abductive logic program). An abductive logic program is a triple T , A, IC where: • T is a logic program (representing the theory of the agent); • A is the set of abducible predicates8 ; • IC is a set of Integrity Constraints. In this setting, abductive explanations can be formalized as follows. Deﬁnition 4.3.2 (Abductive Explanation). Given an abductive logic program T , A, IC and a goal formula γ, the purpose of abduction is to ﬁnd a set of ground atoms Δ ⊆ A which, together with T , entails9 γ and satisﬁes IC: T ∪ Δ |= γ T ∪ Δ |= IC In this case, Δ is an abductive explanation for γ. Example 4.3.3 (An abductive logic program). Let us formalize the situation introduced in Examples 4.3.1 and 4.3.2 as an abductive logic program T , A, IC. We consider the facts that sprinkler was on and that it rained as possible (partial) explanations, hence A = {sprinkler was on, rained last night}. The agent’s theory T is shoes are wet ← grass is wet. grass is wet ← rained last night. grass is wet ← sprinkler was on. whereas IC contains rained last night ∧ moon was shining → ⊥. If the agent observes that her shoes are wet (i.e., γ = shoes are wet), then three possible abductive explanations for T and γ can be placed: Δ1 = {rained last night} Δ2 = {sprinkler was on} Δ3 = {rained last night, sprinkler was on} 8

9

We will use the same symbol to indicate the set of abducible predicates and the set of all their ground instances. To distinguish abducible predicates from the non abducible ones, we will depict them in bold face. The notion of entailment depends on the declarative semantics associated with the theory.

4.3 CLIMB Declarative Semantics

99

Let us now suppose that someone informs the agent that the moon was shining last night. T is extended with moon was shining, and Δ1 becomes the only acceptable abductive explanation, because Δ2 and Δ3 do not entail the integrity anymore. Remark 4.3.1 (Goal reformulation). In the following, we will not consider an explicit goal but only the set of integrity constraints. If we are not interested in the computed answer substitution, this choice do not lead to loose generality: the goal formula γ can be represented as the integrity constraint true → γ, reformulating Def. 4.3.2 as T ∪ Δ |= IC ∪ {true → γ} 4.3.3 Formalizing Interaction Models and Their Executions As discussed in Sects. 4.2.4 and 4.2.5, CLIMB speciﬁcations are composed by two main parts: • a static part representing the background knowledge of the domain under study, modeled by means of a knowledge base; • a dynamic part, composed by a set of declarative rules (integrity constraints) used to constrain the behavior of the interacting entities when executing an instance of the system. A CLIMB speciﬁcation can be then straightforwardly formalized in terms of an abductive logic programs, by considering expectations as abducibles, manipulated by hypothetical reasoning driven by the speciﬁed rules. A set of hypothesized expectations models the ideal behavior (or one of the possible ideal behaviors) that the system must exhibit in order to conform to its requirement, when a certain situation shows up. Deﬁnition 4.3.3 (CLIMB speciﬁcation). A CLIMB speciﬁcation is an abductive logic program KB, A, IC where: • KB is a (static) knowledge base obeying to the syntax shown in Table 4.4; • A = {E/2, EN/2} (expectations are abducibles); • IC is a set of CLIMB integrity constraints obeying to the syntax reported in Table 4.2. Since all CLIMB speciﬁcations have a ﬁxed set of abducibles, A will be omitted. The following deﬁnition and remark explicitly stress that, due to their syntax, CLIMB integrity constraints do not contain expectations in their body. Deﬁnition 4.3.4 (Body and head of an integrity constraint). Given an integrity constraint IC, body(IC) and head(IC) respectively identify its body and head. Given an atom A, A ∈ body(IC) iﬀ A is a conjunct of the body of IC and A ∈ head(IC) iﬀ A is a conjunct of the head of IC.

100

4 The CLIMB Rule-Based Language

sd FIPA query-ref Protocol :Initiator

:Participant

query-ref alternative refuse

inform

Fig. 4.4. AUML diagram depicting a simpliﬁed version of the query-ref FIPA interaction protocol

For example, by considering the integrity constraint x1 ∧ x2 → y ∨ z1 ∧ z2 , x1 and x2 belong to its body, while y, z1 and z2 belong to its head. Remark 4.3.2 (Structure of CLIMB integrity constraints). Given a CLIMB speciﬁcation KB, A, IC, no integrity constraint belonging to IC contains expectations in its body: ∀IC ∈ IC, ∀e ∈ U, ∀t ∈ T, E(e, t) ∈ / body(IC) ∧ EN(e, t) ∈ / body(IC) Example 4.3.4 (A CLIMB speciﬁcation modeling the FIPA query-ref interaction protocol). Let us consider the CLIMB speciﬁcation of a simpliﬁed version of the FIPA10 query-ref interaction protocol11 . As described in the FIPA speciﬁcation [104], query-ref is the act of asking another agent to inform the requestor about the object identiﬁed by a given descriptor. In particular, the initiator agent requests the receiver to perform an inform act containing the object that corresponds to the descriptor; the receiver can return the requested information or refuse the request. The AUML [33] diagram of the protocol is shown in Fig. 4.4. The query-ref protocol can be suitably represented with the CLIMB speciﬁcation Q = {(QRKB )}, {(QR1 ), (QR2 ), (QR3 )} where: • (QR1 ) speciﬁes that when an initiator agent I sends a query-ref message to another agent P , then P is expected to answer by uttering an inform or refuse message. Exploiting the potentialities of CLIMB, we extend the speciﬁcation by introducing a (parametric) deadline on the maximum time by which the answer is expected, and by allowing executions in which the answer is received before the request – the goal of the protocol is to obtain 10 11

Foundation for Intelligent Physical Agents, http://www.fipa.org The full version supports two diﬀerent speech acts to start the protocol, and it foresees the possibility that the receiving agent does not understand the message or experiences an exception.

4.3 CLIMB Declarative Semantics

101

the information, not to over-constrain agents by accepting only interaction instances in which the information is provided after the request12 . H(tell(I, P, query-ref (Inf o)), Tq ) ∧ qr deadline(D) →E(tell(P, I, inf orm(Inf o, Answer)), Ti ) ∧ Ti < Tq + D ∨E(tell(P, I, ref use(Inf o)), Tr ) ∧ Tr < Tq + D.

(QR1 )

• (QR2 ) imposes mutual exclusion between the two answers, stating that if an agent P has accepted a query-ref from an agent I about the information Inf o, then P cannot send a refuse message for the same information to the same agent I 13 . H(tell(P, I, inf orm(Inf o, Answer)), Ti ) →EN(tell(P, I, ref use(Inf o)), Tr ).

(QR2 )

• (QR3 ) expects that the interaction protocol is started by some agent I. true → E(tell(P, I, query-ref (Inf o)), T ).

(QR3 )

• KB speciﬁes the value of the deadline, i.e., contains a fact like qr deadline(10).

(QRKB )

Conforming to the terminology introduced in Sect. 2.1.1, in CLIMB a speciﬁc execution of the system under study is called instance, and it is formally identiﬁed by the CLIMB speciﬁcation modeling the system and by the execution trace produced during the instance execution. Deﬁnition 4.3.5 (CLIMB Instance). Given a CLIMB speciﬁcation S and a trace T , ST = S, T is the T -instance of S. 4.3.4 SCIFF-lite Speciﬁcations Beside syntactic diﬀerences, SCIFF-lite semantically extends CLIMB by supporting arbitrary sets of abducible predicates. The formal deﬁnition of SCIFFlite speciﬁcations is therefore similar to the one of CLIMB, but the abducible set is not restricted to contain only expectations. Deﬁnition 4.3.6 (SCIFF-lite speciﬁcation). A SCIFF-lite speciﬁcation is an abductive logic program KB, A, IC where: 12

13

To introduce that only consequent answers are acceptable, the rule must be simply modiﬁed by introducing a further temporal constraint on the involved expectations. Even if it is not apparent from the rule itself, it suﬃces for expressing “full” mutual exclusions between the two speech acts; see Example 4.4.1 on p. 110 for a proof.

102

4 The CLIMB Rule-Based Language

• A ⊇ {E/2, EN/2}; • KB and IC obey to the syntax shown in Table 4.5, with the additional condition that abducible predicates cannot be negated. The speciﬁcation of arbitrary abducible predicates opens many possibilities to the modeler. For example, some happened events may be declared as abducibles: when they are inserted in the head of an integrity constraint, they are hypothesized (i.e., generated) as the constraint triggers. In this way, their occurrence is simulated, thus supporting the treatment of internal composite events as discussed in Sect. 4.2.614 . Since the abducible predicates can be freely ﬁxed by the modeler, SCIFFlite’s integrity constraints can be also exploited to perform abductive reasoning in general. For example, a prescriptive rule may contain a predicate expressing a data-related condition, whose deﬁnition is however unknown. Think for example at service interaction: each service could expose its behavioral interface, representing an abstract, public version of its internal behavior. Behavioral interfaces do not expose the private knowledge of services, such as for example an internal deﬁnitional rule used to perform a choice. In SCIFFlite, such an incomplete knowledge can be seamlessly managed by declaring the predicate representing the internal choice as abducible, and carrying out hypothetical reasoning on it. 4.3.5 CLIMB Abductive Explanations The declarative semantics of CLIMB is given in two steps, 15 . First, being CLIMB speciﬁcations formalized by means of abductive logic programs, the abductive explanations of such programs must be characterized. Then, a second step, speciﬁcally related to the CLIMB language, consists in the formal characterization of the meaning of expectations, which in turn provides the basis upon which the notion of compliance is deﬁned. Let us now focus on the ﬁrst step. Deﬁnition 4.3.7 (Abductive explanation). Given a CLIMB speciﬁcation S = KB, IC and a trace T , the abducible set Δ ⊆ {E/2, EN/2} is an abductive explanation for ST if and only if 14

Indeed, to properly make the formalization given in Example 4.2.6 working, truly supporting the generation of the connection problem event, H(connection problem, T ) must be declared as abducible. It is worth noting that when we say that H(connection problem, T ) is abducible, we are actually expressing that all its possible ground occurrences are abducible, i.e., A ⊇ {H(connection problem, t) | t ∈ T}

15

In the following, we will focus on CLIMB speciﬁcations, but the same notion of declarative semantics holds for SCIFF-lite speciﬁcations as well.

4.3 CLIMB Declarative Semantics

103

Comp (KB ∪ T ∪ Δ) ∪ CET ∪TX |= IC where Comp is the three-valued completion of a theory [147], CET stands for Clark Equational Theory [77] and TX is the constraint theory [135], parametrized by X . Fixing a CLP theory corresponds to instantiating the parameter X . Therefore, diﬀerent structures (such as R or ﬁnite domains) can be chosen without aﬀecting the notion of CLIMB abductive explanation. The symbol |= is interpreted in three valued logics, thus embedding the CLIMB abductive semantics into a three-valued model-theoretic semantics, as done, in a diﬀerent context, by Fung and Kowalski [111] and by Denecker and De Schreye [89]. Three-valued logics are multi-valued logic systems in which there are three truth values: true, false and unknown. They are therefore particularly appropriate to deal with systems characterized by incomplete knowledge. This is the case of open and heterogeneous EBSs, in which unpredictable events dynamically occur over time, a large share of information is unknown and knowledge evolves over time. For example, let us consider a business constraint stating that “if a private medical examination is completed, the patient is obliged to pay for it within two days”. When such a constraint is applied to an instance of the system, there are many situations in which neither its truth nor its falsity can be determined. One of these situations comes about when the medical examination is completed: it is not possible to know whether the patient will satisfy the payment obligation until the payment is actually done or two days have passed. It is worth noting that if a set of integrity constraints is entailed, then each single constraint is entailed as well. The following remark starts from this trivial observation and establishes a link between an abductive explanation for a certain instance ST , and the T -instances obtained by considering only a sub-set of integrity constraints in S. Remark 4.3.3 (Abductive explanations and sub-speciﬁcations). If Δ is an abductive explanation for KB, ICT , then Δ is an abductive explanation also for KB, IC T , where IC ⊆ IC. The following example introduces some abducible sets, discussing whether they are suitable abductive explanations of a given CLIMB instance or not. Example 4.3.5 (Abductive explanations). Let us consider the CLIMB speciﬁcation Q, described in Example 4.3.4, together with the execution trace T = { H(tell(alice, hatter, query-ref (loc(rabbit))), 5), H(tell(hatter, alice, ref use(loc(rabbit)), 10) } The abducible sets Δ0 = ∅ Δ1 = { E(tell(alice, hatter, query − ref (loc(rabbit))), 5) }

104

4 The CLIMB Rule-Based Language

are not abductive explanations for QT . In fact, they respectively contradict the integrity constraints (QR3 ) and (QR1 ): (QR3 ) states that a query-ref expectation must be included in each abductive explanation, while (QR1 ) states that whenever the trace contains a query-ref event (which is actually the case for T ), then a corresponding inform or refuse expectation must be hypothesized. Conversely, the abducible sets Δ3 = Δ1 ∪ { E(tell(hatter, alice, inf orm(loc(rabbit), garden)), 10), EN(tell(hatter, alice, ref use(loc(rabbit)), T ) } Δ4 = Δ1 ∪ { E(tell(lewis, alice, ref use(loc(rabbit)), 10) } Δ5 = Δ3 ∪ Δ4 are all abductive explanations for QT . It is worth noting that declarative semantics takes into account only ground speciﬁcations. Therefore, abducibles are always considered to be ground; when an abducible contains variables, it must be intrepreted as an abstract scheme for intensionally representing the set of all its ground versions. Such an extensional set is determined by grounding the variables, taking into account both their quantiﬁcation and domain. For example, by relying on the dense-time structure (R, <), the negative expectation contained in Δ3 (Example 4.3.5) EN(tell(hatter, alice, ref use(loc(rabbit)), T ) is used to intensionally represent the set {EN(tell(hatter, alice, ref use(loc(rabbit)), t) | t ∈ R} (being T universally quantiﬁed), whereas E(tell(hatter, alice, inf orm(loc(rabbit), X), T ) ∧ T > 10 is a shortcut for representing a ground expectation e such that e ∈ {E(tell(hatter, alice, inf orm(loc(rabbit), r), t) | r ∈ U, t ∈ (10, ∞)} (being X and T existentially quantiﬁed). Let us consider a more complex example, in which variables are shared by a positive and a negative expectation E(a, T ) ∧ T ≥ 4 ∧ T < 7 ∧ EN(b, T ) By supposing that the chosen time structure is (N, <), such a conjunction of expectation is a shortcut for representing one of the following three sets: { E(a, 4), EN(b, 4) }

{ E(a, 5), EN(b, 5) }

{ E(a, 6), EN(b, 6) }

4.3 CLIMB Declarative Semantics

105

4.3.6 On the Formal Deﬁnition of Compliance In Sect. 4.3.5, we have provided a formal account to CLIMB abductive explanations. However, in the context CLIMB expectations are not simply abducible predicates, but they carry a speciﬁc, prescriptive meaning: a positive expectation states that some event is expected to happen, while a negative expectation states that some event occurrence is prohibited. Hence, expectations are strongly connected to the happened events composing the execution traces of the system: depending on the actual event occurrences contained in a trace, they become fulﬁlled or violated, leading to consequently certifying the trace as correct or not. The CLIMB declarative semantics must take care of formally capturing such an intended meaning, making clear and explicit the relationships between positive and negative expectations, and between expectations and happened events. The connection between positive and negative expectations is tackled by E-consistency, which basically states that they are conﬂicting concepts: the same event cannot be expected to happen and not to happen at the same time. Deﬁnition 4.3.8 (E-consistency). An abducible set Δ is E-consistent iﬀ ∀e ∈ U and ∀t ∈ T: {E(e, t), EN(e, t)} Δ Example 4.3.6 ( E-consistency and intensional representations). Let us consider the abductive explanations of Example 4.3.5. Sets Δ3 and Δ4 are Econsistent, while Δ5 is not E-consistent, because the same refusal event is expected to happen and not to happen at time 10. Indeed, remember that EN(tell(hatter, alice, ref use(loc(rabbit)), T ) is used to intensionally represent the (inﬁnite) set of negative expectations on all the possible ground times, including also T = 10. The intensional representation of expectations may sometimes cause confusion w.r.t. E-consistency. For example, the set { E(ev, T1 ) ∧ T1 ≥ 4 ∧ T1 ≤ 9, EN(ev, T2 ) ∧ T2 > 5 ∧ T2 < 8 } is E-consistent: being T1 existentially quantiﬁed, event if the two contrasting expectations overlap in time, it is suﬃcient that there exists at least one possible assignment of T1 , consistent with the CLP constraints, that is outside the scope of T2 . In particular, by adopting a discrete, integer time structure, the set intensionally represents one of the sets { E(ev, 4), EN(ev, 6), EN(ev, 7) }

(E-consistent)

{ E(ev, 5), EN(ev, 6), EN(ev, 7) }

(E-consistent)

{ E(ev, 6), EN(ev, 6), EN(ev, 7) }

(E-inconsistent)

{ E(ev, 7), EN(ev, 6), EN(ev, 7) }

(E-inconsistent)

{ E(ev, 8), EN(ev, 6), EN(ev, 7) }

(E-consistent)

{ E(ev, 9), EN(ev, 6), EN(ev, 7) }

(E-consistent)

106

4 The CLIMB Rule-Based Language E-inconsistency

E ev

[

(

EN ev 4

5

]

[

] (

9

4

5

) 6

7

8

6

7

[ )

]

8

9

Fig. 4.5. Interplay between CLP temporal constraints and E-consistency

Two of such sets are not E-consistent. The possible choices hence restrict to { E(ev, 4), EN(ev, 6), EN(ev, 7) } { E(ev, 5), EN(ev, 6), EN(ev, 7) } { E(ev, 8), EN(ev, 6), EN(ev, 7) } { E(ev, 9), EN(ev, 6), EN(ev, 7) }

Therefore, by taking into account E-consistency, the original set is equivalent to: { E(ev, T1 ) ∧ [(T1 ≥ 4 ∧ T1 ≤ 5) ∨ (T1 ≥ 8 ∧ T1 ≤ 9)], EN(ev, T2 ) ∧ T2 > 5 ∧ T2 < 8 } The graphical intuition is reported in Fig. 4.5. This kind of manipulation is operationally handled, in SCIFF, by the CLP solver itself. The relationship between expectations and happened events is captured by the notion of fulﬁllment, which formalizes the conditions determining whether an expectation is satisﬁed by a given CLIMB instance or not. In particular, it formalizes the following intended meaning: • positive expectations must have a corresponding matching event in the execution trace of the instance; • negative expectations must have no corresponding matching event in the execution trace of the instance. Deﬁnition 4.3.9 (Fulﬁllment). Given a CLIMB trace T and an abducible set Δ, Δ is T -fulﬁlled if and only if, ∀e ∈ U, ∀t ∈ T: E(e, t) ∈ Δ =⇒ H(e, t) ∈ T EN(e, t) ∈ Δ =⇒ H(e, t) ∈ /T By taking into account the abductive nature of expectations, fulﬁllment can be interpreted as a particular form of hypotheses conﬁrmation: • Expectations are hypothesized according to the running instance of the system and the CLIMB speciﬁcation; this leads to the formulation of expectations as abductive explanations, according to Def. 4.3.7.

4.3 CLIMB Declarative Semantics

107

• According to Def. 4.3.9, The execution trace may fulﬁll the generated expectations or not, conﬁrming or disconﬁrming the formulated hypotheses. Fig. 4.6 provides a graphical intuition about how this two ways relationship is established by the declarative semantics of CLIMB. Expectations

Abductive explanations

CLIMB specification

Fulfillment

(partial) execution trace

Fig. 4.6. The two ways relationship between expectations and happened events, as established by the CLIMB declarative semantics

Given an abductive explanation Δ, fulﬁllment can be interpreted as a means for separating the legal/correct execution traces with respect to Δ from the wrong ones. A trace is correct if it satisﬁes all the expectations contained in Δ, while it is wrong if an expected event is omitted, or a forbidden event is present. In this light, the declarative semantics of CLIMB is able to formally capture the notion of compliance of an execution trace with a given CLIMB speciﬁcation. Thanks to to fulﬁllment, it becomes possible to isolate, in the space of all execution traces, those that are supported by a speciﬁcation. Deﬁnition 4.3.10 (Compliance). A trace T is compliant with a CLIMB speciﬁcation S if and only if there exists an abducible set Δ such that: 1. Δ is an abductive explanation for ST ; 2. Δ is E-consistent; 3. Δ is T -fulﬁlled. If this is the case, we write compliantΔ (ST ) or simply compliant (ST ). Contrariwise, T is said to violate (or be noncompliant with) S, written ¬compliant (ST ).

108

4 The CLIMB Rule-Based Language

Example 4.3.7 (Compliance in CLIMB). Let us consider the CLIMB speciﬁcation Q of Example 4.3.4. The execution trace T introduced in Example 4.3.5 is compliant with Q, because the expectations set Δ4 (also mentioned in that example) is an E-consistent and T -fulﬁlled abductive explanation for Q. The execution traces T2 = ∅ T3 = { H(tell(alice, hatter, query-ref (loc(rabbit))), 5), H(tell(hatter, alice, ref use(loc(rabbit)), 10), H(tell(hatter, alice, inf orm(loc(rabbit), garden)), 12) } T4 = { H(tell(alice, hatter, query-ref (loc(rabbit))), 5), H(tell(hatter, alice, inf orm(loc(rabbit), garden)), 20) } are instead noncompliant with Q. T2 is not compliant with Q due to rule (QR3 ), which states that each abductive explanation must contain a positive expectation about a queryref event. To be fulﬁlled, such an expectation should have a corresponding happened event in T2 , which however is empty. The expectation is therefore violated. T3 is not compliant with Q because hatter sends both a refuse and inform events concerning the same information loc(rabbit). Indeed, from the combination of rule (QR2 ) with the second happened event of T3 , it follows that each abductive explanation Δi for Q must contain the forbidding of a corresponding inform event: ∀Δi , Δi ⊇ { EN(tell(hatter, alice, inf orm(loc(rabbit), garden)), T ) } Since this negative expectation has a corresponding matching occurrence in T3 (with T /12), there does not exist a Δi which is T2 -fulﬁlled, and therefore Q is violated by T3 (in particular, T3 violates rule (QR2 )). T4 is not compliant with Q because hatter sends an inform response too late. In particular, T4 satisﬁes rule (QR3 ) and triggers rule (QR1 ), leading to hypothesize a positive expectation concerning one among the two foreseen answers. Abductive explanations must therefore contain an expectation e such that e ∈ {E(tell(hatter, alice, ref use(loc(rabbit))), T ) | T < 15} or e ∈ {E(tell(hatter, alice, inf orm(loc(rabbit)), L), T ) | T < 15 ∧ L ∈ U}. From the deﬁnition of fulﬁllment, e must have a corresponding matching event in T4 , but this is not the case: no refusal is contained in T4 , and the inform message by hatter after the expiration of the (actual) deadline of 15 time units. A graphical representation summarizing the compliance of the four traces with Q is shown in Fig. 4.7.

4.4 Formal Properties

109

Traces Herbrand base compliant with QR1

compliant with QR2

2

4 3

compliant with QR3

compliant with the query-ref protocol

Fig. 4.7. Compliance evaluation of the traces reported in Examples 4.3.5 and 4.3.7 with the FIPA query-ref protocol

4.4 Formal Properties Three interesting formal properties of SCIFF speciﬁcations are now introduced, namely equivalence, compositionality and replaceability of constraints modulo compliance. The main result following from these formal properties is that a certain class of SCIFF speciﬁcations, which is a superset of CLIMB, is compositional modulo compliance, which in turn implies the replaceability property. 4.4.1 Equivalence Modulo Compliance There are many diﬀerent ways to characterize the same interaction model, i.e., to support the same set of execution traces. In other words, two speciﬁcations could diﬀer concerning their syntactic forms and the corresponding abductive explanations, but, at the same time, they are equivalent from an “external” point of view: given an execution trace, they will always agree when assessing its compliance. Such speciﬁcations are said to be equivalent modulo compliance. Deﬁnition 4.4.1 (Equivalence modulo compliance in SCIFF). Given two SCIFF speciﬁcations S 1 and S 2 , S 1 is equivalent modulo compliance to c S 2 (S 1 ∼ S 2 ) if and only if:

∀T compliant(ST1 ) ⇐⇒ compliant(ST2 ) This notion of equivalence is important because it provides a means for individuating whether two SCIFF speciﬁcations isolate exactly the same set of legal executions, ensuring that one speciﬁcation can be seamlessly replaced by the other without aﬀecting compliance and support. When two speciﬁcations are equivalent modulo compliance, the “best” among the two can be seamlessly chosen by taking into account other aspects, such as readability

110

4 The CLIMB Rule-Based Language

or compactness of the integrity constraints, or impact on the underlying reasoning techniques (we will deeply discuss this issue in the second part of the book). Example 4.4.1 (Equivalence modulo compliance in the “not coexistence” case). Let us suppose that, in a given EBS, two events e1 and e2 cannot both occur within the same instance. To express that the two events cannot coexist, the modeler could rephrase the sentence as follows: if e1 occurs, then e2 must not occur, and if e2 occurs, then e1 must not occur. Starting from this form, a straightforward translation into CLIMB integrity constraints can be devised: H(e1 , Ta ) → EN(e2 , Tb ). H(e2 , Tc ) → EN(e1 , Td ).

(⊗12 ) (⊗21 )

However, it is interesting to note that these two rules are redundant for what regards compliance: it is suﬃcient to use only one of them to express the not coexistence between e1 and e2 . In particular, it can be easily proven that c S 1 = ∅, {(⊗12 )} ∼ S 2 = ∅, {(⊗21 )}

Let us suppose, by reductio ad absurdum, that there exists an execution trace T such that compliant(ST1 ) and ¬compliant(ST2 ). To violate S 2 , T must match with the body of (⊗21 ) and violate the expectation contained in its head, i.e., it must contain the occurrence of both e2 and e1 . However, rule (⊗21 ) states that if T contains e1 , then it cannot contain also e2 , and therefore it is impossible that T is compliant with S 1 . The opposite case can be proven in the same way. 4.4.2 Compositionality Modulo Compliance An interesting point is to exploit the notion of equivalence modulo compliance to know if and to what extent it is possible to split up a SCIFF speciﬁcation S into two separated (sub)speciﬁcations S1 and S2 , so that the combination of S1 and S2 is equivalent to S. This possibility is called compositionality modulo compliance. Deﬁnition 4.4.2 (Compositionality). A SCIFF speciﬁcation KB, A, IC is compositional (modulo compliance) if and only if ∀T , ∀IC 1 and ∀IC 2 s.t. IC = IC 1 ∪ IC 2 : compliant (KB, A, IC 1 T ) ∧compliant (KB, A, IC 2 T ) ⇐⇒ compliant (KB, A, ICT ) A compositional speciﬁcation S can be partitioned into a set of simpler subspeciﬁcations S1 , . . . , Sn , each one covering a sub-set of its integrity constraints. Compliance can be then assessed separately by each sub-speciﬁcation,

4.4 Formal Properties

111

then combining all the obtained results: a trace is compliant with S if and only if it is compliant with each Si . An important question now is the following: given an arbitrary SCIFF speciﬁcation, is it possible to know whether it is compositional or not? The answer is: if the syntax of the speciﬁcation has a particular form (called unchained hereafter), then the speciﬁcation is compositional. After having delimited the class of unchained speciﬁcations, we prove this claim, showing that all CLIMB speciﬁcations are unchained, hence compositional. Deﬁnition 4.4.3 (unchained speciﬁcation). A SCIFF speciﬁcation S = KB, A, IC is unchained iﬀ no integrity constraint in IC contains an abducible in its body: ∀IC ∈ IC, ∀βi ∈ body(IC), θ s.t. [βi ]θ ∈ A The intuition behind unchained speciﬁcation is that the abducibles contained in their abductive explanations do not contribute to (partially) match with the body of their integrity constraints. Example 4.4.2 (Unchained speciﬁcations). Let us consider the integrity constraints H(external(e1 ), T1 ) → H(internal(e2 ), T2 ). H(internal(e2 ), T2 ) → E(external(e3 ), T3 ).

(4.1) (4.2)

H(external(e3 ), T3 ) → EN(external(e4 ), T4 ).

(4.3)

and the SCIFF-lite speciﬁcations S1 = ∅, {E/2, EN/2, H(internal(Ev), T )}, {(4.1), (4.2)} S2 = ∅, {E/2, EN/2, H(internal(Ev), T )}, {(4.1), (4.3)} S3 = ∅, {E/2, EN/2, H/2}, {(4.1), (4.3)} S2 is the only unchained speciﬁcation among the three, because the body of its integrity constraints contains only occurrences of external events, while only internal event occurrences can be abduced. Let us now demonstrate that “being unchained” is a suﬃcient condition for guaranteeing compositionality. Theorem 4.4.1 (Compositionality of unchained speciﬁcations). If a SCIFF speciﬁcation is unchained, then it is also compositional. Proof. Let us consider the speciﬁcation S = KB, A, IC. By taking into account also abductive explanations, we rephrase compositionality as follows: for each execution trace T compliantΔ1 (ST1 ) ∧ compliantΔ2 (ST2 ) ⇔ compliantΔ (ST )

112

4 The CLIMB Rule-Based Language

where S 1 = KB, A, IC 1 , S 2 = KB, A, IC 2 and IC = IC 1 ∪ IC 2 . The proof then reduces to show that suitable Δ1 and Δ2 exist if and only if a suitable Δ exist. ⇐= One has to prove that if an abducible set Δ exists such that ST is compliant, then also two abducible sets Δ1 and Δ2 exist such that ST1 and ST2 are compliant. This is trivial, by choosing Δ1 = Δ2 = Δ. Indeed, Remark 4.3.3 states that Δ is an abductive explanation for any speciﬁcation KB, A, IC where IC ⊆ IC, hence also for S1 and S2 . =⇒ One has to prove that if two abducible sets Δ1 and Δ2 exist such that ST1 and ST2 are compliant, then also an abducible set Δ exist such that ST is compliant. Let us consider Δ = Δ1 ∪Δ2 . The proof reduces to check that such Δ obeys the three properties required by the deﬁnition of compliance (Def. 4.3.10). Let us focus on each property separately: 1. Δ is an abductive explanation for ST . Let us suppose that this is not the case, i.e., Δ is not consistent with an constraint IC. Let us also suppose that IC ∈ IC 1 . Being Δ1 and Δ2 abductive explanations for S1 and S2 respectively, IC is not entailed by considering Δ only if body(IC) is not made true by Δ1 , but it is made true by Δ1 ∪ Δ2 : this would require Δ to contain also a disjunct of head(IC), which is not necessarily guaranteed by Δ. If Δ1 does not make body(IC) true, but Δ1 ∪ Δ2 does, then (at least) some part of body(IC) must unify with an abducible contained in Δ2 : ∃ε ∈ Δ2 , ∃β ∈ body(IC) s.t. [β]θ = ε. However, since Δ2 ⊆ A, the existence of such ε would contradict the hypotheses that S is unchained. 2. Δ is E-consistent. Assume, by absurdum, that Δ is not E-consistent; since Δ1 and Δ2 are both E-consistent, the only way to make Δ E-inconsistent would be to have an e ∈ U and a t ∈ T such that E(e, t) ∈ Δ1 and EN(e, t) ∈ Δ2 . But this is impossible, because both Δ1 and Δ2 are T fulﬁlled, and the T -fulﬁllment of Δ1 would require H(e, t) ∈ T , while the T -fulﬁllment of Δ2 would impose H(e, t) ∈ /T. 3. Δ is T -fulﬁlled, because each element of Δ belongs either to Δ1 or Δ2 , which are both T -fulﬁlled. Corollary 4.4.1 (CLIMB compositionality). CLIMB speciﬁcations are compositional. Proof. By looking at Remark 4.3.2 and at Defs. 4.3.3 and 4.4.3, it becomes apparent that CLIMB speciﬁcations are unchained: the body of each CLIMB integrity constraint can contain happened events, (deﬁned) Prolog predicates, and CLP constraints, while only expectations can be hypothesized. Being CLIMB speciﬁcations unchained, Theorem 4.4.1 guarantees that they are also compositional.

4.4 Formal Properties

compositional specifications

113

SCIFF SCIFF-lite CLIMB

Fig. 4.8. The set of compositional speciﬁcations related to the three variants of SCIFF

CLIMB speciﬁcations are compositional because their integrity constraints can be triggered only by the happened events contained in the execution trace under study, and the predicates deﬁned inside the knowledge base. The hypothesized expectations do not directly feed other rules, but are only checked against the trace to evaluate its compliance. Hence, each rule can be managed separately from the other rules. Fig. 4.8 shows how the set of compositional SCIFF speciﬁcation is related to the three variants of SCIFF. 4.4.3 Replaceability of Rules Let us now imagine the following situation. Assume that we have already proven that a SCIFF speciﬁcation containing one integrity constraint, say, IC1 , is equivalent modulo compliance to a speciﬁcation containing another single integrity constraint IC2 , and the same knowledge base of the ﬁrst speciﬁcation (this is e.g. the case of Example 4.4.1). Formally, we have proven c S = KB, A, {IC2 }. If S is equivalent to S , that S = KB, A, {IC1 } ∼ then S can be seamlessly replace S to perform compliance checking, and vice-versa. But what happens if the original speciﬁcation does not contain only IC1 but also other integrity constraints, i.e., S = KB, A, {IC1 } ∪ IC? Can we still guarantee equivalence modulo compliance by replacing IC1 with IC2 and keeping the other integrity constraints untouched? This is a very important question. Indeed, guaranteeing this replaceability would have a positive impact on the development of CLIMB interaction models: when a new, better (e.g., in terms of eﬃciency) formulation of the same rule is found, it could be directly used to replace the old version, without imposing to study the impact of this change on the rest of the speciﬁcation. The following theorem shows that the replaceability of integrity constraints is guaranteed for compositional speciﬁcations: if S is compositional, then it c S = KB, A, {IC2 } ∪ IC. holds that S = KB, A, {IC1 } ∪ IC ∼ Theorem 4.4.2 (Replaceability of integrity constraints). Given four compositional SCIFF speciﬁcations • S 1 = KB, A, IC 1

114

4 The CLIMB Rule-Based Language

• S ∪1 = KB, A, IC ∪ IC 1 • S 2 = KB, A, IC 2 • S ∪2 = KB, A, IC ∪ IC 2 the following holds: c c S1 ∼ S 2 ⇒ S ∪1 ∼ S ∪2 c In other words, if one shows that S 1 ∼ S 2 , then the integrity constraints of ∪1 S can be modiﬁed by replacing IC 1 with IC 2 , without aﬀecting compliance. c c Proof. Let us consider α = S 1 ∼ S 2 and β = S ∪1 ∼ S ∪2 . One has to prove c that α ⇒ β. From the deﬁnition of ∼ (Def. 4.4.1), we have

α ∀T compliant ST1 ⇔ compliant ST2

Being the speciﬁcations compositional, it holds that:

β ∀T compliant ST∪1 ⇔ compliant ST∪2 =

= ∀T compliant (ST ) ∧ compliant ST1

⇔ compliant (ST ) ∧ compliant ST2

(Def. 4.4.1) (Def. 4.4.2)

where S = KB, A, IC. Let us now separately discuss the case in which ST is compliant, and the case in which ST is noncompliant, showing that in both cases α ⇒ β is true. If ST is noncompliant (i.e., compliant(ST ) is f alse), then

β = ∀T f alse ∧ compliant ST1 ⇔ f alse ∧ compliant ST2 = ∀T f alse ⇔ f alse = true Therefore, α ⇒ β = α ⇒ true = true. If ST is compliant (i.e., compliant(ST ) is true), then

β = ∀T true ∧ compliant ST1 ⇔ true ∧ compliant ST2

= ∀T compliant ST1 ⇔ compliant ST2 = α Therefore, α ⇒ β = α ⇒ α = true.

5 Translating ConDec into CLIMB

In Chaps. 3 and 4, we have discussed two diﬀerent approaches for the speciﬁcation of interaction models: CLIMB and ConDec, together with their abductive and LTL-based semantics. On the one hand, the two approaches have complementary scopes and objectives: while ConDec adopts an intuitive graphical notation and pays particular attention to the usability by non-IT savvy, CLIMB is based on a rigorous, rule-based language, which gives a formal account to compliance, and is therefore apt to veriﬁcation. On the other hand, the two approaches share the same, underlying paradigm: they both rely on the notion of (business) constraint as the fundamental abstraction to specify interaction following an open and declarative style of modeling. This chapter exploits these similarities to provide a complete formalization of ConDec in terms of CLIMB. Thus, it lays the foundation for the veriﬁcation of ConDec models along their entire lifecycle, which will be matter of the next parts of this book. After having shown how all the ConDec constraints can be automatically translated into CLIMB, the discussion will focus on the formal relationship between CLIMB and propositional Linear Temporal Logic (LTL), which was the ﬁrst logic-based framework used to provide an underlying semantics to ConDec. In particular, we will prove that the proposed CLIMB formalization is sound with the original LTL mapping, brieﬂy recalling some general expressiveness results concerning the two logics. Throughout the chapter, we will always assume that ConDec activities are atomic, and can be therefore represented by means of a single, punctual event. The next chapter will exploit the expressiveness of the CLIMB language towards extending ConDec in several directions, including the support of non atomic activities.

M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 115–138, 2010. c Springer-Verlag Berlin Heidelberg 2010

116

5 Translating ConDec into CLIMB

5.1 Translation of a ConDec Model A ConDec model is translated into a CLIMB speciﬁcation by mapping its mandatory constraints onto CLIMB integrity constraints, to the aim of drawing a correspondence between the notion of ConDec support and the one of CLIMB compliance. In this light, optional constraints are not part of the formalization, because they are not meant to eﬀectively place constraints on the courses of interaction, but only as a tool thought for expressing preferable executions, alerting the user if they are not met. Chap. 14 will show how SCIFF-lite can be employed to deal with optional constraints. Since the basic version of ConDec does not support data, the knowledge base of the obtained CLIMB speciﬁcations will be always empty. Chap. 6 will introduce an extended version of ConDec, which provides data support and can therefore making use of the knowledge base to formalize the static domain knowledge. The translation of ConDec to CLIMB is encapsulated into a translation function called tCLIMB . Deﬁnition 5.1.1 (ConDec to CLIMB translation). tCLIMB is a function which translates a ConDec model CM A, Cm , Co into a CLIMB speciﬁcation as follows: CM −→ tCLIMB (CM) = ∅, tIC (Cm )

tCLIMB :

where tIC is a function able to map a set of ConDec mandatory constraints onto a set of CLIMB integrity constraints. By looking at Def. 5.1.1, we will notice that only activities connected to a mandatory constraint will be contained in the obtained CLIMB speciﬁcation, and that unconstrained activities will not appear at all. The openness of CLIMB guarantees that these activities can be executed an arbitrary number of times, without compromising compliance; this is in accordance with the intended ConDec semantics (see Chap. 3). Since an execution trace is supported by a ConDec model if and only if all its constraints are satisﬁed, the application of tIC to a set Cm of mandatory constraints corresponds to the union of the integrity constraints obtained from the application of tIC to each single mandatory ConDec constraint. Deﬁnition 5.1.2 (Translation of a ConDec constraints set). The application of tIC to a set of mandatory ConDec constraints Cm is deﬁned as: tIC (Cm ) = tIC (Ci ) Ci | Ci ∈Cm

The syntactic connection established by tCLIMB between a ConDec model and a CLIMB speciﬁcation has a semantical implication: as in the case of the LTL formalization (discussed in Sect. 3.7), the notion of ConDec support (Def. 3.2.2) can be put in correspondence with the notion of compliance in CLIMB (Def. 4.3.10).

5.3 Embedding a Qualitative Characterization of Time

117

Deﬁnition 5.1.3 (ConDec support in CLIMB). Given a CLIMB execution trace T and a ConDec model CM, T is supported by CM if and only if: compliant (tCLIMB (CM)T ) In Sect. 5.3.2, we will partially revise this deﬁnition, to account for the divergence between the representation of time in the two settings.

5.2 Translation of Events Each atomic ConDec activity can be straightforwardly represented as a CLIMB term; being atomic, its occurred, expected or forbidden execution is associated to a single time point, and can be therefore modeled by means of a single happened event or expectation. Deﬁnition 5.2.1 (Translation of an atomic ConDec activity). Given a ConDec atomic activity a, • H(exec(a), T ) states that a has been executed at time T ; • E(exec(a), T ) states that a is expected to be executed at time T ; • EN(exec(a), T ) states that a cannot be executed at time T .

5.3 Embedding a Qualitative Characterization of Time into a Quantitative Setting Before getting to the heart of the translation, we have to sort out the issue of the diﬀerence between the characterization of time by ConDec and CLIMB. Indeed, while ConDec (as well as LTL) rely on a point-based time structure with qualitative temporal relations, CLIMB adopts a point-based structure and exploits CLP to express both qualitative and quantitative temporal constraints. This diﬀerence has also repercussions on the execution traces of each framework: while LTL traces are linear sequences of event occurrences, in CLIMB each event occurrence is associated to a numerical value. How should then a qualitative characterization of time embedded in a quantitative setting? The following discussion tries to provide an answer to this fundamental question. 5.3.1 Temporal Contiguity In ConDec, time does not ﬂow independently from the interaction, but is instead totally described by the event occurrences constituting the execution traces of the system. Each state of aﬀairs is associated to an event occurrence, and is left entering in a successor state only in response to the occurrence of

118

5 Translating ConDec into CLIMB contiguous

instance of the system

qualitative approach

event

contiguous

event event

event

...

S0

S1

S2

quantitative approach

Fig. 5.1. Quantitative vs qualitative representation of event occurrences, and its implications on the notion of temporal contiguity

a further, immediately consequent event: as far as the execution is quiescent, time remains idle. This qualitative notion of temporal contiguity is formally captured in LTL by the (next time) temporal operator: e is true in a state t if and only if e is executed in the immediate successor state t + 1 (see Sect. 3.6.3). However, when it comes to the real world, interaction models are executed inside a business setting, where the widespread, internationally accepted chronometry of the Gregorian calendar and the International System of Units comes into play: interacting entities employ the everyday life abstractions of “months”, “days”, “seconds”, etc. These abstractions advocate a shift towards a quantitative characterization of time objects. Indeed, depending on the domain of discourse, diﬀerent time granularities [100] are chosen by humans to express unanchored, absolute temporal data (e.g., 1983, September 18th 1996) and anchored, relative ones (e.g., 1 minute, 2 hours and a half). For example, a patient monitoring care-ﬂow protocol requires to promptly react to critical conditions, which are detected by a frequent sampling of vita signals, in the order of milliseconds. Conversely, in a loan management process a time granularity of hours would suﬃce. In this light, it is unreasonable to assume that two contiguous event occurrences are still captured by relying on the “next time” paradigm, i.e., by requiring that they are separated by a single time unit: contiguity is a qualitative notion, while time units express a measure related to the ﬂow of time. Contiguity can be instead suitably rephrased as: two event occurrences are contiguous if and only if no further event has occurred between them. Depending on the speciﬁc domain, a maximum time span could also be introduced, to determine whether two consecutive events are actually contiguous or too distant. Fig. 5.1 gives an intuition of the diﬀerence between a qualitative vs quantitative representation of event occurrences.

5.3 Embedding a Qualitative Characterization of Time

119

5.3.2 Compact Execution Traces The temporal contiguity issue gives rise to two question: • How can ConDec and LTL deal with real execution traces? • How is it possible to accommodate a qualitative characterization of time inside the quantitative setting of CLIMB? The ﬁrst question is related to the ontological incompatibility between ConDec or LTL and the real execution traces of the systems considered in this book. Such an incompatibility is obviously overcome by means of an abstraction step. An LTL execution trace is not a “real” trace: it is a linear sequence of event occurrences that abstracts away from their quantitative time values, but maintains their right ordering. Maintaining the ordering is a necessary and suﬃcient condition for guaranteeing that qualitative time relationships can be applied on the abstract trace in place of the real one. Under the assumption that only qualitative time relationships are used (which is true for ConDec), the qualitative notion of temporal contiguity can be also adopted in the quantitative CLIMB setting without loss of generality, provided that also the CLIMB traces are subject to a suitable abstraction step before assessing their compliance. In particular, the abstraction step must guarantee that: • the ordering among event occurrences is maintained in the abstract trace; • if two event occurrences are contiguous in the real trace (i.e., no further event has occurred between them), then they are separated by a single time unit in the abstract trace. Let us ﬁrst focus on the second requirement. It implicitly assumes that, in the abstract trace, time is marked only by the execution of events, and therefore it is not possible to have a time value, inside the trace, at which nothing happens. A CLIMB trace that meets this requirement is called compact. Deﬁnition 5.3.1 (Compact CLIMB execution trace). A CLIMB execution trace T is compact if and only if ∀ t ∈ [0, tmax ], ∃ H(e, t) ∈ T where tmax = max ({t | ∃ H(e, t) ∈ T }) Example 5.3.1 (Compactness of traces). Let us consider the following execution traces:

120

5 Translating ConDec into CLIMB

instance event of the system

event event

event

event

event event

event

...

... COMPACTION

qualitative approach

S0

S1

S2

quantitative approach

S0

S1

S2

0

1

2

Fig. 5.2. Compaction of an execution trace, towards the accommodation of qualitative temporal contiguity in a quantitative setting

T1 = { H(exec(choose item), 0), H(exec(choose item), 7), H(exec(pay), 15), H(exec(send receipt ), 30) } T2 = { H(exec(choose item), 0), H(exec(choose item), 1), H(exec(pay), 2), H(exec(send receipt ), 3) } T2 is compact, while T1 is not. Given a general CLIMB trace, modeling a “real” execution trace of the system, the desired abstraction step can then be concretely carried out by transforming it into a corresponding compact trace, such that ordering is maintained. Let us for example consider the execution trace of a Business Process, in which an item is chosen at time 5, and then the order is paid at time 10. This trace could be represented in CLIMB as T = {H(choose item, 5), H(pay, 10)}. Since between time 5 and 10 nothing happens, the choose item and pay occurrences are contiguous. The corresponding compact trace that maintains the ordering, and in which contiguous occurrences are separated by a single time unit, is Tcomp = { H(choose item, 0), H(pay, 1) }. In the general case, a compaction function can be devised, which takes a general CLIMB trace and produces a corresponding compact trace, that obeys to the aforementioned requirements. A graphical intuition of such a compaction function is provided in Fig. 5.2. Deﬁnition 5.3.2 (Compaction function). compact is a compaction function which translates an execution trace into a corresponding compact execution trace. It is deﬁned as follows: compact : BH −→ BH T −→ Tcomp s.t. ∀ H(e, t), H(e, t ) ∈ Tcomp having t = {tbef ore | H(e∗ , tbef ore ), tbef ore < t} where BH is the Herbrand base built upon CLIMB happened events.

5.4 Translation of ConDec Constraints

121

Roughly speaking, the compaction function has the eﬀect of substituting the time value associated to each event occurrence with a timestamp, which simply reﬂects the temporal “position” of the event occurrence inside the trace. E.g., by considering the execution traces shown in Example 5.3.1, it holds that T2 = compact (T1 ). Concurrent occurrences, i.e., occurrences associated to the same time value, are mapped onto the same timestamp. Given a ConDec model CM and a CLIMB execution trace T , the compaction function must be applied on T before assessing its compliance with the CLIMB representation of CM. Formally, Def. 5.1.3 must be revised as follows. Deﬁnition 5.3.3 (ConDec support in CLIMB under compaction). Given a CLIMB execution trace T and a ConDec model CM, T is supported by CM if and only if: compliant tCLIMB (CM)compact(T ) Obviously, the application of the compaction function hinders the modeling of metric temporal constraints, which is one of the most interesting features of CLIMB. Chap. 6 will discuss how ConDec can be extended with quantitative time aspects, getting back such an interesting feature. In this light, it will be necessary to recover the quantitative nature of CLIMB, and to revise the formalization proposed in this chapter accordingly.

5.4 Translation of ConDec Constraints tIC maps each ConDec constraint onto one or more CLIMB rules. Obviously, many possible diﬀerent mappings, equivalent modulo compliance (see Def. 4.4.1) can be devised; here we try to preserve as much as possible the compactness and readability of the translation, to stress the similarities between the two approaches, and to show that the natural language description of each ConDec constraint can be easily represented in CLIMB. 5.4.1 Translation of Existence Constraints The result of the application of tIC on existence constraints is shown in Table 5.1. The absence n constraint expresses a prohibition of executing the targeted activity if it has already been executed a certain number of times, and is therefore formalized by exploiting a negative expectation. More speciﬁcally, the prohibition of executing activity a n + 1 times is modeled by stating that a is expected not to be executed if n diﬀerent executions have already

122

5 Translating ConDec into CLIMB

Table 5.1. Translation of ConDec existence constraints into CLIMB (it is assumed that T0 = −1) constraint

translation ( tIC )

0

a 0..n

a

true → EN(exec(a), T ). n

H(exec(a), Ti ) ∧ Ti > Ti−1 →EN(exec(a), Tn+1 ) ∧ Tn+1 > Tn .

i=1 n..∗

a

true →

n i=1

n

a

tIC

E(exec(a), Ti ) ∧ Ti > Ti−1 .

n..∗

⎛

a

∪ tIC ⎝ a ⎠

0..n

⎞

init

a

true → E(exec(a), 0).

occurred1 . The diﬀerence among such expected executions is modeled as a diﬀerence among their time variables2 , which in turn is captured by means of “=” CLP constraints. In a specular way, the existence n constraint expresses that the targeted activity is expected to be executed at least a minimum number of times. In the general case, it states that activity a must be executed at least n times, and is therefore represented by imposing a conjunction of n positive expectations about n diﬀerent executions of a. The formalization points out the goal-oriented nature of this constraint: existence n imposes the mandatory presence of a set of event occurrences independently of the other constraints and of the speciﬁc courses of interaction, and in fact the corresponding CLIMB integrity constraint has a true body. A proper combination of the absence n and existence n constraints can be used to jointly express the exactly n one. In particular, modeling that an activity a must be executed exactly n times can be reformulated as • a is expected to be executed at least n times (existence(n,a)), and • a cannot be executed more than n times (absence(n+1,a)). From the CLIMB viewpoint, an execution trace containing exactly n executions of a: 1 2

The borderline case in which n = 0 is captured by the absence 0 constraint, which simply states that the execution of a is forbidden. Indeed, two identical ground event occurrences, such as H(exec(a), 5) and H(exec(a), 5), are logically indistinguishable, hence they count as a single occurrence.

5.4 Translation of ConDec Constraints

123

Table 5.2. Translation of ConDec choice constraints into CLIMB constraint

a1 am

a1 am

n of m

a2

translation ( tIC ) true →

...

(Xi :: [a1 , . . . , am ] ∧ E(exec(Xi ), Ti ))

i=1

...

n of m

n

∧ all diﬀerent([X1 , . . . , Xn ]). true →

a2

n

(Xi :: [a1 , . . . , am ] ∧ E(exec(Xi ), Ti ))

i=1

∧ all diﬀerent([X1 , . . . , Xn ]) ∧ EN(exec(Y ), T ) ∧ Y :: [a1 , . . . , am ]

n

Y = Xi .

i=1

• satisﬁes all the n expectations imposed by tIC (existence(n,a)); • triggers tIC (absence(n+1,a)), generating a negative expectation about further occurrences of a. Finally, the init constraint is modeled by imposing that activity a is expected to be the ﬁrst executed activity, i.e., according to Def. 5.3.1, it is expected to occur at time 0. 5.4.2 Translation of Choice Constraints The formalization of choice constraints is reported in Table 5.2. Choice (n of m) is a natural extension of the existence constraint. While existence(n, a) expects that the same activity is executed at least n times, choice(n of m, [a1 ,...,am]) expects that n diﬀerent activities belonging to the set {a1 , . . . , am } are executed; hence, expectations do not diﬀer in their time variables, but in their activities. It is worth noting the constraint does not ﬁx which concrete n activities will be chosen: interacting entities can freely select them from the set a1 , . . . , am . To guarantee this ﬂexibility, the translation of the choice constraint does not contain expectations about concrete activities, but only on variables belonging to the set {a1 , . . . , am }. Set membership is expressed by means of the CLP membership constraint (denoted by “::”), where V :: L states that V is a discrete variable ranging over list L. The CLP membership constraint represents a compact way to formalize that V must unify with one of the elements contained in L, i.e., in the CLIMB setting, to formalize a non-deterministic, deferred choice among a set of candidate activities. As we have already pointed out, in the choice constraint the separation of the involved expectations is not tackled by imposing a diﬀerence among their time variables. Indeed, the n parameter ranges now over the candidate activities, and not over diﬀerent executions of the same activity. Furthermore,

124

5 Translating ConDec into CLIMB

alertByCall

alertByEMail

2 of 4

alertByMail

alertBySMS

Fig. 5.3. A simple ConDec model containing a choice constraint

in order to accommodate concurrency, time variables must be left as unconstrained as possible. The diﬀerence among the activity variables contained inside the n expectations is captured in CLIMB by means of the all diﬀerent CLP global constraint. It represents a compact way to express that all the elements of a list must be pairwise diﬀerent, and is handled by CLP solvers in an eﬃcient way [254]. The following example points out the beneﬁts of the membership CLP constraint, which helps in maintaining the formalization as concise as possible, avoiding the combinatorial explosion caused by the use of explicit disjunctions. Example 5.4.1 (Formalization of a choice constraint). Let us consider the following business constraints, explaining how critical informations must be communicated to the customer: 1. the customer can be informed by ordinary mail, by e-mail, by SMS or by executing a vocal call; 2. to ensure that the information is eﬀectively delivered, the customer must be alerted using at least two diﬀerent methods. The ﬁrst statement points out that four activities are available to inform the customer, while the second statement suggests that they must be interconnected by means of a 2 of 4-choice constraint. The resulting ConDec model is depicted in Fig. 5.3. By following the directives of Table 5.2, the choice constraint of the model can be represented as: true → X1 :: [alertByEMail , alertByMail, alertBySMS , alertByCall ] ∧X2 :: [alertByEMail , alertByMail, alertBySMS , alertByCall ] ∧E(exec(X1 ), T1 ) ∧ E(exec(X2 ), T2 ) ∧ all diﬀerent([X1 , X2 ]). This concise rule could be rewritten by unfolding the membership constraints, and by enumerating all the possible (combinations of) choices:

5.4 Translation of ConDec Constraints

125

true → E(exec(alertByEMail ), T1,1 ) ∧ E(exec(alertByMail), T1,2 ) ∨ E(exec(alertByEMail ), T2,1 ) ∧ E(exec(alertBySMS ), T2,2 ) ∨ E(exec(alertByEMail ), T3,1 ) ∧ E(exec(alertByCall ), T3,2 ) ∨ E(exec(alertByMail), T4,1 ) ∧ E(exec(alertBySMS ), T4,2 ) ∨ E(exec(alertByMail), T5,1 ) ∧ E(exec(alertByCall ), T5,2 ) ∨ E(exec(alertBySMS ), T6,1 ) ∧ E(exec(alertByCall ), T6,2 ). Although the two formulations are equivalent modulo compliance, the head of the ﬁrst integrity constraint contains a single disjunct, and delegates the management of non-determinism to the underlying CLP solver, while the head of the second one contains six explicit disjuncts. In the general n of m case, the number of disjuncts required for the ﬁrst formulation would be still one, while

m the number of disjuncts required for the second would correspond to n . Compared to the translation of choice, the formalization of exclusive choice contains an additional part, used to state that exactly n activities must be chosen out of the m candidates. Similarly to the exactly n constraint, the formalization complements the positive expectations of choice with a negative expectation, expressing that the m − n not chosen activities cannot be executed at all. The negative expectation is placed on a variable activity Y , which ranges over the set {a1 , . . . , am }, but excluding the n chosen activities X1 , . . . , Xn . Since Y appears only in a negative expectation, it is universally quantiﬁed on the {a1 , . . . , am }/{X1, . . . , Xn } domain, thus eﬀectively forbidding each one of the not chosen activities. It is worth noting that such a prohibition is not determined a priori: the forbidden set is dynamically determined as the n activities are progressively chosen and executed by the interacting entities. 5.4.3 Translation of Relation and Negation Constraints The translation of relation constraints follows the guidelines described in Table 5.3. They establish a precise correspondence between the basic graphical elements of ConDec relation/negation constraints, and several parts of the produced integrity constraints. Tables 5.4 and 5.5 apply such guidelines to provide a complete characterization of the tIC function in the context of relation and negation constraints respectively. As pointed out in Table 5.3, negation constraints are mapped in the same way as relation constraints, but replacing positive expectations with negative ones. Two points deserve a close examination. First of all, the formalization of alternate constraints relies on a interposition constraint , which is not a ﬁrst-class relationship in the ConDec setting. It is a ternary constraint, with a positive and negative variant:

126

5 Translating ConDec into CLIMB

Table 5.3. Guidelines for expressing ConDec relation and negation constraints in CLIMB notation

description

climb representation

binding a •−

− b

Activity a is the constraint’s H(exec(a), T ) used in the body of source; its occurrence triggers the an integrity constraint constraint Activity a is the constraint’s target; E(exec(b), T ) or EN(exec(b), T ) its execution is expected or forbid- used in the head of an integrity conden when the constraint triggers straint

ordering − The constraint does not involve any temporal ordering − The constraint involves a forward temporal ordering (“after”) −•

No CLP constraints over time variables Use of a CLP constraint stating that the target time is greater than the source time The constraint involves a backward Use of a CLP constraint stating temporal ordering (“before”) that the target time is lower than target time

strength − Basic constraint =

≡

kind − −

Use of a single rule (two in case of succession constraints) Alternate constraint The formalization is split into two parts: one for the basic behavior and one for the alternation Chain constraint (temporal conti- Use of a CLP constraint stating guity) that the source and target times are contiguous Relation constraint Negation constraint Succession constraint

Use of positive expectations Use of negative expectations The formalization is split into two parts, that separately capture the response and precedence part

• interpos(a,b,c) states that activity b must be executed between every execution of activity a and each following execution of activity c3 ; • neg interpos(a,b,c) expresses that b cannot be executed between any executions of a and a following c.

3

Equivalently, it states that between every occurrence of a and the ﬁrst following execution of c, b must be executed at least once.

5.4 Translation of ConDec Constraints

127

Table 5.4. Translation of ConDec relation constraints into CLIMB constraint a •−−−− b

translation ( tIC )

a •−−−• b

H(exec(a), Ta ) → E(exec(b), Tb ). ∪ tIC tIC a •−−−− b a −−−−• b

a •−−− b

H(exec(a), Ta ) → E(exec(b), Tb ) ∧ Tb > Ta .

a −−−• b

H(exec(b), Tb ) → E(exec(a), Ta ) ∧ Ta < Tb . ∪ tIC tIC a •−−− b a −−−• b

a •−−• b inter(a,b,c)

H(exec(a), Ta ) ∧ H(exec(c), Tc ) ∧ Tc > Ta

a •==• b

→E(exec(b), Tb ) ∧ Tb > Ta ∧ Tb < Tc . ∪ tIC (inter(a,b,a)) tIC a •−−− b ∪ tIC (inter(b,a,b)) tIC a −−−• b ∪ tIC tIC a •=== b a ===• b

a •= −= −= − b

H(exec(a), Ta ) → E(exec(b), Tb ) ∧ Tb = Ta + 1.

a = −= −= −• b

H(exec(b), Tb ) → E(exec(a), Ta ) ∧ Ta = Tb − 1. a •= a = ∪ tIC tIC −= −= − b −= −= −• b

a •=== b a ===• b

a •= −= −• b

The three activities are not necessarily diﬀerent; indeed, when interposition constraints are used to address the alternate ConDec constraints, their ﬁrst and third activities are always the same. In this way, they are exploited to specify that between two occurrences of a given activity, the execution of a second activity is expected or forbidden. A second important issue is concerned with the formalization of chain constraints. Chain relationships constrain activities occurring next to each other, and are therefore strongly connected to the notion of temporal contiguity, investigated in Sect. 5.3. In fact, the LTL formalization of chain constraints make use of the “next time” operator, which gives a qualitative semantics to temporal contiguity. For example, the chain response constraint is represented in LTL as: (a ⇒ b) −= −= − b tLTL a •= As pointed out in Sect. 5.3, the embedding of a qualitative characterization of time into a quantitative one leads to deﬁne temporal contiguity as a

128

5 Translating ConDec into CLIMB

Table 5.5. Translation of ConDec negation constraints into CLIMB constraint a •−− −− b

translation ( tIC )

a •−− −• b

H(exec(a), Ta ) → EN(exec(b), Tb ). ∪ tIC tIC a •−− −− b a −−−−• b

a •−− − b

H(exec(a), Ta ) → EN(exec(b), Tb ) ∧ Tb > Ta .

a −−− • b

H(exec(b), Tb ) → EN(exec(a), Ta ) ∧ Ta < Tb . a •−− a −−− ∪ tIC tIC − b • b

a •−− • b neg interpos(a,b,c)

H(exec(a), Ta ) ∧ H(exec(c), Tc ) ∧ Tc > Ta →EN(exec(b), Tb ) ∧ Tb > Ta ∧ Tb < Tc .

a •== = b

tIC (neg interpos(a,b,a))

a === • b a •== • b

tIC (neg interpos(b,a,b)) a •== a === ∪ tIC tIC = b • b

a •= −= −= − b

H(exec(a), Ta ) → EN(exec(b), Tb ) ∧ Tb = Ta + 1.

a = −= −= − • b

H(exec(b), Tb ) → EN(exec(a), Ta ) ∧ Ta = Tb − 1. a •= a = tIC −= −= − b −= −= − • b ∪ tIC

a •= −= − • b

diﬀerence of one time unit. Chain relationships are the only ConDec constraints whose underlying semantics is inﬂuenced by the chosen time ontology. Therefore, they are also the only constraints whose formalization must be properly revised when the quantitative nature of CLIMB is recovered.

5.5 Dealing with Branching ConDec Constraints As far as now, our discussion has been focused on the formalization of binary relation and negation constraints, i.e., constraints with a single source as well as a single target activity. As pointed out in Sect. 3.3.5, ConDec supports branching constraints, which extend the binary relationships to three or more activities. Branches are interpreted in a disjunctive manner, and introduce deferred choices for those who execute the model. Their formalization can be therefore tailored to the CLP membership constraint, as done for choice constraints. In particular, the obtained rules have the same structure as in

5.5 Dealing with Branching ConDec Constraints

129

the binary case, but involving activity variables instead of concrete activities, and imposing that such variables range into the set activities connected to the source or target branches. For example, the branching coexistence constraint is formalized as: ⎛ ⎞ a1 a2 ⎠ H(exec(X ), TX ) ∧ X :: [a1 , . . . , an ] tIC ⎝ →E(exec(Y ), TY ) ∧ X = Y ∧ Y :: [a1 , . . . , an ]. ... an

while the generalized response constraint, branching both in the source and in the target, is formalized in the following way: ⎛ ⎞ ⎜ s1 ⎜ tIC ⎜ ... ⎝ sn

t1

⎟

t2 ⎟ ⎟

...

⎠

H(exec(SA), Ts ) ∧ SA :: [s1 , . . . , sn ] →E(exec(TA), Tt ) ∧ Tt > Ts ∧ T A :: [t1 , . . . , tm ].

tm

It is worth noting that while the use of a membership CLP constraint in the head implicitly models a disjunction, its eﬀect in the body is to replicate the integrity constraint for each possible choice. Indeed, the rule triggers every time a source activity is performed. The formalization of the generalized response constraint is then implicitly composed by n integrity constraints, each one tailored to one speciﬁc source activity. By unfolding the membership constraints, the following equivalent (modulo compliance) formalization is obtained: ⎧ H(exec(s1 ), Ts )→E(exec(t1 ), Tt1 ) ∧ Tt1 > Ts ⎪ ⎪ ⎪ ⎪ ∨E(exec(t2 ), Tt2 ) ∧ Tt2 > Ts ⎪ ⎪ ⎪ ⎪ ∨. . . ⎪ ⎪ ⎪ ⎪ ∨E(exec(tm ), Ttm ) ∧ Ttm > Ts . ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ H(exec(s2 ), Ts )→E(exec(t1 ), Tt1 ) ∧ Tt1 > Ts ⎪ ⎛ ⎞ ⎪ ⎪ ⎪ ∨E(exec(t2 ), Tt2 ) ∧ Tt2 > Ts ⎪ t1 ⎪ ⎜ s1 ⎟ ⎨ ∨. . . t 2 ⎟ tIC ⎜ ⎝ ... ... ⎠ ∨E(exec(tm ), Ttm ) ∧ Ttm > Ts . ⎪ ⎪ sn ⎪ ⎪ tm ⎪ ⎪ ⎪ ⎪ ... ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ H(exec(sn ), Ts )→E(exec(t1 ), Tt1 ) ∧ Tt1 > Ts ⎪ ⎪ ∨E(exec(t2 ), Tt2 ) ∧ Tt2 > Ts ⎪ ⎪ ⎪ ⎪ ∨. . . ⎪ ⎪ ⎩ ∨E(exec(tm ), Ttm ) ∧ Ttm > Ts .

130

5 Translating ConDec into CLIMB

5.6 Translation of a ConDec Choreography Let us now consider the ConDec order management choreography designed in Sect. 3.4, and shown in Fig. 3.2 – p. 64. Let us denote the choreography model by OM. The complete translation of OM into the CLIMB language can be derived in a push-button manner, without human intervention: the modeler takes only care of designing the model at the graphical level, and exploits tCLIMB for automatically obtaining the corresponding CLIMB representation. As stated by Defs. 5.1.1 and 5.1.2, tCLIMB (OM) corresponds to a CLIMB speciﬁcation ∅, IC, where tIC (Ci ) IC = tIC (Cm (OM)) = Ci ∈Cm (OM)

The translation of each speciﬁc ConDec constraint is in turn produced following the indications contained in Tables 5.1, 5.2, 5.4 and 5.5, by substituting the placeholder activities a and b with the real ones contained in OM. The resulting integrity constraints are listed in Table 5.6. For the sake of readability, we have sometime sacriﬁced the compactness of the translation by unfolding the membership constraints. In this way, all the integrity constraints contain happened events and expectations bound to concrete, ground events.

5.7 Equivalence of ConDec Constraints Thanks to the CLIMB-based representation of ConDec, it is possible to prove whether two ConDec constraints are equivalent modulo compliance (Def. 4.4.1), i.e., whether they exhibit the same behavior, despite their diﬀerent graphical notation. In [242], van der Aalst and Pesic showed that there are several equivalences among negation constraints, and that they can be therefore reduced to a minimum core set. Table 5.7 recall all the established equivalences. Through the application of tCLIMB and the notion of equivalence modulo compliance, it is possible to give a formal account of such a reduction. Let us e.g. focus on the behavioral equivalence between the responded absence and not coexistence constraints. It can be easily proven by recalling Example 4.4.1 – p. 110, in which we have already demonstrated that: c −− b ∼ tCLIMB a −−−−• b tCLIMB a •−− Starting from the deﬁnition of tCLIMB in the not coexistence and considering the aforementioned equivalence, it holds: tCLIMB a •−− −• b ⎫ ⎧ ⎪ ⎪ t a •− − − − b ⎪ ⎪ CLIMB ⎨ ⎬ c ∪ ∼ t a •− − − − b CLIMB ⎪ ⎪ ⎪ ⎪ ⎩ tCLIMB b •−− −− a ⎭

5.7 Equivalence of ConDec Constraints

131

Table 5.6. CLIMB representation of the ConDec order management choreography shown in Fig. 3.2 - p. 64 (for space reasons, activities are directly represented with their names, without wrapping them inside the exec functor) constraint 0..1 close order cancel order

choose item

cancel order close order

close order

translation ( tIC ) H(close order , Tc ) → EN(close order , Tc2 ) ∧ Tc2 > Tc .

close order cancel order close order

choose item

accept order refuse order

true →E(cancel order , Tca ) ∧ EN(close order , Tcl ) ∨E(close order , Tcl ) ∧ EN(cancel order , Tca ). H(cancel order , Tca ) → E(choose item, Ti ) ∧ Ti < Tca . H(close order , Tcl ) → E(choose item, Ti ) ∧ Ti < Tcl . H(cancel order , Tca ) → EN(choose item, Ti ) ∧ Ti > Tca . H(close order , Tcl ) → EN(choose item, Ti ) ∧ Ti > Tcl . H(close order , Tcl ) →E(accept order , Ta ) ∧ Ta > Tcl ∨E(refuse order , Tr ) ∧ Tr > Tcl . H(accept order , Ta ) → E(close order , Tcl ) ∧ Tcl < Ta . H(refuse order , Tr ) → E(close order , Tcl ) ∧ Tcl < Tr .

refuse shipment

refuse order

H(refuse shipment, Trs ) → E(refuse order , Tro ).

accept shipment

accept order

H(accept order , To ) →E(accept shipment, Ts ) ∧ Ts < To .

refuse shipment

accept shipment

accept order

pay

refuse order

pay

pay

deliver receipt

0..1 deliver receipt

H(refuse shipment, Trs ) → EN(accept shipment, Tas ). H(accept shipment, Tas ) → EN(refuse shipment, Trs ). H(pay , Tp ) →E(accept order , Ta ) ∧ Ta < Tp . H(refuse order , Tr ) →EN(pay, Tp ). H(pay , Tp ) →EN(refuse order , Tr ). H(pay, Tp ) →E(deliver receipt , Ta ) ∧ Td > Tp . H(deliver receipt , Td ) →E(pay , Tp ) ∧ Tp < Td . H(deliver receipt , Td ) →EN(deliver receipt , Td2 ) ∧ Td2 > Td .

and thus responded absence and not coexistence can be substituted for one another when assessing compliance of execution traces.

132

5 Translating ConDec into CLIMB

Table 5.7. Behavioral equivalence of ConDec negation constraints (from [242]) constraint ⎫ a •−− −− b ⎪ ⎪ ⎬ a •−− −• a •−− − a −−− • a •−− •

⎪ ⎪ b ⎭ ⎫ ⎪ b ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎬ b ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎭ b ⎪

⎫ ⎪ a •= −= −= − b ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎬ a = −= −= − • b ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎭ a •= −= − • b ⎪

equivalent constraint

a •−− −• b

a •−− • b

a •= −= − • b

5.8 Soundness of the Translation Thanks to the translation presented in this chapter, ConDec is now equipped with two alternative underlying logic-based semantics: one based on propositional Linear Temporal Logic, and the other based on Abuctive Logic Programming with hypotheses conﬁrmation. In particular: • tLTL (Def. 3.7.1) takes a ConDec model and produces a corresponding LTL conjunction formula; • tCLIMB (Def. 5.1.1) takes a ConDec model and produces a corresponding CLIMB speciﬁcation. A series of important question then arises: is there an agreement between the two mappings? Are they “equivalent” when evaluating whether a trace of the system under study is supported by the ConDec model? In other words, is the CLIMB-based formalization sound with respect to the the LTL-based one? Fig. 5.4 graphically sketches how the two formalizations are connected. Even if they rely on diﬀerent logics, they are both meant to express interaction models, and to evaluate whether the execution traces of the system under study are compliant with such models. Starting from this observation, we prove soundness by means of the following four steps: 1. we present an isomorphism between LTL and CLIMB execution traces;

5.8 Soundness of the Translation

133

ConDec Model a

b c

tLTL

behavioral equivalence

tCLIMB

LTL formula

CLIMB specification complies with

complies with LTL trace

tm CLIMB trace

tm-1

Real execution trace

Fig. 5.4. Formal connections between the CLIMB-based and LTL-based formalizations of ConDec

2. we exploit this isomorphism to introduce the notion of LTL-CLIMB behavioral equivalence, tailored to compliance; 3. we deﬁne soundness in terms of the behavioral equivalence between the outcome of tCLIMB and tLTL ; 4. we show that a suﬃcient condition for proving soundness in the general case, is to prove soundness by considering each single constraint, and ﬁnally we focus on this latter task. The last step guarantees that verifying whether tCLIMB and tLTL are behaviorally equivalent when translating each single ConDec constraint separately amounts as a general proof, which guarantees that the application of tCLIMB on an arbitrary ConDec model always produces a CLIMB speciﬁcation equivalent to the LTL formula generated by tLTL . 5.8.1 Trace Mapping The ﬁrst step towards the comparison of the translations consists in ﬁnding a suitable way to relate the traces of the two logics. There exists a very intuitive mapping to accomplish this task: the states of an LTL trace are mapped onto the timestamps of a corresponding CLIMB trace, where H(exec(e), t) is the CLIMB counterpart for asserting that e is executed in state t. Deﬁnition 5.8.1 (Trace mapping). A trace mapping tm is an isomorphism which maps an arbitrary LTL trace TL onto a corresponding CLIMB one: tm :

(N, <, vocc ) −→ BH TL −→ T = {H(exec(e), t)|t ∈ TL (e)}

where BH is the Herbrand universe built upon CLIMB happened events.

134

5 Translating ConDec into CLIMB

Example 5.8.1 (Trace mapping). Let us consider an LTL execution trace TL = (N, <, vocc ), where E = {choose item, pay, send receipt , report failure} is the set of propositional events and: vocc (choose item) = {0, 1}

vocc (pay) = {2}

vocc (send receipt) = {3}

vocc (report f ailure) = ∅

Then tm (TL ) = { H(exec(choose item), 0),H(exec(choose item), 1), H(exec(pay), 2),H(exec(send receipt ), 3) } Obviously, being tm an isomorphism, it can be applied back and forth. The inverse translation, which starts from a CLIMB execution trace and produces a corresponding LTL trace, will be denoted by tm−1 . 5.8.2 Behavioral Equivalence Thanks to the trace mapping function tm, it is possible to evaluate whether the “same” execution trace complies with an LTL and a CLIMB speciﬁcation: if the prescriptions contained in the two speciﬁcations agree, then the outcomes are the same. Generalizing, if such an agreement is valid for all the possible execution traces, then the two speciﬁcations are behaviorally equivalent. Deﬁnition 5.8.2 (Behavioral equivalence). A CLIMB speciﬁcation S and c S) if and only if: an LTL formula φ are behaviorally equivalent (φ

∀ LTL trace TL , TL |=L φ ⇐⇒ compliant Stm(TL ) 5.8.3 Soundness Roughly speaking, a CLIMB translation function is sound with respect to an LTL translation function, if their application on an arbitrary ConDec model always produce two behaviorally equivalent formal speciﬁcations. Deﬁnition 5.8.3 (Soundness of the translation function). A CLIMB translation function t (mapping a ConDec model onto a CLIMB speciﬁcation), is sound with respect to an LTL translation function t (mapping a ConDec model onto an LTL formula) if and only if for each ConDec model c t (CM). CM, it holds that t (CM) Our claim is that tCLIMB is sound with respect to tLTL . To prove it, we rely on the following intermediate result: given an arbitrary ConDec model CM, showing that the two translation functions produce equivalent speciﬁcations

5.8 Soundness of the Translation

135

when applied to each single constraint of CM is a suﬃcient condition to show that they also agree for the overall model. It is worth noting that the result holds for any pair of “ConDec to LTL” and “ConDec to CLIMB” translations but, for the purpose of our discussion, we limit the analysis to tCLIMB and tLTL . In this speciﬁc setting, the result can be reformulated as: attesting soundness of tIC (with respect to tLTL ) is a suﬃcient condition for proving soundness of tCLIMB . Lemma 5.8.1 (Soundness of tIC implies soundness of tCLIMB ). For each ConDec model CM,

c tIC (Ci ) ∀Ci ∈ Cm (CM), tLTL (Ci ) ∅, c tCLIMB (CM) =⇒ tLTL (CM)

Proof. With an abuse of notation, we will use ∀ Ci to denote ∀ Ci ∈ Cm (CM). The proof starts from the behavioral equivalence between the translations of the single constraints, then relies on the logical tautology ∀i, αi ⇒ βi =⇒ αi ⇒ βi i

i

to put them together, and ﬁnally exploits the semantics of conjunction in LTL, as well as the compositionality of CLIMB speciﬁcations, to shift from a conjunction of equivalences between the single constraints to a global equivalence between the translations of the overall model.

c ∅, tIC (Ci ) ⇔ ∀Ci , tLTL (Ci ) (Def. 5.8.2)

∀TL ∀Ci , TL |=L tLTL (Ci ) ⇔ compliant ∅, tIC (Ci )tm[TL ] ⇒

∀TL , TL |=L tLTL (Ci ) ⇔ compliant ∅, tIC (Ci )tm[TL ] ⇔ i

∀TL ,

i

(Cor. 4.4.1) TL |=L tLTL (Ci ) ⇔ compliant tCLIMB (CM)tm[TL ] ⇔

i

(Sect. 3.6.3) tLTL (Ci ) ⇔ compliant tCLIMB (CM)tm[TL ] ⇔ ∀TL , TL |=L

i

(Def. 3.7.1) ∀TL , TL |=L tLTL (CM) ⇔ compliant tCLIMB (CM)tm[TL ] ⇔ (Def. 5.8.2)

136

5 Translating ConDec into CLIMB c tLTL (CM) tCLIMB (CM)

Lemma 5.8.1 guarantees that soundness of tCLIMB can be proven by comparing the translations of each single constraint in isolation. Theorem 5.8.1 (Soundness of tIC with respect to tLTL ). tCLIMB is sound with respect to tLTL . Proof (sketch). Thanks to Lemma 5.8.1, it is suﬃcient to prove that tIC is sound with respect to tLTL . To this aim, the explicit deﬁnitions of tLTL (Def. 3.7.1) and tIC (Sect. 5.4) must be compared taking into account each possible ConDec constraint (considering branching as well). We do not report here the complete proof of equivalence, but limit our discussion to some illustrative examples4 . Lemma 5.8.2 (Soundness in the case of absence). It holds that ⎛ ⎞ ⎛ ⎞ 0

0

c tLTL ⎝ a ⎠ tCLIMB ⎝ a ⎠

Proof. By considering the deﬁnitions of the two translations function, we have to show that: c ¬a S = ∅, {true → EN(exec(a), T ).} c c one must ﬁnd an Let us proceed by reductio ad absurdum. To disprove , LTL trace which is compliant with ¬a, but whose corresponding CLIMB trace is not compliant with S. To violate S, a CLIMB trace must contain the execution of a at a certain time, say, t. Hence, Tneg = {H(exec(a), t)} violates S. The corresponding LTL trace TL = tm−1 (Tneg ) satisﬁes a ∈ TL (t), which however contradicts ¬a, whose semantics states that i such that a ∈ TL (i). c c Similar to .

Lemma 5.8.3 (Soundness in the case of response). It holds that c a •−−− b tCLIMB a •−−− b tLTL Proof. The proof reduces to check that H(exec(a), T ) c a (a ⇒ ♦b) S = ∅, →E(exec(b), Tb ) ∧ Tb > Ta . 4

They would be propaedeutic to the complete proof, hence they are presented as lemmas.

5.8 Soundness of the Translation

137

c c does not hold, then there exits an LTL trace which complies with ¬a, If but whose corresponding CLIMB trace is not compliant with S. To violate S, a CLIMB execution trace must contain the execution of a at a certain time, say, t, such that after t activity b is never executed. By applying the tm−1 function on such a trace, an LTL trace TL obeying to the following properties is obtained:

1. a ∈ TL (t) 2. ∀t > t, b ∈ TL (t ) From the combination of the ﬁrst property with the LTL formula (a ⇒ ♦b), we obtain (TL , t |=L ♦b), and therefore it must hold that ∃t > t where b ∈ TL (t ). However, this contradicts the second property. c c Similar to . Lemma 5.8.4 (Soundness in the case of chain response). It holds that c tLTL a •= −= −= − b tCLIMB a •= −= −− = b Proof. We must show that: c S = ∅, (a ⇒ b)

H(exec(a), Ta ) →E(exec(b), Tb ) ∧ Tb = Ta + 1.

c c To disprove , one must ﬁnd an LTL execution trace which is compliant with ¬a, but whose corresponding CLIMB trace is not compliant with S. To violate S, a CLIMB execution trace must contain the execution of a at a certain time, say, t, such that at time t + 1 activity b is not executed. By the application of tm− 1 on such a trace, we obtain an LTL trace TL which obeys to the following properties:

1. a ∈ TL (t) 2. b ∈ TL (t + 1) By combining the ﬁrst property with the LTL formula (a ⇒ b), we obtain (TL , t |=L b), hence b ∈ TL (t + 1). However, this contradicts the second property. c c Similar to .

5.8.4 On the Expressiveness of SCIFF As far as now, we have limited our investigation to the ConDec setting, showing that CLIMB is able to express all the ConDec constraints in a sound way

138

5 Translating ConDec into CLIMB

with respect to the LTL-based approach. Generalizing, the notion of behavioral equivalence could be exploited for relating an arbitrary LTL formula to an arbitrary SCIFF speciﬁcation. Hence, an expressiveness challenge is issued: • Is it possible to translate every SCIFF speciﬁcation into LTL? • Is it possible to translate every LTL formula into SCIFF? The answer to the ﬁrst question is trivially “no”: thanks to its ﬁrst-order nature, CLIMB can model data-related conditions and metric temporal constraints, which cannot be addressed by LTL. Conversely, the fact that SCIFF is able to express any LTL formula has been recently demonstrated in [171]5 . Theorem 5.8.2 (SCIFF can express LTL). Given an arbitrary LTL forc mula φ, there exists a SCIFF speciﬁcation S such that φ S. Proof. See [171] – Sect. 5.6, p. 99. Theorem 5.8.2 points out a theoretical result, which absolutely does not imply that reasoning on LTL formulae can be completely carried out by reasoning on the corresponding SCIFF speciﬁcations. Indeed, being SCIFF a ﬁrst-order framework, it is semi-decidable, and suitable restrictions must be therefore imposed on the language to guarantee the termination of the corresponding reasoning techniques. For example, static veriﬁcation is unable to manage speciﬁcations requiring execution traces of inﬁnite length. We will deal with such issues further on in the book.

5

It is worth noting that the CLIMB fragment is not able to cover the expressiveness of LTL: full SCIFF is needed instead.

6 Extending ConDec

In this chapter, we investigate how the ﬁrst-order nature of the CLIMB language can be exploited to extend the expressiveness of ConDec along diﬀerent dimensions, towards the support of: • quantitative (metric) temporal constraints; • activity data and data aware conditions; • a non atomic model of activities. We call the extended language ConDec++ . ConDec++ reconciles ConDec with MXML, a well known meta model proposed by van Dongen and van der Aalst for standardizing the representation and storing of event logs [253].

6.1 Metric Constraints As pointed out in Chaps. 3 and 4, ConDec adopts a qualitative characterization of time, while CLIMB relies on a quantitative approach, modeling execution times explicitly and relying on CLP for expressing qualitative as well as metric relationships among them. In Sect. 5.3 – p. 117, we have shown that the only qualitative relation which is aﬀected when shifting from one approach to the other is contiguity: the LTL-based formalization of ConDec states that two event occurrences are contiguous if and only if they belong to consecutive states, while in a quantitative setting contiguity is expressed by imposing that the two event occurrences must not be separated by a further intermediate occurrence. As far as now, our purpose has been to provide a CLIMB-based formalization for the (basic) ConDec language. Since ConDec relies only on qualitative constraints, we have chosen to accommodate the qualitative notion of contiguity inside CLIMB. We are now instead interested in fully exploiting CLIMB’s quantitative approach, towards the introduction of metric temporal constraints at the graphical level of ConDec, while maintaining a complete mapping onto the

M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 139–161, 2010. c Springer-Verlag Berlin Heidelberg 2010

140

6 Extending ConDec

underlying formalization. To this purpose, we must provide a new CLIMB representation for contiguity, and properly revise the formalization of all ConDec constraints aﬀected by contiguity. 6.1.1 Temporal Contiguity in a Quantitative Setting When only qualitative temporal relationships are imposed over event occurrences, what matters is not which are the actual time values of event occurrences, but only their ordering. Time ﬂows only as events occur, and therefore it can be assumed, without loss of generality, that two occurrences diﬀering of a single time unit are contiguous. We have accommodated this approach in CLIMB, formalizing the concept of temporal contiguity as “diﬀerence of a single time unit” and hypothesizing that the analyzed execution traces are compact. Compact traces are associated to timestamps which only account for the relative ordering among event occurrences, without considering the actual time values. Conversely, when the domain under study involves metric temporal constraints, this assumption is not reasonable anymore: metric distances have a meaning only if they are anchored to the eﬀective time values at which events occur, which in turn depend on the chosen granularity. Example 6.1.1 (Metric temporal constraints). Metric temporal constraints are widespread in our targeted application domains, as illustrated by the following business constraints: • in a care-ﬂow protocol, each time a certain drug is administered to the patient, then no more drugs can be administered for at least 4 hours; • in a service choreography, the seller is expected to deliver a receipt within at most two days after the payment by the customer; • in an administrative process, each time the winner of a competitive examination is announced, then the winner has one month’s time to communicate the acceptance or refusal of the job. In a quantitative setting, time ﬂows independently from the event trails. Hence, two contiguous occurrences could be separated by an arbitrary time gap, unless another event occurs in between. The absence of events inside a certain time interval can be tackled by CLIMB by means of a general negative expectation, whose activity is a variable matching with any possible event occurrence, and whose time variable ranges inside the interval’s bounds. Deﬁnition 6.1.1 (Temporal contiguity and distance in CLIMB). Given a CLIMB trace T , two happened events H(exec(e1 ), t1 ), H(exec(e2 ), t2 ) ∈ T , with t2 > t1 , are contiguous if and only if EN(exec(X ), Tx ) ∧ Tx > t1 ∧ Tx < t2 is T -fulﬁlled The two happened events are distant if and only if E(exec(X ), Tx ) ∧ Tx > t1 ∧ Tx < t2 is T -fulﬁlled

6.1 Metric Constraints

141

6.1.2 Quantitative Formalization of Chain Constraints As pointed out in Sect. 5.3, ConDec chain constraints are tightly related to the notion of temporal contiguity. Let us for example consider the chain resp(a,b) constraint, which states that whenever a is executed, then b must be executed immediately next to a. By adopting a qualitative notion of temporal contiguity, we have modeled it as “if a is executed at time T , then b must be executed at time T + 1”. To account for the new characterization of contiguity, given in Def. 6.1.1, we rephrase the mapping onto CLIMB as follows: “if activity a is executed, then a following occurrence of b is expected such that no further activity is executed in between”. We encapsulate the revised CLIMB representation inside a new translation function tCLIMB , which is equivalent to the basic translation function tCLIMB except in the cases discussed here. As tCLIMB exploits tIC for the translation of ConDec constraints, tCLIMB relies on tIC . From the replaceability result (Theorem 4.4.2, p. 113), we know that the formalization of single ConDec constraints can be seamlessly revised without aﬀecting the other ones. In particular, following the aforementioned natural language description, we reformulate the CLIMB representation of chain response as: H(exec(a), Ta ) −= −= − b tIC a •= → E(exec(b), Tb ) ∧ Tb > Ta ∧ EN(exec(X ), Tx ) ∧ Tx > Ta ∧ Tx < Tb . Similarly, the chain precedence constraint is reformulated as follows: H(exec(b), Tb ) tIC a = −= −= −• b → E(exec(a), Ta ) ∧ Ta < Tb ∧ EN(exec(X ), Tx ) ∧ Tx > Ta ∧ Tx < Tb . The group of negation chain constraints must be revised as well, taking into account the notion of distance (see Def. 6.1.1), which is the opposite of contiguity. As we have shown in Table 5.7 – p. 132, negation chain response, negation chain precedence and negation chain succession are equivalent modulo compliance. We will therefore discuss only the case of neg chain resp(a,b), which states that whenever a is executed, then b cannot be executed immediately after a. To satisfy the constraint, there must be at least one further activity executed between a and b, i.e., they must be distant. Hence, we have: H(exec(a), Ta ) −= −= − b tIC a •= ∧H(exec(b), Tb ) ∧Tb > Ta → E(exec(X ), Tx ) ∧ Tx > Ta ∧ Tx < Tb .

142

6 Extending ConDec

6.1.3 Init Constraint The last ConDec constraint, whose formalization is aﬀected by the qualitative vs quantitative characterization of time, is the init constraint. Indeed, its original formalization (given in Table 5.1) simply states that the targeted activity must be executed at time 0, because it is assumed that ConDec models are tailored to compact execution traces, which always start from 0. In the pure CLIMB setting, instead, each execution trace starts with an event occurring at an arbitrary unanchored time value. We must therefore abstracting away from its actual value. To this aim, we propose to model that activity a must initiate the execution by stating that it is expected to happen, and no further event can occur before: ⎛ ⎞ init

tIC ⎝ a ⎠ true →E(exec(a), Tinit ) ∧ EN(exec(X ), Tx ) ∧ Tx < Tinit .

6.1.4 Extending ConDec with Quantitative Temporal Constraints The revised ConDec formalization, generated by applying the tCLIMB function, supports the possibility of extending some of the ConDec constraints to model metric time aspects. In particular, we propose metric extensions of: • all the relation constraints, in order to express delays and deadlines; • negation response1, in order to express latencies. When the source of timed relationships occurs, the eﬀect of metric constraints is to reduce the time window inside which the target activity is expected (not) to happen, by imposing a lower and/or upper bound on the expected time value. Such bounds are dynamically determined by dynamically anchoring the numerical values that express bounds to the actual time at which the source activity has been executed. For example, the response constraint could be extended by stating that “when the source activity occurs, then the target activity is expected to occur afterwards, but within n time units at most”. When the target activity is concretely executed at a speciﬁc time, say, t, then the actual maximum time span n + t is calculated. To graphically depict these temporal extensions, we propose to annotate the aforementioned ConDec constraints with a time interval marked oﬀ by two non negative values, Tmin and Tmax , which could be treated both in an exclusive or inclusive manner. As usually, parentheses (. . .) are used to indicate exclusion and square brackets [. . .] to indicate inclusion. The interval is interpreted as a time window relative to the occurrences of the source 1

I.e., all the “weak” negation constraints, due to their equivalence modulo compliance.

6.1 Metric Constraints

143

activity. In particular, the time window is translated backward or forward with respect to the source execution time, depending on whether the constraint is of a precedence or response type. CLIMB is able to capture such desiderata in a straightforward way. For example, the formalization of the metric response is2 :

tIC

(n,m)

!

a •−−− b

H(exec(a), Ta ) →E(exec(b), Tb ) ∧ Tb > Ta + n ∧ Tb < Ta + m.

The constraint expresses that if activity a is executed at time Ta , then a following activity b is expected to occur with a minimum delay of n time units, and a maximum delay of m time units, i.e., (strictly) between Ta + n and Ta + m. Symmetrically, precedence is extended as follows: ! (n,m) a −−−• b tIC H(exec(b), Tb ) →E(exec(a), Ta ) ∧ Ta > Tb − m ∧ Ta < Tb − n. Metric precedence expresses that activity b is executable only inside the time windows ranging from n to m time units after each occurrence of activity a. The membership of Tb to such a time window is expressed by means of the two CLP constraints Tb > Ta + n and Tb < Ta + m, which are equivalent to the ones shown in the formalization. Fig. 6.1 shows how ConDec++ is able to combine the proposed notation with basic relation constraints (i.e., responded existence, response and precedence) to express a plethora of metric relationships between the involved activities. A typical use of the metric extension is the modeling of deadlines. For example, a customer could express that she wants to interact only with sellers able to deliver the ordered items by at most two days after the order’s payment. By assuming a time granularity of hours, ConDec++ can capture this business constraint as: (−,48)

pay •−−− deliver Finally, the metric extension can be combined with negation relationships to model latencies, i.e., minimum time spans that must be respected before executing a certain activity. For example, a warehouse could state that it takes at least one day to ship a an order after having received a request; ConDec++ models such a latency constraint as: (−,24)

receive order request •−− − ship order 2

We show the case in which bounds are excluded. Inclusion of bounds is modeled by substituting the < and > CLP constraint with ≤ and ≥ respectively.

144

6 Extending ConDec validity of TB

activity a performed at time Ta anytime after

a

b

a

b

a

after(N)

(N,-)

b

Ta+N

a

before

a

before(N) Ta-N

between(N1,N2) Ta+N1

Ta+N2

between(N1,N2) Ta-N2

Ta-N1

a a

equals(N)

a equals(N)

Ta+N

a

b (N,-) (N1,N2) (N1,N2) [N,N] [N,N]

b b b b b

Ta-N

Fig. 6.1. Some metric constraints in ConDec++

The constraint expresses that when a request is received, say, at time t, then the order cannot be shipped during the ﬁrst 24 time units following t. Quantitative temporal constraints should not be interpreted as a way to force the execution of a certain activity within a desired time interval: interacting entities are autonomous, and cannot be controlled. Instead, temporal constraints should be considered as a means to specify temporal requirements on the possible supported interactions, contributing to the deﬁnition of the Quality of Service (QoS) that must be guaranteed by participants: compliant traces must not only respect the modeled constraints, but also satisfy all the metric temporal requirements. For example, a business constraint stating that an order must be delivered within two days after the execution of the payment, could represent a desiderata of the customer, who exploits it to select potential partners among all the available sellers. In particular, the temporal requirement could be exploited either: • to statically select good candidates among the possible sellers, such as e-sellers whose behavioral interface promises that they are always able to respect the deadline; • to check at run-time whether the real evolving behavior is eﬀectively complying with it; the prompt detection of a violation could be in turn used to alert the customer that the seller is breaking its public contract.

6.2 Data Aware Aspects

145

6.2 Data Aware Aspects The basic version of ConDec is only concerned with activities, and does not take into account the actual data involved in the courses of interaction. This is a great limitation: the prescriptions of business constraints often depend on the data values associated to their targeted activities. Data are used inside events to model their input and output informations, and exploited by business constraints to diﬀerentiate their behavior depending on data. Furthermore, a special kind of datum, called activity identiﬁer, is necessary to model non atomic ConDec activities, i.e., non instantaneous activities whose execution consists of more than one punctual event. We discuss such issues starting from some representative examples, then focusing on the MXML meta model for representing data and introducing a life cycle for non atomic ConDec activities. The next section will be instead devoted to show how these aspects can be accommodated by CLIMB, making it possible to extend ConDec in order to treat them at the graphical, modeling level. 6.2.1 Examples of Data Aware Business Constraints Data aware business constraints are widespread. The following example introduces some constraints belonging to diﬀerent application domains. Example 6.2.1 (Data aware business constraints). Let us consider ﬁve business constraints, taken from service choreographies, business processes and clinical guidelines. (DA1) A person under 18 years of age cannot open a bank account. (DA2) If a premium customer pays for an order by credit card, then the seller should answer within 10 time units by delivering a corresponding receipt, or by communicating a payment failure (rule (Br3-CLIMB) of Example 4.2.3). (DA3) The respondent bank must always be added to the black list in case its due diligence evaluation fails [22]. (DA4) Every time a blood glucose test is executed, if the measured level is less than 70 mg/dl, then the patient must eat something sweet within 5 minutes. (DA5) Before taking a medical test whose type is “no-food”, the person cannot eat anything for 8 hours. By looking at these ﬁve rules, it is easy to recognize that (DA1) is an absence ConDec constraint, (DA5) is a negation precedence constraint, while the others resemble all response relationships. However, they are all dependent on data. For example, (DA1) forbids the execution of the open account activity only if the person responsible for its execution has an age of less than 18 years. Table 6.1 analyzes the ﬁve business constraints, to the aim of discovering all their data-related aspects.

146

6 Extending ConDec

Table 6.1. Discovering data aware aspects inside business constraints constraint

activity

absence target open account (DA1)

activity’s datum data condition • responsible • age

less than 18

• • • •

responsible premium customer seller payment method credit card order

targets deliver

• • • •

responsible customer order receipt info

payment’s recipient the one who paid the paid one

failure

• • • •

responsible customer order failure reason

payment’s receipient the one who paid the paid one

response source pay (DA2)

response source diligence study • responsible (DA3) • respondent bank • evaluation failed target add to black list • responsible • target

the responsible of the diligence study the respondent bank

• responsible • patient • level

less than 70 mg/dl

target eat

• responsible • food

the targeted patient sweet

neg precedence source test (DA5)

• responsible • test code • patient

of type “no-food”

target eat

• responsible • food

response source test glucose (DA4)

the targeted patient

There are also a plenty of situations in which business constraints are modeled by assuming that activities are non atomic, i.e., characterized by a set of punctual events. A typical case is when constraints are expressed over the beginning, completion and cancelation of activities, instead of directly focusing on the activities themselves. The following example points out this issue in the context of a paper review process.

6.2 Data Aware Aspects

Log

*

1..*

Interaction Model 1

1

0..*

147

Instance 1

1..*

Activity

1..*

1

0..*

Datum

Entry Originator

Date EntryType

Fig. 6.2. An MXML-like meta model for representing the traces produced by the executions of interaction models

Example 6.2.2 (A submit&review process fragment with non atomic activities). Let us consider a fragment of a review process. The fragment involves two roles: an author and a reviewer. A person playing the author role has the possibility of submitting a paper. When a paper submission is successfully completed, then a review must be completed by a (person acting as a) reviewer within 45 days from the submission. However, the four-eyes principle must be guaranteed when executing the two activities: the same person cannot start a review of her own paper, even if she is entitled to act both as an author and reviewer. Examples 6.2.1 and 6.2.2 point out the necessity of extending ConDec in many respects. In particular, the following issues emerge from the two examples: • activities could be atomic or non atomic; • activities could involve (input and output) data; • activities could be associated to a special datum, used to model the role that must be played by an interacting entity to execute the activity; • data aware conditions contribute to determine when a business constraint must be applied; • data aware requirements augment business constraints by imposing restrictions on the data of the involved activities.

6.2.2 The MXML Meta Model The MXML meta model has been proposed by van Dongen and van der Aalst as an universal format for representing and storing event logs [253]. The meta model has been originally developed to address Business Process event trails, but it can seamlessly accommodate any trace produced inside an Event-Based System. Fig. 6.2 presents an UML class diagram of MXML, where the names of the participating entities are adapted to the case of interaction models.

148

6 Extending ConDec execution successful completed (tc)

started (ts)

initial

execution canceled (tx)

execution failed

Fig. 6.3. The life cycle of non atomic activities in (extended) ConDec (from [191])

The MXML meta model states that a log is associated to a set of interaction models. Being the set of activities the only portion of the interaction model that leaves a trace during the execution, in the context of MXML interaction models are simply characterized as sets of (non atomic) activities. Interaction models can be executed multiple times: each execution is called instance, and is composed by a set of audit trail entries. Each entry represents an observed event occurrence, and is associated to: • a corresponding activity of the interaction model; • an originator , i.e., the interacting entity responsible for the generation of the event; • an event type, reﬂecting the speciﬁc type of event with respect to the activity; • a date, representing the time value at which the event occurred; • a (possibly empty) set of further speciﬁc domain-dependent data values related to the event occurrence. The possible event types are taken from the MXML transactional model, which characterizes the life cycle of each non atomic activity in terms of atomic, punctual events. Such a life cycle has been devised by carrying out an extensive analysis of the diﬀerent types of logs in real-life systems, paying particular attention to Workﬂow Management Systems. Summarizing, MXML provides a standardized way to model execution traces, and tackles the ﬁrst two requirements pointed out in Sect. 6.2.1, namely support of data and of non atomic activities. 6.2.3 The Life Cycle of Non Atomic Activities in ConDec++ The MXML transactional model ﬁxes a set of events (or operations) that can be executed on each activity. Since activities can be executed multiple times, the life cycle models the evolution of each speciﬁc execution of the activity, i.e., of each activity instance, describing how its state is aﬀected by the generation of events. For example, the execution of an activity could be started by someone, then assigned to a new originator, and ﬁnally completed by the new responsible.

6.3 Modeling Data in ConDec++

149

In [191], Pesic introduced a simpliﬁed life cycle for ConDec, whose states and transitions are reported in Fig. 6.3. At quiescence, the activity (i.e., each potential instance of the activity) is in the initial state, meaning that it is not currently in execution. When the ts event related to the activity occurs, then an instance is started, becoming in execution. To complete the execution of the started instance, two possibilities are supported: • event tc occurs, and the activity instance is successfully completed; • the instance cannot be completed, and therefore its execution is canceled by means of the tx event.

6.3 Modeling Data in ConDec++ As we will see later on in this chapter, all the data-related desiderata summarized at the end of Sect. 6.2.1 can be expressed in CLIMB. Therefore, ConDec++ can be suitably extended to deal with them. The insertion of data aware aspects at the graphical level poses important challenges concerning the readability and compactness of the resulting notation. Finding the best way to graphically represent them, towards the right balance between readability and expressiveness, is out of the scope of this book: our purpose is just to give an intuition about the potentialities of data aware ConDec++ relationships, and to show that they can be formalized in CLIMB. 6.3.1 Representing Non Atomic Activities and Data ConDec++ supports two types of activities: • atomic activities, corresponding to the ones of ConDec; • non atomic activities, characterized by three ports which graphically capture the ts (start), tc (completion) and tx (cancelation) events of the ConDec++ activity life cycle. The proposed graphical notations for atomic and non atomic activities are shown in Figs. 6.4a and 6.4b respectively. Atomic activities, as well as the ports of non atomic ones, can be associated to data using a notation resembling the one of BPMN. Since the originator is always associated to each activity, we will omit its explicit modeling, relying on an ActivityN ame.O notation to recall it. In the case of non atomic activities, there is a diﬀerentiation between input and output data: data connected to the ts port represent the input data for the activity, whereas data connected to the tc port represent output data. We assume that the activity’s completion and cancelation ports have a complete visibility of the data associated to the start port. An activity can be optionally associated to a role, graphically represented inside the activity boundary in italics, and surrounded by parentheses. We will discuss two possible interpretations concerning the interplay between roles and originators in Sect. 6.4.2.

150

Datum1

6 Extending ConDec (role)

a

Datum2

ts

Input datum

(role)

tc

a

Output datum

tx

Fig. 6.4a. Atomic ConDec++ activity with data and role absolute conditions on a's data

Fig. 6.4b. non atomic ConDec++ activity with data and role relative conditions between a's and b's data

1..* a absolute conditions on a's data

b absolute conditions on b's data

Fig. 6.5. ConDec++ notation for expressing data aware conditions

ConDec++ inherits (and extends) all the ConDec constraints . Since ConDec constraints are applied to punctual events, in the case of a non atomic activity they are not directly connected to the activity itself, but rather on its ports. In this way, it is possible to model complex situations, such as that a some activity must have at least one successful completion (by anchoring an existence 1 constraint to its completion port), or that a certain activity can be started only if another activity has been successfully completed before (by using a precedence constraint that interconnects the start port of the ﬁrst activity and the completion port of the second one). 6.3.2 Modeling Data Aware Conditions Fig. 6.5 depicts how data aware conditions are represented in ConDec++ . They are graphically represented as strings composed by a conjunction of CLIMB atoms, i.e., Prolog predicates and CLP constraints. Typical examples are equality (or disequality) constraints, stating that two data do (not) have the same value. CLP-based conditions are especially useful when dealing with numerical data. The text of a condition is anchored to the targeted ConDec++ constraint by means of a dashed arrow with a small ﬁlled diamond on its top. When conditions are associated to an existence constraint, they are interpreted as an absolute restriction on the activity’s data, reducing the set of ground event occurrences to which the constraint applies. In other words, only occurrences satisfying the imposed restriction will aﬀect the constraint. Such a restrictions is “absolute” because it does not relate the targeted variables to other variables, but only to ground terms. Example 6.3.1 (A data aware absence constraint). Let us consider the business constraint (DA1) of Example 6.2.1. Following the analysis reported in Table 6.1,

6.3 Modeling Data in ConDec++

151

we can model it by relying on an open account activity, associated to an age datum3 . Then, an absence constraint can be employed to state that accounts cannot be opened. However, since the prohibition is only applied to originators whose age is less than 18, a data condition age < 18 must be associated to absence. The resulting model is then: Age < 18

Age

0 open account

“Age < 18” acts as a restriction on the applicability of absence. Indeed, the 0 cardinality constraint will be enforced (and violated) only if open account is executed by a person whose age is under 18. It will instead remain quiescent every time an account is opened by persons whose age is ≥ 18. When conditions are associated to binary relationships, it is necessary to separate them into diﬀerent (optional) groups. First, groups of conditions may be associated to each constraint’s endpoint. This is graphically rendered by anchoring the group of conditions to the contact point between the constraint and the activity or port. Such a group is interpreted as a set of absolute conditions on the data of the activity, applied in the context of the constraint. If the activity is a source of the constraint, then the group of conditions contributes to determine when the constraint is triggered: it will trigger only if all the group’s conditions are met. In this respect, the group plays the role of an explicit choice, i.e., a choice driven by the actual data [239]. If instead the activity is a target of the constraint, then the group of conditions is interpreted as a mandatory requirement restricting the possible matching event occurrences. Moreover, a further group of conditions may be anchored to the constraint, in order to model relative conditions between the data of the involved activities. Such an additional group is interpreted as a further restriction applied on the target activity. Since relative conditions are expressed over data of diﬀerent activities, to resolve possible name clashes each datum is recalled by using an ActivityN ame.datum notation. Summarizing, a data aware response like Cm

a

b Cs Ct

is interpreted as: “every time a is executed such that Cs is satisﬁed, then an instance of b, satisfying both Ct and Cm , must be eventually executed”. Example 6.3.2 (Data aware response constraints). Let us focus on the (DA3) and (DA4) business constraints of Example 6.2.1. They can be both modeled 3

The second datum, namely the responsible of the activity, is implicitly associated to each activity, and can be recalled, in this speciﬁc case, using notation “ open account.O”.

152

6 Extending ConDec

by means of a response constraint, suitably extended with data and data aware conditions. As shown in Table 6.1, (DA3) involves a source condition, stating that only failed evaluations will trigger the constraint, and two relative conditions, expressing that the constrained activities must be executed by the same originator, as well as that the target of the add to black list activity must be the bank whose evaluation failed. While the source condition is modeled as a predicate f ailed(evaluation), the two relative conditions are actually equality constraints. We thus obtain the ConDec++ response: Bank

Evaluation

Target

diligence study failed(Evaluation)

add to black list add to.O = diligence.O /\ add to.Target = diligence.Bank

(DA4) involves instead three diﬀerent types of data aware conditions. First, a CLP constraint level < 70 is employed as source condition, to state that the constraint triggers only when the glucose level is lower than 70 mg/dl. Second, an equality constraint models that the eat activity is expected to be executed by the patient who has been subjected to the glucose test. Third, a Prolog predicate sweet(F ood) is used to impose that the eaten food must be sweet. The graphical ConDec++ representation of (DA4) is then: Level

Patient

test glucose Level < 70

Food (0,5)

eat

sweet(Food) test glucose.Patient = eat.O

Note that the constraint is also associated to a (0, 5) temporal constraint, because the sweet food must be eaten by the patient within 5 time units at most. Example 6.3.3 (A data aware negation response constraints). Rule (DA5) of Example 6.2.1 is an example of data aware negation response constraint. It is triggered by the occurrences of the test activity, when the test has type “nofood”. This condition can be expressed by attaching a type(code, ‘no-food’) Prolog predicate to the source of the constraint. Furthermore, the constraint must be enforced on the patient subjected to the medical test, and therefore an equality condition between the patient datum of test and the originator of eat must be anchored to the constraint. Finally, the constraint is delimited in time: eating food is forbidden only during the 8 hours preceding the test. The graphical ConDec++ representation of (DA5) hence becomes: Food

Code

Patient

(0,8]

eat eat.O = test.Patient

test type(Code, 'no-food')

6.3 Modeling Data in ConDec++ Order Order

Method

Customer

deliver

Seller

Info

(0,10)

deliver.Order = pay.Order /\ deliver.Customer = pay.O /\ deliver.O = pay.Seller

(0,10)

failure.Order = pay.Order /\ failure.Customer = pay.O /\ failure.O = pay.Seller

pay

Method = 'credit card' Order /\ premium(pay.O, Seller)

153

failure

Customer Reason

Fig. 6.6. A ConDec++ data aware branching response constraint

Let us ﬁnally focus on branching constraints. When a constraint branches on the target side, then diﬀerent target data are possible. In this respect, relative data conditions can be anchored to each branch, tailoring them to each target data separately. Note that if the constraint also branches on the source side, then potential ambiguities and inconsistencies may arise when modeling relative conditions. Therefore, we assume that data aware constraints can branch only on one side, i.e., they could involve multiple sources or targets, but not both. As discussed in Sect. 3.3.5, constraints branching on both sides can be always equivalently modeled as constraints branching on one side, augmented with further non-branching constraints. Therefore, this assumption does not lead to a loss of generality. Example 6.3.4 (A data aware branching response constraint). The business constraint (DA2) of Example 6.2.1 can be modeled as a ConDec++ data aware branching response constraint, with the pay activity as source and the deliver and failure activities as targets. The two branches are both associated to a (0, 10) metric temporal constraint, to model that the answer must be provided by the seller within 10 time units after the payment. Fig. 6.6 shows the resulting constraint. A complex condition is attached to its source, specifying that it must trigger only when the payment method is equal to “credit card”, and it is performed by a premium customer. This latter condition can be expressed by means of a premium(pay.O, Seller) predicate, representing that the originator of the pay activity is a premium customer for the paid seller. Then, two groups of relative conditions are attached to the pay→deliver and pay→refuse branches, to express that: • customer’s payment and seller’s answer refer to the same order; • the answer must be provided by the paid seller, and sent to the customer who executed the payment.

154

6 Extending ConDec review.P_id = submit.P_id (0,45)

Paper

(author)

(reviewer)

submit

review P_id

P_id review.O = submit.O /\ review.P_id = submit.P_id

Review

Fig. 6.7. A ConDec++ diagram containing non atomic activities and data aware aspects

6.3.3 Modeling the Submit&Review Process Fragment We now brieﬂy discuss how all the proposed extensions can be combined to design a ConDec++ model for the submit&review process fragment, described in Example 6.2.2. First of all, the fragment targets the activities submit and review, associated to two corresponding roles, namely author and reviewer. Furthermore, since the start and completion of such activities are explicitly mentioned, then a non atomic model must be adopted for them. In particular, we assume that the submit activity takes a P aper in input, returning a corresponding identiﬁer P id when successfully completed. Conversely, the review activity takes a paper identiﬁer P id and returns the produced Review. Two business constraints are then mentioned inside the description of the process fragment. A succession constraint relates the completion of the submit activity to the completion of a corresponding review and vice-versa4. The constraint involves a (0, 45) metric temporal constraint, because the review must be completed within 45 days from the completion of the submission. Furthermore, the review must refer to the same paper identiﬁer returned by the submission, and therefore an equality condition between submit.P id and review.P id must be attached the constraint. A not coexistence constraint accounts for the four eyes principle. The four eyes principle forbids the coexistence of the submit and review activities only when they are executed by the same originator, and involve the same paper identiﬁer. This, two equality conditions must be attached to the not coexistence constraint in order to restrict its range accordingly. The ﬁnal result of this analysis is shown in Fig. 6.7. 4

Even if the natural language description of the submit&review process mentions only its response part, also the precedence part is needed for ensuring the consistency of the process: without it, it would be possible to review a paper that has not been submitted

6.4 Formalizing Data Aware Aspects in CLIMB

155

6.4 Formalizing Data Aware Aspects in CLIMB As extensively discussed in Chap. 4, thanks to its ﬁrst-order ﬂavor, CLIMB is not only able to constrain execution times, but it also supports data aware aspects. Events can be equipped with variables, which can be subject to CLP constraints and Prolog predicates, deﬁned in the CLIMB knowledge base. In the following, we show how CLIMB can accommodate the MXML meta model and support the ConDec++ ’s data aware conditions and roles. We then provide a CLIMB-based axiomatization of the life cycle characterizing the execution of non atomic activities. 6.4.1 Formalizing Data and Data Aware Conditions The ﬁrst step towards the accommodation of ConDec++ data in CLIMB, consists in properly revising the translation of events. As discussed in Sect. 5.2, the simple term exec(a) is used to translate a basic ConDec activity into CLIMB. We must now extend such a representation to account for all the elements introduced by the MXML meta model. Deﬁnition 6.4.1 (CLIMB extended event). CLIMB extended events are represented by the term exec(Etype , A, EID , O , DataList ) where: • Etype is the event type, taken from the ConDec++ activity life cycle, i.e., Etype ∈ {ts , tc , tx } – if the targeted activity is atomic, then this ﬁeld is omitted; • A is the activity the event refers to; • EID is the event identiﬁer, representing a speciﬁc occurrence of the event; • O is the originator responsible for the event occurrence; • DataList is a list of further domain-independent data associated to the event. A set of ground occurrences of CLIMB extended events can be therefore exploited to represent an MXML trace. Contrariwise, when the extended event is used inside the CLIMB representation of a ConDec++ constraint, only the Etype and A ﬁelds must be ground, capturing one of the endpoints to which the constraint is connected. The other ﬁelds could instead be variable, matching with diﬀerent speciﬁc executions, each one characterized by its own (previously unknown) originator, data and event identiﬁers. In this respect, data aware conditions are translated into corresponding CLIMB CLP constraints and Prolog predicates, which restrict the domain of such variables and put them in relation. The following guidelines are followed when data aware conditions are anchored to a ConDec++ constraint:

156

6 Extending ConDec

• For unary constraints, conditions are added to the head of the resulting integrity constraints, putting them in conjunction with the expectations of the targeted activity. For example (abstracting away from data), it holds that: 0

tIC

a

C

true → EN(exec(a, EID , O , Data), T ) ∧ C.

• For binary constraints, conditions anchored to the source are added to the body of the resulting integrity constraints, putting them in conjunction with the happened events related to the corresponding activity. Relative conditions, as well as conditions anchored to the target activity, are instead translated as done for unary constraints. For example (abstracting away from data), we have: ⎧ ! ⎨ H(exec(a, EIDa , Oa , Dataa ), Ta ) ∧ Cs Cm → E(exec(b, EIDb , Ob , Datab ), Tb ) tIC a b ⎩ C s Ct ∧Cm ∧ Ct ∧ Tb > Ta . Table 6.2 applies the aforementioned guidelines to some concrete data aware ConDec++ constraints, taken from Examples 6.3.1, 6.3.2 and 6.3.3. Obviously, in order to make such concrete ConDec++ constraints really work in a speciﬁc context, the deﬁnitions of the Prolog predicates used inside them should be provided into a corresponding CLIMB knolwedge base. Considering again Table 6.2, the listed integrity constraints should be complemented with a knowledge base containing: • the deﬁnitional rules formalizing when an evaluation fails; • a database of foods, in particular describing sweet foods; • a database of medical examinations, recording which ones have type “nofood”.

6.4.2 Formalizing the Eﬀect of Roles As shown in Figs. 6.4a and 6.4b, ConDec++ activities can be optionally associated to roles. Two possible interpretations can be given to model the interplay between the role associated to an activity and its possible originators. In the following discussion, we will use the Prolog predicate role(O, R) to denote that originator O plays role R5 , assuming that a CLIMB knowledge base is associated to the integrity constraints in order to provide a domain-dependent theory of roles for the system under study. A sample theory of roles has been described in Example 4.2.5 - p. 91. 5

A more elaborated notion of role, foreseeing the possibility of dynamically changing roles as the course of interaction evolves, could obviously be investigated, but it is out of the scope of this discussion.

Evaluation

Patient

eat.O = test.Patient

eat

Food

Level < 70

test glucose

Level

failed(Evaluation)

diligence study

Bank

Age

eat

(0,8]

Patient

type(Code, 'no-food')

test

Code

sweet(Food) test glucose.Patient = eat.O

(0,5)

Food

add to.O = diligence.O /\ add to.Target = diligence.Bank

add to black list

Target

0 open account

Age < 18

∧ Oe = P atient ∧ Te < Tt ∧ Te ≥ Tt − 8.

→EN(exec(eat, EIDe , Oe , [Food ]), Te )

H(exec(test, EIDt , Ot , [Code, Patient]), Tt ) ∧ type(Code, no-food )

∧ Oe = P atient ∧ sweet(Food ) ∧ Te > Tt ∧ Te < Tt + 5.

→E(exec(eat, EIDe , Oe , [Food ]), Te )

H(exec(test glucose, EIDt , Ot , [Level , Patient]), Tt ) ∧ Level < 70

∧ Ob = Os ∧ Target = Bank ∧ Tb > Ts .

→E(exec(add to black list, EIDb , Ob , [Target]), Tb )

H(exec(diligence study, EIDs , Os , [Bank , Evaluation]), Ts ) ∧ failed (Evaluation)

true →EN(exec(open account, EID , O, [Age]), T ) ∧ Age < 18.

Table 6.2. Translation of some data aware ConDec++ constraints into CLIMB

6.4 Formalizing Data Aware Aspects in CLIMB 157

158

6 Extending ConDec

Deﬁnition 6.4.2 (Weak and strong eﬀect of roles). Given an activity a subject to role R: • R has a strong eﬀect on a if only originators playing R can execute a; • R has a weak eﬀect on a if only the executions performed by originators playing R aﬀect the constraints attached to a. Under the strong interpretation, there is always an implicit constraint associated to each activity, expressing that it is only executable by originators playing the attached role. Under this perspective, the CLIMB translation obtained from the application of the tCLIMB function must be augmented with a set of additional CLIMB integrity constraints (one for each activity with role) expressing such a strong eﬀect. Deﬁnition 6.4.3 (Formalization of the strong eﬀect of roles). Given a ConDec++ activity a with associated role R, the strong eﬀect of R on a is formalized by means of the following integrity constraint: H(exec(a, EID , O , Data), T ) → role(O, R). if a is atomic H(exec(ts , a, EID , O , Data), T ) → role(O, R). if a is non atomic Diﬀerently from the strong interpretation, under the weak interpretation every originator can execute a, but the executions made by originators that do not play the attached role are ignored. In this respect, it is not possible to provide a separate formalization for roles, but tCLIMB itself must be properly modiﬁed. More speciﬁcally, the translation of ConDec++ constraints remains untouched, except for the fact that the happened events and expectations involving the interconnected activities are always put in conjunction with the corresponding role(O, R) predicate. For example, the formalization of the chain response constraint is modiﬁed as follows: −= −= − (r2 ) b tIC (r1 ) a •= H(exec(a, EIDa , Oa , Dataa ), Ta ) ∧ role(Oa , r1 ) → E(exec(b, EIDb , Ob , Datab ), Tb ) ∧ role(Ob , r2 ) ∧ T2 > T1 ∧ EN(exec(X , EIDx , Ox , Datax ), Tx ) ∧ Tx > T1 ∧ Tx < T2 . The formalization attests that if a is executed by an originator who does not play role r1 , then the constraint is not triggered. Symmetrically, when the constraint is triggered, the generated expectation cannot be fulﬁlled by a following occurrence of b if it is performed by someone who does not play role r2 . Example 6.4.1 (Formalization of the submit&review process fragment with weak roles). We show how the submit&review process fragment, described in Example 6.2.2 and shown in Fig. 6.7, can be formalized in CLIMB by

6.4 Formalizing Data Aware Aspects in CLIMB

159

relying on a weak interpretation of roles. The fragment consists of two relationships, a succession and a not coexistence constraint in particular. The succession constraint is translated as follows: ⎧ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ ⎪ → ⎪ ⎪ ⎪ ⎪ ⎨

H(exec(tc , submit, EIDs , Os , [Paper , P ids ]), Ts ) (•−−−) ∧role(Os , author) E(exec(tc , review , EIDr , Or , [P idr , Review ]), Tr ) ∧role(Or , reviewer ) ∧ P idr = P ids ∧ Tr > Ts ∧ Tr < Ts + 45.

⎪ ⎪ H(exec(tc , review , EIDr , Or , [P idr , Review ]), Tr ) ⎪ ⎪ ⎪ ⎪ ∧role(Or , reviewer ) ⎪ ⎪ ⎪ ⎪ ⎪ → E(exec(tc , submit, EIDs , Os , [Paper , P ids ]), Ts ) ⎪ ⎩ ∧role(Os , author) ∧ P ids = P idr ∧ Ts < Tr ∧ Ts > Tr − 45.

(−−−•)

while the not coexistence one leads to6 : H(exec(tc , EIDs , submit paper , Os , [Paper , P ids ]), Ts ) ∧ role(Os , author) →EN(exec(ts , EIDr , review paper , Or , [P idr ]), Tr ) ∧ role(Or , reviewer) ∧ Or = Os ∧ P idr = P ids .

6.4.3 Formalizing the Activity Life Cycle When non atomic activities are introduced inside a ConDec++ model, they are treated as black boxes: it is possible to interconnect their ports with constraints, but their internal life cycle (shown in Fig. 6.3 ) is encapsulated inside them, and cannot be accessed. Anyway, such a life cycle must be properly formalized in terms of CLIMB rules, in order to: • ensure the consistency of each execution of the activity, e.g. to guarantee that an activity instance cannot be completed if it has not been started before; • properly handle multiple parallel executions of the activity, binding each completion or cancelation event to a single previous start event (e.g., if an activity is started twice, then two separate instances of the activity become in execution, and must be eventually terminated by two separate cancelation or completion events). The second issue is particularly challenging, because it requires to correlate two separate events, a feature that is needed to establish a one-to-one relationship between each ts event and a corresponding tc or tx one. Correlation 6

We show only one side of ! the not coexistence constraint. ! Indeed, remember that c tCLIMB a •−− −• b ∼ tCLIMB a •−− −− b

160

6 Extending ConDec

cannot be handled by propositional logics, and therefore it cannot be accommodated by propositional Linear Temporal Logic (LTL) [191]. CLIMB can instead easily solve the correlation problem by exploiting the event identiﬁer (EID ) introduced in the extended representation of events (Def. 6.4.1). In particular, correlation is tackled by sharing the same event identiﬁer between a starting event and a corresponding completion or cancelation. We now show how a small set of CLIMB integrity constraints can be used to formalize the ConDec++ activity life cycle. Such constraints must be interpreted as ﬁxed axioms that must be repeated for each non atomic activity contained in the model. We therefore introduce the axioms supposing their application to an arbitrary activity a. The ﬁrst axiom expresses the uniqueness of executions with respect to a given event identiﬁer, whereas the following three axioms deal with the deﬁnition of legal orderings between ts and tc /tx , as depicted in Fig. 6.3. Axiom 6.4.1 (Uniqueness of the event identiﬁer). Each event performed on activity a must occur at most once with a given event identiﬁer: H(exec(E , EID , a, O1 , D1 ), T ) → EN(exec(E , EID , a, O2 , D2 ), T2 ) ∧ T2 > T. H(exec(E , EID , a, O1 , D1 ), T ) ∧H(exec(E , EID , a, O2 , D2 ), T ) → O1 = O2 ∧ D1 = D2 . where E is a variable used to intensionally represent either ts , tc and tx . Since the negative expectation is imposed with the same EID contained in the body, many occurrences of the same event can happen if they have diﬀerent identiﬁers. Axiom 6.4.2 (Completion of a started activity). When a is started by a certain originator, and identiﬁer EID is associated to the corresponding activity instance, then the same originator is committed to complete or cancel the EID -instance of a: H(exec(ts , EID , a, O , In), Ts ) → E(exec(tc , EID , a, O , In), Tc ) ∧ Tc > Ts ∨ E(exec(tx , EID , a, O , [In, Out]), Tx ) ∧ Tx > Ts . Axiom 6.4.4 formalizes also the data visibility informally pointed out in Sect. 6.3.1: the cancelation event has complete visibility of the input data, while the completion event is associated to the input data as well as to the output data produced during the activity executions. Axiom 6.4.3 (Cancelation enabling). An instance of a, associated to an event identiﬁer EID , can be canceled by an originator if and only if the same EID -instance of the activity has been previously started by the same originator: H(exec(tx , EID , a, O , ), Tx ) → E(exec(ts , EID , a, O , ), Ts ) ∧ Ts < Tx .

6.4 Formalizing Data Aware Aspects in CLIMB

161

Axiom 6.4.4 (Completion enabling). An instance of a, associated to an event identiﬁer EID , can be successfully completed by an originator if and only if the same EID -instance of the activity has been previously started by the same originator: H(exec(tc , EID , a, O , ), Tc ) → E(exec(ts , EID , a, O , ), Ts ) ∧ Ts < Tc .

7 Related Work and Summary

Related work concerning the speciﬁcation languages for interaction models is presented. Then, the major contributions of this part of the book are brieﬂy summarized.

7.1 Related Work We present related work by taking into account the diﬀerent areas discussed in Chap. 2: • • • •

Business Process Management (BPM); Clinical Guidelines (CGs); Service Oriented Computing (SOC); Multi-Agent Systems (MASs).

We discuss in particular those approaches that face the speciﬁcation of such systems by adopting a ﬂexible, declarative and open approach. 7.1.1 Business Process Management The need for ﬂexibility in BPM systems has been recognized in the last two decades by many diﬀerent authors. It is largely acknowledged that ﬂexibility is a key feature towards the eﬀective adoption of BPs in many diﬀerent domains, making processes able to continuously adapt to changing business strategies and dynamic contexts. It is not surprising, then, that languages and tools able to accommodate ﬂexibility in BPM systems have been matter of extensive research. We will mainly restrict our analysis to those approaches that propose new declarative languages for dealing with ﬂexibility by design (see Sect. 2.1.4). The adoption of a constraint-based approach to model ﬂexible BPs has been proposed since the early 90’s. In [96], a constraint-based Workﬂow Management System called FreeFlow is described. It relies on a previous system, called Contraﬂow, in which process model “describe the dependency M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 163–173, 2010. c Springer-Verlag Berlin Heidelberg 2010

164

7 Related Work and Summary

relationships between tasks, rather than procedurally describing sequences of action”. Contraﬂow shares with ConDec and CLIMB the declarativeness of the approach: constraints are used to declaratively describe the dependency relations between activities, instead of procedurally describing all the supported sequences of action. Constraints are continuously exploited to present the activities in which users might engage, leaving them free to choose the actual execution sequence. FreeFlow extends Contraﬂow by providing a complex six-state model of non atomic activities. Three of such states (“inactive”, “active” and “ready”) are dedicated to represent the activity life cycle, while the other ones are used to capture the ongoing impact of the constraint’s application on the activity: the activity is “enabled” if it can be currently executed, whereas it is “disabled” or “pending” if some constraint is respectively forbidding its start or completion. In ConDec++ , the two latter situations implicitly arise when there is a negative expectation on the start or completion of the activity. Diﬀerently from ConDec++ , in which constraints are imposed over events, FreeFlow associates constraints to activity states. Hence, a ConDec++ response relationship expressing that “activity b cannot start until a is started” can be represented in FreeFlow as “activity b cannot enter the enabled state until a is enabled and active”. Another constraint-based approach has been proposed by Wainer and Bezerra in [258]. The authors present a framework and prototype for modeling and executing process fragments in a loosely-coupled way. These fragments are speciﬁed as rules, which interconnect activities by means of pre-, par- and post-conditions. A controller is then used to dynamically compose the modeled fragments by chaining their rules. In particular, the controller asks the systems which precondition activities are necessary in order to execute a target activity, and then schedule the target activity for execution. At the language level, pre-conditions are used to state that a certain activity is executable only if some other activity has been previously executed. Contrariwise, postconditions are employed to model that when an activity is performed, then another activity must be eventually executed as well. Finally, par-conditions express temporally unordered relationships between activities. Negated activities can be exploited in place of “normal” activities, enabling the possibility of expressing negation constraints. Although very diﬀerent from a structural viewpoint, this rule-based language and ConDec share many similarities. Table 7.1 shows some correspondences between the two languages. In [209], Sadiq et al. introduce a hybrid framework, in which a procedural and a declarative modeling style beneﬁt from each other. In particular, they propose to integrate a procedural workﬂow speciﬁcation language, where activities are interconnected by means of classical control-ﬂow relations relations (i.e., sequence, split and merge constructs), with unstructured parts, called pockets of ﬂexibility. A pocket of ﬂexibility is a partially speciﬁed sub-process, composed by a series of activities and a set of order and inclusion constraints. These constraints strictly resemble the ConDec’s response, precedence, existence and choice ones; negative relationships are not

7.1 Related Work

165

Table 7.1. Comparison between ConDec and the rule-based approach of [258] ConDec constraint

rule-based representation

a •−−−− b

target: a parcondition: b

a −−−• b

target: b precondition: a

a •−−− b

target: a postcondition: b

a −−− • b

target: b precondition: not a

tackled. During the enactment phase, when a pocket of ﬂexibility is encountered, the user is guided through the dynamic construction of a completely speciﬁed procedural sub-process, by combining the enclosed activities so as to satisfy all the order and inclusion constraints. The authors then present Chamaleon, a prototypical management system supporting the enactment of pockets of ﬂexibility, as well as a set of veriﬁcation techniques able to detect conﬂicting and redundant constraints. Their approach is however not tailored to an underlying formal semantics, making therefore impossible to investigate the formal properties of the language and to guarantee the correctness of the proposed veriﬁcation techniques. Event-based speciﬁcations, such as Event Condition Actions (ECA) rules, have been also applied to model BPs in a ﬂexible manner. For example, in [138] a distributed agent-based architecture is presented, in which a set of task agents are employed to account for the decentralized enactment of BPs. The behavior of each task agent encapsulates a portion of the distributed workﬂow, and is deﬁned as a set of ECA-rules. During the execution, agents exchange events, leading to mutually triggering their controlled rules. The use of rules, together with the decoupled proposed architecture, jointly make the system able tackle both a-priori and a-posteriori ﬂexibility. ECA-rules closely resemble the structure of CLIMB constraints. Both approaches rely on forward rules, whose body is constituted by a conjunction of event occurrences, possibly associated to conditions. They however diﬀer concerning the head of rules: while ECA-rules trigger the execution of some actions, CLIMB integrity constraints generate an expectation stating that some actions are desired or forbidden, demanding their execution to the interacting entities. In [116], Goedertier proposes the EM-BrA2 CE framework, which supports the declarative BP modeling by relying on a vocabulary based on the OMG Semantics for Business Vocabulary and Business Rules (SBVR) speciﬁcation1 . 1

http://www.omg.org/spec/SBVR/1.0/

166

7 Related Work and Summary

The vocabulary of EM-BrA2 CE supports the speciﬁcation of highly expressive statements, concerning a plethora of business concerns, such as: • business concepts and rules of the organization under study; • characterization of the involved interacting entities (called agents); • description of the events characterizing the running instances of the system. Among the advantages of the EM-BrA2 CE speciﬁcation language, we cite the use of Natural Language Expressions to characterize business rules in a human-readable and machine-understandable way, and local closure, i.e., the possibility of specifying which parts of the modeled system must be treated with an open or closed world assumption, towards the speciﬁcation of semiopen models. Among the limits of the approach, we cite the lack of an underlying characterization of time: while the translation from ConDec to LTL and CLIMB enables the formal speciﬁcation of qualitative and quantitative time constraints, EM-BrA2 CE cannot deal with temporal constructs. In [193, 191], ConDec models are designed, veriﬁed and enacted inside a prototypical management system called DECLARE. In order to carry out veriﬁcation and enactment, DECLARE relies on the LTL-based formalization of ConDec. Beside supporting the basic notation, which has been presented in Chap. 3, DECLARE provides some advanced features: • modeling instance-related data, whose value is aﬀected by the execution of activities; • dealing with a non atomic model of activities; • attaching data aware conditions to relation constraints, inhibiting their triggering when the associated condition evaluates to false. Activities-related data, which have been extensively discussed in Chap. 6, are not treated. Furthermore, all the added features are not part of the formalization, i.e., they are treated by DECLARE separately from the LTL conjunction formula which formalizes the model. In this way, the extended diagrams speciﬁed in DECLARE are only partially associated to an underlying semantics, and they cannot be thus fully supported by the employed LTL-based reasoning techniques. In this book, instead, all the additional features of ConDec++ are fully formalized on top of CLIMB formalization. 7.1.2 Clinical Guidelines Several proposals for representing the procedural knowledge of CGs can be found in the literature: the interested reader can refer to [189, 229] for a survey and comparison of the most popular ones. In [180], Mulyar et al. provide a pattern-based evaluation of four guideline modeling languages, focusing in particular on the control-ﬂow perspective, which determines the ordering of actions in medical treatments. In [181], the authors rely on the results of this analysis, pointing out that it reveals several

7.1 Related Work

167

limitations of the state-of-the-art guideline speciﬁcation languages. In particular, their procedural nature tends to sacriﬁce ﬂexibility, an essential aspect in the medical setting, which is characterized by an high degree of unpredictability: when treating a patient, exceptional situations and emergencies may arise at any point in time, making it unfeasible to assume that the sequence of activities can be established a-priori. To overcome these issues, they propose to specify guidelines by means of the declarative CigDec language, which is a variant of ConDec. They however go from one extreme to the other, supposing that the whole knowledge underlying the guideline can be completely tackled by means of a declarative and open perspective. As we have described in Sect. 2.5, this is a too strong assumption: guideline speciﬁcation documents are usually written by following a procedural style of modeling, while ﬂexibility issues arise when such procedural prescriptions are interpreted by health-care professionals inside a concrete setting, and combined with their declarative Basic Medical Knowledge (BMK). As far as we are concerned, few proposals exist for complementing CG prescriptions with the BMK. In [219], Shiﬀman proposes the adoption of augmented decision tables as a unifying knowledge representation for clinical practice guidelines and their collateral informations. CGs are modeled by means of Condition-Action rules, linking a set of observed clinical conditions with corresponding actions. Conventional decision tables are then introduced to display, manage and verify such rules, organizing them into a matrix which correlates decision variables (such as symptoms and results of laboratory tests) with actions. The decision table theory is exploited to ensure the consistency of the modeled rules, as well as to support the user in the identiﬁcation of missing rules. Conventional decision tables are then augmented to complement the knowledge captured by rules with further medical informations. In particular, a multi-layered augmented decision table is exploited to detail also how medical tests and interventions are to be performed, and to enumerate beneﬁts, harms and costs of the recommended strategies, as well as to capture the quality and sources of evidence supporting such recommendations. More recently, the research activity carried out within the Protocure and Protocure II EU projects [228]2 has attempted to combine CGs with the BMK. CGs are modeled using the Asbru plan-based language [169], while the BMK is captured by means of Computation Tree Logic (CTL) and LTL formulae. However, the combination is not actually an integration: the BMK is not explicitly included in the model, but it is instead exploited for verifying whether its prescriptions are entailed by the procedural speciﬁcation of the guideline. In other words, it is assumed that both kinds of knowledge are ultimately included inside the CG, and that the temporal logic-based formalization of the BMK is only used for veriﬁcation purposes. The integration between these two kinds of knowledge has been instead recently investigated in the BPM setting. In [193], a layered integration between 2

http://www.protocure.org/

168

7 Related Work and Summary

Table 7.2. ConDec representation of the semantic constraints proposed in [157] semantic constraint in Adept

ConDec constraint

(Dependency, a, b, notSpeciﬁed, . . . )

a •−−−− b

(Dependency, b, a, pre, . . . )

a −−−• b

(Dependency, a, b, post, . . . )

a •−−− b

(Exclusion, a, b, notSpeciﬁed, . . . )

a •−− −− b

(Exclusion, b, a, pre, . . . )

a −−− • b

(Exclusion, a, b, post, . . . )

a •−− − b

ConDec and the YAWL procedural workﬂow language [231] is described. The integration is “layered” because a ConDec non atomic activity could be internally modeled as a YAWL process, or, conversely, a YAWL activity could be expanded as a ConDec diagram, while the interplay between the two approaches at the same level is not investigated. In [157], the adaptive system Adept is augmented with semantic constraints. Adept [84] is a workﬂow management system that supports ﬂexibility by change: the structure of a process model can be modiﬁed at run-time, supporting diﬀerent policies for reconciling the running instances with the new process structure. As suggested by their name, semantic constraints complement the syntactic control-ﬂow relationships imposed by an Adept speciﬁcation with further dependencies, introduced because of the meaning of the involved activities. For example, while the two activities of administer phenprocoumon and administer ASA are considered by Adept as two standard units of work, they are semantically conﬂicting, due to the incompatibility between the involved drugs. Semantic constraints are split into two families: • dependency constraints, imposing that if an activity is executed, then some other activity must be executed as well; • mutual exclusion constraints, expressing that if an activity is executed, then some other activity cannot be executed. Such two types of constraints are combined with the three fundamental temporal orderings of “before”, “after” and “no order”, giving raise to six possibilities. Hence, they represent a subset of the ConDec++ notation, because they do not deal with alternate and chain relationships, and do not take into account metric temporal constraints nor data. Table 7.2 shows how the six aforementioned semantic constraints can be represented in ConDec.

7.1 Related Work

169

7.1.3 Service Oriented Computing As pointed out in Chap. 2, all the state-of-the-art approaches model service oriented systems by adopting a procedural ﬂavor, i.e., by completely ﬁxing the control and message ﬂow of the interacting services. This has a great impact on the underlying formal languages onto which these approaches are mapped: Petri Nets [167, 186, 94], state machines [34] and message sequence charts [107] to cite some. In [269], Zaha et al. argue that the procedural nature of such modeling languages is an obstacle when specifying choreographies of autonomous web services, because all the possible interactions must be foreseen at design time, introducing unnecessary ordering and synchronization constraints. To overcome this issue, they propose a new declarative language, called Let’s Dance, for the ﬂexible speciﬁcation of choreographies. Let’s Dance focuses on the elicitation of the constraints needed to properly regulate service interaction, abstracting away from implementation details. It is therefore especially suited for business analysts and software architects. The language features a graphical notation for capturing message exchange patterns and constraints, and is translated into π-calculus [170] for formally capturing its underlying operational semantics [85]. It also adopts an open perspective, providing the ﬁrst-class abstraction of inhibitor arc to express negative relationships between messages. Hence, Let’s Dance and ConDec share the same philosophy: the acceptable sequences of messages are not explicitly enumerated in the graphical models, but rather they are derived from the speciﬁed constraints as all their compliant orderings. According to the classiﬁcation introduced in [86], the models generated by employing both languages are classiﬁed as: • implementation independent, because they do not ﬁx the format of messages nor the underlying communication protocol; • interaction models, because they tackle choreographies by considering message exchanges as the basic building blocks, without focusing on the internal control ﬂow of participants, as done by the “interconnected interface behavior models”. A huge amount of literature relies on various types of logics (especially temporal logics) to capture desired and undesired properties that must be respectively guaranteed and avoided by a service composition. For example, LTL is exploited in [93] for expressing correctness properties of service compositions, while in [128] a restricted form of LTL is translated into XQuery for expressing and monitoring behavioral properties. Within the Logic Programming framework, the Event Calculus [146, 218]3 is used in [226, 159, 205] to formalize behavioral properties of web service compositions, checking if they are eﬀectively guaranteed either before, during or after a concrete course of interaction is performed. All these approaches consider these correctness and behavioral properties as completely “external” to the targeted interaction model: they are 3

We will introduce the Event Calculus framework in Chapt. 14.

170

7 Related Work and Summary

speciﬁed separately from the model, and used only for verifying if they are implicitly (dis)entailed by the model. This is a necessary assumption only when the system under study is not under control of the modeler (see Sect. 2.7.2). Otherwise, it would be desirable to incorporate some of them directly inside the model. This is the philosophy underlying ConDec: interaction models are built by composing business rules, constraints, properties and contributions coming from diﬀerent sources. Flexibility issues in modeling (semantic) Web Services have been also deeply investigated by the semantic web research community. The two principal approaches in this area are the OWL-based web Service ontology [163]4 (OWL-S) and the Web Service Modeling Ontology [203]5 (WSMO). Both approaches model the contracts published by web services in terms of their Input, Output, Preconditions and Eﬀect (IOPEs). All these elements are semantically annotated, so as to express their intended meaning in a machineunderstandable way. In this respect, service retrieval and composition is carried out by taking into account the semantics of concepts involved in the published contracts, overcoming the limitations of a pure syntactic matching. Therefore, while ConDec is aimed at introducing ﬂexibility for the control ﬂow speciﬁcation, these approaches introduce ﬂexibility concerning terminological issues. 7.1.4 Multi-Agent Systems To the best of our knowledge, the SOCS Project, upon which SCIFF found its main motivations, has been the ﬁrst attempt to use Abuctive Logic Programming for reasoning about agent interaction at the social level. A variety of other logics have been proposed to represent complex social and institutional entities, such as normative systems and electronic institutions. In [20], Artikis et al. present a theoretical framework for the management of executable speciﬁcations of particular kinds of MASs, called open computational societies. Open computational societies are characterized by the unpredictability of the behavior of participants and of the possible courses of interaction. The framework helps to attack this complexity by enabling the formal speciﬁcation and enactment of the developed models, as well as the veriﬁcation of their properties. Three key aspects of computational systems are tackled, namely social constraints, social roles and social states. They are motivated by the formal study of legal and social systems, and therefore they rely on Deontic Logic for their formal speciﬁcation. Deontic Logic [266, 213] is a special kind of modal logic in which modalities are used to express obligations and permissions. In particular, given an atomic activity a, Oa represents that “it is obligatory to execute a”, while Pa denotes that “it is permitted to do a”. In the standard Deontic Logic, the concept of 4 5

http://www.w3.org/Submission/OWL-S http://www.wsmo.org

7.1 Related Work

171

prohibition, expressing that “a is forbidden” (F a), can be derived equivalently from permission or prohibition: F a ¬Pa or F a O¬a. In this respect, CLIMB and Deontic Logic share some similarities: • the notion of positive expectation (E) is related to obligation (O); • the notion of negative expectation (EN) is related to prohibition (F ). A detailed investigation concerning the similarities and diﬀerences between SCIFF and Deontic Logic can be found in [5]. Social approaches have been proposed for the ﬂexible, architecture-agnostic and veriﬁable speciﬁcation of global interaction protocols in open MASs. Prominent schools, including the one of Castelfranchi [56], of Singh et al. [268, 221], and of Colombetti et al. [82, 105] indicate social commitments as the ﬁrst class entities for tracking the evolution of social agent interactions. Commitments represent the mutual obligations established by the interacting parties during the interaction: an agent x becomes debtor towards a creditor agent y to bring about some property p (C(x, y, p)). Conditional commitments extend this concept by introducing a further condition, which determines when the commitment is eﬀectively established. For example, a business constraint could state that the seller is committed to send the good to the customer if the customer has paid for it. Such a requirement could be represented as a conditional commitment CC(seller, customer, orderP aid, orderSent), which states that, when orderP aid becomes true, the seller becomes committed to the customer to bring about orderSent. In this way, a further degree of ﬂexibility is introduced: commitments center around the notion of “property to be brought about”, without predeﬁning which are the possible candidate activities whose eﬀect is to made that property true. In the aforementioned example, the seller is free to choose on its own how to accomplish its commitment towards the customer, provided that the chosen activity has the eﬀect of sending the order. Similarly to the activity life cycle in the BPM setting, commitments are characterized by a set of states (such as active, satisﬁed, violated) and operations (e.g., create, discharge, cancel), which trigger a state change when certain events occur. The correspondence between events, eﬀects of events and operations is declaratively speciﬁed by the modeler. The resulting framework is therefore more ﬂexible than traditional approaches to protocol speciﬁcation, as it does not necessarily deﬁne action sequences, nor it prescribes initial/ﬁnal states or necessary transitions. This is why social commitments have been increasingly applied for capturing normative aspects and interaction protocols in open MASs [268] and, more recently, for modeling Business Protocols and Service Oriented Systems [223]. ConDec and commitments can be considered similar approaches when it comes to their underlying paradigm (modeling interaction with an open and declarative ﬂavor), but they are diﬀerent in purpose: ConDec constrain the acceptable execution traces, while commitments focus on the higher level of mutual obligations, characterizing the (un)desired and exceptional state of aﬀairs while abstracting away from the speciﬁc event occurrences. Fig. 7.1

172

7 Related Work and Summary

A payment can be

After the payment, the

When the payment is

A receipt can be

executed only if at

customer cannot

executed, the seller is

delivered either by e-

least one item has

choose further items.

committed to deliver a

mail or via sms.

been chosen.

receipt within 20 t.u.

ConDec (flow) constraints

Events 㲗 Effects

Social Commitments C(seller,customer,receiptDelivered) null

choose item

pay

create active

sms receipt

discharge

e-mail receipt

satisfied

cancel (after 20 t.u.) violated

Fig. 7.1. A comprehensive characterization of business constraints, integrating ConDec with social commitments

points out this complementarity, showing that the glue between the two levels is the link between events and their eﬀects and between events and their relationship with commitment operations. In [268], Yolum and Singh have provided an Event Calculus-based formalization of the commitment life cycle. In Chap. 14, we will show how the SCIFF-lite language can accommodate a reactive form of Event Calculus, laying the foundations for an eﬀective integration of ConDec and commitments. A preliminary investigation on this topic has been addressed in [66].

7.2 Summary of the Part In the ﬁrst part of the book, we have focused on the speciﬁcation of interaction models, arguing that the procedural and closed nature of current mainstream approaches needs to be complemented with a declarative and open perspective, for the sake of ﬂexibility. To support our claim, we have considered diﬀerent settings in which interaction plays a central role: Business Process Management, Clinical Guidelines, Service Oriented and Multi-Agent Systems. We have then introduced the constraint-based speciﬁcation of declarative and open interaction models. While procedural and closed languages impose to explicitly enumerate all the acceptable sequences of event occurrences, leading to produce rigid, over-speciﬁed and over-constrained models, constraint-based

7.2 Summary of the Part

173

approaches focus on the (minimal) set of business dependencies that must be guaranteed to correctly interact. In this way, the acceptable executions are implicitly derived as the executions which satisfy all business constraints, leaving many open possibilities to the interacting entities, and accommodating unpredicted behaviors. Two speciﬁc constraint-based approaches have been extensively discussed: • ConDec, a graphical language which provides a plethora of abstractions for constraining activities, ranging from weak, loosely coupled relationships to negative dependencies and tight interconnections; • CLIMB, a formal language based on Computational Logic, which employs forward rules to bind event occurrences with expected and forbidden courses of interaction, and exploits a Prolog knowledge base to capture the static, domain-dependent knowledge. We have then demonstrated how all the ConDec constructs can be eﬀectively translated into CLIMB, enabling the possibility of designing interaction models at a pure graphical level, automatically obtaining a corresponding CLIMB formal representation. Since CLIMB is equipped with a clear declarative semantics,which formally deﬁnes the notion of compliance of an execution trace with the speciﬁed constraints, the translations opens the possibility of investigating formal properties. In particular, we have discussed the compositionality of CLIMB (an hence ConDec) speciﬁcations, showing that compliance veriﬁcation with an overall model can be reduced to compliance veriﬁcation of its single business constraints. We have also investigated the relationships between the proposed translation and the original formalization proposed for ConDec, which relies on propositional Linear Temporal Logic (LTL). In particular, we have analyzed their diﬀerent characterization of time, and shown that the application of the two translations produces formal speciﬁcations which are behaviorally equivalent, thus attesting the soundness of our the CLIMB-based mapping with respect to the LTL-based one. We have ﬁnally exploited the expressiveness of CLIMB to extend ConDec with new interesting features, such as: • metric temporal constraints, augmenting some ConDec relations with delays, deadlines and latencies; • activity-related data, handling the speciﬁcation of data aware conditions; • a non atomic model for activities, supporting the possibility of constraining their start, completion and cancelation events. Summarizing, we have described a graphical, intuitive language for modeling declarative and open interaction models, providing a push-button methodology to obtain a corresponding formal speciﬁcation. How can we operationally exploit this formal speciﬁcation, to the aim of assisting the modeler during the design phase? The second part of the book will provide an answer to these questions.

Part II

Static Veriﬁcation

8 Static Veriﬁcation of Declarative Open Interaction Models In formal logic, a contradiction is the signal of defeat, but in the evolution of real knowledge it marks the ﬁrst step in progress toward a victory. — Alfred North Whitehead

Static veriﬁcation oﬀers design-time support for guaranteeing that an interaction model will meet, during the execution, certain desired properties, enabling the early identiﬁcation of errors and undesired situations. It is therefore exploited a-priori, before the execution. The positive outcome of static veriﬁcation can be used as a proof attesting the trustworthiness and reliability of the developed model. This chapter provides an introductory characterization of the static veriﬁcation of declarative open interaction models, speciﬁed using the ConDec notation. We discuss the desiderata that a static veriﬁcation technology must accomplish, and then focus on two speciﬁc problems: • static veriﬁcation of properties, carried out on a single model; • static veriﬁcation of a composition of local models, and conformance checking of a set of local models with a global (choreographic) model.

8.1 Desiderata for Static Veriﬁcation Technologies Static veriﬁcation technologies are especially useful for modelers, who need to constantly check the designed speciﬁcations, evaluating whether requirements and goals have been really met and deciding if a new design iteration is needed, or the current version is ready to be executed. Fig. 8.1 shows the resulting design cycle. In Sect. 3.5, we have pointed out that ConDec models present hidden dependencies, which can unexpectedly lead to inconsistent models. In this respect, static veriﬁcation is even more important: the design phase requires a “progressive evaluation”, as it is called in the cognitive dimensions framework [122]. In order to eﬀectively help the modeler in the assessment of ConDec models, the following desiderata should be accomplished by a static veriﬁcation framework. M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 177–199, 2010. c Springer-Verlag Berlin Heidelberg 2010

178

8 Static Veriﬁcation of Declarative Open Interaction Models Design Design Iteration current version

requirements

Static

model

Verification

Fig. 8.1. Design cycle of interaction models, exploiting a static veriﬁcation technology

Soundness and completeness. If the veriﬁer answers that the system will never reach an undesired state of aﬀairs, we must be sure that this is truly the case. In other words, our veriﬁer should never compute wrong answers, i.e., it should be sound. On the other hand, it should be able to provide a positive answer if such a positive answer exists, i.e., it should be complete. If soundness or completeness are guaranteed only when the veriﬁed model meets certain assumptions, the veriﬁer must be complemented with techniques able to: • identify whether a given model respects the assumptions; • alert the user, and/or automatically take speciﬁc countermeasures, if that is not the case. Generation of (counter)examples. When the veriﬁer returns a negative answer, indicating that the current model does not entail a given requirement, it would be desirable if it also provides some hints helping in the isolation of the relevant part of the model which is causing the violation. This desiderata is usually rephrased by requiring that the veriﬁer must generate a (counter)example, i.e., an execution trace which motivates the computed answer. Push-button style. After having started the veriﬁcation process, it should operate as much as possible in an automatic fashion, without requiring a constant intervention of the user (as done, for example, by proof assistants and interactive theorem provers). Scalability. Being carried out at design time, the performance of static veriﬁcation is not time-critical. However, the veriﬁer is continuously exploited by the modeler during the design phase, following the engineering process shown in Fig. 8.1. This methodology is practically feasible only if the veriﬁer exhibits scalability and good performance.

8.2 Veriﬁcation of a Single Model vs. a Composition of Models

179

Fig. 8.2. Conformance and replaceability inside a service choreography

8.2 Veriﬁcation of a Single Model vs. a Composition of Models We identify two diﬀerent situations in which static veriﬁcation comes into play. Veriﬁcation of a single model. During the design phase, a model must be constantly veriﬁed to: • ensure its correctness and consistency; • check if it covers all the requirements elicited by the analysis of the domain; • test if it meets the business objectives for which it has been conceived; • assess its compliance with internal policies, best practices, external regulations and norms, which are not intended to be included inside the model itself. In this respect, static veriﬁcation helps in the premature identiﬁcation of violations which, if encountered at run-time, could be costly to repair or could even compromise the entire system. When a problem is detected, a new design cycle can be triggered to properly revise the model. Veriﬁcation of a composition of models. When the system under study is split into separated components, static veriﬁcation supports the modeler in the process of checking whether diﬀerent (possibly already existing) concrete components can be put together to eﬀectively realize the overall composition. A typical example is service choreography, which is thought to capture in an abstract way the mutual obligations and business dependencies that must be respected to make a set of services correctly interact: static veriﬁcation aims here at checking whether a concrete service composition is able to accomplish all the choreography constraints. The same methodology can be applied to deal with service conformance and replaceability, i.e., to respectively check whether a given concrete service can play a role inside the choreography, or to test whether a service playing a certain role in the choreography can be replaced by another concrete service (see Fig. 8.2).

180

8 Static Veriﬁcation of Declarative Open Interaction Models

property yes Properties Verification

model

(counter) example

no

Fig. 8.3. Veriﬁcation of properties

8.3 Static Veriﬁcation of Properties Static veriﬁcation tasks focusing on a single model are collected under the umbrella of veriﬁcation of properties, whose general schema is sketched in Fig. 8.3. The broad problem of proving or disproving the correctness of a model with respect to some property is usually called formal veriﬁcation. Properties formally capture requirements that must be covered by the system under development. Requirements may diﬀer from one another in nature and purpose, and can be classiﬁed along diﬀerent axes. For example, a requirement may express that an external regulation must be fulﬁlled in every execution of the system. Another requirement may capture a desired (hidden) dependency among activities, which should be entailed by the model even if not explicitly contained by it. In the following, we will focus on two fundamental dimensions: existential vs universal and general vs particular properties. It is worth noting that properties themselves are captured by means of business constraints. Hence, when a property is expressible in ConDec, we will use ConDec’s graphical notation to describe it. For example, a property saying that “a receipt must be eventually sent” corresponds to the ConDec constraint 1..∗

send receipt 8.3.1 Existential vs. Universal Properties When the modeler is interested in verifying whether the ConDec model under development always meets a best practice of the company, the intended meaning is that the property must be respected in any possible execution of the system. Contrariwise, the reachability of a certain state of aﬀairs is guaranteed if there exists at least one execution which leads to that situation. In general, properties quantify over execution traces in two complementary ways: existential and universal. Deﬁnition 8.3.1 (∃-entailment). A property Ψ is ∃-entailed by a ConDec model CM (CM |=∃ Ψ ) if at least one execution trace supported by CM

8.3 Static Veriﬁcation of Properties

181

entails the property. Such an execution trace can be considered as an example attesting the satisﬁability of the property. Deﬁnition 8.3.2 (∀-entailment). A property Ψ is ∀-entailed by a ConDec model CM (CM |=∀ Ψ ) if all the possible execution traces supported by the model entail the property. The generation of an execution trace which complies with all the constraints of the model but violates the property can be interpreted as a counterexample which disproves the entailment. As we will see, ∀-entailment can be reduced to ∃-entailment by exploiting the following intuition: the existence of a counterexample showing that the ∀-entailment of a property does not hold, can be interpreted as an example attesting that the negated property is ∃-entailed. 8.3.2 General vs. Particular Properties Properties can be • general , if they describe domain-agnostic requirements that must be satisﬁed by an arbitrary interaction model; • particular , if they consider the peculiar features and requirements of the targeted domain. An example of a particular, domain-dependent property is the good atomicity of an e-commerce protocol; good atomicity states that the customer receives the ordered goods if and only if the corresponding payment transaction is successfully completed. General properties aim instead at ensuring the executability of interaction models, identifying (potential) deadlocks, i.e., global and local inconsistencies. More speciﬁcally, a globally inconsistent model is called conﬂicting, while a locally inconsistent model contains dead activities [193]. Deﬁnition 8.3.3 (Conﬂict-free model). A ConDec model CM is conﬂictfree if and only if it supports at least one possible execution trace: CM |=∃ true If it is not the case, CM is said to be conﬂicting. A conﬂicting model is an over-constrained model: it is never possible to fulﬁll all its mandatory constraints. The inconsistency of a conﬂicting model is a global inconsistency: the model does not support any trace, and therefore it cannot be executed at all. A conﬂicting model must be necessarily revised, trying to rearrange (a subset of) its constraints in order to remove the conﬂict. In order to identify the minimal combination of constraints that is causing the conﬂict, one should repeat a conﬂict-freedom test by separately considering each possible subset of the mandatory constraints. If the conﬂicting model

182

8 Static Veriﬁcation of Declarative Open Interaction Models

had n mandatory constraints, 2n−1 combinations should be checked to isolate the minimal conﬂicting part. Checking the presence of conﬂicts is the ﬁrst step towards the correctness veriﬁcation of a ConDec model. However, it does not suﬃce: there could be local inconsistencies which do not aﬀect the entire model, but make some of its activities non executable. Such activities are called dead, and represent a declarative version of the well-known notion of deadlock state in distributed systems. Deﬁnition 8.3.4 (Dead activity). Given a ConDec model CM and an activity a, a is dead in CM if and only if there does not exist an execution trace supported by CM which contains a: 0

CM |=∀

a

The execution of a dead activity will always cause to violate one of the mandatory constraints of the model. Since dead activities are non executable, their presence reveals potential local inconsistencies in the ConDec diagram, and hence they must be critically analyzed during the design phase. Example 8.3.1 (Example of dead activities). Let us consider the simple ConDec model 0

a •−−− b Activity b is dead “by construction”, being associated to an absence constraint. Activity a is dead as well, due to a (negative) hidden dependency between the absence and response constraints. Let us suppose, by absurdum, that there exists an execution trace supported by the model which contains the execution of a. Due to the response(a,b) constraint, such an execution trace would also contain a following execution of activity b. However, the execution of b is not supported, being b a dead activity. Hence, there does not exist an execution trace supported by the model which contains a, i.e., a is dead.

8.3.3 On the Safety-Liveness Classiﬁcation In the context of formal veriﬁcation, properties are usually classiﬁed along the safety vs liveness dimension [142]. Intuitively, a safety property asserts that something bad will not happen during any execution of the system, whereas a liveness property states that something good will happen. In this section, we will show why this classiﬁcation is not suitable for ConDec. Usually, safety and liveness are characterized in terms of execution traces with inﬁnite length:

8.3 Static Veriﬁcation of Properties

183

• Ψ is a safety property if and only if for every execution trace which violates Ψ , the violation can be ascribed to a ﬁnite preﬁx of the trace. A violation can be therefore detected in ﬁnite time, and its occurrence is irreparable: there is no way to extend the preﬁx so as to satisfy the violated property. • Ψ is a liveness property if and only if it is always possible to fulﬁll it by complementing the ﬁnite preﬁx of an arbitrary trace with a suitable inﬁnite suﬃx. Let us consider some typical LTL safety and liveness properties1 used in formal veriﬁcation, and discuss whether they are reasonable in the ConDec setting or not. 1. ♦a is a liveness property, which states that activity a must be eventually executed; it corresponds to the LTL formalization of the existence 1 ConDec constraint. 2. (¬a) is a safety property, usually called invariant property, that forbids the execution of activity a; it is the LTL counterpart of the absence ConDec constraint. 3. a is a safety property, imposing the execution of a inside all the states of an inﬁnite trace. 4. (a ⇒ ♦b) is a liveness property, which states that each time activity a is executed, then a following occurrence of b must be eventually produced as well. It represents the response(a,b) ConDec constraint. 5. a variation of the response property, stating b must occur no later than 6 time units after a, is a safety property. It is commonly called promptness property [148], and formalizes the metric ConDec++ constraint (0,6]

a •−−− b 6. ♦a is a liveness property, and more precisely it represents a kind of fairness property; it states that activity a must be executed inﬁnitely often. A ﬁrst thing to note is that, as argued in [182], there is a gap between the intuitive and the formal characterization of safety and liveness. It is often diﬃcult for humans to evaluate whether a given property is a safety or a liveness property. For example, while the LTL formalization of the response ConDec constraint is a liveness property, its metric variation, augmenting it by a deadline, is a safety property. Beside this drawback, there is also an issue speciﬁcally related to ConDec: the formal characterization of safety and liveness properties is given for inﬁnite length traces, while in ConDec traces are always ﬁnite. As pointed out in Def. 3.7.4 – Sect. 3.7.3, this means that each LTL formula must be 1

The semantics of propositional Linear Temporal Logic has been introduced in Sect. 3.6.

184

8 Static Veriﬁcation of Declarative Open Interaction Models

put in conjunction with a formula expressing that traces are ﬁnitary, or alternatively switching to a ﬁnite-trace semantics for LTL. The introduction of such a termination property in standard LTL, in turn, makes some of the aforementioned cases inconsistent, i.e., unsatisﬁable. For example, despite their structural similarity, the two safety properties (¬a) and a are treated diﬀerently by ConDec: while the ﬁrst is legitimate (it actually represents one of the ConDec constraints), the second is not. Indeed, a states that activity a must be inﬁnitely executed in each state of the trace, and thus it is incompatible with the termination property. Formally, the property, augmented with termination, becomes a ∧ ♦¬a, which is unsatisﬁable. Similarly, while the liveness property ♦a is acceptable, fairness cannot be never guaranteed. ♦a is the existence ConDec constraint, and can be interpreted inside a ﬁnite trace as “activity a must be performed at least once before the termination of the execution”. Contrariwise, fairness cannot be never fulﬁlled by a ConDec model because it is impossible to execute a certain activity inﬁnitely often. This diﬀerent treatment is due to the fact that ♦a can be fulﬁlled by complementing any trace with a ﬁnite suﬃx (e.g., a suﬃx containing only activity a), while fairness necessarily requires an inﬁnite suﬃx. In general, only ﬁnitary liveness and fairness properties [14, 57, 220] can be satisﬁed by a ConDec model2 . Summarizing, the implicit assumption that the execution of a ConDec model must eventually terminate (i.e., that execution traces are always ﬁnite) cuts out some properties, no matter whether they are safety or liveness properties. Thus, the safety-liveness classiﬁcation is unsuitable, and we will instead rely on the two dimensions identiﬁed in Sects. 8.3.1 and 8.3.2, namely existential vs universal and general vs particular properties. 8.3.4 A ConDec Example Fig. 8.4 shows the ConDec speciﬁcation of an order&payment protocol. There are three diﬀerent parties involved–a merchant, a customer, and a banking service to handle the payment– which are left implicit. An execution of the model deals with a single order, i.e., an order can be closed at most once. It is possible to close an order only if at least one item has been chosen, and once the order has been closed no more items can be added to it. Two possible methods are available to pay a closed order: 1-click payment and standard payment. 1-click payment is a special fast payment method which becomes available only if the customer has previously registered; registration, in turn, requires that the customer explicitly accepts to receive advertising (either before or after the registration). The payment phase involves an alternate succession between the payment and the answer from the banking service: after having executed a payment, further payment attempts are forbidden until a response is 2

Given a ﬁnite preﬁx of an execution trace, the satisﬁability of ﬁnitary liveness (or fairness) properties can be obtained by adding a ﬁnite suﬃx, whose length is unknown.

8.3 Static Veriﬁcation of Properties

accept ads

choose item

register

0..1 close order

1-click payment

payment done

standard payment

payment failure

185

0..1 send receipt

Fig. 8.4. ConDec model of an order&payment protocol

received, and only a single answer is allowed for each payment. Finally, only if the banking service sends a payment conﬁrmation, a single receipt is delivered by the seller, attesting that the order has been eﬀectively ﬁnalized.

Some execution traces supported by the model are: • the empty trace (no activity executed); • a trace containing one instance of accept ads followed by a registration; • an trace containing 5 instances of choose item followed by a close order (in this case, the order is not paid and hence not delivered by the seller). Let us now consider some properties that should be veriﬁed against the ConDec model shown in Fig. 8.4. Query 8.3.1. Is “send receipt” a dead activity? This is a general property, veriﬁed in a universal way. A positive answer to Query 8.3.1 means that send receipt cannot be executed in any possible supported instance. Since getting the receipt represents one of the customer’s business goals, this would probably indicate the presence of a (local) conﬂict. In our example, a veriﬁer should return a negative answer, together with a counterexample, such as: choose item → close order → standard payment → payment done → send receipt. This trace amounts to a proof that send receipt is not dead. Query 8.3.2. Is it possible to complete a transaction under the hypotheses that the customer does not want to receive ads, and the merchant does not oﬀer standard payment? This is a particular domain-dependent property that must be veriﬁed in an existential way. A veriﬁer should return a negative answer. In fact, to complete a transaction the customer must pay, and the only accepted payment modality is, by hypothesis, 1-click payment; however, such a modality is supported only if the customer has previously registered, which in turn requires to accept ads, contradicting the customer’s requirement. Query 8.3.3. It is true of all transactions that with 1-click payment a receipt is always sent after the customer has accepted the ads?

186

8 Static Veriﬁcation of Declarative Open Interaction Models

This is a domain-dependent property, which must be veriﬁed in an universal way. A veriﬁer must discover that the property does not hold: since there is no temporally-ordered constraint associated with accept ads, accept ads is not forced to be executed before send receipt. The existence of an execution trace in which the customer chooses 1-click payment but accepts ads only after having received the receipt amounts to a counterexample against the universal query. More speciﬁcally, a veriﬁer should produce a counterexample like: choose item → close order → register → 1-click payment → payment done → send receipt → accept ads. The outcome of the static veriﬁcation task could consequently lead the designer to improve the model, for example by introducing an explicit precedence constraint from send receipt to accept ads. Query 8.3.4. Is there a transaction with no accept ads, terminating with a send receipt within 12 time units as of close order, given that close order, 1-click payment, and standard payment cause a latency of 6, 3, and 8 time units? This is an existential query with explicit times, used to express minimum and maximum latency constraints on the activities execution. It turns out that the property is unsatisﬁable. Indeed, avoiding the accept ads activity leads to rule out the 1-click payment path, and the standard payment choice takes more than 12 time units. A veriﬁer should therefore return failure.

8.4 A-Priori Compliance Veriﬁcation A special case of property veriﬁcation when the property collects a set of regulations that must be guaranteed by all the execution traces supported by the model (see Fig. 8.5). This task is usually identiﬁed as a-priori compliance veriﬁcation. A typical example is when the model under development represents the Business Process (BP) of an organization, and the property includes the prescriptions of the business contract stipulated with an external stakeholder, such as the customer. Despite the importance of checking the alignment between these two complementary aspects, they are usually kept completely separated [120]. The need of a-priory compliance veriﬁcation has recently grown after the outbreak of high-proﬁle accounting and ﬁnancial scandals such as Enron, WorldCom and Tyco International. New legislation has been produced3 to speciﬁcally target corporate governance, standardization procedures, as well as auditing and compliance requirements and mechanisms, calling for the development of corresponding methodologies and tools. In the ConDec setting, a-priori compliance veriﬁcation takes a model and a set of regulations, checking if the regulations are fulﬁlled by all the execution traces supported by the model. Therefore, it can be reduced to universal entailment. 3

Think for example at the Sarbanes-Oxley Act.

8.5 Composing ConDec Models

187

regulatory model yes A-priori Compliance

model

Verification

no

Fig. 8.5. A-priori compliance veriﬁcation

Deﬁnition 8.4.1 (A-priori compliance with regulations). A ConDec model CM complies with a set of regulations Ψ1 , . . . , Ψn if and only if all the execution traces supported by CM entail each one of the regulations: ∀ i = 1, . . . , n CM |=∀ Ψi It is worth noting that a-priori compliance veriﬁcation does not guarantee that the company will eﬀectively comply, during the execution, with the intended regulations: at run-time, the (autonomous) interacting entities could deviate from the prescriptions of the model, and the presence of behavioral deviations could in turn lead to a fraud or noncompliance. This problem can be tackled by monitoring the behavior of the interacting entities, checking at the same time if they follow the prescriptions of the model as well as the regulations. This topic will be discussed in Chap. 15.

8.5 Composing ConDec Models ConDec could be used to express “local” models, i.e., models covering only a portion of the system under study. For example, a service could expose its behavioral interface by means of a ConDec diagram, expressing its behavioral constraints in a declarative manner. Local models are then composed to realize a joint, complex behavior. When it comes to model composition, two diﬀerent cases may arise: • bottom-up composition; • composition guided by a global (choreographic) model. They are represented in Figs. 8.6a and 8.6b, by focusing on service interaction. In bottom-up composition, the local models are directly composed, trying to build an overall interaction model which combines their constraints. Static veriﬁcation aims here at checking whether the composition can be eﬀectively established. An example of bottom-up composition is the combination of a ticket-reservation and a hotel-booking service in order to obtain an integrated travel management service.

188

8 Static Veriﬁcation of Declarative Open Interaction Models

Fig. 8.6a. Bottom-up composition: local models are directly put together

Fig. 8.6b. Choreography-driven composition: the overall rules of engagement are explicitly captured inside an abstract global model

In choreography-driven composition, there exists a predeﬁned global model (also called choreography) which captures the multiparty rules of engagement that must be fulﬁlled by the local models (see Sect. 2.3.2). It is an abstract speciﬁcation, because its constraints do not predicate over concrete interacting entities, but over abstract roles. The problem is then to ﬁnd a suitable set of local models whose composition is, at the same time, consistent and compliant with the global model. This scenario is widespread in B2B settings, where diﬀerent organizations are interested in cooperating with each other. The cooperation is realized in two steps: 1. the mutual obligations and business constraints of each organization must be made explicit, negotiated and combined, obtaining a choreography model; 2. each organization selects a set of concrete services in order to ﬁll the abstract roles mentioned in the choreography, in a way that the obtained actual composition is not only consistent, but it also satisﬁes choreography prescriptions. 8.5.1 Compatibility between Local Models Checking if two local models can suitably interact is called, in the ConDec setting, compatibility veriﬁcation. Roughly speaking, if two local models are compatible, then there exists at least one course of interaction which is supported by both models. We capture such an intuitive meaning by deﬁning the concept of composite model , obtained by combining the activities and constraints of the local models, and by reducing the compatibility of local models to conﬂict-freedom of the composite one. i , Coi (i = 1, . . . , Deﬁnition 8.5.1 (Composite model). Let CMi = Ai , Cm n) be a set of n ConDec models. The composite model obtained by combining CM1 , . . . , CMn is deﬁned as4 : 4

Note that in [191] the composition operator is denoted by ⊕.

8.5 Composing ConDec Models

comp (CM1 , . . . , CMn )

n

Ai ,

i=1

n

i Cm ,

i=1

n

Coi

189

i=1

Deﬁnition 8.5.2 (Compatibility). Two ConDec models CM1 and CM2 are compatible if their composition is conﬂict-free: comp (CM1 , CM2 ) |=∃ true Obviously, the notion of compatibility can be generalized to the case of n local models. Incompatibility means that a subset of the n local models is conﬂicting. A precise identiﬁcation of the conﬂicting local models would require to build and check all the 2n−1 possible compositions. Compatibility veriﬁcation is the ﬁrst fundamental step in the evaluation of the feasibility of the composition, but it must be followed by the veriﬁcation of further properties, starting from the discovery of dead activities to the evaluation of domain-dependent requirements. The following example points out this issue. Example 8.5.1 (Trivial compatibility). A modeler wants to investigate whether the two models CM1 = a •==• b

CM2 = b •−−• c •−− −− a

can be composed. The two models are compatible, because they both support the empty execution trace. Hence, it would seem that a composition can be actually built. However, let us take a look at the composite model:

comp CM1 , CM2

a

b c

It is apparent that no activity can be executed in the composition: a, b and c are all dead activities. In general, if none of the local models contains goal-oriented ConDec constraints (see p. 51), compatibility always returns a positive answer, because the empty execution trace is supported by all local models. Compatibility veriﬁcation must be therefore followed by further tests, aimed at answering to questions like: “Are all activities of the local models still executable in the composition?”, “Does the composition eﬀectively achieve the business goals which motivated its realization?”, “Does the composition respect the regulations and norms of each involved party?”. These questions can be answered by means of properties veriﬁcation on the global, composite model. For example, an answer to the ﬁrst question could be provided by checking if the composition contains dead activities.

190

8 Static Veriﬁcation of Declarative Open Interaction Models

8.5.2 Augmenting ConDec with Roles and Participants As far as now, local models have been naively composed by combining their activities and constraints. However, there are plenty of cases in which local models do not simply represent a portion of the composition, but carry speciﬁc meaning, due to their partial, subjective view of interaction. Generally speaking, each local model could be considered as a declarative behavioral interface exposed by a component. By adapting the terminology used in ComponentBased Software Engineering [83], the activities contained inside the behavioral interface are split into two parts: • an export interface, including the activities that the component controls and exposes to the outer environment; • an import interface, containing external activities, which are required by the component in order to work correctly, but are not under its control. The external activities must be provided by other components, which are however unknown when the behavioral interface is speciﬁed. Therefore, while the originator of internal activities is the component itself, the originators of external activities cannot be ﬁxed, but only associated to abstract roles. In Sect. 6.3.1, we have proposed to extend ConDec with roles. In order to deal with local behavioral interfaces, we need to further elaborate on this topic, dealing also with ﬁxed originators and augmenting the deﬁnition of ConDec model accordingly. Deﬁnition 8.5.3 (Augmented ConDec model). An augmented ConDec model is a 4-tuple AO, AR, Cm , Co , where: • AO is a set of (a, o) pairs, where a is an activity and “o” represents its originator; they are graphically represented by [o] a • AR is a set of (a, r) pairs, where a is an activity and “r” represents the role of its originator; they are graphically represented by (r) a • Cm is a set of mandatory constraints over AO and AR; • Co is a set of optional constraints over AO and AR. If AR = ∅, the model is concrete, otherwise it is abstract. If AO = ∅ the model is fully abstract. A ConDec local model can be then deﬁned as an augmented abstract model containing also an indication about the identiﬁer of the local model, and in which every activity is associated either to such an identiﬁer (export interface) or to an abstract role (import interface).

8.5 Composing ConDec Models s1 (plays role r1)

191

s2 (plays role r2)

import interface

export interface

(abstract, r2)

(concrete, s2)

import interface

export interface

(abstract, r1)

(concrete, s1)

composite model (concrete, s1 + s2)

Fig. 8.7. Composition of local ConDec models

Deﬁnition 8.5.4 (Local augmented model). A ConDec local augmented model is a 5-tuple id, AO, AR, Cm , Co , where: • • • •

“id” is the identiﬁer of the participant executing the local model; the other elements retain the meaning of Deﬁnition 8.5.3; AR represents the import interface of the model; AO is a set containing only elements of the type (ai , id), and represents the export interface of the model.

The purpose of the composition process is therefore to put a set of abstract local models together, in order to complement the abstract import interface of each local model with a corresponding export interface of another one. Fig. 8.7 gives a graphical intuition of the composition process. When a local model is composed with other local models in order to concretely realize its import interface, then a grounded version of the local model is produced. The new version replaces each abstract role mentioned in the import interface of the original model with the actual identiﬁer of another model playing that role. Deﬁnition 8.5.5 (Grounding of a model). Given an augmented model CMaug = AO, AR, Cm , Co and a function “plays” mapping roles to concrete identiﬁers (i.e., stating that a certain identiﬁer “plays” some role), the grounding of CMaug on “plays” (written CMaug ↓plays ) is obtained by substituting each role ri with the corresponding concrete participant identiﬁer plays(ri ): • AO ↓plays AO ∪ {(a, plays(ri )) | ri ∈ dom(plays) ∧ (a, ri ) ∈ AR}; • AR ↓plays AR/{(a, ri ) |ri ∈ dom(plays)}; • Cm ↓plays and Co ↓plays are updated accordingly.

192

8 Static Veriﬁcation of Declarative Open Interaction Models

Since the purpose of the composition is to obtain an executable model, then all the abstract roles of the involved local models must be ﬁlled by a corresponding identiﬁer, leading to a concrete global model in which AR ↓plays = ∅. Furthermore, to ensure executability, the obtained composition must be conﬂict-free. If both these conditions are met, we say that the composition is legal . Deﬁnition 8.5.6 (Augmented composite model). Given a set of augi , Coi (i = 1, . . . , n) and a function mented local models Li = idi , AO i , ARi , Cm n n " # plays : rj | (rj , aj ) ∈ ARi −→ {idi } i=1

i=1

mapping roles to identiﬁers, the augmented composite model under “plays” is deﬁned as: comp(L1 , . . . , Ln ) ↓plays comp(L1 ↓plays , . . . , Ln ↓plays ) n n n n i ↓plays , AO i ↓plays , ARi ↓plays , Cm Coi ↓plays i=1

i=1

i=1

i=1

Deﬁnition 8.5.7 (Legal composition). Given a set of augmented local i models Li = idi , AO i , ARi , Cm , Coi (i = 1, . . . , n) and a function “plays” mapping roles to identiﬁers, comp(L1 , . . . , Ln ) ↓plays is a legal composition if and only if it is concrete and conﬂict-free. When a legal composite model is ﬁnally obtained, it can be then subject to veriﬁcation of properties, checking whether it is eﬀectively executable and meets the desired global requirements or not. 8.5.3 From Openness to Semi-Openness Since ConDec models are open, they support the execution of activities not contained inside them. While this feature is desirable for ConDec models used in isolation, it must be properly revised when a composition of local models is tackled. Indeed, the combination between openness and the abstract import interface of a local model could cause undesired compositions to be evaluated as correct. The following example clariﬁes this issue. Example 8.5.2 (Composition and openness). Let us consider a composition scenario, in which a customer wants to ﬁnd a suitable e-selling service for establishing an interaction. The customer identiﬁes herself as “c” and comes with an augmented local ConDec model (Lc ) representing her own constraints and requirements. In particular, such constraints express that: • c wants to receive a good from a seller;

8.5 Composing ConDec Models

193

Table 8.1. Four ConDec local augmented models, representing the business constraints of a customer and three candidate sellers identifier

role

local model

notes 1..*

c

[c]

(seller)

pay

send good

customer (seller)

provide guarantee 1..*

s1

(customer)

[s1]

pay

send good

seller

0

cannot emit a guarantee

[s1]

provide guarantee 1..*

s2

(customer)

[s2]

pay

send good

is able to emit a guarantee

seller [s2]

provide guarantee 1..*

s3

seller

(customer)

[s3]

pay

send good

does not mention the emission of a guarantee

• if c pays for a good, then she expects that the seller will deliver it; • before paying, c wants a certiﬁcate guaranteeing that the payment method is secure. The ﬁrst row of Table 8.1 shows the corresponding ConDec diagram. The payment is under the responsibility of c, while the other two activities belong to the import interface of the local model, and are associated to the abstract role of seller. There are three possible candidate sellers for building a composition; their ConDec models are shown in Table 8.1. In particular, all sellers state that before sending a good to the customer, they expect a payment from her. They instead diﬀer for what concerns the emission of a secure-payment guarantee. In particular: • the local model of s1 (L1s ) explicitly states that it does not provide any guarantee;

194

8 Static Veriﬁcation of Declarative Open Interaction Models

• the local model of s2 (L2s ) supports the possibility of providing a guarantee; • the local model of s3 (L3s ) does not mention the possibility of providing a guarantee among its activities. To test wether the three candidates are compatible with her speciﬁcation, leading to a legal composition, the customer ﬁrst builds such three compositions, following Def. 8.5.6. In particular: • with plays1 (customer) = c and plays1 (seller) = s1 1..*

CM1 = comp(Lc , L1s ) ↓plays1 =

[c]

[s1]

pay

send good 0 [s1]

provide guarantee

• with plays2 (customer) = c and plays2 (seller) = s2 1..*

CM2 = comp(Lc , L2s ) ↓plays2 =

[c]

[s2]

pay

send good [s2]

provide guarantee

• with plays3 (customer) = c and plays3 (seller) = s3 1..*

CM3 = comp(Lc , L3s ) ↓plays3 =

[c]

[s3]

pay

send good [s3]

provide guarantee

All the three composite models are concrete. CM1 is however not legal, because it is a conﬂicting model. Indeed, before obtaining the good from s1 , c must pay; before paying, c needs to receive a guarantee from s1 , but s1 cannot perform that operation. CM2 and CM3 are instead both legal. In particular, despite the diﬀerence in the seller’s identiﬁer, the two compositions produce exactly the same global model. The problem is that while the answer obtained from the ﬁrst two compositions is in accordance with the intuitive notion of composition and compatibility, the third one is not: when Lc is composed with L3s , the local model of the customer has the eﬀect of extending the behavior of the seller, introducing a new provide guarantee activity which is not mentioned in the local model of s3 . During the execution, there is no guarantee that the seller will be eﬀectively able to provide a guarantee.

8.5 Composing ConDec Models

195

The issue pointed out in Example 8.5.2 is caused by the fact that the import interface of the customer contains an activity under the responsibility of the seller, but the export interface of the local model of the seller does not mention such an activity. Hence, the openness assumption must be properly revised in order to account for this asymmetry. In particular, to ensure that an augmented composition can be eﬀectively executed, the obtained global model must obey to the following semi-openness requirement: for each local model L involved in the composition, the activities under the responsibility of L must also explicitly appear inside its export interface. We revise the notion of compatibility among augmented local models to deal also with the semi-openness assumption. Deﬁnition 8.5.8 (Strong compatibility). n augmented local models Li (i = 1, . . . , n) are strong compatible under “plays” if and only if their augmented composition CM = comp(L1 , . . . , Ln ) ↓plays obeys to the following properties: • CM is legal (according to Def. 8.5.7); • ∀ (a, idi ), (a, idi ) ∈ AO(CM) =⇒ (a, idi ) ∈ AO(Li ). The latter property states that if a certain activity a has been associated to a participant idi inside the composition, then idi must contain a inside its local model (in particular, inside its export interface). Example 8.5.3 (Example 8.5.2 revisited). Let us examine again the compatibility between the local models of customer c and seller s3 , discussed in Example 8.5.2. The local model of c is: " # " # Lc = (pay, c) , (send good , seller ), (provide guarantee, seller ) , " # existence(1,(send good,seller), . . . , ∅ Due to the application of “plays3 ”, which maps the customer role to c and the seller role to s3 , Lc is transformed to " # Lc ↓plays3 = (pay, c), (send good , s3 ), (provide guarantee, s3 ) , ∅, # " existence(1,(send good,s3), . . . , ∅ The set AO(Lc ) will be included in the composite model CM. Therefore, it holds that AO(CM) (provide guarantee, s3 ). However, the provide guarantee activity is not included in the local model of s3 , i.e., AO(L3s ) (provide guarantee, s3 ). Therefore, the two augmented local models Lc and L3s are not strong compatible.

196

8 Static Veriﬁcation of Declarative Open Interaction Models

8.6 Conformance with a Choreography When there is an explicit choreographic model, the correctness of the global concrete speciﬁcation, obtained by composing a set of local models, does not only require their (strong) compatibility, but must also ensure that the abstract roles mentioned in the choreography are correctly played by such local models. A choreography is represented as an augmented fully abstract ConDec model, i.e., a model whose activities are all associated to abstract roles (see Def. 8.5.3). To verify whether a composition conforms to a desired choreography, two approaches can be followed. The weak approach states that the combination between the composite model and the choreography must be conﬂict free, i.e., there must exists at least one execution trace supported by the composition which also complies with the choreography. Conversely, the strong approach requires that the composition is a reﬁnement of the choreography, i.e., contains the same constraints of the choreography or more tight constraints; in other word, a composition strongly conforms to a choreography if any possible execution trace supported by the composite model is compliant with the choreography. Deﬁnition 8.6.1 (weak conformance). A composition of augmented local models comp(L1 , . . . , Ln ) ↓plays weakly conforms to a choreography model CHOR if and only if: • L1 , . . . , Ln are strong compatible under “plays” (see Deﬁnition 8.5.8); • comp(L1 , . . . , Ln ) ↓plays |=∃ CHOR ↓plays . Deﬁnition 8.6.2 (strong conformance). A composition of augmented local models comp(L1 , . . . , Ln ) ↓plays strongly conforms to a choreography model CHOR if and only if: • L1 , . . . , Ln are strong compatible under “plays” (see Deﬁnition 8.5.8); • comp(L1 , . . . , Ln ) ↓plays |=∀ CHOR ↓plays . It is worth noting that strong conformance strictly resembles the notion of a-priori compliance veriﬁcation introduced in Def. 8.4.1: the overall composition represents the ConDec model under study, while the choreography is a regulatory model. Another interesting point is that, in a declarative setting, the fact that a concrete component, considered in isolation, is not strongly conforming with a choreography, does not imply that a composite model containing that component will be non conforming as well. In fact, the constraints of a local model could be suitably complemented by another local model when building the composition, leading to a strongly conforming global model. The following example clariﬁes this aspect.

8.6 Conformance with a Choreography

197

Example 8.6.1 (Local and global strong conformance). Let us consider a simple choreography model CHOR =

(r1)

(r2)

a

b

and two possible candidate local models: L1 =

[s1]

(r2)

a

b

L2 =

(r1)

[s2]

a

b

Let us also introduce a role mapping function “plays” such that plays (r1 ) = s1 and plays (r2 ) = s2 . By grounding the three models using “plays”, we obtain: L∗1 = L1 ↓plays =

[s1]

[s2]

a

b

L∗2 = L2 ↓plays =

[s1]

[s2]

a

b

CHOR∗ = CHOR ↓plays =

[r1]

[s2]

a

b

Both L∗1 and L∗2 weakly conform to CHOR, because all the three models support the empty execution trace, or the execution trace (a, s1 ) → (b, s2 ). Contrariwise, L∗1 does not strongly conform to CHOR. Indeed L∗1 supports a trace containing one occurrence of (b, s2 ), but this trace is not compliant with CHOR∗ , which would also require a previous occurrence of (a, s1 ). The same holds for L∗2 , because it supports a trace containing only one occurrence of (a, s1 ), and this trace is not supported by CHOR∗ . However, let us build the composite model combining L1 and L2 under “plays”. We obtain G = comp(L1 , L2 ) ↓plays =

[s1]

[s2]

a

b

which strongly conforms to CHOR. In particular, G is a reﬁnement of CHOR∗ , since both models contain a response constraint, but G contains the tighter chain precedence constraint in place of a precedence one. We conclude the section by introducing a ﬁctitious but relevant example, which applies in practice the notions of weak and strong conformance, pointing out their diﬀerence. An important aspect, discussed in the example, is that a correct composition could cover only a portion of the choreography, provided that its local models are strong compatible and (strong) conforming to the choreography.

198

8 Static Veriﬁcation of Declarative Open Interaction Models

(host)

serve tea (guest)

give ungift (host)

serve coffee

Fig. 8.8a. The “unbirthday party” choreography

[hatter]

(guest)

serve tea

give ungift

Fig. 8.8b. Local model of a service playing the host role

Table 8.2. Three candidate guests for realizing the “unbirthday party” choreography, and their composition with the local model of the candidate host, depicted in Fig. 8.8b identifier alice

march hare

composition with hatter

local model (host)

[alice]

serve tea

give ungift

(host)

[march hare]

serve tea

give ungift

Lah =

[hatter]

[alice]

serve tea

give ungift

Lmh =

[hatter]

[march hare]

serve tea

give ungift

[hatter]

(host)

lewis

serve coffee

[lewis]

give ungift

Llh =

serve coffee

[lewis]

give ungift

[hatter]

serve tea

Example 8.6.2 (Weak and strong conformance). An “unbirthday party” choreography UP regulates the interaction between a guest and a host. The simple choreographic model is depicted in Fig. 8.8a, and states that: • when the host serves tea or coﬀee to the guest, the guest must eventually give an “ungift” to the host; • an ungift can be given only if tea or coﬀee have been previously served. Hatter is a possible candidate for playing the host role. His model is shown in Fig. 8.8b. It expresses that hatter is able to serve tea, and after having served tea, he eventually expects to receive an ungift. Table 8.2 shows instead three possible local models of candidate guests: • Alice expresses that she is able to give an ungift only if tea has been previously served; • March hare states that he is able to give an ungift, provided that tea is served either before or afterwards;

8.6 Conformance with a Choreography

199

• Lewis says that he is able to give an ungift only if coﬀee has been previously served. The same table also depicts the composition between these three local models and the one of Hatter (omitting the trivial role mapping function). They are called Lah , Lmh and Llh respectively. Lah strongly conforms to UP, because all its supported execution traces are compliant with the business constraints of the (grounded) choreography. In particular, there is an agreement between the local models of Alice and Hatter: they respectively require and provide the serve tea activity, ﬁxing the “tea or coﬀee” open choice of UP. Lmh does not strongly conform to UP, because March hare does not impose any temporal ordering between the ungift and tea delivery. Therefore, the composition supports an execution trace in which two ungifts are given: one ungift before the execution of serve tea, and a second ungift afterwards. In other words, the following execution trace is supported by the composition: give ungift → serve tea → give ungift. The ﬁrst ungift delivery activity is not preceded by a tea delivery, thus violating a prescription of the choreography. However, Lmh weakly conforms to UP, because it supports a variety of possible executions complying with the choreography. Llh is instead not strongly nor weakly conforming to the choreography, because the local models of Lewis and Hatter are not strong compatible under the role mapping function which establish the correspondences Lewis-guest and Hatter-host. Indeed, independently from UP, the two local models do not agree on the service which must be oﬀered by the host: Hatter supports tea, while Lewis requires coﬀee. As a consequence, Lewis injects into the composition a serve coﬀee activity, which is under the responsibility of Hatter, but Hatter does not include such an activity inside its export interface.

9 Proof Procedures

This chapter introduces two abductive proof procedures for reasoning upon SCIFF (and therefore also CLIMB) speciﬁcations: sciff and g-sciff. The sciff proof procedure checks whether an execution trace complies with a SCIFF speciﬁcation1 , providing a concrete operational framework for: • generating positive and negative expectations starting from a trace and a speciﬁcation; • checking whether the generated expectations are fulﬁlled by the actual occurring events (hypotheses conﬁrmation step). sciff is able reason upon a complete execution trace, or upon a growing trace, by dynamically acquiring and processing occurring events as they happen. The g-sciff proof procedure is a generative extension of sciff which focuses on the veriﬁcation of properties. Starting from a speciﬁcation and a property, it tries to generate an execution trace which is compliant with the speciﬁcation and, at the same time, (dis)conﬁrms the property. It is therefore especially suited for carrying out static veriﬁcation tasks. Thanks to the translation of ConDec into CLIMB presented in Chap. 5, the two proof procedures can be applied to ConDec models. In the following chapters, we will deeply investigate how they can be exploited and combined to tackle all the reasoning capabilities needed to realize the comprehensive support framework presented in Sect. 8.1. Before doing that, we need to provide an overview of both proof procedures, describing how they work and discussing their formal properties. We will focus our attention to the salient aspects, omitting some technical details, that can be found in [8, 58].

1

We will use typewriter to diﬀerentiate the SCIFF proof procedure from the SCIFF language and framework.

M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 201–227, 2010. c Springer-Verlag Berlin Heidelberg 2010

202

9 Proof Procedures

9.1 The SCIFF Proof Procedure sciff is an abductive proof procedure able to verify whether the execution traces of the system under study comply with a SCIFF speciﬁcation. It represents the operational counterpart of the SCIFF declarative semantics (see Sect. 4.3), and of the notion of compliance in particular (see Deﬁnition 4.3.10 – p. 107). Starting from a (partial) execution trace Ti and from a SCIFF speciﬁcation S, sciff is able to dynamically fetch new events and compute abductive explanations for the evolving course of interaction, checking if such abductive explanations are E-consistent and fulﬁlled by the occurred events2 . Hence, sciff concretely realizes the schema depicted in Fig. 4.6 – p. 107: it reacts to the actual event occurrences, produces expectations about the desired courses of interaction, and ﬁnally checks if they are met by the behavior of interacting entities or not. Both the language and declarative semantics of the SCIFF are closely related with the IFF abductive framework [111], and therefore sciff is designed as an extension of the IFF proof procedure. The IFF proof procedure is one of the most well-known abductive proof procedures for reasoning upon speciﬁcations with undeﬁned predicates: it accommodates (backward, goal-oriented) reasoning with deﬁned predicates and (forward, reactive) reasoning with abducible predicates and integrity constraints. Both IFF and sciff are general abductive proof procedures, but sciff is extended to speciﬁcally deal with compliance veriﬁcation in open systems3 . In particular, sciff introduces, in a nutshell, the following features [8]: • sciff supports the dynamic acquisition of events, i.e., the exploitation of new information during the computation; • sciff supports CLP constraints on variables; • sciff supports universally quantiﬁed variables in abducibles and quantiﬁer restrictions [53], in order to properly deal with negative expectations and E-consistency; • sciff supports the concepts of fulﬁllment and violation (see Def. 4.3.9), operationally carried out by means of a “hypotheses conﬁrmation” step in which the generated expectations are checked against the actual trace. 9.1.1 Fulﬁlled, Violated and Pending Expectations When reasoning on a partial execution trace, sciff cannot always provide a deﬁnitive answer concerning the fullﬁllment of expectations. For example, 2

3

Remember that E-consistency is guaranteed when expectations are not contradictory, i.e., there does not exist an event occurrence expected and forbidden at the same time. Fulﬁllment instead requires that each positive expectation has a corresponding event occurrence inside the execution trace, and that negative expectations do not match with any event occurrence. This is suggested by the name itself: SCIFF stands for Social Constrained IFF.

9.1 The SCIFF Proof Procedure

203

a currently violated positive expectation E(exec(serve coﬀee), T ) could be fulﬁlled by the future course of interaction, if the coﬀee is eventually served. In sciff, this transient state is captured by the notion of pending expectation: a pending expectation is an expectation which cannot be currently evaluated as fulﬁlled nor violated. Pending expectations therefore account for the threevalued semantics of sciff. As soon as an expectation is generated, it is considered as pending. sciff then modiﬁes such a status by combining the expectation with the events occurred so far, keeping the evaluation “suspended” until a deﬁnitive answer can be computed. In particular, the fulﬁllment of pending positive expectations can be evaluated during the execution: as soon as an event matching with the expectation occurs, the expectation can be considered as fulﬁlled4 . Conversely, if a positive expectation is still pending when the execution reaches its end, then no further event will occur to fulﬁll it, and therefore it becomes violated. Negative expectations are treated in the opposite way. As soon as an event, matching with a pending negative expectation, occurs, the negative expectation becomes violated. If a negative expectation remains pending until the end of the execution, then it is ﬁnally considered fulﬁlled, because no further event will happen to violate it. As we will see, this behavior can be properly tuned depending on the application domain. For example, if it is guaranteed that events always occur in ascending order, then the violation (fulﬁllment) of a positive (negative) expectation equipped with a deadline can be detected at the deadline time. Conversely, when ordering is not guaranteed, their deﬁnitive evaluation must be postponed until the execution terminates. Finally, sciff constantly monitors the E-consistency of pending expectations: as soon as two contradictory expectations are generated, the current computation fails. 9.1.2 Data Structures and Proof Tree As in the case of IFF, sciff is based on a rewriting system which transforms one node into a successor node or a set of successor nodes by applying transitions. Each node captures the actual instantiations of integrity constraints in response to event occurrences, as well as the sets of currently pending, violated and fulﬁlled expectations. Transitions represent either the reaction to an event occurrence or a reasoning step autonomously carried out by the proof procedure. Each transition is characterized by a set of preconditions which determine whether the transition is ﬁreable or not, and by a set of eﬀects which will hold after the transition is eﬀectively chosen by the search strategy of sciff. 4

As we will see, such a fulﬁllment is however non deterministic: a further event occurrence which also matches with the expectation could be generated afterwards, and sciff must take into account also this second possibility.

204

9 Proof Procedures

Deﬁnition 9.1.1 (sciff node and computed abductive explanation). A SCIFF node is a tuple R, CS, psIC, T , ΔA , ΔP , ΔF , ΔV , where: • R is the resolvent, i.e., (a disjunction of ) conjunctions of literals – in CLIMB, literals are positive/negative expectations and predicates deﬁned in the knowledge base of the speciﬁcation; • CS is the constraint store, containing CLP constraints and quantiﬁer restrictions; • psIC is a set of partially solved integrity constraints (PSICs), i.e., instantiations of rules whose body has partially matched with occurred events; • T is the currently fetched (partial) execution trace; • ΔA is the set of abduced predicates but expectations, which are treated separately – in CLIMB, expectations are the only abducible predicates, hence ΔA is always empty; • ΔP , ΔF and ΔV respectively represent the set of pending, fulﬁlled and violated expectations. The abductive explanation computed in the node is the set Δ of all abduced atoms: Δ = ΔA ∪ ΔP ∪ ΔF ∪ ΔV . When at least one element of the node contains ⊥, then the node is a failure node, and the whole tuple is rewritten as ⊥. A failure node does not have successors. Deﬁnition 9.1.2 (Initial node). Given a SCIFF speciﬁcation S = KB, A, IC and an execution trace T , the initial node for the instance ST is I(ST ) = true, ∅, IC, T , ∅, ∅, ∅, ∅. Deﬁnition 9.1.3 (Derivation). Given a SCIFF speciﬁcation S and an initial execution trace Ti , a derivation is a sequence of nodes I(STi ) → N1 → . . . → Nn , where: • nodes N1 , . . . , Nn are obtained by applying the transitions listed in Sect. 9.1.3; • Nn is a node in which no transition is applicable, i.e., Nn is a quiescent node. If the initial execution trace is not explicitly mentioned, it is assumed to be empty. In general, several transitions can be applied by sciff on a given node. For example, when an integrity constraint contains two disjuncts in its head, both possibilities must be investigated. Therefore, starting from an initial node, the rewriting system builds a proof OR-tree, where each leaf node is a quiescent node. In turn, a quiescent node is either the special failure node ⊥ or a succcess node. If at least one success leaf node exists, then sciff has a successful derivation. Deﬁnition 9.1.4 (Success node). Given a SCIFF speciﬁcation S = KB, IC and a (ﬁnal) execution trace Tf , a success node for STf has the form S(STf ) = true, CS, psIC, Tf , ΔA , ∅, ΔF , ∅, where CS is consisent. S(STf ) has a true resolvent and does not contain pending nor violated expectations.

9.1 The SCIFF Proof Procedure

205

Deﬁnition 9.1.5 (sciff successful derivation). Given a SCIFF speciﬁcation S, an initial execution trace Ti and a ﬁnal execution trace Tf such that Ti ⊆ Tf , there exists a successful derivation for STf starting from Ti 5 if and only if the proof tree with root node I(STi ) has at least one leaf success node of T the form S(STf ). In this case, we write STi Δf true, where Δ is the abductive explanation computed in S(STf ) (according to Def. 9.3.1). It is worth noting that abducibles in Δ may contain variables, i.e., sciff computes intensional abductive explanations, while the declarative semantics is given for ground explanations. We have discussed the meaning of intensional abductive explanations in Sect. 4.3, but brieﬂy recall their intuition here, for the sake of readability. Roughly speaking, variables contained in positive expectations are existentially quantiﬁed, whereas variables contained in negative expectations are universally quantiﬁed (unless they also appear in a positive expectation). Therefore, the relationship between computed explanations and the corresponding ground abductive explanations is that: • An abducible containing universally quantiﬁed variables intensionally represents the (possibly inﬁnite) abducibles that are obtained by grounding such variables in all possible ways, while respecting the constraints contained in the constraint store. For example, supposing that the time structure is (N, <), EN(e, T ) ∧ T > 9 intensionally represents the inﬁnite set {EN(e, 10), EN(e, 11), EN(e, 12), . . .}. • An abducible containing existentially quantiﬁed variables intensionally represents one among the possible abducibles obtained by choosing a grounding that respects the constraints contained in the constraint store6 . For example, supposing that the time structure is (N, <), E(e, T ) ∧ T > 2 ∧ T ≤ 5 intensionally represents one among E(e, 3), E(e, 4) and E(e, 5). 9.1.3 Transitions We brieﬂy recall the (most relevant) transitions applied by sciff; for a complete technical description of all transitions see [8]. Transitions represent the application of inference rules to transform a node into a set of possible successor nodes, until quiescence is reached. sciff adapts all the inference rules 5

6

Without loss of generality, it can be assumed that Ti = ∅. As we will see, reasoning starting from a trace Ti is equivalent as starting from the empty trace and applying a sequence of happening transitions for “importing” all the happened events contained in Ti . If the constraint solver is (theory) complete [137], then for each set of constraints c, the solver always returns true or false, and never unknown. This means that there will always exist, for each success node, a substitution σ grounding such existential variables. Conversely, if the solver is incomplete, σ may not exist. The non existence of σ would be in this case discovered during the grounding phase, leading to mark the node as a failure node.

206

9 Proof Procedures

developed for IFF [111] and introduces further transitions, in order to deal with dynamically growing execution traces, and to check E-consistency and fulﬁllment. Furthermore, being SCIFF equipped with CLP constraints, also the transitions of the underlying CLP solver [135] are incorporated. A description of the transitions inherited from IFF follows. Each transition is described supposing its application on a generic node Nk . Propagation Given a partially solved integrity constraint H(Ev1 , T1 ) ∧ Body → Head ∈ psIC k and a happened event H(Ev2 , T2 ) ∈ Tk that uniﬁes with H(Ev1 , T1 ), part of the PSIC can match with this happened event. sciff propagates such a possibility by generating a new child node Nk+1 in which the rule H(Ev1 , T1 ) ∧ Body → Head is copied, obtaining a rule H(Ev1 , T1 ) ∧ Body → Head7 ; the copy is then modiﬁed by removing H(Ev1 , T1 ) from its body and by inserting an equality constraint between the two elements8 . Therefore, psIC k+1 = psIC k ∪ { E1 = E2 ∧ T1 = T2 ∧ Body → Head } The original rule must be kept inside psIC k+1 because happened events belonging to the body of a (partially solved) integrity constraint are universally quantiﬁed with scope the entire rule. As a consequence, a further occurring event matching with H(Ev1 , T1 ) would trigger a new, separate propagation on the original rule. Case analysis If the body of a partially solved integrity constraint of psIC k contains an equality constraint A = B, case analysis deals with such an equality constraint generating two child nodes: 1. in the ﬁrst node, sciff hypothesizes that the equality A = B holds9 ; 2. in the second node, sciff hypothesizes that the equality constraint does not holds, i.e., it assumes A = B. A similar behavior is exhibited when another kind of CLP constraints is encountered.

7 8 9

A copy is obtained by taking into account each constitutive element of the constraint, renaming its variables. Equality will be then handled by the case-analysis transition. Uniﬁcation is then handled by the underlying constraint solver, taking into account the variables quantiﬁcation as well as their attached CLP constraints and restrictions.

9.1 The SCIFF Proof Procedure

207

Logical equivalence When the body of a PSIC is true in psIC k , i.e., PSIC = true → Head ∈ psIC k , then a new child node is generated, where PSIC is removed from psIC k and Head is added to the resolvent: psIC k+1 = psIC k /{true → Head} Rk+1 = Rk ∧ Head The resolvent is then rearranged as a disjunction of conjunctions. Unfolding When a predicate p deﬁned in the knowledge base of the speciﬁcation is encountered by sciff, sciff unfolds it by considering its deﬁnitions. sciff could encounter p in two diﬀerent situations: 1. sciff selects p from the resolvent Rk . In this case, the possible deﬁnitions of p are considered in a disjunctive manner, inserting into the new resolvent a disjunct for each deﬁnition of the predicate. The resolvent is then rewritten as a disjunction of conjunctions For example, supposing that Rk = D1 ∨ D2 ∨ (D3 ∧ p), and that the knowledge base of the speciﬁcation contains the two clauses p ← q and p ← r, the application of unfolding will produce: Rk+1 = D1 ∨ D2 ∨ (D3 ∧ q) ∨ (D3 ∧ r) 2. The body of a PSIC in psIC k contains a predicate deﬁned in the knowledge base. Here, all the possible deﬁnitions must be simultaneously taken into account, and therefore sciff generates a unique child node which contains as many copies of the PSIC as the number of deﬁnitions of the predicate; each copy substitutes the predicate with one of its deﬁnitions. For example, supposing that the knowledge base of the speciﬁcation contains the two clauses p ← q and p ← r, and that p ∧ Body → Head ∈ psIC k , the application of unfolding will produce: psIC k+1 = (psIC k /{p ∧ Body → Head}) ∪ {q ∧ Body → Head, r ∧ Body → Head} Abduction When sciff extracts an abducible predicate from Rk , it hypothesizes it (i.e., makes it true). In the successor node, the predicate is removed from the resolvent, and is inserted: • into ΔA k+1 , if it is a generic abducible; • into ΔP k+1 , if it is an expectation (i.e., the expectation becomes pending).

208

9 Proof Procedures

Splitting If the resolvent of the current node contains a disjunction (Rk = A ∨ B), a choice point is opened by sciff. More speciﬁcally, two candidate child 1 2 and Nk+2 are generated, each one containing only one of the two nodes Nk+1 1 2 disjuncts: Rk+1 = A and Rk+1 = B.

The following transitions are peculiar to sciff, and are introduced to handle • • • •

the dynamic acquisition of happened events; CLP constraints; E-consistency; fulﬁllment and violation of expectations.

CLP transitions sciff embeds all the transitions of CLP [135]. A further set of speciﬁc inference rules is also included to the aim of handling universally quantiﬁed variables and their interaction with existentially quantiﬁed variables, taking into account the involved CLP constraints and quantiﬁer restrictions. Just to cite an example, an inequality constraint A = B is replaced with ⊥ if A is a universally quantiﬁed unconstrained variable. Happening This transition takes a new event occurrence H(Ev, T ) from an external event queue and generates a successor node, in which H(Ev, T ) is inserted into the execution trace: Tk+1 = Tk ∪ {H(Ev, T )}. Closure Closure can be applied only when no other transition is applicable. It is used to hypothesize that the instance has reached its termination, i.e., that no further event will occur. Therefore, closure makes a Closed World Assumption (CWA, [200]) on the execution trace, imposing that if an event occurrence is not contained in the trace, then it will never happen. Hence, closure makes it possible to evaluate all the expectations which are still pending. In the general case, this transition is applied non-deterministically: it generates two child nodes, where the ﬁrst child makes the closure hypotheses, while the second child makes the opposite hypothesis, i.e., it assumes that further events could still occur. When the execution trace has eﬀectively reached its termination, closure is applied deterministically, and only the ﬁrst child node is generated. In order to inform sciff that the trace is complete, a ﬂag must be set by the user. Such a ﬂag is usually set when a special complete event occurrence is extracted from the external queue by the happening transition.

9.1 The SCIFF Proof Procedure

209

Times update This is a special transition enabled only by an explicit request from the user, and that exhibits a correct behavior only if events always occur in ascending order. In other words, it can be exploited only if there is the guarantee that each time an event occurrence is acquired, it is associated to a time T which is greater or equal than the ones of happened events already contained in the current execution trace. If this assumption holds, then the time variables associated to pending positive expectations can be updated: if they have not fulﬁlled so far, then their fulﬁllment time is surely greater or equal than T . In particular, times update operates as follows: 1. it selects the maximum time tMAX contained in the current execution trace, i.e., tMAX = max{t | H(ev, t) ∈ Tk }; 2. it introduces a set of CLP constraints stating that ∀ E(Ev, T ) ∈ ΔP k , CSk+1 T ≥ tMAX

E-violation Violation of a positive expectation can be determined only if no matching happened event is contained in the current execution trace, nor it is possible that such a matching occurrence will be acquired in the future. In particular, let us suppose E(Ev, T ) ∈ ΔP k ; E(Ev, T ) is violated if either: 1. The closure transition has been previously applied to the derivation containing Nk ; in fact, closure states that no further events will occur. 2. The times update transition has been applied, and T is associated to an expired deadline; in this case, the violation is caused by the combination of the CLP constraint expressing the deadline and the one imposed by times update. If one of such conditions hold, transition E-violation is applied. It has the eﬀect of moving the involved expectation from the set of pending expectations to the set of violated expectations: ΔP k+1 = ΔP k /{E(Ev, T )} ΔV k+1 = ΔV k ∪ {E(Ev, T )}

E-fulﬁllment It tries to fulﬁll a currently pending expectation, say, E(Ev1 , T1 ) ∈ ΔP k , with an occurred event, say, H(Ev2 , T2 ) ∈ Tk . To do so, it generates two child 1 2 and Nk+2 . nodes, Nk+1

210

9 Proof Procedures

1 In Nk+1 , sciff hypothesizes that the expectation is fulﬁlled by the happened event, consequently imposing a matching between the two:

ΔP k+1 = ΔP k /{E(Ev1 , T1 )} ΔF k+1 = ΔF k ∪ {E(Ev1 , T1 )} CSk+1 = CSk ∪ {Ev1 = Ev2 ∧ T1 = T2 } 2 Contrariwise, in Nk+1 , a sort of case-analysis is applied, stating that the happened event does not match with the expectation:

ΔP k+1 = ΔP k ΔF k+1 = ΔF k CSk+1 = CSk ∪ {Ev1 = Ev2 ∨ T1 = T2 } The two alternatives must be both exploited due to completeness reasons: there could be, in the future, a further event occurrence which also matches with the expectation, and such a second possibility must not be ignored by sciff. EN-violation Symmetrically to E-fulﬁllment, EN-violation investigates whether an acquired event occurrence violates a pending negative expectation. In particular, when EN(Ev1 , T1 ) ∈ ΔP k and H(Ev2 , T2 ) ∈ Tk , EN-violation generates two 1 2 child nodes Nk+1 and Nk+1 . 1 In Nk+1 , it hypothesizes that the happened event matches with the negative expectation, leading to a violation: ΔP 1k+1 = ΔP k /{EN(Ev1 , T1 )} ΔV 1k+1 = ΔV k ∪ {EN(Ev1 , T1 )} 1 = CSk ∪ {Ev1 = Ev2 ∧ T1 = T2 } CSk+1 2 Conversely, in Nk+1 a sort of case-analysis is applied, hypothesizing that the happened event does not match with the expectation, and consequently keeping the expectation pending:

ΔP 2k+1 = ΔP k ΔV 2k+1 = ΔV k 2 CSk+1 = CSk ∪ {Ev1 = Ev2 ∨ T1 = T2 }

The constraint store will then handle the whole set of equality and inequality constraints, taking into account how Ev1 and T1 are quantiﬁed. For example, it could be the case that, despite the fact that T1 belongs to a negative expectation, it is existentially quantiﬁed (typically, because it also appears in a positive expectation). If it is the case, case-analysis is necessary.

9.1 The SCIFF Proof Procedure

211

On the contrary, if both Ev1 and T1 are universally quantiﬁed, the con2 with ⊥, straint solver will substitute the two inequalities imposed in CSk+1 leading to label the node as a failure node; in this case, violation is therefore deterministic. EN-fulﬁllment Symmetrically to E-violation, the fulﬁllment of a pending negative expectation EN(Ev, T ) ∈ ΔP k can be ensured either . . . 1. After the closure transition, if no event in the execution trace matches with the negative expectation, i.e., ∀ Ev2 ∀ T2 , H(Ev2 , T2 ) ∈ Tk ⇒ (Ev, T ) does not unify with (Ev2 , T2 ) In this case, no further event will occur, hence the expectation cannot be violated anymore. 2. After a times update transition, if the negative expectation is associated to an expired deadline, and no event happened before the deadline matched with the negative expectation. If one of these preconditions holds, the transition moves the negative expectation from the set of pending expectations to the set of fulﬁlled expectations: ΔP k+1 = ΔP k /{EN(Ev, T )} ΔF k+1 = ΔF k ∪ {EN(Ev, T )}

Consistency This transition encapsulates the veriﬁcation of E-consistency of the current computed explanation, ensuring that it does not contain two contradictory expectations. It is worth noting that, from the compliance point of view, this is a redundant transition: the contemporary presence of a positive and negative expectation concerning the same event would surely lead to a failure independently of E-consistency, because an execution trace cannot fulﬁll two contradictory expectations. Anyway, it has the positive eﬀect of pruning the proof tree, anticipating the detection of such a kind of violation. To check E-consistency, sciff implicitly augments each speciﬁcation with the following integrity constraint10 : E(X, T ) ∧ EN(X, T ) → ⊥. 10

(ICconsistency )

Such constraint cannot be expressed in CLIMB. Anyway, it does not undermine the formal properties of CLIMB, because it contains only a “⊥” in its head.

212

9 Proof Procedures

If two contradictory expectations exist, then sciff infers ⊥, and the current derivation fails. It is worth noting that when a positive and a negative expectation matches with such an integrity constraint, case analysis is applied. In this way, sciff restricts the domains of the variables contained in the positive expectation so as to guarantee E-consistency. Example 9.1.1 ( E-consistency). Let us consider a sciff derivation which is currently focused on node Nk , having: ΔP k {E(exec(a), T ), EN(exec(a), T2 )} CSk {T > 4, T2 > 8} sciff reasons upon Nk by applying a combination of case analysis and consistency. In particular, it tests whether the two expectations match with the antecedent of (ICconsistency ), investigating both possibilities. If the two expectations actually match, (ICconsistency ) is triggered, leading to a failure node. Contrariwise, matching is avoided; this is actually one by attaching further constraints to T . In particular, the constraint store will infer that T ≤ 8. This inference step must be read as: to have an E-consistent explanation, the positive expectation must be fulﬁlled by executing activity a after time 4 and before or at 8.

We conclude this section by brieﬂy discussing how sciff eﬀectively works when reasoning upon a simple instance. Example 9.1.2 (A sciff derivation). Let us consider the CLIMB speciﬁcation S = ∅, {IC = H(a, Ta ) → E(exec(b), Tb ) ∧ Tb > Ta .} and the execution trace Ti = {H(exec(a), 5), H(exec(b), 10)}. It is supposed that Ti represents a complete course of interaction, hence the dynamic acquisition of new event occurrences is not exploited. Let us brieﬂy recall how the transitions of sciff are applied in order to prove that such a trace is compliant with S. The entire proof tree, as it is produced at the end of the computation, is shown in Fig. 9.1. For the sake of simplicity, some transitions are collapsed. N1 ) sciff starts from the root node I(S, Ti ), characterized by: • a true resolvent; • a set of partially solved integrity constraint corresponding to the one of S (i.e., psIC 1 = {IC}); • an execution trace equal to Ti . N2 ) sciff applies propagation, because H(exec(a), 5) ∈ T1 can match with the body of IC. A successor node is generated, in which a copy of IC is inserted, removing the old body and inserting the equality constraint between T and 5: psIC 2 = {IC} ∪ {Ta = 5 → E(exec(b), Tb ) ∧ Tb > Ta .}

9.1 The SCIFF Proof Procedure

213

N3 ) The equality constraint Ta = 5 is subject to case analysis, leading to effectively impose the matching inside the constraint store, or to disconﬁrm it, asserting the constraint Ta = 5. This second successor node is evaluated as a failure node by the constraint solver, because Ta is a universally quantiﬁed variable and must therefore necessarily unify with 5. The ﬁrst choice is instead consistent, and leads to generate a successor node in which the constraint store is properly extended with the equality constraint, and the body of the aﬀected partially solved integrity constraint is consumed: CS3 = {Ta = 5} psIC 3 = {IC} ∪ {true → E(exec(b), Tb ) ∧ Tb > 5.} N4 ) Since psIC 3 contains a partially solved integrity constraint whose body is true, transition logical equivalence is applied, removing such an integrity constraint from the set, and adding its expectation to the resolvent. Furthermore, the CLP constraint attached to the expectation is inserted into the constraint store: psIC 3 = {IC} CS4 = {Ta = 5, Tb > 5} R4 = {E(exec(b), Tb )} The assertion of the Tb > 5 CLP constraint leads to reduce the domain of Tb to (5, ∞). The constraint is then kept suspended. N5 ) Abduction moves the expectation from the resolvent to the set of pending expectations: psIC 5 = {IC} CS5 = {Ta = 5 ∧ Tb > 5} R5 = true ΔP 5 = {E(exec(b), Tb )} N6 ) The second happened event in the trace is able to fulﬁll the pending expectation. Therefore, sciff applies E-fulﬁllment generating two possible successor nodes. N6a ) In the ﬁrst successor, the pending expectation matches with the occurrence of b contained in T5 , leading to insert Tb = 10 into the constraint store, and to move the expectation from the set of pending expectations to the set of fulﬁlled ones. Since no further event is present in the external queue, the execution can be then declared as closed. transition closure is thus applied deterministically, and a success node is reached, because no expectation is violated, the resolvent is true and the constraint store is consistent (indeed, Tb = 10 awakes Tb > 5, which becomes true).

214

9 Proof Procedures

N6b ) In the second successor, the matching between the pending expectation and the occurrence of b at time 10 is forbidden. This is done by imposing the CLP constraint Tb = 10. sciff then waits for a further happened event able to fulﬁll the pending expectation. However, there is no such event, and the execution is ﬁnally declared as closed. Transition closure and E-violation are applied in sequence, because the expectation cannot be fulﬁlled anymore. sciff has therefore a single successful derivation , characterized by the computed abductive explanation Δ = {E(exec(b), 10)}. If the trace given in input had included also a further event H(exec(b), 15), then the derivation through node N6b would have led to a successful derivation as well, with Δ = {E(exec(b), 15)}. In fact, this extended trace includes two executions of activity b, and both executions are good candidates for fulﬁlling the triggered expectation.

9.2 Formal Properties of the SCIFF Proof Procedure The two formal properties of soundness and completeness have been proven for sciff. Fig. 9.2 depicts how such two properties relate the notion of sciff derivation with the one of compliance. The combination of soundness and completeness guarantees that sciff produces always a correct answer. Furthermore, sciff guarantees also termination, provided that the speciﬁcation under study obeys to certain syntactic restrictions. We brieﬂy recall these fundamental formal results. The proofs of all theorems can be found in [8]. 9.2.1 Soundness Generally speaking, a logic-based system meets the soundness property if its inference rules prove only formulae valid with respect to its declarative semantics. In other words, soundness requires that every formula derived from a given theory by applying the inference rules is also entailed by (i.e., is a logical consequence of) the theory. In the context of SCIFF, soundness states that whenever sciff has a successful derivation (Def. 9.1.5) for an instance ST , then T is compliant with S according to Def. 4.3.10. Theorem 9.2.1 (Soundness of sciff). Given an arbitrary SCIFF instance ST , it holds that S∅

T Δ

true =⇒ compliant (ST )

Proof. See [8].

9.2 Formal Properties of the SCIFF Proof Procedure

215

I(S, Ti ) T1 R1 CS1 psIC 1

= = = =

Ti true ∅ {IC}

ΔP 1 ΔF 1 ΔV 1 ΔA1

= = = =

∅ ∅ ∅ ∅

propagation

T2 R2 CS2 psIC 2

T3 R3 CS3 psIC 3

= = = =

= = = =

Ti true ∅ {IC, Ta = 5 → E(exec (b) , Tb ) ∧ Tb > Ta .} >> >> T =5 case analysis Ta =5 >> a >> > ⊥ Ti ΔP 3 = ∅ true ΔF 3 = ∅ {Ta = 5} ΔV 3 = ∅ {IC, true → E(exec (b) , Tb ) ∧ Tb > 5.} ΔA3 = ∅

ΔP 2 ΔF 2 ΔV 2 ΔA2

= = = =

∅ ∅ ∅ ∅

logical equivalence and constraint solver

T4 R4 CS4 psIC 4

= = = =

Ti E(exec (b) , Tb ) {Ta = 5, Tb > 5} {IC}

ΔP 4 ΔF 4 ΔV 4 ΔA4

= = = =

∅ ∅ ∅ ∅

abduction

Ti ΔP 5 = {E(exec (b) , Tb )} true ΔF 5 = ∅ {Ta = 5, Tb > 5} ΔV 5 = ∅ {IC} ΔA5 = ∅ ?? E-fulﬁllment Tb =10 ???Tb =10 ?? ?? =∅ T6b = Ti ΔP 6b R6b = ⎧ = {E(exec (b) , 10)} true ⎫ ΔF 6b ⎨ Ta = 5, ⎬ T = 10, CS6b = =∅ ΔV 6b ⎩ b ⎭ Tb > 5 =∅ ΔA6b psIC 6b = {IC}

T5 R5 CS5 psIC 5

T6a = Ti ΔP 6a R6a = true ⎧ ⎫ ΔF 6a ⎨ Ta = 5, ⎬ T = 10, CS6a = ΔV 6a ⎩ b ⎭ 10 > 5 ΔA6a psIC 6a = {IC}

= = = =

closure

SUCCESS

= {E(exec (b) , Tb )} =∅ =∅ =∅

closure and E-violation

⊥(ΔP 6b = ∅)

Fig. 9.1. Proof tree computed by sciff when verifying compliance of the CLIMB instance illustrated in Example 9.1.2

9.2.2 Completeness A logic-based system is complete if its inference rules are able to prove all formulae that are valid under its declarative semantics. In other words, every logical consequence of a given theory is also derived by the inference rules. In the SCIFF setting, completeness states that for each compliant instance ST , sciff has a successful derivation for S starting from the empty trace and leading to T . By contraposition, completeness ensures that a failure of the proof procedure attests that T is not compliant with S. Theorem 9.2.2 (Completeness of sciff). Given an arbitrary SCIFF instance ST , it holds that compliant (ST ) =⇒ S∅ TΔ true

216

9 Proof Procedures

CLIMB Instance STR lll RRRinterpretation RRR l speciﬁcation l RRR ll RRR lll lll Syntax Semantics sciff Proof Procedure ()

S∅ TΔ true o

soundness

/

(|=) Logical Entailment

compliant (ST )

completeness

Fig. 9.2. Soundness and completeness in sciff

Proof. See [8].

9.2.3 Termination A logic-based system meets the termination property if every derivation produced by applying its inference rules is ﬁnite. First Order Logic (FOL) does not always guarantee termination when proving if a certain formula is entailed by a theory. In particular, given a provable sentence, a successful derivation will be always generated in ﬁnite time, but when the sentence is not provable, the application of the inference rules may run forever. This issue is known as semidecidability. Fortunately, decidable fragments of FOL, i.e., fragments which guarantee termination, can be found. SCIFF is based on a fragment of FOL which is semi-decidable. Indeed, it is an extension of logic programming, which is usually based on the semidecidable theory of Horn clauses. As a consequence, suitable restrictions of the SCIFF language are needed to guarantee termination. In particular, these restrictions stem from the acyclicity conditions, ﬁrst introduced by Apt and Bezem [19] for guaranteeing the termination of a logic program. Roughly speaking, acyclicity imposes the absence of loops in a logic program, i.e., it requires that if predicate p is deﬁned in terms of q, then q cannot be (directly nor indirectly) deﬁned by means of p. In presence of a cyclic knowledge base such as q ← p, p ← q, sciff would run forever when it encounters p: it would inﬁnitely unfold p in terms of q, then q in terms of p, and so on. The acyclicity conditions deﬁned in [19] suﬃces for the knowledge bases of SCIFF. However, SCIFF also involves integrity constraints, and is tailored to Abductive Logic Programming. the acyclicity conditions must be therefore extended to cover also the integrity constraints, as pointed out by Xanthakos [267]. More speciﬁcally, Xhantakos deﬁned a set of extended acyclicity conditions to guarantee termination of the IFF proof procedure. These conditions hence seamlessly hold for sciff.

9.2 Formal Properties of the SCIFF Proof Procedure

217

We brieﬂy recall the extended acyclicity conditions deﬁned in [267]11 , showing that they are always met when formalizing ConDec. Deﬁnition 9.2.1 (Level mapping). Let P be a logic program. A Level mapping for P is a function which maps ⊥ to 0 and each ground atom in BP to a positive integer: | · | : BP −→ N/{0} where BP is the Herbrand base of P. Given A ∈ BP , |A| denotes the level of A. Deﬁnition 9.2.2 (Boundedness). Given a level mapping | · |, a literal L is bounded with respect to | · | if and only if | · | is bounded on the set of ground instances of L. In this case, we assume |L| max{|Lg | such that Lg is a ground instance of L} Deﬁnition 9.2.3 (Acyclic knowledge base). Given a knowledge base KB, a clause C ∈ KB is acyclic with respect to the level mapping | · | if, for every ground instance H ← B1 ∧ . . . ∧ Bn of C, it holds that: ∀ i ∈ [1, . . . , n], |H| > |Bi | The entire KB is acyclic with respect to | · | if all its clauses are. KB is called acyclic if it is acyclic with respect to some level mapping. Deﬁnition 9.2.4 (Acyclic SCIFF speciﬁcation). A SCIFF speciﬁcation S = KB, A, IC is acyclic with respect to | · | if and only if: 1. KB is acyclic with respect to | · |; 2. each IC ∈ IC is acyclic with respect to | · |, i.e., for each ground instance B1 ∧ . . . ∧ Bn → H1 ∨ . . . ∨ Hm of IC, it holds that ∀ i ∈ [1, . . . , n] ∀ j ∈ [1, . . . , m], |Bi | > |Hj |. S is called acyclic if it is acyclic with respect to some level mapping. The following theorem states that sciff is guaranteed to terminate the computation if the speciﬁcation under study is acyclic and bounded. Theorem 9.2.3 (Termination of sciff). Given a SCIFF instance ST , if S = KB, IC is acyclic and all the literals occurring in KB and IC are bounded, then every sciff derivation for ST is ﬁnite. Proof. See [8]. 11

For the sake of simplicity, we do not discuss here the case of negated literals; the interested reader is referred to [267].

218

9 Proof Procedures

9.2.4 ConDec and Termination of the SCIFF Proof Procedure In Chap. 5, we have shown how CLIMB can be successfully adopted for formalizing ConDec. In particular, we have deﬁned, in Sect. 5.1, the tCLIMB translation function, which takes a ConDec model and produces the corresponding CLIMB representation. The syntax of CLIMB corresponds to a fragment of the SCIFF one, and the CLIMB speciﬁcations produced by tCLIMB are an even smaller fragment, because they always have an empty knowledge base. An important question then arises: is termination always guaranteed for such fragments? This question is especially critical for the tCLIMB case, because a negative answer would require to introduce restrictions on the graphical speciﬁcations produced by a human modeler. Fortunately, termination is always guaranteed for this fragment. Theorem 9.2.4 (sciff terminates when reasoning upon ConDec speciﬁcations). Given a ConDec model CM, sciff is guaranteed to terminate when reasoning upon tCLIMB (CM). Proof. We prove that tCLIMB (CM) = ∅, IC is acyclic and bounded by deﬁning a suitable, generally valid level mapping. Since the knowledge base obtained by applying tCLIMB is always empty (see Def. 5.1.1, p. 116), it is acyclic. Furthermore, all integrity constraints belonging to IC contain only happened events in their body, and expectations in their head. Hence, the following level mapping can be established: 1. for each ground happened event H(e, t), |H(e, t)| = 2; 2. for each ground positive expectation E(e, t), |E(e, t)| = 1; 3. for each ground negative expectation EN(e, t), |EN(e, t)| = 1. From Deﬁnitions 9.2.2 and 9.2.4, it holds that tCLIMB (CM) is acyclic and bounded with respect to such a level mapping and, from Theorem 9.2.3, termination is therefore guaranteed. It is worth noting that the two properties of acyclicity and boundedness continue to hold even by considering the further integrity constraint E(X, T ) ∧ EN(X, T ) → ⊥, implicitly introduced by the consistency transition of sciff. When reasoning upon ConDec++ models or, more generally, upon CLIMB speciﬁcations, the level mapping proposed in the proof of Theorem 9.2.4 is still valid for the integrity constraints part, but must be suitably extended in order to cover also the knowledge base as well. Therefore, for an arbitrary CLIMB speciﬁcation the termination of sciff is guaranteed if and only if the knowledge base of the speciﬁcation is acyclic and bounded.

9.3 The g-SCIFF Proof Procedure g-sciff is an abductive proof procedure speciﬁcally dedicated to check whether a SCIFF speciﬁcation entails some property. It relies on the data

9.3 The g-SCIFF Proof Procedure

219

structures and transitions of sciff, extending them with a further transition which transforms a positive pending expectation into a corresponding happened event, simulating the expectation’s fulﬁllment. In this way, given a CLIMB speciﬁcation, g-sciff is able to generate a set of execution traces compliant with the speciﬁcation. We will describe how g-sciff is able to concretely do that, and we will then investigate its formal properties. The discussion concerning the application of g-sciff to the veriﬁcation of properties (in the ConDec setting), is instead postponed to the next chapter. Note that, in the following, the property will never appear explicitly. Indeed, we rely on Remark 4.3.1 – p. 99, which states that properties can be expressed by means of integrity constraints, and hence added to the integrity constraints of the speciﬁcation under study before starting the proof procedure. 9.3.1 Generation of Intensional Traces g-sciff is able to generate execution traces because it considers all the possible happened events as abducibles. More speciﬁcally, it reasons upon the integrity constraints of the speciﬁcation under study, using abduction to simulate the execution of compliant execution traces. To concretely realize this feature, g-sciff incapsulates the following behavior inside a dedicated transition: “if there is a pending positive expectation, then hypothesize the existence of a happened event able to fulﬁll it”. This behavior leads to the following generation cycle: 1. g-sciff starts from the speciﬁcation and runs as sciff would run, abducing the pending expectation; 2. one pending positive expectation is taken and transformed into a corresponding event occurrence; 3. the generated event occurrence is added to the (simulated) execution trace; 4. the updated execution trace could trigger some (partially solved) integrity constraint of the speciﬁcation; 5. the triggered constraint, in turn, would lead to generate further pending expectations; 6. a new iteration of the generative process is performed, choosing another pending expectation and transforming it into an event occurrence; 7. the generation cycle is repeated until quiescence is reached, or a failure is detected; in the ﬁrst case, the simulated trace actually represents an execution compliant with the speciﬁcation. In a nutshell, g-sciff combines the current (partial) execution trace with the speciﬁcation, “simulating by abduction” the occurrence of new events so as to obtain a complete trace compliant with the speciﬁcation.

220

9 Proof Procedures

Since pending positive expectations could contain variables12 , g-sciff generates partially speciﬁed happened events, containing variable parts. In other words, g-sciff abduces intensional traces, which represent classes of (ground) traces compliant with the speciﬁcation. The CLP constraints attached to the time variables of the intensional event occurrences have the eﬀect of partially ordering them. Last but not least, in the general case also an initial execution trace Ti could be provided as input for g-sciff: the proof procedure will try to extend Ti so as to make it compliant with the speciﬁcation under study. 9.3.2 Data Structures Revisited The data structures and the concepts of initial and success node are very close to the ones of sciff, deﬁned in Sect. 9.1.2. The only diﬀerence is that g-sciff interprets also happened events as abducibles, and thus abductive explanations are a generalization of the ones of sciff. Deﬁnition 9.3.1 (g-sciff node and computed abductive explanation). A g-sciff node is a tuple R, CS, psIC, T , ΔA , ΔP , ΔF , ΔV , where: • R is the resolvent, i.e., a conjunction (of disjunctions) of literals; • CS is the constraint store, containing CLP constraints and quantiﬁer restrictions; • psIC is a set of partially solved integrity constraints; • T is the generated execution trace, which contains the initial trace Ti speciﬁed in the initial node; • ΔA is the set of abduced predicates but expectations, which are treated separately13 ; • ΔP , ΔF and ΔV respectively represent the set of pending, fulﬁlled and violated expectations. The abductive explanation computed in the node is the set Δ of all abduced atoms: Δ = ΔA ∪ ΔP ∪ ΔF ∪ ΔV ∪ (T /Ti ). Deﬁnition 9.3.2 (g-sciff successful derivation). Let S be a CLIMB speciﬁcation, and Ti an initial execution trace. There exists a g-sciff successful derivation for S starting from Ti if and only if the proof tree with root node I(STi ) has at least one leaf success node. In this case, we write Tf

STi g Δ true, where Δ is the computed abductive explanation in a success node (as deﬁned in Def. 9.3.1) and Tf /Ti ⊆ Δ is the set of (intensional) happened events generated by g-sciff during the derivation. 12 13

For example, node N2 of Example 9.1.2 is characterized a pending positive expectation with an unknown time value. Also in the case of g-sciff, when dealing with CLIMB speciﬁcations such a set is always empty, because only expectations and happened events are abducible.

9.3 The g-SCIFF Proof Procedure

221

Variables contained in the partially speciﬁed execution trace are existentially quantiﬁed. E.g., H(exec(a), T ) represents that activity a has been performed at some time. Hence, a completely speciﬁed compliant execution trace can be simply extracted from a success node by choosing a grounding for all variables, so that the CLP constraints contained in the constraint store are respected. This is in accordance with the grounding of a computed explanation described in Sect. 9.1.2. 9.3.3 Transitions Revisited sciff transitions are modiﬁed by g-sciff as follows: Happening is removed because the dynamic acquisition of external occurred events is not needed. Indeed, an initial execution trace could be provided, but then the proof procedure works autonomously, trying to extend such an initial trace in order to make it compliant with the speciﬁcation. Fulﬁller is introduced to concretely implement the generative rule “if an expectation cannot be fulﬁlled by a happened event in the current execution trace, then the trace is extended with a further occurrence able to fulﬁll the expectation”. Technically, fulﬁller can be applied on node Nk only if: • ΔP k = ∅; • E-fulﬁllment cannot be applied; • the closure transition has not been applied before in the derivation. This situation represents the case in which there is a pending expectation which cannot be fulﬁlled, and the execution trace has not yet been declared as complete. Checking whether E-fulﬁllment can be applied is a test executed for eﬃciency reasons: if E-fulﬁllment can be applied, g-sciff will ﬁrst try to match the pending expectation with the suitable candidates contained in the current trace, and thus it postpones the simulation of happened event as latest as possible. When applied to node Nk , fulﬁller extracts a pending expectation E(Ev, T ) from the ΔP k set, moving it to the set of fulﬁlled expectations and inserting in the execution trace a corresponding happened event H(Ev, T ): ΔP k+1 = ΔP k /{E(Ev, T )} ΔF k+1 = ΔF k ∪ {E(Ev, T )} Tk+1 = Tk ∪ {H(Ev, T )} Example 9.3.1 (A g-sciff derivation). Let us consider again Example 9.1.2, but using g-sciff as a reasoning engine. The proof tree generated by g-sciff is identical to the one discussed in Example 9.1.2 and shown in Fig. 9.1, except for the fact that node N6b does not lead to failure anymore. In such a node, while sciff states that the expectation E(exec(b), Tb ) cannot be fulﬁlled with

222

9 Proof Procedures

Tb = 10, g-sciff applies fulﬁller, generating a new series of transitions in which: • • • •

H(exec(b), Tb ) is generated and added to the execution trace; E(exec(b), Tb ) is declared fulﬁlled; constraint Tb = 10 is inserted into the constraint store; transition closure is ﬁnally applied, leading to a success node.

The answers provided by g-sciff state that the initial execution trace {H(a, 5), H(exec(b), 10)} is compliant with the given speciﬁcation (ﬁrst derivation), or that a further execution of activity b is needed to make the initial history compliant (second derivation). In particular, such a further b must be executed at a time diﬀerent than 10 and greater than 5. In this latter case, the computed explanation is Δ = {E(exec(b), Tb ), H(exec(b), Tb )} and the intensional generated execution trace is {H(a, 5), H(exec(b), 10), H(exec(b), Tb )}, with Tb > 5 ∧ Tb = 10 (these CLP constraints are extracted from the constraint store of the success node). Each execution trace grounding Tb at a value which is greater than 5 and diﬀerent than 10 is therefore compliant with the speciﬁcation. 9.3.4 Linking the Proof Procedures g-sciff extends sciff because it is able to generate happened events, following (an optimized version of) the rule which states that each positive expectation must have a corresponding happened event. Since sciff is a general abductive proof procedure, it is able to abduce arbitrary happened events as well, provided that the speciﬁcation under study has declared H/2 predicates as abducible. This requirement can be accommodated within the SCIFF-lite fragment, which employs happened events as abducibles in order to deal with composite events and complex events processing (see Sect. 4.2.6 – p. 93). It is then possible to extend a CLIMB speciﬁcation with an integrity constraint that declaratively encodes the rule applied by the fulﬁller transition of g-sciff. In this way, it is obtained a SCIFF-lite speciﬁcation which can be processed by sciff exhibiting, from a theoretical point of view, the same behavior of g-sciff. More speciﬁcally, Given a CLIMB speciﬁcation S, the computations of g-sciff over S are, from a theoretical point of view, equivalent to the computations of sciff over the “generative” SCIFF-lite version of S. Deﬁnition 9.3.3 (Generative extension). Given a CLIMB speciﬁcation S = KB, IC , its SCIFF-lite generative extension is: gen (S) = KB, {E, EN, H}, IC ∪ {E(Ev, T ) → H(Ev, T ).} However, from a practical point of view the performance of g-sciff when reasoning upon S is much better than the one of sciff upon gen (S), because of the eﬃcient implementation of the fulﬁller transition vs the general rule E(Ev, T ) → H(Ev, T ).

9.4 Formal Properties of the g-SCIFF Proof Procedure

223

9.4 Formal Properties of the g-SCIFF Proof Procedure The formal properties of g-sciff are established by exploiting the results given for sciff. 9.4.1 Soundness Soundness of g-sciff states that each trace generated by g-sciff starting from a speciﬁcation and an initial trace, is compliant with the speciﬁcation, according to the declarative semantics of SCIFF. Theorem 9.4.1 (Soundness of g-sciff). For each SCIFF speciﬁcation S and for each (initial) trace Ti : ∀ Δ, STi

Tf gΔ

true ⇒ compliant STf

Proof. Soundness of g-sciff can be reduced to soundness of sciff by considering the generative extension of S (introduced in Def. 9.3.3). 9.4.2 Completeness Modulo Trace Generation The completeness result given in Theorem 9.2.2 for sciff also holds for g-sciff. In fact, for an arbitrary SCIFF speciﬁcation S and for each trace T compliant with that speciﬁcation, the proof tree produced by g-sciff when reasoning upon S starting with T corresponds to the proof tree of sciff. In particular, being T compliant, there is a g-sciff derivation in which the fulﬁller transition is never employed, because all the generated positive expectations can be fulﬁlled by happened events contained in T ; when producing this derivation, g-sciff exhibits a behavior identical to the one of sciff. Formally, it holds therefore that, given an arbitrary CLIMB speciﬁcation S: ∀ T , compliant (ST ) ⇒ ST

T gΔ

true

However, g-sciff could be studied by considering a more interesting notion of completeness, which focuses on the generative nature of the proof procedure. More speciﬁcally, we are interested in investigating whether, given a SCIFF speciﬁcation S and an initial execution trace Ti , g-sciff is able to generate all the possible execution traces which contain Ti and are compliant with S:

∀ Ti ∀ Tf ⊇ Ti , compliant STf ⇒ STi

Tf gΔ

true

We will refer to this notion of completeness as completeness modulo trace generation. g-sciff does not guarantee this completeness property: its generative approach is driven by the integrity constraints of the speciﬁcation and by the initial execution trace, hence only a subset of all compliant traces will be found. A counterexample for completeness modulo trace generation follows.

224

9 Proof Procedures

Example 9.4.1 ( g-sciff is not complete modulo trace generation). As shown in Example 9.3.1, given • the speciﬁcation S = ∅, {H(exec(a), Ta ) → E(exec(b), Tb ) ∧ Tb > Ta } ; • the (initial) execution trace Ti = {H(exec(a), 5), H(exec(b), 10)} g-sciff computes the following (intensional) compliant execution traces: 1. Ti 2. Ti ∪ {H(exec(b), Tb )} with Tb > 5 ∧ Tb = 10 which correspond to the following (inﬁnite) set of ground traces: 1. {H(exec(a), 5), H(exec(b), 10)} 2. {H(exec(a), 5), H(exec(b), 7), H(exec(b), 10)} 3. {H(exec(a), 5), H(exec(b), 8), H(exec(b), 10)} 4. . . . 5. {H(exec(a), 5), H(exec(b), 10), H(exec(b), 11)} 6. . . . However, inﬁnite other execution traces compliant with S and including Ti exist, including for example: 1. {H(exec(a), 2), H(exec(a), 5), H(exec(a), 6), H(exec(b), 10)} 2. {H(exec(a), 2), H(exec(b), 4), H(exec(a), 5), H(exec(b), 10)} Let us now consider the same speciﬁcation S, but with an empty initial execution trace (Ti = ∅). In this case g-sciff would produce a single derivation, in which the ﬁnal execution trace is the empty trace. In fact, remember that the behavior of g-sciff is initially driven by the integrity constraints of S together with the initial trace: with an empty trace, no execution of activity a occurs, hence the integrity constraint of S does not trigger. As a consequence, no pending expectation is generated and no fulﬁller transition is applied. As shown by the example, g-sciff does not guarantee completeness modulo trace generation. Anyway, it is able to compute a subset of each compliant execution trace. We call this property weak completeness modulo trace generation. The computed subsets represent the “core” of compliant execution traces. This is a key property: as we will see in the next chapter, g-sciff will be employed to verify whether a given speciﬁcation is consistent, i.e., admits at least one compliant execution; weak completeness modulo trace generation guarantees that g-sciff handles such an issue in a complete way, and is also able to generate a signiﬁcant witness. Theorem 9.4.2 (Weak completeness modulo trace generation). Given an arbitrary SCIFF speciﬁcation S: !

Tf ∀ Ti ∀ Tf ⊇ Ti , compliant STf ⇒ ∃ Δ, STi g Δ true ∧ Tf ⊆ Tf

9.4 Formal Properties of the g-SCIFF Proof Procedure

225

Proof. A compliant execution trace extending Ti can be found if and only if STi admits at least one abductive explanation which is E-consistent. In particular, each Tf must extend Ti so as to fulﬁll a set of positive pending expectations generated from the combination of Ti with the integrity constraints of S. Diﬀerent alternative sets of pending expectations are generated when the integrity constraints of S contain disjunctions of expectations. Therefore, each compliant trace Tf can be written as Tf = Ti ∪ Tf ulf ∪ Tothers , where Tf ulf is the set of happened events necessarily needed to comply with the speciﬁcation, while Tothers contains a set of further occurrences which do not undermine compliance. g-sciff produces exactly the Ti ∪ Tf ulf part of each Tf .

9.4.3 Termination Given a SCIFF speciﬁcation, the termination of g-sciff can be determined by assessing whether sciff terminates when reasoning upon the generative extension of the speciﬁcation (Def. 9.3.3). Theorem 9.4.3 (Termination of g-sciff). Given a CLIMB speciﬁcation S, if gen (S) is acyclic and all its literals are bounded, then every g-sciff derivation for S starting from an arbitrary execution trace is ﬁnite. Proof. A g-sciff derivation for S starting from an initial trace Ti corresponds to a sciff derivation for gen (S)Ti , whose termination is guaranteed by hypotheses. gen (S) augments S with the generative rule, which contains a general expectation in the body and a corresponding happened event in the head. Such an integrity constraint has a syntactic structure which is contrary to the one of CLIMB. Therefore, gen (S) contains rules relating happened events with expectations, and a rule relating expectations with happened events. Finding a suitable level mapping becomes then a challenging issue, making the acyclicity and boundedness conditions much more restrictive in the case of g-sciff. In particular, while Theorem 9.2.4 guarantees termination when reasoning upon the translation of an arbitrary ConDec model, for g-sciff this is no longer true: termination must be investigated case by case, trying to deﬁne a suitable model-dependent level mapping, which does not always exist. The following example illustrates this issue in a simple case. Example 9.4.2 (A looping ConDec model). Let us consider the ConDec model Loop =

a

b

The corresponding integrity constraints are:

226

9 Proof Procedures

tIC (Loop) = H(exec(a), Ta ) → E(exec(b), Tb ) ∧ Tb > Ta .

(ab)

H(exec(b), Tb ) → E(exec(a), Ta ) ∧ Ta > Tb .

(ba)

When considering the generative extension of the obtained CLIMB speciﬁcation, also the generative rule E(Ev, T ) → H(Ev, T ) must be introduced. Being Ev variable, the rule is applied on each possible ground event, including exec(a) and exec(b). Therefore, the deﬁnition of a suitable level mapping, needed to guarantee the termination of g-sciff when reasoning upon Loop, must take into account also the rules E(exec(a), T ) → H(exec(a), T ).

(GENa )

E(exec(b), T ) → H(exec(b), T ).

(GENb )

From Def. 9.2.4, we know that termination of g-sciff is guaranteed if we can ﬁnd a level mapping | · | for (ab), (ba), (GENa ) and (GENb ) so that acyclicity and boundedness are preserved. In turn, acyclicity requires that each element contained in the body of an integrity constraint has a level greater than the one of elements contained in its head. Hence, taking into account the CLP temporal constraints, we have: |H(exec(a), 0)| >

(from (ab))

>|E(exec(b), 1)| >

(from (GENb ))

>|H(exec(b), 1)| > >|E(exec(a), 2)| >

(from (ba)) (from (GENa ))

>|H(exec(a), 2)| > >|E(exec(b), 3)| > . . .

(from (ab))

which is not bounded. The impossibility of ﬁnding a level mapping which obeys to the acyclicity and boundedness conditions attests that the termination of g-sciff is not guaranteed. Indeed, by running g-sciff with an initial empty trace, it will terminate, returning the empty trace. Contrariwise, giving the initial trace {H(exec(a), 0)}, g-sciff will run forever, trying to explicitly build the inﬁnite execution trace: H(exec(a), 0), H(exec(b), T1 ) with T1 > 0 H(exec(a), T2 ) with T2 > T1 H(exec(b), T3 ) with T3 > T2 ... The non-termination of g-sciff when reasoning upon the ConDec model presented in Example 9.4.2 comes from the fact that the model is not correct: it supports the (ﬁnite) empty trace, but as soon as one activity among a and

9.5 Implementation of the Proof Procedures

227

b is executed, the course of interaction enters in an inﬁnite loop, where a further activity is always expected to occur. This contrasts with the ﬁniteness requirement of ConDec, which states that each course of interaction must eventually terminate. It is worth noting that the declarative semantics of CLIMB would also state that

T ⊇{H(exec(a),0)} compliant tIC (Loop)T (remember that CLIMB execution traces must be ﬁnite). The non-terminating behavior of g-sciff thus represents a direct consequence of semi-decidability: g-sciff should answer “no”, but instead it loops forever. Chap. 10 will discuss this problem in more detail, giving some useful guidelines for preprocessing ConDec models, to the aim of discovering these kinds of inconsistencies before employing g-sciff.

9.5 Implementation of the Proof Procedures As we have seen, sciff and g-sciff deﬁne a set of transitions for building proof trees. The search strategy is instead not ﬁxed, and can be then freely chosen at the implementation level. The current implementation is based on a depth-ﬁrst strategy, tailored to the built-in computational features of Prolog, for the sake of eﬃciency. The proof procedures are freely available14 and run either under SWI Prolog15 and SICStus 416 . In particular, they are implemented on top of the Constraint Handling Rules (CHR) library [110]: the data structures are implemented as CHR constraints, while the transitions are encapsulated into CHR rules. The implementation relies on constraint solvers to handle CLP constraints and quantiﬁer restrictions. Both the CLP(F D) [95] and the CLP(R) [136] solvers embedded in SWI and SICStus have been integrated into the proof procedures. The user can therefore choose the most suitable solver for the application at hand, which is an important issue in practice. It is well known, in fact, that no solver dominates the other, and we measured, in diﬀerent applications, orders of magnitude of improvements by switching solver. In the following experimentations we will report the results obtained with the CLP(R) solver, which is based on the simplex algorithm, and features a complete propagation of linear constraints. The interested reader can refer to the web site of the book17 for getting started with the practical use of the proof procedures. 14 15 16 17

See http://www.lia.deis.unibo.it/research/sciff/ http://www.swi-prolog.org http://www.sics.se/sicstus.html http://www.lia.deis.unibo.it/Research/climb/

10 Static Veriﬁcation of ConDec Models with g-SCIFF

This chapter is devoted to discuss how the g-sciff proof procedure can be adopted for the static veriﬁcation of ConDec models. The scalability of the approach will be investigated in the next chapter. The ﬁrst part of the chapter demonstrates how existential and universal properties, as deﬁned in Sect. 8.3.1, can be expressed in CLIMB and veriﬁed with g-sciff. Thanks to this possibility, g-sciff can be exploited to deal with all the static veriﬁcation tasks introduced in Chap. 8: • • • • •

conﬂict detection; discovery of dead activities; a-priori compliance veriﬁcation; checking the executability of composite models; veriﬁcation of conformance to a choreography.

The second part of the chapter is instead focused on termination issues; as sketched in Sect. 9.4.3, the termination of g-sciff cannot be generally guaranteed when reasoning upon CLIMB speciﬁcations, and therefore an ad-hoc solution for ConDec must be provided.

10.1 Existential and Universal Entailment in CLIMB In the CLIMB framework, properties are represented with the same language used for specifying interaction models, i.e., by means of integrity constraints. The existential and universal entailment properties are expressed by suitably quantifying on execution traces and combining the notions of compliance with the speciﬁcation and compliance with the property. 10.1.1 Speciﬁcation of Properties with ConDec A CLIMB property consists of a set of CLIMB integrity constraints. M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 229–249, 2010. c Springer-Verlag Berlin Heidelberg 2010

230

10 Static Veriﬁcation of ConDec Models with g-SCIFF

Deﬁnition 10.1.1 (CLIMB property). A CLIMB property Ψ is a set of $ CLIMB integrity constraints: Ψ = i ICi . A CLIMB property is simple if it is expressed by a single integrity constraint, i.e., i = 1. Since all the ConDec constraints can be translated into CLIMB , then also properties can be speciﬁed by means of ConDec models. Obviously, the CLIMB language is more expressive than the fragment needed for formalizing ConDec; however, the speciﬁcation of properties in ConDec takes advantage from its graphical and intuitive front-end, which supports non-IT savvy in the elicitation of the intended requirements. In the following, we will mainly consider ConDec as a graphical language for specifying both interaction models and properties, but all the provided results hold for general CLIMB speciﬁcations and properties as well. Example 10.1.1 (ConDec properties). Let us consider the four queries introduced in Sect. 8.3.4 for verifying the order&payment protocol of Fig. 8.4 – p. 8.4, interpreting them as ConDec models. Query 8.3.1 expresses that send receipt is a dead activity, i.e., can never be executed. It can be then represented as the universal entailment of the ConDec model 0

send receipt Query 8.3.2 checks whether a transaction can be completed such that the customer does not accept ads and the seller does not oﬀer standard payment. It can be formalized in terms of the existential entailment of the ConDec model 1..∗

0

0

send receipt

accept advert

standard payment

The 1..* cardinality constraint models the correct completion of a transaction, where the concept of “correct completion” is related to the emission of a receipt, whereas the two 0 cardinality constraints are used to express that the customer refuses ads and that standard payment is not available. Query 8.3.3 is a universal query, which states that in every instance where 1-click payment is chosen, it must be guaranteed that a receipt is sent only if the customer has previously accepted ads. It can be formalized by rewriting implication as a disjunction1 , and stating that each execution supported by the model must entail either one of the two following properties. 0

• 1-click payment is not involved: 1-click payment 1

A ⇒ B = ¬A ∨ B

10.1 Existential and Universal Entailment in CLIMB

231

0 1..*

accept advert

send receipt

(0,12)

(0,6)

1-click payment

(0,3) (0,3)

payment done

close order (0,6)

standard payment

payment failure

(0,8)

(0,8)

Fig. 10.1. Representation of the metric query 8.3.4 (p. 186) with ConDec++

• The precedence relationship between send receipt and accept advert is guaranteed: accept advert −−−• send receipt Query 8.3.4 is an existential query that involves metric temporal constraints (deadlines and latencies in particular). It can be formalized using the extended ConDec++ notation proposed in Sect. 6.1. The resulting model is shown in Figure 10.1. Note that (0,12)

close order •−−− send receipt models the deadline by which the completion of the transaction is desired, while metric negation response constraints are used to represent latencies. For example, (0,6)

close order •−− − 1-click payment states that if the order is closed at a certain time T , then it is possible to execute 1-click payment only from time T + 6 excluded. It is worth noting that the ﬁrst three ConDec properties shown in Example 10.1.1 can be translated into CLIMB by applying both the tCLIMB and the tCLIMB functions2 : depending on the domain under study, a qualitative vs quantitative time perspective can be chosen. Contrariwise, since the last model contains quantitative temporal constraints, it can be translated into CLIMB only by means of the tCLIMB function. In the remainder of this chapter, we will always consider basic ConDec models and properties formalized by applying tCLIMB , but all the presented results also hold for ConDec++ models and for the tCLIMB translation function. 10.1.2 Formalizing Existential and Universal Entailment The formalization of ∃- and ∀-entailment in CLIMB follows straightforwardly from the natural language characterization given in Sect. 8.3.1, using the 2

tCLIMB has been deﬁned in Sect. 5.1, while tCLIMB has been introduced in Sect. 6.1.2.

232

10 Static Veriﬁcation of ConDec Models with g-SCIFF

formal notion of compliance in the CLIMB setting (see Def. 4.3.10) to express the “support of an execution trace by a ConDec model”. A CLIMB speciﬁcation S ∃-entails a CLIMB property if there exists at least one execution trace which is at the same time compliant with S and with the property. Since the property is modeled by a set of integrity constraints, but compliance refers to a complete CLIMB speciﬁcation, we assume that the property is embedded into a CLIMB speciﬁcation which has the same knowledge base of S. Deﬁnition 10.1.2 (∃-entailment in CLIMB). A CLIMB speciﬁcation S = KB, IC ∃-entails a CLIMB property Ψ (S |=∃ Ψ ) if and only if: % & ∃ T compliant (ST ) ∧ compliant (KB, Ψ T ) S ∃-violates Ψ (S |=∃ Ψ ) if and only if: & % ∃ T compliant (ST ) ∧ compliant (KB, Ψ T ) A CLIMB speciﬁcation ∀-entails a CLIMB property if every execution trace compliant with the speciﬁcation is also compliant with the property. Deﬁnition 10.1.3 (∀-entailment in CLIMB). A CLIMB speciﬁcation S = KB, IC ∀-entails a CLIMB property Ψ (S |=∀ Ψ ) if and only if: % & ∀ T compliant (ST ) =⇒ compliant (KB, Ψ T ) S ∀-violates Ψ (S |=∀ Ψ ) if and only if: & % ∃ T compliant (ST ) ∧ ¬compliant (KB, Ψ T )

10.2 Veriﬁcation of Existential Properties with g-SCIFF As discussed in Sect. 9.3, the g-sciff proof procedure is speciﬁcally thouht to deal with the static veriﬁcation of CLIMB models: it realizes a “simulation by abduction” approach, starting from an initial execution trace and the integrity constraints of the speciﬁcation under study, and trying to generate an execution trace compliant with the speciﬁcation. We now discuss how g-sciff can be successfully exploited to verify whether a ConDec model ∃-entails some property. The following approach is adopted: • we describe how g-sciff is able to detect the presence of conﬂicts inside a ConDec model (see Def. 8.3.3); • we show how ∃-entailment of properties can be reduced to conﬂicts detection.

10.2 Veriﬁcation of Existential Properties with g-SCIFF

233

10.2.1 Conﬂict Detection with g-SCIFF Conﬂict detection is the process of verifying whether a ConDec model supports at least one execution trace, i.e., ∃-entails the true property. If it is not the case, then the model contains a (global) conﬂict, which undermines its executability. When verifying the presence of conclits, the user is interested in detecting whether at least one supported execution trace exists, but she is not interested in ﬁnding all the possible supported traces. Therefore, g-sciff is a suitable technology to deal with this problem: from the combination of soundness and weak completeness modulo trace generation, we know that at least one execution trace compliant with a CLIMB speciﬁcation exists if and only g-sciff has a successful derivation. Therefore, g-sciff deals with conﬂict detection in a correct way. Theorem 10.2.1 (g-sciff can detect conﬂicts). A ConDec model CM is conﬂict free if and only if g-sciff has a successful derivation for tCLIMB (CM) starting from the empty trace: T tCLIMB (CM) |=∃ true ⇐⇒ ∃Δ tCLIMB (CM)∅ g Δ true If it is the case, the execution trace T generated by g-sciff represents an (intensional) example of a concrete course of interaction supported by CM. Proof. Straightforward from the results of soundness and weak completeness modulo trace generation (Theorems 9.2.1 and 9.4.2).

10.2.2 Existential Entailment with g-SCIFF As far as now, we have seen g-sciff derivations related to a single speciﬁcation. When using g-sciff for prove ∃-entailment, the following issue therefore arises: how is it possible to consider at the same time the speciﬁcation of the model and and the desired property? We prove that by composing the model with the property (using the composition operator comp introduced in Def. 8.5.1), ∃-entailment can be reduced to conﬂict detection on the composite model. Theorem 10.2.2 (∃-entailment with g-sciff). Given a ConDec model CM and a ConDec property Ψ , T tCLIMB (CM) |=∃ tCLIMB (Ψ ) ⇐⇒ ∃Δ tCLIMB (comp (CM, Ψ ))∅ g Δ true If it is the case, the execution trace T generated by g-sciff can be considered as an (intensional) example of a course of interaction which respects both the constraints of the model and the desired property.

234

10 Static Veriﬁcation of ConDec Models with g-SCIFF

Proof. The proof relies: • on the compositionality of CLIMB speciﬁcations, which has been discussed in Sect. 4.4 and proven in Corollary 4.4.1 • on the deﬁnition of tCLIMB (given in Sect. 5.1), which states that a ConDec model is translated into a CLIMB speciﬁcation whose knowledge base is empty and whose integrity constraints are the union of the translations of each mandatory constraint. In particular, it holds that: ∃Δ tCLIMB (comp (CM, Ψ ))∅

T gΔ

true ⇔

compliant(tCLIMB (comp (CM, Ψ ))T ) ⇔

CM Ψ T ) ⇔ ∪ Cm compliant(∅, tIC Cm

CM

Ψ compliant(∅, tIC Cm ∪ tIC Cm T ) ⇔

CM T ) ∧ compliant(∅, tIC Cm

Ψ T ) ⇔ compliant(∅, tIC Cm compliant(tCLIMB (CM)T ) ∧ compliant(tCLIMB (Ψ )T ) ⇔

(Th. 10.2.1) (Def. 5.1.1) (Def. 5.1.2) (Def. 4.4.2) (Def. 5.1.1) (Def. 10.1.2)

tCLIMB (CM) |=∃ tCLIMB (Ψ )

10.3 Veriﬁcation of Universal Properties with g-SCIFF Universal entailment of properties is carried out with g-sciff via a reduction to existential entailment, which in turn is reduced to conﬂict detection. 10.3.1 Complementation of Integrity Constraints The idea behind the reduction of ∀-entailment to ∃-entailment resembles model checking [79]3 : a property is ∀-entailed if and only if the negated property is not ∃-entailed. In the CLIMB setting, the negation of a basic property (which corresponds to a single integrity constraint) cannot be directly juxtaposed to the property, due to syntactic restrictions. Therefore, the property must be explicitly manipulated to obtain the negated version. An integrity constraint and its negation are complementary modulo compliance: given an arbitrary execution trace, the integrity constraint evaluates the trace as compliant if and only its negated version evaluates it as noncompliant. 3

Model checking will be described in Sect. 11.3.3.

10.3 Veriﬁcation of Universal Properties with g-SCIFF

235

Deﬁnition 10.3.1 (Complementary integrity constraints). Given a knowledge base KB, two CLIMB integrity constraints IC1 and IC2 are complemenKB KB and IC2 = IC1 , if and only tary with respect to KB, written IC1 = IC2 if:

∀T compliant KB, {IC1 } T ⇐⇒ ¬compliant KB, {IC2 } T With an abuse of notation, we will simply say IC1 = IC2 , IC2 = IC1 where the knowledge base is apparent from the context or is empty. An arbitrary integrity constraints has many diﬀerent complementary integrity constraints and, in the general case, the complementation is a task that must be accomplished manually. In the ConDec setting, there is a ﬁnite number of constraints, and therefore we could write their complementation once and for all; we could then encapsulate the complementation of all the integrity constraints used to formalize ConDec into a translation function tIC which, given a ConDec constraint C, returns a CLIMB rule complementary to tIC (C). Example 10.3.1 (Complementing the absence constraint). Let us consider the ConDec absence(a) constraint, which states that the targeted activity a cannot be executed. It is violated by an execution trace if the trace contains at least one occurrence of a. This situation can be characterized by means of an existence(1,a) ConDec constraint, and hence we have: ⎛ ⎞ ⎛ ⎞ 0

1..∗

tIC ⎝ a ⎠ tIC ⎝ a ⎠ Example 10.3.2 (Complementing the response and negation response ConDec constraints). Let us focus on the ConDec response(a,b) constraint. It is violated by an execution trace if the trace contains at least one execution of activity a which is not followed by a consequent execution of b. Such a natural language description can be easily formalized in CLIMB, obtaining a rule which complements response(a,b): true → E(exec(a), Ta ) tIC a •−−− b ∧ EN(exec(b), Tb ) ∧ Tb > Ta . The complementation of neg response(a,b) can be devised in a very similar way. It is suﬃcient to replace the negative expectation about b with a positive expectation: true → E(exec(a), Ta ) tIC a •−− − b ∧ E(exec(b), Tb ) ∧ Tb > Ta . Indeed, an execution trace violates neg response(a,b) if it contains at least one execution of activity a which is followed by an occurrence of b.

236

10 Static Veriﬁcation of ConDec Models with g-SCIFF

10.3.2 Reducing Universal to Existential Entailment ∀-entailment can be reduced to ∃-entailment by exploiting the complementation of integrity constraints. In particular, the following theorem states that a ConDec property Ψ is ∀-entailed by a ConDec model CM if and only if there does not exist a mandatory constraint of Ψ whose complementation is ∃-entailed by CM. Contrariwise, if at least one complemented constraint is ∃-entailed, then the execution trace generated for proving the ∃-entailment amounts to a counterexample, which demonstrates that the original property is not guaranteed in any possible execution. Theorem 10.3.1 (Reduction of ∀-entailment to ∃-entailment). Given a ConDec model CM and $ a ConDec property Ψ , where the mandatory conΨ = i Ci , straints of Ψ are Cm ' ( ∀i tCLIMB (CM) |=∃ ∅, tIC (Ci ) ⇔ tCLIMB (CM) |=∀ tCLIMB (Ψ ) Proof. As in the case of Theorem 10.2.2, the proof relies on the compositionality of CLIMB speciﬁcations, and on the deﬁnition of tCLIMB . It also involves the notion of complementation between integrity constraints. tCLIMB (CM) |=∀ tCLIMB (Ψ ) ⇔

∀T compliant tCLIMB (CM)T ∀T

(Def. 10.1.3) ⇒ compliant tCLIMB (Ψ )T ⇔

∅, tIC compliant tCLIMB (CM)T ⇒ compliant

n

Ci

T

i=1

∀T

∅, compliant tCLIMB (CM)T ⇒ compliant

n i=1

∀T

n

compliant tCLIMB (CM)T ⇒

tIC (Ci )

(Def. 5.1.1) ⇔

(Def. 5.1.2) T

⇔

(Def. 4.4.2) ' ( compliant ∅, tIC (Ci ) T ⇔

i=1

' ( ∀i ∀T compliant tCLIMB (CM)T ⇒ compliant ∅, tIC (Ci ) T ⇔ ' ( ∀i ∃T compliant tCLIMB (CM)T ∧ ¬compliant ∅, tIC (Ci ) T ⇔

∀i ∃T compliant tCLIMB (CM)T

∧ compliant

'

(Def. 10.3.1) ( ∅, tIC (Ci ) T ⇔

(Def. 10.1.2) ( ' ∀i tCLIMB (CM) |=∃ ∅, tIC (Ci )

10.3 Veriﬁcation of Universal Properties with g-SCIFF

C1

C2 ...

Cn

C1

C2 ...

Cn

237

ConDec property

tIC complementation

C1

C2

...

Cn

no

yes

-Verification ConDec model

no yes

-Verification

counter example

no

... yes

-Verification

no

yes

-Verification Fig. 10.2. ∀-entailment veriﬁcation through a reduction to ∃-entailment

Given a complex ConDec property composed by a set of constraints C1 , . . . , Cn , if g-sciff computes a Δ showing that there exists a k for which tCLIMB (CM) |=∃ ∅, tIC (Ck ) , the intensional execution trace contained in Δ can be considered as a counterexample proving that the property is not ∀-entailed. Therefore, ∀-entailment can be concretely veriﬁed by focusing on each single constraint Ci separately. Each Ci is ﬁrst complemented by means of tIC . The complemented version is then subject to ∃-entailment. If the veriﬁcation fails, then constraint Ci+1 is subject to the same procedure. Conversely, if the veriﬁcation succeeds, then we have a proof showing that the original property is not ∀-entailed, and thus the veriﬁcation procedure can terminate without checking the other constraints of the property. A graphical representation of the approach is provided in Fig. 10.2. One of the simplest properties that are veriﬁed under ∀-entailment is the absence ConDec constraint, to the aim of discovering whether its targeted activity is dead inside the model under study. g-sciff deals with this problem by reducing ∀-entailment to ∃-entailment. Theorem 10.3.2 (g-sciff can discover dead activities). An activity a is dead inside a ConDec model CM if and only if g-sciff does not ∃-entail the existence of at least one execution of a:

238

10 Static Veriﬁcation of ConDec Models with g-SCIFF

⎛

0

⎞

⎛

1..∗

⎞

tCLIMB (CM) |=∀ tCLIMB ⎝ a ⎠ ⇐⇒ tCLIMB (CM) |=∃ tCLIMB ⎝ a ⎠ When g-sciff generates an (intensional) execution trace T showing that existence(1,a) is ∃-entailed, T represents a proof showing that a is not dead. 0

Proof. Straightforward from Theorem 10.3.1, noticing that a

1..∗

and a

complementary (as discussed in Example 10.3.1).

are

The discovery of dead activities consists of a simple ConDec property, i.e., a property composed only by a single constraint. When it comes to properties expressed as a complex ConDec model, Theorem 10.3.1 shows how to treat their universal entailment. There is, however, a third case, which has not been yet covered so far: how to deal with the universal entailment of a complex disjunctive property involving a set of alternative constraints, i.e., a property requiring that at least one constraint is entailed. In this particular situation, all the constraints are complemented. The complemented versions are then combined into a unique model, which is in turn combined with the ConDec model under study. Existential veriﬁcation is then applied on this composite model. We show how this idea can be concretely applied to verify, with g-sciff, that Query 8.3.3 – introduced in Sect. 8.3.4 and modeled in Example 10.1.1 – is not universally entailed by the ConDec model depicted in Fig. 8.4. Example 10.3.3 (Universal veriﬁcation of disjunctive property via a reduction to ∃-entailment). As pointed out in Example 10.1.1, query 8.3.3 cannot be modeled by means of a single ConDec model: it is in fact a disjunction of two properties, each one representable in ConDec. The two properties are: 0

P1 = 1-click payment P2 = accept advert −−−• send receipt Let us now consider the ConDec order&payment protocol shown in Fig. 8.4. We will call it O&P. Formally, the desired property is ∀-entailed by O&P if and only if: tCLIMB (O&P) |=∀ tCLIMB (P1 ) ∨ tCLIMB (O&P) |=∀ tCLIMB (P2 ) By reducing ∀-entailment to ∃-entailment, the property can be rephrased as follows: the complementation of P1 nor of P2 must be ∃-entailed by O&P. Formally, tCLIMB (O&P) |=∃ ∅, {tIC (P1 )} ∧ tCLIMB (O&P) |=∃ ∅, {tIC (P2 )}

10.4 ConDec Loops and Termination of g-SCIFF

239

which is equivalent, by compositionality, to: tCLIMB (O&P) |=∃ ∅, {tIC (P1 ) , tIC (P2 )} The complementation of the two properties P1 and P2 is discussed in Examples 10.3.1 and 10.3.2 respectively. In particular, we have: ⎛ ⎞ 1..∗

tIC (P1 ) = tIC ⎝ 1-click payment ⎠ = = true → E(exec(1 -click payment ), Tp ). tIC (P2 ) = true → E(exec(send receipt ), Ts ) ∧ EN(exec(accept advert ), Ta ) ∧ Ta < Ts . Intuitively, the speciﬁcation obtained by complementing the two properties states that the chosen payment modality must be “1-click”, and that advertising must not be accepted before the receipt is sent. In order to (trying to) refute such a complemented complex property, g-sciff joins it with O&P, looking for a counterexample. A counterexample actually exists, attesting that the original disjunctive property does not hold. One of the counterexamples generated by g-sciff is constituted by the following intensional, partially ordered trace:

H(exec(choose item), Ti )

H(exec(register ), Tr ) q qq To >Ti qq q q qq H(exec(closeM order ), To ) qqqTqp >Tr MMM qq MMM qqqq Tp >To q H(exec(1 -click payment), Tp ) Td >Tp

H(exec(payment done), Td ) Ts >Td

H(exec(send receipt), Ts ) Ta >Ts

H(exec(accept ads), Ta )

10.4 ConDec Loops and Termination of g-SCIFF In Sect. 9.4.3, we have shown that the conditions needed for guaranteeing the termination of g-sciff do not hold for arbitrary ConDec models. In fact,

240

10 Static Veriﬁcation of ConDec Models with g-SCIFF

the generative rule E(Ev, T ) → H(Ev, T ), which must be considered when deﬁning a suitable level mapping for the model under study, interferes with the integrity constraints that contain a happened event in the body and a positive expectation in the head. An ad-hoc solution must be therefore provided, in order to identify and treat ConDec models for which g-sciff termination is not guaranteed. There are two diﬀerent sources of non-termination: • non-termination caused by the particular syntactic structure of the integrity constraints chosen to formalize ConDec (i.e., the tCLIMB function); • non-termination caused by the inherent structure of the speciﬁc ConDec model under study4 . 10.4.1 Constraints Reformulation The ﬁrst issue can be tackled by properly reformulating the CLIMB integrity constraints used to formalize ConDec, so that they express the same behavior modulo compliance, but at the same time they overcome (or reduce) the interference with the generative rule of g-sciff. We do not provide the technical details concerning how tCLIMB has been changed to accommodate this. The interested reader can ﬁnd them in [171] – Sects. 10.4.1 and 10.6. We discuss just a single case, which also contributes to clarify the relationships among basic, alternate and chain relation constraints. Example 10.4.1 (Reformulation of the alternate response constraint). Alternate constraints can be reformulated so as to remove the explicit use of an interposition integrity constraint (introduced in Table 5.4). More specifically, the reformulation leads to embed the alternate behavior in one single integrity constraint, which takes the form of an augmented response or precedence rule. Let us consider the ConDec constraint alternate response(a,b), which states that: • if a occurs, then b must be executed afterwards; • b must be executed between any two occurrences of a. It can be equivalently formulated as: • if a occurs, then b must be executed afterwards; • if a occurs, then a second occurrence of a is forbidden until b is executed (such a further occurrence of a would indeed lead to violate the interposition part of the constraint, because no b exists in between). These two alternative but equivalent characterizations are depicted in Fig. 10.3. 4

This situation makes it impossible to ﬁnd an acyclic and bounded level mapping for the corresponding CLIMB representation, and there is no way of restructuring the representation so as to overcome the problem.

10.4 ConDec Loops and Termination of g-SCIFF

b expected

b expected

b expected

a

241

a forbidden

b

a

a

b

a

Fig. 10.3. Two possible CLIMB-based characterizations of the alternate response ConDec constraint Table 10.1. Tightness of the future-tense relation ConDec constraints constraint

strength interposition behavior

a •−−− b

weak

Between the two occurrences of a and b, further activities (including a and b) can be executed

a •=== b

medium

Between the two occurrences of a and b, other activities but a can be executed

a •= −= −= − b

strong

Between the two occurrences of a and b, no activity can be executed

By adopting the second perspective, alternate response/precedence constraints can be simply formalized as follows: tIC

a •=== b

H(exec(a), Ta ) →E(exec(b), Tb ) ∧ Tb > Ta ∧ EN(exec(a), Ta2 )

tIC

a ===• b

∧ Ta2 > Ta ∧ Ta2 < Tb . H(exec(b), Tb ) →E(exec(a), Ta ) ∧ Ta < Tb ∧ EN(exec(b), Tb2 ) ∧ Tb2 > Ta ∧ Tb2 < Tb .

By comparing this formalization with the quantitative-time formalization of chain response (the one produced by tCLIMB ), it becomes apparent that the tightness of relation constraints increases moving from the basic to the chain ones (see Table 10.1). 10.4.2 Looping ConDec Models The second cause of nontermination is the inherent structure of some graphical ConDec models. ConDec constraints can be combined in an underhand manner, leading to produce faulty models. To deal with this issue, we will proceed

242

10 Static Veriﬁcation of ConDec Models with g-SCIFF

as follows. First of all, the cause of nontermination is characterized in terms of structural, undesired conﬁgurations of relation constraints inside a model. Then, an analysis procedure is synthesized, to the aim of preprocessing a ConDec model before employing g-sciff. The purpose of the preprocessing phase is to check whether the model contains potential sources of non-termination, and take proper countermeasures if this is the case. In Example 9.4.2, we have shown that the ConDec model Loop =

a

b

can possibly cause a non-terminating behavior of g-sciff. In particular, g-sciff ﬁnitely demonstrates that the model is conﬂict-free (generating the empty execution trace as a proof), but cannot compute an answer to the question “is a a dead activity?”, because it inﬁnitely loops in the attempt to generate the inﬁnite sequence a → b → a → . . . In this case, g-sciff incurs in a inﬁnite computation because the ConDec model itself expresses a loop, built upon the incorrect combination of the two response constraints. As soon as one activity between a and b is executed, the constraints of Loop always require to eventually execute a further instance of b and a, and therefore a compliant course of interaction cannot never reach an end. However, ConDec execution traces must always be ﬁnite, hence both a and b should be considered as dead activities. A similar undesired behavior would arise by employing alternate response or chain response constraints (or an arbitrary combination of future-tense relation constraints). Even by replacing such future-tense relationships with pasttense ones (i.e. precedence, alternate precedence or chain precedence), the looping situation persists. Indeed, the problem is not caused by the tightness nor by the speciﬁc temporal ordering of the involved constraints, but by their relation nature, and by the concordance of their temporal ordering (they must be both future-tense or past-tense). In the general case, a set of activities a1 , . . . , an forms a loop if such activities are interconnected by a sequence of time ordered, concordant relation constraints such that a1 is connected with a2 , a2 with a3 , . . . , an−1 with an , and an with a1 . The presence of a loop does not always undermine the correctness of the model. If all the relation constraints forming the loop are straight (i.e., do not branch), then the loop introduces a (local) inconsistency in the model, because the execution of one activity inside the loop causes the interaction to enter into a situation where it is impossible to terminate the interaction in a compliant manner. This is the case of the aforementioned Loop model. Conversely, if at least one among the constraints forming the loop is a branching constraint, then all the possible (disjunctive) choices must be considered: if at least one alternative does not incur in a loop, then the model is correct. The following examples illustrate three CoDec models containing these various forms of loops, and show how g-sciff behaves when discovering their dead activities.

10.4 ConDec Loops and Termination of g-SCIFF

a

b

-loop

c

243

e

d

Fig. 10.4. A ConDec model containing a loop composed by straight connections; the loop causes all activities but e to be dead

a

b

-loop

c

e

a

d

b

-loop

c

e

d

Fig. 10.5. Two diﬀerent kinds of loops including a branching constraint; on the left no activity is dead, whereas on the right all activities are dead

Example 10.4.2 (Reasoning on a straight loop). Figure 10.4 shows a ConDec model containing a loop composed by straight response constraints, which make the model locally inconsistent. The inconsistency is only local because the model is not conﬂicting, i.e., it supports at least one execution trace. More speciﬁcally, it supports the empty execution trace, but also an execution trace where activity e is executed. Conversely, the execution of one among activities a, b, c and d leads to enter into the inﬁnite loop, and therefore all these activities are dead. g-sciff always loops when trying to discover these dead activities. For example, when analyzing whether d is dead or not, it incurs in a never ending computation, producing the execution trace d → c → a → b → c → . . . Example 10.4.3 (Reasoning on loops containing branching constraints). Fig. 10.5 shows two ConDec models containing loops that involve a branching constraint. Let us call them L and R respectively. The diﬀerence between the two models is that while in L one of the two branches allows the interacting entities to exit from the a-b-c loop, in R both alternatives incur in a loop. Therefore, L is a correct model, which does not contain dead activities: even if one of the looping activities is executed, it is always possible to eventually execute activity e, obtaining a compliant ﬁnite trace. Conversely, all activities contained in R are dead: no matter which decision is taken after having executed c, the interacting entities enters into a never ending course of interaction. When it comes to g-sciff, termination is not guaranteed in any of the two cases. In particular, when reasoning upon L to check whether d is a

244

10 Static Veriﬁcation of ConDec Models with g-SCIFF

dead activity, termination depends on the adopted search strategy, and on the syntactic structure of the integrity constraints used to formalize the model. By opting for a depth-ﬁrst strategy . . . • if the branching constraint response(c,[a,e]) is formalized as H(exec(c), Tc ) →E(exec(a), Ta ) ∧ Ta > Tc ∧ E(exec(e), Te ) ∧ Te > Tc . then g-sciff loops as in the case of Figure 10.4. The adoption of an iterative deepening strategy5 would help in this speciﬁc case, but not in general. • if the branching constraint response(c,[a,e]) is formalized as H(exec(c), Tc ) →E(exec(e), Te ) ∧ Te > Tc ∧ E(exec(a), Ta ) ∧ Ta > Tc . then g-sciff has a ﬁnite successful derivation, which correctly proves that d is not dead by means of the counterexample d → c → e. The three ConDec models captured in Figs. 10.4 and 10.5 show that two types of loops could be formed by combining relation constraints; the diﬀerence depends on whether there is the possibility of exiting from loop choosing a ﬁnite compliant alternative or not. If such an alternative exists, we call the loop an ∨-loop , otherwise we call it ∧-loop. Hence, in Fig. 10.4, activities a, b and c belong to an ∧-loop. In the left model of Fig. 10.5, such activities belong to an ∨-loop, because the choice of activity e after c represents a suitable “exit strategy”. Finally, in the right model of Fig. 10.5 all activities belong to an ∧-loop: no matter what choice is taken after having performed c, the user is forced to execute the same activity again. All the other ConDec models discussed so in this book are instead loop-free. With this loop classiﬁcation in mind, we can draw a link between ∧-loops and dead activities. Remark 10.4.1 (∧-loops contain dead activities). Each activity belonging to a ∧-loop is a dead activity. The remark interprets the nature of ∧-loop in terms of executability of the involved activities: since it is impossible to exit from an ∧-loop, the execution of one of its activity makes it impossible to support a ﬁnite compliant execution trace. The remark also points out that if we had an algorithm for discovering ∧-loops, we could automatically mark all the looping activities as dead, by explicitly attaching an absence constraint to them. The interesting fact is 5

Where, at each iteration, the maximum depth of the proof tree is related to the maximum number of distinct happened events that can be generated.

10.4 ConDec Loops and Termination of g-SCIFF

a

-loop

0

e

a

-loop

(incorrect)

245 0

f

e (implicitly) dead

b

c

d

b

c

d

Fig. 10.6. Two similar ConDec models for which an ∨-loop detection algorithm diverges; indeed, for the model on the right a mere analysis of its structure cannot take advantage from the information that e is a dead activity

that it is eﬀectively possible to design such an algorithm, carrying out the ∧loops detection directly at the graphical level of ConDec. We do not provide the algorithmic details here; they can be found in [171] – Sect. 10.5, where two algorithms for extracting ∧- and ∨-loops from a ConDec model are presented. In the remainder of the chapter, we will thus suppose that the following two functions are available: • FindAndLoops takes a ConDec model and returns a series of sets, each one enumerating the activities that belong an ∧-loop; • FindOrLoops takes a ConDec model and returns a series of sets, each one enumerating the activities that belong to an ∨-loop. The algorithms are devised so that they take into account when an activity is explicitly marked as dead by means of an absence constraint. This is particularly important for ∨-loops, because dead activities cannot be considered as a viable alternative for exiting from a loop. Consider for example the ConDec model shown in Fig. 10.6 – left side. It represents a slight modiﬁcation of the one shown in 10.5 – left side: activity e is now associated to an absence constraint. This information can be exploited by the loop-detection algorithm, which infers that e is not a viable alternative for exiting from the a-b-c loop, consequently marking the loop as an ∧-loop. However, since the proposed algorithms carry out a mere structural analysis of the ConDec models, they cannot deal with activities that are implicitly dead, i.e., whose non executability can be detected only by reasoning upon the model. Fig. 10.6 – right side – shows an example of this situation: even if activity e is dead, the loop-detection algorithm cannot exploit such an information, and thus marks the a-b-c loop as an ∨-loop. On the one hand, this lack does not undermine the correctness of the preprocessing procedure that will be introduce in the next section for detecting and handling looping models. On the other hand, it shows that it is possible to design inconsistent ConDec models for which g-sciff does not compute a “deﬁnitive” answer, even in presence of the preprocessing procedure.

246

10 Static Veriﬁcation of ConDec Models with g-SCIFF

ConDec model

no

-loops?

yes Augment the model attaching an absence constraint to each -looping activity

Consider the augmented model for further analysis

no

-loops?

yes

Alert the user and ask a bound

Select a bounded search strategy for g-SCIFF - termination guaranteed - completeness guaranteed

- termination guaranteed - completeness not guaranteed

Fig. 10.7. Preprocessing procedure for detecting and handling the presence of loops inside a ConDec model

10.5 A Preprocessing Procedure We introduce a preprocessing procedure which, given an arbitrary ConDec model, detects the presence of ∧- and ∨-loops and acts accordingly. In general, the preprocessing procedure must be applied on the ConDec model which will be then subject to conﬂict detection. Therefore, in case of ∃-entailment the composite model obtained by combining the model with the property has to be considered. The schema of the preprocessing procedure is depicted in Figure 10.7 and formalized in Listing PreProcess(CM), where CM represents the model under study (or the composition of the model and the property). The procedure consists of the following steps:

10.5 A Preprocessing Procedure

1 2 3 4 5 6 7 8 9 10 11 12 13

247

function: PreProcess(ConDec model CM) returns : An augmented version of CM, where all activities belonging to an ∧-loop are subject to an absence constraint, and a boolean, stating whether g-sciff must switch to a bounded search strategy to guarantee termination. begin L∧ set ← FindAndLoops(CM); CMaug ← CM; foreach activity a ∈ A do foreach set L∧ ∈ L∧ set do if a ∈ L∧ then 0

CMaug

Cm

CMaug

← Cm

∪

a ;

end end end L∨ set ← FindOrLoops(CM aug ); return [ CMaug , L∨ set = ∅] ; end

Function PreProcess(CM) 1. ∧-loop detection is carried out on the model, using the FindAndLoops function. 2. If the model contains ∧-loops, then it is augmented by attaching an absence constraint to each activity that belongs to an ∧-loop, in order to explicitly mark it as a dead activity (see Remark 10.4.1). g-sciff can ﬁnitely deal with the augmented model, without experiencing nontermination issues anymore. Indeed, each absence constraint triggers a negative expectation concerning the targeted activity. Hence, as soon as a positive expectation involving a looping activity is generated, the proof procedure immediately derives a failure, because E-consistency is not respected. 3. ∨-loop detection is carried out on the (possibly augmented) model, using the FindOrLoops function. 4. The outcome of ∨-loop detection is exploited as follows: • If the model is ∨-loop free, then it is guaranteed that g-sciff will terminate when reasoning upon the (augmented) model. • If instead the model contains at least one ∨-loop, then termination cannot be guaranteed anymore. First of all, it is important to recognize this situation and communicating it to the modeler. Second, the search strategy of g-sciff can be changed so as to guarantee termination. In particular, a maximum bound on the length of the execution traces produced by g-sciff can be imposed, selecting a bounded depth-ﬁrst

248

10 Static Veriﬁcation of ConDec Models with g-SCIFF

search strategy for g-sciff6, in the spirit of bounded model checking [43]7 . The bound can be tuned by the user, trying to adapt it ot the “size” of the model. However, it is important to point out that a bounded search strategy preserves termination, but undermines completeness. Indeed, the correctness of a positive computed answer is guaranteed, whereas a negative answer does not prove that the ConDec model contains a conﬂict, but only that there is no compliant execution trace whose length is up to the bound8 . In other words, it is not possible to diﬀerentiate an actual negative answer from a negative answer produced because of the inadequacy of the chosen bound. We conclude the section by discussing how the presented preprocessing procedure can be used to help g-sciff in the veriﬁcation of looping models. Example 10.5.1 (Discovery of dead activities through the combined use of the preprocessing procedure and g-sciff). Let us consider the ﬁve ConDec models shown in Figs. 10.4, 10.5 and 10.6, to the aim of checking whether d is a dead activity, through the combined use of the preprocessing procedure depicted in Fig. 10.7 and g-sciff. After the application of the preprocessing procedure, the ConDec model of Fig. 10.4 is augmented with three absence constraints, attached to activities a, b and c. g-sciff is then applied on the augmented ConDec model, composed with an existence(1,d) constraint. The proof procedure simulates an occurrence of activity d, which in turn triggers the outgoing response constraint. A positive expectation concerning an execution of c is consequently generated. Such a positive expectation is E-inconsistent with the absence of c, and therefore g-sciff correctly proves that d is a dead activity. The same behavior is exhibited for the ConDec model shown in Fig. 10.6 – left side. All the activities contained in the ConDec model of Fig. 10.5 – right side – are directly labeled as dead by the preprocessing procedure. The fact that d is a dead activity is therefore inferred without requiring the use of g-sciff. A diﬀerent situation arises when analyzing the ConDec model of Fig. 10.5 – left side. The preprocessing procedure detects the presence of an ∨-loop, and then a maximum bound for g-sciff is asked to the user. If a bound of 6 7 8

An alternative solution would be to investigate suitable heuristics for driving the search strategy. Bounded model checking addresses the problem of verifying the validity of a formula within a predeﬁned number of the system’s transitions. For example, with a bound of 2 event occurrences, g-sciff would wrongly state that the ConDec model 3..∗

a is conﬂicting. If the bound had been instead ﬁxed to 3 (or a greater value), g-sciff would correctly infer that the model is conﬂict-free, computing the sample execution trace a → a → a as a proof.

10.5 A Preprocessing Procedure

249

2 is provided, then g-sciff incorrectly infers that d is dead. The negative answer, in this case, does not reﬂect reality, but simply says that the model does not support an execution trace composed by the occurrence of activity d and by a further occurrence. Indeed, by choosing a bound of 3 or more, g-sciff would correctly prove that d is not dead, generating the execution trace d → c → e as a proof. Finally, let us consider the ConDec model of Fig. 10.6 – right side. As we have already pointed out, the preprocessing procedure returns that the model contains an ∨-loop, even if such a loop should be actually considered as an ∧-loop, being activity e (implicitly) dead. g-sciff is then conﬁgured to exploit a bounded search strategy, tuned by the user. Independently from the speciﬁc chosen bound value, g-sciff will always return a negative answer when verifying whether d is dead. This answer is correct, because d is actually dead. However, it cannot be interpreted as a “deﬁnitive” negative answer, because it has been produced in a bounded setting.

11 Experimental Evaluation

In Chap. 10, it has been shown how g-sciff can deal with the static veriﬁcation of ConDec models. In order to assess the usability of the proposed approach, it is necessary to evaluate its performance and scalability, comparing it with other veriﬁcation techniques. This chapter aims at showing that g-sciff is an eﬀective technology when it comes to the static veriﬁcation of ConDec models. An extensive experimental evaluation is presented, stressing g-sciff and emphasizing its performance results in both favorable and unfavorable cases. After having discussed how the static veriﬁcation task can be also interpreted as a model checking problem, we compare g-sciff with state-of-the-art explicit and symbolic model checkers, providing an empirical discussion of their beneﬁts and drawbacks. The presented benchmarks will stress the scalability and performance of the veriﬁcation techniques along two signiﬁcant dimensions: • size of the model (number of mandatory constraints contained in the model); • cardinality on activities (presence of existence constraints requiring a minimum number of executions of some activity in the model). All experiments have been performed on a MacBook Intel CoreDuo 2 GHz machine, and considering the SICStus-based implementation of g-sciff.

11.1 Veriﬁcation Procedure with g-SCIFF In Chap. 10, we have shown how the ∃- and ∀-entailment of properties can be tackled by the g-sciff proof procedure, through a reduction to conﬂict detection. Stemming from these theoretical results (Theorems 10.2.2 and 10.3.1 in particular), we now synthesize two concrete procedures for verifying ∃- and ∀-entailment of properties with g-sciff. The veriﬁcation procedures are embedded inside the two Functions ∃-entailment(M,Ψ ) and ∀-entailment(CM,Ψ ). The two functions exploit the preprocessing technique M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 251–275, 2010. c Springer-Verlag Berlin Heidelberg 2010

252

11 Experimental Evaluation

1 2 3 4 5 6 7 8 9 10 11

function: Call GSCIFF(CLIMB speciﬁcation S, initial trace Ti , integer Bound) returns : true, together with a sample execution trace Tf if there is a g-sciff successful derivation for S starting from Ti , f alse otherwise; if Bound = −1, the result is produced by adopting a depth-ﬁrst strategy, otherwise a bounded depth-ﬁrst strategy with bound Bound is selected begin if Bound ≥ 0 then Set g-sciff’s search strategy to bounded-depth-first(Bound); else Set g-sciff’s search strategy to depth-first; end Tf

if S Ti g Δ true then return [true, Tf ] ; end return [false, -] ; end

Function Call GSCIFF(S,Ti ,Bound)

1 2 3 4 5 6 7 8 9 10 11

function: ∃-entailment(ConDec model CM, ConDec property Ψ ) returns : true, together with a sample execution trace if tCLIMB (CM) |=∃ tCLIMB (Ψ ), f alse otherwise begin CMΨ ← comp (CM, Ψ ); [CMΨAug ,Bounded] ← PreProcess(CMΨ ); S ← tCLIMB (CMΨAug ); if ¬Bounded then return Call GSCIFF(S, ∅, −1); else Bound ← ask a bound to the user; return Call GSCIFF(S, ∅, Bound); end end

Function ∃-entailment(CM,Ψ ) introduced in Sect. 10.5 for dealing with looping models. Moreover, they rely on a further function, Call GSCIFF(S,Ti ,Bound), which encapsulates the g-sciff computation on the speciﬁcation S, starting with Ti as initial trace and possibly providing a bound Bound in order to setup a bounded depth-ﬁrst search strategy for g-sciff.

11.2 Scalability of the g-SCIFF Proof Procedure

1 2 3 4 5 6 7 8 9 10

253

function: ∀-entailment(ConDec model CM, ConDec property Ψ ) returns : true if tCLIMB (CM) |=∀ Ψ , f alse, together with a counterexample execution trace, otherwise begin foreach Ci ∈ Ψ do ICcompl ← tIC (Ci ); [Success,T ] ← ∃-entailment(CM,ICcompl); if Success then return [false, T ] ; end end return [true, -] ; end

Function ∀-entailment(CM,Ψ )

a4 a2 1..*

a5

a1

a6 a3 a7

Fig. 11.1. An instance of the branching responses benchmark, with 7 activities and 8 constraints

11.2 Scalability of the g-SCIFF Proof Procedure A ﬁrst quantitative evaluation of g-sciff is focused on artiﬁcial yet signiﬁcant ConDec models, employing diﬀerent kinds of existence and relation constraints. The focus is mainly on existence and relation constraints because they involve positive expectations, whose management is the most expensive task for g-sciff. Indeed, g-sciff follows a generative approach, where positive expectations are transformed into happened events, which in turn must be combined with the integrity constraints of the model under study. 11.2.1 The Branching Responses Benchmark The ﬁrst benchmark aims at evaluating the scalability of g-sciff when a growing number of branching response constraints is used. For this reason, it will be referred to as the branching responses benchmark. Each response has a branching factor of 2. The structure of the model is as follows:

254

11 Experimental Evaluation

Table 11.1. Performance of g-sciff when reasoning upon the branching responses benchmark # of constraints

time (sec.)

# of constraints

time (sec.)

4

0.00

512

1.04

8

0.01

1024

3.64

16

0.01

2048

14.01

32

0.02

4096

56.85

64

0.04

8192

249.77

128

0.10

16384

1100.26

256

0.34

32768

6149.99

7000

Execution time (sec.)

6000

5000

4000

3000

2000

1000

0 0

5000

10000

15000

20000

25000

30000

35000

Nr. Constraints

Fig. 11.2. Trend of g-sciff when reasoning upon the branching responses benchmark

• the model contains an activity a1 which is expected to be executed at least once; • a1 is source of a branching response, which states that one among activities a2 and a3 must be executed after a1 ; • both a2 and a3 are sources of a branching response as well, and this structure is repeated until a “frontier” is reached; • all the activities belonging to this “frontier” have an outgoing negation precedence constraint pointing to a1 . The benchmark is then built by increasing the number of activities and their branching response constraints – Fig. 11.1 shows the instance of the benchmark where 7 activities and 8 constraints are employed.

11.2 Scalability of the g-SCIFF Proof Procedure

255

The negation precedence constraints are used to introduce a conﬂict in the model, consequently forcing g-sciff to explore the entire search space. The model is conﬂicting because: 1. a1 must be executed; 2. after having generated an occurrence of a1 , no matter what combination of choices is made to fulﬁll all the triggered branching response constraints, one among the activities in the frontier must be eventually executed; 3. however, the execution of an activity in the “frontier” triggers one of the negation precedence constraints, forbidding a previous occurrence of a1 . The proof tree built by g-sciff strictly resembles the structure of the model itself: it must explore the entire model before trying each possible combination of choices, before detecting the conﬂict. In the instance shown in Fig. 11.1, g-sciff tries to generate the following execution traces: • • • •

a1 a1 a1 a1

→ a2 → a2 → a3 → a3

→ a4 ; → a5 ; → a6 ; → a7 .

All these attempts lead to a failure, because the execution of ai (i = 4, . . . , 7) forbids a previous execution of a1 ; each failure is detected by g-sciff through the consistency transition, because there are two contradictory expectations concerning a1 . Nevertheless, as attested by the timings reported in Table 11.1 and Fig. 11.2, g-sciff scales very well: when reasoning upon the instance of the benchmark that involves 4096 constraints, the presence of a conﬂict is detected in less than one minute. 11.2.2 The Alternate Responses Benchmark This benchmark focuses on alternate response constraints and their interplay with the existence constraint; it will be referred to as the alternate responses benchmark. Its structure is shown in Fig. 11.3; it is parametric in N and K, and can be brieﬂy described as follows: 1. K − 1 alternate response constraints interconnect a sequence of K activities; 2. the ﬁrst activity of the sequence is associated to an N..* cardinality constraint; 3. the last activity of the sequence is associated to a 0..N-1 cardinality constraint. An interesting property of alternate response constraints is that the target activity must be executed at least as many times as the source activity: each

256

11 Experimental Evaluation

N..*

a1

0..N-1

a2

...

aK

Fig. 11.3. The alternate responses benchmark, parametrized in N and K

Fig. 11.4. Trend of g-sciff when reasoning upon the alternate responses benchmark

occurrence of the source requires one separated execution of the target. In our speciﬁc case, the number of executions of activity a2 must be therefore greater than the one of a1 (i.e., always greater than N ), the number of executions of activity a3 must be greater than the one of a2 , and so on. This implies that aK must be executed at least N times. However, such a requirement contrasts with the absence N constraint attached to aK , introducing a conﬂict inside all instances of the benchmark. When checking whether the alternate responses benchmark contains a conﬂict, g-sciff intensively applies the consistency transition and the underlying CLP solver. In fact, each generated occurrence triggers an expectation about the next one, together with a negative expectation expressing the interposition, i.e., stating that the source activity cannot be executed again until the next activity is eﬀectively executed (see the formalization provided in Example 10.4.1). By looking at the timings reported in Table 11.1 and the trends depicted in Fig. 11.2, it is apparent that the N value is, in this setting, critical. When N = 1, veriﬁcation reduces to the case in which basic response constraints are

11.2 Scalability of the g-SCIFF Proof Procedure

257

Table 11.2. Performance of g-sciff when reasoning upon the alternate responses benchmark

K

N=1

N=2

time (sec.) N=3

N=4

N=5

1

0.0

0.0

0.01

0.02

0.16

2

0.0

0.0

0.01

0.05

0.36

3

0.0

0.01

0.03

0.11

0.66

4

0.0

0.02

0.05

0.2

1.26

5

0.01

0.02

0.08

0.31

2.0

6

0.01

0.04

0.11

0.47

2.75

7

0.01

0.04

0.15

0.65

4.32

8

0.01

0.05

0.2

0.88

5.93

9

0.02

0.06

0.25

1.15

10.51

10

0.01

0.07

0.32

1.47

13.91

11

0.01

0.09

0.39

1.84

20.0

12

0.02

0.1

0.46

2.32

30.25

13

0.02

0.12

0.55

2.85

36.61

14

0.04

0.14

0.64

3.53

54.37

15

0.03

0.15

0.75

4.83

63.32

16

0.03

0.17

0.87

5.7

71.84

17

0.04

0.2

1.05

8.11

100.21

18

0.04

0.21

1.15

9.42

110.49

19

0.05

0.24

1.3

11.92

124.49

20

0.05

0.27

1.48

14.85

143.01

adopted instead of alternate ones, because the interposition part does not come into play (for each activity, there is only a single occurrence generated by the proof procedure). Hence, an answer is provided almost immediately even for large values of K. On the contrary, when N is increased, each one of the N required executions generates its own negative “interposition” expectation, which must be combined with the expectations about the other N − 1 occurrences of the same activity, to the aim of preserving E-consistency. Such combinations require an extensive use of the CLP solver, which is in charge of handling and propagating all the involved temporal constraints. At the end of the the computation, g-sciff recognizes that all the N positive expectations about

258

11 Experimental Evaluation

N..*

a1

0..N-1

a2

...

aK

Fig. 11.5. The chain responses benchmark, parametrized in N and K

aK actually refer to diﬀerent occurrences of the activity, contradicting the absence N constraint attached to aK . Anyway, we should not forget that ConDec is a language thought for the declarative and open speciﬁcation of interaction models. In this respect, two points deserve a brief discussion. First of all, in reality it is rather uncommon to ﬁnd situations where some activity is constrained to be always executed several times. Furthermore, when many tight relationships are introduced inside a model, the ConDec philosophy is being broken. ConDec aims at leaving the execution as unconstrained as possible. Therefore, in this situation the modeler should ask herself whether ConDec is the right notation for dealing with the problem at hand. Maybe a procedural approach would ﬁt better. 11.2.3 The Chain Responses Benchmark The chain responses benchmark is a modiﬁcation of the alternate responses one: all the alternate response constraints are substituted with chain response constraints. As pointed out in Sects. 5.3 and 6.1, chain response constraints are the only elements of ConDec which must to be reformulated when switching from a qualitative to a quantitative notion of time, due to the diﬀerent characterization of temporal contiguity. The benchmark is speciﬁcally thought to compare the two formulations. Let us ﬁrst comment on the behavior exhibited on the qualitative formalization. We brieﬂy recall how the chain response constraint is formalized in this setting: tIC

a •= −= −= − b

H(exec(a), Ta ) → E(exec(b), Tb ) ∧ Tb = Ta + 1.

In other words, when g-sciff generates an (intensional) occurrence of the source activity, say, H(exec(a), Ta1 ), then the the required occurrence of the target activity will be in turn generated with a ﬁxed time equal to Ta1 + 1. Thus, when reasoning upon the chain responses benchmark, g-sciff generates N sequences of event occurrences concerning a1 -aK , where: • the ﬁrst event occurrence of each sequence (associated to a1 ) has a variable time; • all the other time values of the sequence are completely ﬁxed with respect to such a variable time.

11.2 Scalability of the g-SCIFF Proof Procedure

259

Table 11.3. Performance of g-sciff when reasoning upon the chain responses benchmark qualitative time (tCLIMB )

quantitative time (tCLIMB )

K

N=1

time (sec.) N=2

N=3

K

N=1

time (sec.) N=2

N=3

1

0.00

0.01

0.04

1

0.00

0.01

0.03

2

0.00

0.02

0.07

2

0.00

0.02

0.35

3

0.00

0.03

0.15

3

0.00

0.09

4.04

4

0.00

0.05

0.24

4

0.00

0.34

27.12

5

0.10

0.07

0.39

5

0.01

1.13

134.77

6

0.00

0.09

0.60

6

0.00

3.02

616.94

7

0.01

0.13

0.89

7

0.00

7.63

2733.64

8

0.00

0.17

1.27

8

0.00

17.10

>1h

9

0.01

0.21

1.81

9

0.01

37.09

>1h

10

0.01

0.28

2.38

10

0.01

71.73

>1h

11

0.00

0.33

3.18

11

0.01

137.03

>1h

12

0.00

0.41

4.25

12

0.00

256.48

>1h

13

0.00

0.53

5.55

13

0.01

756.34

>1h

14

0.01

0.65

7.24

14

0.01

1460.47

>1h

15

0.00

0.78

9.36

15

0.01

2332.65

>1h

This greatly simpliﬁes the management of temporal constraints, and, as shown in Fig. 11.6 and Table 11.3 – left side, g-sciff does therefore scale very well: it employs less than 10 seconds for the instance of the benchmark containing 15 chain response constraints and requiring at least 3 executions of a1 . As in the case of the alternate responses benchmark, the most inﬂuencing parameter is N . When temporal contiguity is modeled by following a quantitative approach, the chain response constraint is formalized by including a negative expectation forbidding the occurrence of any activity between two consecutive executions of the source and the target: H(exec(a), Ta ) →E(exec(b), Tb ) ∧ Tb > Ta −= −= − b tIC a •= ∧ EN(exec(X ), Tx ) ∧ Tx > Ta ∧ Tx < Tb .

260

11 Experimental Evaluation

Execution time (sec.)

Qualitative time 10 9 8 7 6 5 4 3 2 1 0

N=1 N=2 N=3

1

3

5

7

9

11

13

15

K

Fig. 11.6. Trend of g-sciff when reasoning upon the chain responses benchmark with a qualitative notion of time

Quantitative time

Execution time (sec.)

3000 2500 2000

N=1

1500

N=2

1000

N=3

500 0 1

3

5

7

9

11

13

15

K

Fig. 11.7. Trend of g-sciff when reasoning upon the chain responses benchmark with a quantitative notion of time

The management of such a negative expectation is even more diﬃcult than the one used to express the interposition behavior of alternate constraints, because it involves a variable activity (X), which matches with all the generated event occurrences. The timings needed by g-sciff are reported in Fig. 11.7 and Table 11.3 – right side, and clearly point out such a diﬃculty. However, as argued for the alternate responses benchmark, when the ConDec diagram contains many chain relationship, it tends to become a procedural, closed model, which would be probably better captured using a procedural, ﬂoworiented language.

11.3 Static Veriﬁcation of ConDec Models as Model Checking

261

11.3 Static Veriﬁcation of ConDec Models as Model Checking Thanks to the formalization of ConDec models in terms of propositional Linear Temporal Logic (LTL) formulae [191, 173]1 , it is possible to carry out their static veriﬁcation by means of model checking techniques. To show how this can be eﬀectively done, we ﬁrst investigate how ∃- and ∀-entailment can be formalized in the LTL setting, and how they can be respectively reduced to formulae satisﬁability and validity. We then provide a brief overview of model checking, discussing how satisﬁability and validity can be cast as a model checking problem. In this way, it becomes possible to compare the performance of g-sciff with the one of state-of-the-art model checkers, in the ConDec setting. 11.3.1 Existential and Universal Entailment of ConDec Properties in LTL Following the natural language description provided in Sect. 8.3.1, we can easily provide a corresponding LTL-based formalization. The formalization relies on the concept of ﬁnite support, which gives a formal account to the notion of compliance of an LTL execution trace with a ConDec model. As stated in Def. 3.7.5, a ConDec model CM ﬁnitely supports a trace TL 2 (i.e., TL complies with CM) if and only if: TL |=L tLTL (CM) ∧ term(CM) The ﬁniteness requirement is needed to capture that, in ConDec, each course of interaction must eventually terminate. Indeed, standard temporal logics rely on inﬁnite traces. As extensively discussed in Section 3.7.3, two possible workarounds for such a mismatch can be investigated: either ﬁnite LTL models are considered, or the LTL formula representing the model is augmented with the termination property. Since the ﬁrst solution requires to modify the model checking algorithm, making state-of-the-art model checkers inapplicable, we rely in this chapter on the second one. Starting from the notion of ﬁnite support, ∃- and ∀-entailment of an LTL property by a ConDec model can be characterized as follows. Deﬁnition 11.3.1 (∃-entailment in LTL). A ConDec model CM ∃-entails an LTL property ϕ (tLTL (CM) |=∃ ϕ) if and only if: ∃TL TL |=L tLTL (CM) ∧ term(CM) ∧ ϕ 1 2

The translation has been embedded inside the tLTL function, introduced in Sect. 3.7. LTL execution traces correspond to LTL model, and have been introduced in Def. 3.6.1.

262

11 Experimental Evaluation

Deﬁnition 11.3.2 (∀-entailment in LTL). A ConDec model CM ∀-entails an LTL property ϕ (tLTL (CM) |=∀ ϕ) if and only if: tLTL (CM) ∧ term(CM) =⇒ ϕ ∀TL TL |=L Note that if also the property is speciﬁed in ConDec, then we can seamlessly compose it with the model under study, before applying the translation function. Indeed, from the deﬁnitions of ConDec composition and of tLTL , it holds that, given a ConDec model CM and a ConDec property Ψ : tLTL (CM) ∧ tLTL (Ψ ) ⇐⇒ tLTL (comp(CM, Ψ )) 11.3.2 ConDec Properties Veriﬁcation as Satisﬁability and Validity Problems We introduce the satisﬁability and validity of an LTL formula. Deﬁnition 11.3.3 (Satisﬁability). An LTL formula ϕ is satisﬁable if and only if there exists at least one LTL trace which entails the formula: & % sat(ϕ) ∃TL TL |=L φ Deﬁnition 11.3.4 (Validity). An LTL formula ϕ is valid if and only if all possible LTL traces satisfy the formula: % & val(ϕ) ∀TL TL |=L φ Satisﬁability and validity can then directly accommodate the notions of ∃and ∀-entailment. Conﬂict detection is a speciﬁc case of ∃-entailment. Theorem 11.3.1 (ConDec conﬂict in terms of LTL satisﬁability). A ConDec model CM is conﬂict-free if and only if sat tLTL (CM) ∧ term (CM) Proof. Straightforward from the deﬁnitions of satisﬁability (Def. 11.3.3) and of LTL-based ∃-entailment (Def. 11.3.1), considering a true property. Theorem 11.3.2 (∃-entailment in terms of LTL satisﬁability). A ConDec model CM ∃-entails a ConDec property Ψ if and only if sat tLTL (CM) ∧ term (CM) ∧ tLTL (Ψ ) Proof. Straightforward from the deﬁnitions of satisﬁability (Def. 11.3.3) and of LTL-based ∃-entailment (Def. 11.3.1).

11.3 Static Veriﬁcation of ConDec Models as Model Checking

263

Theorem 11.3.3 (∀-entailment in terms of LTL validity). A ConDec model CM ∀-entails a ConDec property Ψ if and only if val tLTL (CM) ∧ term (CM) =⇒ tLTL (Ψ ) Proof. Straightforward from the deﬁnitions of validity (Def. 11.3.4) and of LTL-based ∀-entailment (Def. 11.3.2). Example 11.3.1 (LTL-based discovery of dead activities). Let us consider the looping ConDec model Loop shown in Fig. 10.4, p. 243 – left side. Suppose that the modeler wants to know whether activity d is dead or not. The problem consists in verifying if the ConDec model ∀-entails the absence of d, which is translated into LTL as ¬d. This problem in turns reduces to check whether the formula tLTL (Loop) ∧ term (CM) =⇒ ¬d is valid. The answer is positive, and attests that there does not exist a ﬁnite execution trace supported by the model which contains d. If we had erroneously forgot to take into account the term (CM) property, then a wrong answer would be produced: the formula tLTL (CM) =⇒ ¬d is not valid, because the inﬁnite-length trace d → c → a → b → c → . . . contains an execution of activity d. Clearly, the trace respects all the constraints of the model, but it is however not ﬁnitely supported by the model. As in the case of g-sciff, in LTL it holds that ∀-entailment can be reduced to ∃-entailment. Diﬀerently from g-sciff, the reduction simply requires to negate the property, without requiring to ﬁnd an explicit complementation. In fact, satisﬁability and validity are intimately connected: a formula ϕ is valid if its negation is unsatisﬁable, i.e. val(φ) ⇐⇒ ¬sat(¬φ). Theorem 11.3.4 (Reduction of ∀-entailment to ∃-entailment in LTL). A ConDec model CM ∀-entails a ConDec property Ψ if and only if it does not ∃-entail the negation of tLTL (Ψ ), i.e., if and only if ¬sat tLTL (CM) ∧ ¬ tLTL (Ψ ) ∧ term (CM) Proof. tLTL (CM) |=∀ tLTL (Ψ ) ⇐⇒ val tLTL (CM) ∧ term (CM) =⇒ tLTL (Ψ ) ⇐⇒ ¬sat ¬ tLTL (CM) ∧ term (CM) =⇒ tLTL (Ψ ) ⇐⇒ ¬sat tLTL (CM) ∧ term (CM) ∧ ¬ tLTL (Ψ ) ⇐⇒ tLTL (CM) |=∃ ¬ tLTL (Ψ )

(Def. 11.3.2)

(Def. 11.3.1)

264

11 Experimental Evaluation cook

2 close heat open door 1

5 start close heat

start cooking

done

close door 3

6 start oven

start close

close

open door

warmup

reset

start oven 4

close door start error

open door

7 start close error

Fig. 11.8. Interpreted transition system of a micro-wave oven (from [79])

11.3.3 Model Checking Model checking [79] designates a collection of technique for the automatic veriﬁcation of ﬁnite state concurrent systems. Model checking started in the 1980’s from seminal research conducted by Clarke and Emerson, and has found widespread application in the hardware and software industries, ranging from veriﬁcation of security and cryptographic protocols to debugging of software programs and digital circuits. The model checking process consists of three steps [79]: Modeling of the (current draft of the) system by means of a formalism accepted by the model checking tool. The most widespread formalism used in model checking is an interpreted (labeled) transition system, also called Kripke model, a non-deterministic state machine in which each state is associated to the set of propositions true in that state. An example is given in Fig. 11.8. Transition systems can accommodate inﬁnite execution traces, and can be easily translated into automata on inﬁnite words. Speciﬁcation of the properties that the system must satisfy, using some logic. Temporal logics, such as propositional Linear Temporal Logic (LTL), are commonly employed to accomplish this task, because they provide a powerful yet intuitive way for concisely characterizing the system’s evolution over time. Veriﬁcation is then carried out automatically, checking whether the desired properties are entailed by the model of the system. If a properties is violated, the model checker generates an error execution trace, which represents a counterexample and can help in the identiﬁcation of where the errors is located. For example, the transition system of Fig. 11.8 could be veriﬁed against the property (start ⇒ ♦heat), which states that the systems must always guarantee that every time the oven is started, then it will eventually heat. A model checker would answer that the property

11.3 Static Veriﬁcation of ConDec Models as Model Checking ¬startheat

265

true

true init

heat

1

Fig. 11.9. A non-deterministic B¨ uchi automaton representing the LTL formula (start ⇒ ♦heat), produced by the LTL2BA algorithm [112]

does not hold, providing e.g. a trace which starts from state 1 and contains the inﬁnite sequence of transitions start oven → close door → reset → open door → start oven → . . . Formally, given a Kripke model M and a temporal property ϕ, the model checking problem is to verify whether M, s |= ϕ meaning that each possible execution of M starting from state s satisﬁes the property. Usually, s is one of the initial states of the transition system – in this case, it can be omitted. If M |= ϕ, then a counterexample is returned by the model checker. Among the advantages of model checking techniques, we ﬁnd that: 1. they do not require the intervention of the user during the veriﬁcation phase, i.e., they are fully automated; 2. they can handle inﬁnite-length executions; 3. for propositional temporal logics such as LTL, they are decidable, and thus guarantee termination. Classical model checkers, called explicit-state, face the model checking problem by relying on automata-based methods. The core idea has been initially proposed by Sistla, Vardi and Wolper [224], and consists in the following steps: 1. translation of a temporal logic formula into a B¨ uchi automaton, which accepts exactly those traces which satisfy the formula – Fig. 11.9 shows how the LTL formula (start ⇒ ♦heat) can be represented as a nondeterministic B¨ uchi automaton3 ; 2. composition of the automaton representing the formula with the automaton obtained from the Kripke model; 3. model checking as a standard language containment automata-based technique. SPIN [133] is probably the most popular state-of-the-art explicit model checker. The most critical aspect of explicit model checking is known as the state explosion problem [80], and essentially arises because: 3

Propositions, i.e. events, are in this case attached to transitions instead of states.

266

11 Experimental Evaluation

• a Kripke model is exponential in the size of the system description, leading to produce intractable situations even for small applications4 • the B¨ uchi automaton built upon an LTL formula is exponential in the size of the formula [79, 88]. More speciﬁcally, the time and space complexity of LTL model checking is O |M| × 2|ϕ| where M is the Kripke model, and ϕ the property to be veriﬁed. The state explosion problem motivated research about how to represent the states in a compact way. Two major mainstream approaches emerged in the last decade [80]: Abstraction techniques exploit the domain knowledge of the system and the property in order to obtain a Kripke model which only deals with the relevant portions of the system. Symbolic veriﬁcation employs more compact data structures to store the transition system and the automaton representing the property, without any information loss. As stated in [80]: A fundamental breakthrough [for the state explosion problem] was made in the fall of 1987 by Ken McMillan, who was then a graduate student at Carnegie Mellon. He argued that larger systems could be handled if transition relations were represented implicitly with ordered Binary Decision Diagrams (BDDs) [50]. By using the original model checking algorithm with the new representation for transition relations, he was able to verify some examples that had more than 1020 states [52]. NuSMV [76] is one of the most popular state-of-the-art symbolic model checkers. 11.3.4 Reduction of Validity and Satisﬁability to Model Checking In the ConDec setting, both the model of the system and the properties are represented in terms of LTL formulae. In this respect, there is a conceptual diﬀerence with model checking, in which the model of the system is represented by a (procedural) Kripke model. This aﬀects also the veriﬁcation task: as we have seen, the ∃- and ∀-entailment of properties are not directly cast as a model checking problem, but they are instead reduced to satisﬁability and validity of formulae. In order to employ state-of-the-art model checkers for the static veriﬁcation of ConDec models, it is therefore necessary to show how model checking is able to check for satisﬁability and validity. Rozier and Vardi tackled this issue in [206]. Their approach centers around the construction of an universal Kripke model. 4

For example, in a concurrent system the Kripke structure is exponential in the number of interacting processes

11.3 Static Veriﬁcation of ConDec Models as Model Checking

ask

267

inform

repeat

ask inform repeat

ask inform

inform repeat

ask repeat

Fig. 11.10. An example of universal Kripke model built upon three activities; a straightforward modiﬁcation can be applied to generate only compact execution traces

Deﬁnition 11.3.5 (Universal Kripke model). Given a set of proposition symbols S, the universal Kripke model over S, written univ (S), is an interpreted transition system able to generate all the possible execution traces over the proposition symbols of S. Thus, the universal model built upon an LTL formula ϕ corresponds to univ (P (ϕ)), where P (ϕ) is the set of proposition symbols contained in ϕ. In the ConDec setting, propositional symbols are the activities contained inCM , CoCM and side the model. Hence, given a ConDec model CM = ACM , Cm Ψ Ψ Ψ a ConDec property Ψ = A , Cm , Co , the universal model over CM and Ψ is

univ ACM ∪ AΨ . Fig. 11.10 illustrates an example of universal model built upon a ConDec speciﬁcation including the three activities of ask, inform and repeat. l Given an LTL formula ϕ . . . • validity checking can be tackled by model checking ϕ against univ (P (ϕ)) [206]: if the model checker returns a negative answer, the generated counterexample shows that there exists a possible execution trace which violates ϕ; • satisﬁability checking can be tackled by model checking ¬ϕ against univ (ϕ) [206]: if the model checker returns a negative answer, the generated counterexample is actually a positive example for the original formula ϕ, and shows that there exists at least one possible execution trace which satisﬁes ϕ.

268

11 Experimental Evaluation

1 2 3 4 5 6 7 8 9 10

function: ∃-entailmentM C (ConDec model CM, ConDec property Ψ ) returns : true, together with a sample LTL execution trace if tLTL (CM) |=∃ tLTL (Ψ ), f alse otherwise begin U ← BuildUniversalModel(A(CM) ∪ A(Ψ )); μψ ← tLTL (comp (CM, Ψ )); [Success, TL ] ← ModelChecking(U, ¬ (μψ ∧ term (CM))); if ¬Success then return [true, TL ] ; else return [false, -] ; end end

Function ∃-entailmentMC (CM,Ψ )

1 2 3 4 5 6

function: ∀-entailmentM C (ConDec model CM, ConDec property Ψ ) returns : true if tLTL (CM) |=∀ tLTL (Ψ ), f alse, together with an execution trace amounting as a counter-example, otherwise begin univ ← BuildUniversalModel(A(CM) ∪ A(Ψ )); μ ← tLTL (CM); ψ ← tLTL (Ψ ); return ModelChecking(univ, μ ∧ term (CM) ⇒ ψ); end

Function ∀-entailmentMC (CM,Ψ ) Deﬁnition 11.3.6 (Validity checking via model checking). An LTL formula ϕ is valid if and only if univ (P (ϕ)) |=L ϕ. Deﬁnition 11.3.7 (Satisﬁability checking via model checking). An LTL formula ϕ is satisﬁable if and only if univ (P (ϕ)) |=L ¬ϕ. Note that, in the two deﬁnitions, we have used LTL entailment event if an interpreted transition system is not an LTL model: LTL models are interpreted, linear sequences of states. The intended meaning is that ϕ must be entailed by all the execution traces produced by the Kripke model. These correspond to all possible traces when the Rozier and Vardi’s universal model is used. 11.3.5 Veriﬁcation Procedure by Model Checking Functions ∃-entailmentMC (CM,Ψ ) and ∀-entailmentMC (CM,Ψ ) implement the ∃- and ∀-entailment of properties in the LTL setting, by reducing satisﬁability and validity to model checking. Besides the function tLTL , which maps a ConDec model onto the corresponding LTL representation, two further functions are exploited:

11.4 Comparative Evaluation

269

• BuildUniversalModel(ϕ) builds a universal Kripke model able to generate all the execution traces over the proposition symbols of ϕ, i.e., over all the activities of the ConDec model and the property under study; • ModelChecking(M,ϕ) model checks M againts ϕ, returning true if M meets ϕ in every possible execution, f alse, together with a counterexample, otherwise.

11.4 Comparative Evaluation In order to choose a suitable model checker and run a comparative evaluation of g-sciff with the state of the art, we referred to the results of the experimental investigation conducted by Rozier and Vardi concerning LTL satisﬁability checking [206]. The authors found that the symbolic approach is clearly superior to the explicit approach, and that NuSMV is the best performing model checker for the benchmarks they considered. We thus chose NuSMV and ran our benchmarks to compare g-sciff with it. Some preliminary tests we carried out by using the SPIN explicit model checker conﬁrmed the results of Rozier and Vardi: SPIN could not handle in reasonable time even a ConDec chart and properties as simple as the ones introduced in Sect. 8.3.4 for the order&payment protocol. g-sciff, instead, correctly handles all the queries described in Sect. 8.3.4, p. 184, with the following timings: Query 8.3.1 in 10 ms, Query 8.3.2 in 20 ms, Query 8.3.3 in 420ms and Query 8.3.4 in 80ms. Unfortunately, the comparison could not cover all relevant aspects of the ConDec++ language, such as quantitative temporal aspects (presented in Query 8.3.4) and data-aware conditions, because NuSMV and all the most diﬀused model checkers rely on propositional temporal logics, and do not provide support for Metric Temporal Logic (MTL) [13]. Anyway, since existing MTL tools seem to use explicit model checking and not symbolic model checking, our feeling is that g-sciff would largely outperform them on these instances. 11.4.1 The Order&Payment Benchmarks To obtain our comparison benchmarks, we complicated the model shown in Sect. 8.3.4 – Fig. 8.4 so as to stress the veriﬁcation techniques both in satisﬁable and unsatisﬁable cases. In particular, as for the alternate responses and chain responses benchmarks (see Sects. 11.2.2 and 11.2.3), they scale along two axes: Size of the model. Instead of a single activity, standard payment consists of a sequence of K steps (plus the two start and complete payment activities). Every two consecutive steps are linked by an alternate succession relation. Each alternate succession has two branches; the second branch

270

11 Experimental Evaluation standard payment start failure

start payment

step1 failure step 1

step2 failure step 2

stepK-1 failure ...

stepK failure step K

complete payment

Fig. 11.11. Parametric extension of the order&payment ConDec protocol, shown in Fig. 8.4

is used to model a possible failure of the current step (start failure, step 1 failure, . . . ). This extension is depicted in Fig. 11.11. Number of required executions We add an existence N..* constraint on activity payment failure, simulating that a at least N failures are experienced when trying to pay. g-sciff and NuSMV have been compared on this parametrized version of the order&payment protocol, by considering the following veriﬁcation tasks: Benchmark O&Punsat . ∃-entailment of query 8.3.2 – p. 185, attaching the absence constraint about the standard payment on the ﬁrst activity of the payment sequence, i.e., start payment; Benchmark O&Psat . ∀-entailment of query 8.3.1 – p. 185, that aims at discovering whether send receipt is a dead activity. Both properties are not satisﬁed by the order&payment protocol. Hence, the ﬁrst benchmark concerns veriﬁcation of an unsatisﬁable property, whereas the second one requires to produce a counterexample demonstrating the ∃entailment of the negated property (executability of send receipt). The generation of a counterexample increases the veriﬁcation time. The runtime resulting from the benchmarks has been presented in [172] and is reported in Table 11.4. Fig. 11.5 gives a graphical intuition about the trends of g-sciff and NuSMV. Each chart ﬁxes the number of steps concerning the payment (K parameter) and shows how the veriﬁcation techniques are aﬀected by the number of payment failures (N parameter). It turns out that g-sciff outperforms NuSMV in most cases, up to several orders of magnitude. This is especially true by focusing on the O&Punsat benchmark, for which g-sciff always terminates in less than 0.15 s, while NuSMV takes up to 136 s. For the O&Psat benchmark, g-sciff does comparatively better as K increases, for a given N, whereas NuSMV improves and eventually outperforms g-sciff, for a given K, as N increases (see the instance where K = 5 and N = 5). 11.4.2 Discussion The main diﬀerence between g-sciff and model checking is that in g-sciff queries are evaluated top-down, i.e., starting from expectations and using

11.4 Comparative Evaluation

271

Table 11.4. Results of the order&payment protocol benchmarks (SCIFF/NuSMV ), in seconds [172] N \K

0

1

2

3

4

5

benchmark O&Punsat 0

0.01/0.20

0.02/0.57

0.03/1.01

0.02/3.04

0.02/6.45

0.03/20.1

1

0.02/0.35

0.03/0.91

0.03/2.68

0.04/4.80

0.04/8.72

0.04/29.8

2

0.02/0.46

0.04/1.86

0.05/4.84

0.05/10.8

0.07/36.6

0.07/40.0

3

0.03/0.54

0.05/2.40

0.06/8.75

0.07/20.1

0.09/38.6

0.10/94.8

4

0.05/0.63

0.05/2.34

0.08/9.51

0.10/27.1 0.11/56.63

0.14/132

5

0.05/1.02

0.07/2.96

0.09/8.58

0.12/29.0

0.14/136

0.15/134

0.08/37.9

benchmark O&Psat 0

0.02/0.28

0.03/1.02

0.04/1.82

0.05/5.69

0.07/12.7

1

0.06/0.66

0.06/1.67

0.07/4.92

0.08/9.21

0.11/17.3 0.15/57.39

2

0.14/0.82

0.23/3.44

0.33/8.94

0.45/22.1

0.61/75.4 0.91/72.86

3

0.51/1.01

1.17/4.46 1.87/15.87 3.77/41.2

5.36/79.2

11.4/215

4

1.97/1.17

4.79/4.43 10.10/17.7 26.8/52.2

61.9/116

166/268

5

5.78/2.00

16.5/5.71 48.23/16.7

244/296

446/259

120/60.5

abduction as a mechanism to simulate events. No intermediate format needs to be generated, which eliminates a computationally expensive step. By going top-down, the veriﬁcation algorithm only considers relevant portions of the search space, which can boost performance. On the downside, the performance strongly depends on the way CLIMB programs are written. Due to the leftmost, depth-ﬁrst search tree exploration strategy that g-sciff inherits from Prolog, the order of clauses inﬂuences performance, and so does the ordering of atoms inside the clauses. However, this does not impact on soundness, completeness and termination. In particular, since veriﬁcation is performed by g-sciff starting from expectations, its performances are heavily inﬂuenced by the presence of existence/choice constraints in the ConDec model and query. Indeed, existence and choice constraints are the ones that, translated to CLIMB, impose expectations about the execution of a certain activity independently from the other activities and constraints. At the beginning of the g-sciff computation, these expectations are transformed to happened events via the fulﬁller transition. These happened events, in turn, trigger new parts of the model under study, leading to the generation of new expectations and happened events. This is why the performance of g-sciff decreases as the N value of the benchmarks increases: all the N expected executions are simulated, triggering the outgoing

272

11 Experimental Evaluation

Table 11.5. Trends of g-sciff and NuSMV when reasoning upon the order&payment protocol benchmark O&Punsat

benchmark O&Psat

g-sciff: NuSMV:

relationships N times, and so on. On the other side, if a portion of the ConDec model is not aﬀected by this propagation, i.e., its execution is not mandatory, then its constraints do not aﬀect veriﬁcation at all. The extreme case is the one in which no activity is expected to be executed by the ConDec model nor by the (complemented) query: in this situation, independently of the size of the

11.4 Comparative Evaluation

273

model, g-sciff answers immediately by returning the void execution trace as a proof. This is the case, for example, when presence of conﬂict is checked on the order&payment diagram shown in Fig. 8.4. This smart exploration of the search space motivates why when K (i.e., the number of constraints) increases, performances of g-sciff degrade gracefully. Furthermore, it suggests that suitable heuristics that choose how to explore the search tree could help to improve the g-sciff performance. This is subject for future research. Diﬀerently from g-sciff, model checking techniques ﬁrst translate the formulae representing the ConDec model and the query to an intermediate structure: a B¨ uchi automaton in the case of explicit model checking, a BDD in the case of symbolic model checking. As already pointed out, this translation is exponential in the size of the formula [79, 88]. When model checking is adopted to check if declarative speciﬁcations are satisﬁable, this is a critical point, because both the model of the system and the property are represented by means of LTL formulae. Furthermore, the satisﬁability and validity problems are reduced to model checking by exploiting the notion of universal Kripke model, which is exponential in the number of propositional symbols: given a |P | set P , the universal model univ(P ) has 2|P | states and 22 transitions. The state explosion issue has, for ConDec, also an intuitive explanation. A ConDec model is a ﬂexible, loosely-coupled speciﬁcation, formalized in terms of a declarative LTL formula. Model checking translates such a formula into a corresponding transition system, which explicitly enumerates all the execution traces which satisfy the formula, i.e., comply with the ConDec model. In this respect, the translation phase experiences the same drawbacks of procedural speciﬁcation languages. Even if symbolic model checking experiences a more graceful degradation rather than explicit model checking (due to the compactness of BDDs), it cannot avoid state explosion when verifying declarative speciﬁcations such as the ones obtained from a ConDec model. Moreover, practical experiments show that the performance of symbolic methods is highly unpredictable; this phenomenon can be partially explained by complexity theoretical results which state that the use of BDDs does not improve worst case complexity [80]. It then comes as no surprise that NuSMV experiences an exponential degradation as the K value of our benchmark increases: K reﬂects the number of constraints contained in the ConDec model, and thus indirectly aﬀects the size of the underlying LTL formalization. When N increases, the degradation is more graceful; indeed, an existence constraint stating that activity a must be executed at least N times is modeled in LTL by applying the (recursive) translation ⎛ ⎞ ⎛ ⎞⎞ ⎛ N..∗

tLTL ⎝ a ⎠ ♦ ⎝a ∧ ♦ tLTL ⎝

N −1..∗

a

⎠⎠

which attests that the size of the formula does not dramatically increase when moving from N − 1 to N .

274

11 Experimental Evaluation

Table 11.6. Trends of g-sciff and NuSMV when reasoning upon the alternate responses benchmark

g-sciff: NuSMV:

The fact that g-sciff scales better when the number of constraints grows, while model checking scales better when the required executions of some activity grow, emerges also by considering the charts shown in Fig. 11.6. They present a comparison between g-sciff and NuSMV when reasoning upon the alternate responses benchmark, discussed in Sect. 11.2.2. We have applied the opposite grouping of the one used for the order&payment protocol: each chart ﬁxes the required number of executions of the ﬁrst activity, and shows how the veriﬁcation techniques behave by varying the number of constraints. A great advantage of model checking is that it always guarantees that an answer is provided in ﬁnite time. While g-sciff needs to be accompanied by an ad-hoc preprocessing procedure for avoiding non termination issues, necessarily requiring to select a bounded (incomplete) search strategy when the ConDec model contains ∨-loops, model checking techniques can seamlessly deal with inﬁnite-length computations: the implicit requirement that “each supported execution must eventually terminate” can be made explicit in the logic, and combined with the formulae representing the model and the property. If ConDec had been extended with new constraints, then g-sciff would require to update the preprocessing procedure, while model checking techniques would seamlessly work without changing anything. However, it is important to point out that the non termination of g-sciff is caused by its ﬁrst-order nature: the CLIMB language is able to express metric and data-aware constraints by exploiting variables, a feature which is not available for state-of-the-art model checkers, which realy on propositional temporal logics. All the features added in ConDec++ can be expressed in CLIMB and veriﬁed with g-sciff, while they cannot be captured by LTL, thus making model checking inapplicable. When ﬁrst-order and/or metric temporal logics are chosen to widen the expressiveness of LTL, model checking

11.4 Comparative Evaluation

275

experiences the same drawbacks of g-sciff; just to cite an example, the translation of a temporal logic formula into an underlying automaton becomes undecidable for variants of temporal logic with explicit time, such as Metric Temporal Logic (MTL) with dense time [13]. Last but not least, as we will see in the next part of the book, the same CLIMB formalization produced for g-sciff can be used in conjunction with the sciff proof procedure, enabling monitoring and run-time veriﬁcation capabilities.

12 Related Work and Summary

Related work concerning the static veriﬁcation of interaction models is presented. Then, the major contributions of this part of the book are brieﬂy summarized.

12.1 Related Work We present related work by focusing in particular on the following topics: • • • •

static veriﬁcation of properties; a-priori compliance veriﬁcation; formalisms and reasoning techniques for model composition; interoperability and conformance to a choreography.

12.1.1 Veriﬁcation of Properties Existing formal veriﬁcation tools rely on model checking or theorem proving. A drawback of most model checking tools is that they typically only accommodate discrete time and range on ﬁnite domains, and that the cardinality of domains impacts heavily on their performance, especially in relation to the production of an automaton (or other more compact structures such as BDDs) starting from a temporal logic formula. On the other hand, theorem proving in general has a low level of automation, and it may be hard to use, because it heavily relies on the user’s expertise [129]. g-sciff presents interesting features from both approaches. Like theorem proving, its performance is not heavily aﬀected by domain cardinality, and it accommodates both discrete and dense time. Similarly to model checking, it works in a push-button style, thus oﬀering a high level of automation. In [193], Pesic et al. describe the DECLARE integrated framework, in which ConDec models can be graphically speciﬁed, automatically obtaining the underlying LTL formalization. The derived LTL formula is then used for M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 277–286, 2010. c Springer-Verlag Berlin Heidelberg 2010

278

12 Related Work and Summary

the enactment and veriﬁcation of models. Veriﬁcation is limited to conﬂict detection and discovery of dead activities, without support for the ∃- and ∀entailment of properties. Instead of adopting standard model checking techniques, it is carried out by exploiting the ﬁnite-trace model checking approach proposed by Giannakopoulou and Havelund in [115, 131]. Their proposed semantics has been recalled previously in this book (Sect. 3.7.3, p. 74). To model check ﬁnite-trace speciﬁcations, the authors devise a new automata-based translation algorithm, which produces a B¨ uchi automaton containing exactly those ﬁnite traces that satisfy the LTL formula under study. The obtained automaton thus embeds by construction the ConDec termination property. Nevertheless, the approach presents the same computational drawbacks of explicit model checking: the translation phase has a cost which is exponential in the size of the formula, making veriﬁcation of even medium-sized ConDec models diﬃcult. This approach has been recently improved in [195], where a translation algorithm devised for standard LTL is modiﬁed so as to take into account two assumptions: ﬁniteness of traces and “single events” semantics (stating that at most one event occurrence can happen at a given time). It is worth noting that also the universal Kripke model of Rozier and Vardi would take beneﬁt from the second hypothesis: given a set of proposition symbols P • (without the “single events” hypothesis) the universal model univ(P ) |P | would consist of 2|P | states and 22 transitions; • (with the “single events” hypothesis) the universal model univ(P ) would consist of |P | states and 2|P | transitions. As pointed out in Sect. 11.4, the quantitative evaluation presented in Chap. 11 does not cover all aspects of ConDec++ , which contains data-related constraints, supports a non atomic model of activities and accommodates metric time constraints. Several extensions of propositional LTL have been proposed in order to explicitly referencing time and expressing quantitative time constraints. For example, one of the timed requirements of Query 8.3.4 – Fig. 10.1, which expresses that a receipt is expected by at most 12 time units after having executed accept ads, can be expressed in Metric Temporal Logic (MTL) [13] as: (accept advert ⇒ ♦≤12 send receipt) which is equivalent to the Timed Propositional Temporal Logic (TPTL) [12] formula: x.(accept advert ⇒ ♦y.(y − x ≤ 12 ∧ send receipt)) Many tools have been developed to verify real-time systems with respect to timed temporal logics through the adoption of timed automata [37]. For example, UPPAAL [15, 151] is an integrated environment for modeling and verifying real-time systems transforming them into networks of timed automata;

12.1 Related Work

279

it supports a limited set of temporal logic-based reachability properties. A timed automaton is a B¨ uchi automaton extended with a set of real-valued (constrained) variables modeling clocks. As in standard explicit model checking, building and exploring (a product of) timed automata is a very time and space-consuming task, made even more complex due to presence of such clocks. g-sciff incorporates CLP solvers to deal with metric constraints, and therefore can seamlessly deal with qualitative as well as quantitative time aspects. TRIO [113] is another temporal logic-based language able to cope with quantitative time constraints. More speciﬁcally, TRIO is based on a metric extension of ﬁrst-order temporal logic, and aims at modeling critical real-time systems. Like in ConDec, TRIO systems are modeled in a declarative manner, i.e., as a set of TRIO formulae. Several approaches have been investigated to model check TRIO speciﬁcations, but many important features of the initial language are lost in the eﬀort of obtaining a decidable and tractable speciﬁcation language. For example, the time domain is reduced to natural numbers, there is no quantiﬁcation over time variables, and the language can range only on ﬁnite domains. Such a restricted language can be mapped onto a Promela1 alternating B¨ uchi automaton using the Trio2Promela tool [41], or encoded as a SAT problem in Zot [198]. Zot directly deals with the veriﬁcation of satisﬁability of TRIO formulae, without exploiting the reduction method of Rozier and Vardi. As g-sciff, it is not only able to perform satisﬁability checking, but it also supports the possibility of providing an initial partial execution trace of the system, obtaining as a result an extension of the trace which makes it compliant with the formulae of the model. As stated in [198], Zot is in general slower than NuSMV. A preliminary comparison of g-sciff and Zot in the ConDec context can be found in [174]. Zot exploits SAT-based technologies to perform bounded satisﬁability checking of TRIO speciﬁcations. SAT-based technologies have been introduced to overcome the state explosion problem of classical bounded and unbounded model checking [42]. One represents with boolean formulae the initial state of the system I(Y0 ), the transition relation between two consecutive states T (Yi , Yi+1 ), and the (denied) property F (Yi ). Then, the property is veriﬁed in the set of states 0 . . . k if and only if the formula k k

T (Yi , Yi+1 ) ∧ F (Yi ) I(Y0 ) ∧ i=0

i=0

is unsatisﬁable [160]. Bounded model checking is obviously not complete, in that a ﬁxed bound is imposed. Furthermore, in a metric setting the bound represents a maximum time span, making the veriﬁcation of temporal 1

Promela is the process modeling language veriﬁed by the SPIN model checker [133].

280

12 Related Work and Summary

constraints depending on the time granularity: verifying a deadline of 120 time units is much more diﬃcult than verifying a deadline of 12 time units [174]. In [103], Fisher and Dixon propose a clausal temporal resolution method for proving satisﬁability of LTL formulae. The approach is two-fold: ﬁrst, the LTL formula is translated into a “separated normal form”; second, a resolution method, encompassing classical as well as temporal resolution rules, is applied until either no further resolvents can be generated or ⊥ is derived. In this latter case, the formula is unsatisﬁable. From a theoretical point of view, clausal temporal resolution always terminates, and avoids the state explosion problem; however, the translation into the separated normal forms produces large formulae, and looking for suitable candidates to carry out a temporal resolution step makes the resolution procedure exponential in the size of the formula. Furthermore, in case of satisﬁability no example is produced. Several approaches for verifying interaction models have been also proposed in the ﬁeld of Logic Programming (LP). For example, Alessandra Russo et al. [208] exploit abduction for the veriﬁcation of declarative event-based speciﬁcations. They rely on the Event Calculus (EC) and on an explicit representation of time. Global systems invariants are proven by refutation, adopting a goal-driven approach similar to the one of g-sciff. Veriﬁcation is then carried out by using general-purpose abductive proof procedure. Diﬀerently from their approach, CLIMB adopts a language which directly captures occurred events and expectations, and whose temporal relationships are expressed as CLP constraints. g-sciff is a general-purpose proof procedure, extended with speciﬁc features dedicated to reason upon such events and expectations. West2East [55] is another system for proving properties of graphical speciﬁcations thanks to a translation into LP. In West2East, interaction protocols are modeled in Agent UML [33], and mapped onto a Prolog program, which is then veriﬁed by exploiting the Prolog meta-programming facilities. The veriﬁable properties are (conjunctions of) guard conditions or existential/universal queries about the exchanged messages, checking whether some message is guaranteed to be exchanged in at least one or all of the possible protocol instantiations. It is not obvious how to express and verify more complex properties. Diﬀerently from g-sciff, in other works LP and CLP have been exploited to implement model checking techniques. Of course, since they mimic model checking, they inherit the same computational drawbacks of classical model checkers when applied for statically verifying ConDec models. For example, Delzanno and Podelski [87] propose to translate a procedural system speciﬁcation into a CLP program. Safety and liveness properties, expressed in Computation Tree Logic, are checked by composing them with the translated program, and by calculating the least and the greatest ﬁx-point. In [126], Gupta and Pontelli model the observed system through an automaton, and convert it into CLP. As in our approach, they cannot handle inﬁnite traces: the user must explicitly provide a predicate that generates a ﬁnite number

12.1 Related Work

281

of event occurrences, which represent all the possible ﬁnite executions of the system. 12.1.2 A-Priori Compliance Veriﬁcation A vast literature has developed on the a-priori compliance veriﬁcation of interaction models, especially focusing on Business Processes (BPs). The speciﬁcation of BPs by means of declarative approaches such as ConDec is a recent research line; as we have seen in the ﬁrst part of the book, they are usually captured by means of graphical procedural speciﬁcation languages such as BPMN [184]. Business rules and policies have instead an inherent declarative nature. Hence, most of the literature relies on a procedural representation of BPs, and on declarative (logic-based) languages for capturing the regulatory models against which the processes must be veriﬁed. Two major mainstream approaches can be identiﬁed: • formalization of the regulatory model by exploiting the deontic notions of obligations and permissions, carrying out veriﬁcation by exploiting dedicated resolution techniques underlying the logic; • mapping of the BP onto a transition system and of the regulatory model onto some temporal logics, using model checking techniques for veriﬁcation. In [120], the authors introduce the Formal Contract Language (FCL) to formalize business contracts. FCL combines concepts from the logic of violations and normative positions based on Deontic Logic with Directed Obligations. FCL is reduced to a normal form which makes it possible to reason upon execution traces, verifying if all the obligations are satisﬁed. The analyzed execution traces are extracted from a BPMN model before veriﬁcation. In [117], Goedertier and Vanthienen introduce PENELOPE, a declarative language which captures the obligations and permissions imposed by business policies, dealing with sequencing constraints between activities. Instead of using such policies to verify an external process model, the policies itself are then employed to drive the generation of a “compliant by construction” BPs model. As pointed out in Sect. 7.1.4, although CLIMB does not directly employ deontic notions, a link between obligations and permission and positive and negative expectations has been drawn [5]. The suitability of SCIFF for representation and verifying business contracts has been instead discussed in [7]. In [21], Awad et al. adapt the BPMN-Q graphical notation (inspired from BPMN, in order to express business rules and queries. Standard BPMN is used to specify BP model. A designed process model is translated into a Petri Net via a multi-step methodology which employs abstraction techniques to isolate its relevant subparts, while BPMN-Q queries are formalized as past-LTL formulae. Model checking is ﬁnally exploited to verify whether the formulae are entailed by the Petri Net.

282

12 Related Work and Summary

A similar approach is proposed in [106], where UML Activity Diagrams are used to specify the BP model, and the graphical PPSL language, inspired by Activity Diagrams, is used to represent business rules. PPSL-rules are then model checked by mapping then onto past-LTL formulae. It is worth noting that both BPMN-Q and PPSL employ constructs very similar to a sub-set of ConDec, such as for example response, precedence and existence/absence constraints. In [153], a static compliance checking framework is presented, where BPEL[183] speciﬁcations are model checked against BPSL rules. BPSL is a graphical notation which supports the speciﬁcation of orderings among activities and metric temporal constraints. In order to make model checking applicable, BPEL speciﬁcations are mapped onto π calculus, which is in turn translated into a ﬁnite state machine. BPSL requirements are instead formalized in LTL, using nested operator to model the quantitative aspects. For example, a requirement stating that “if a request is received, then an answer must be provided exactly after 3 time units” is formalized by means of the following formula: (request ⇒ answer) A slightly diﬀerent approach is the one of [114], in which a methodology to audit BPMN-based processes is presented. The BP models are annotated with the eﬀects of activities, and then formalized as Semantic Process Networks (SPNs). A plethora of compliance patterns, which share many similarities with the ConDec constraints, are proposed to capture legislative and regulatory requirements. They can be veriﬁed against the obtained SPNs; in case of noncompliance, the methodology assists the user in the investigation of alternative modiﬁcations to the incorrect model, in order to restore compliance. Veriﬁcation of procedural interaction models against a regulatory ConDec model can be seamlessly carried out with model checking techniques, mapping the interaction model onto a transition system and exploiting the LTL-based formalization of ConDec. With g-sciff, there is a diﬃculty related to the speciﬁcation of the procedural BP, which cannot be easily captured by means of CLIMB rules. In this respect, two possible approaches can be followed: • The BP model is maintained separated from CLIMB, as done, for example, in [120]. A set of relevant execution traces supported by the procedural model are extracted, typically relying on simulation techniques. The simulated execution traces are then subject to compliance veriﬁcation against the CLIMB rules, using the sciff proof procedure. This kind of veriﬁcation resembles the a-posteriori analysis of the concrete BP’s executions, and will be therefore matter of discussion in the next part of the book (Chap. 15 in particular). • The BP is translated into CLIMB, and the obtained speciﬁcation is combined with the CLIMB speciﬁcation formalizing the ConDec regulatory model. A simple structured BP modeling notation, speciﬁcally thought

12.1 Related Work

283

for the speciﬁcation of clinical guidelines, has been mapped onto CLIMB in [60]; however, when the focus is on static veriﬁcation, the termination of g-sciff is guaranteed only if the BP does not contain loops.

12.1.3 Model Composition The issue of composing local models so as to obtain a single, global model has been subject to extensive research in the last years, especially in the ﬁelds of Component-Based Software Engineering, Business Process Management (BPM) and Service Oriented Computing (SOC). In [175], Moschoyiannis and Shields provide a set-theoretic mathematical framework for modeling components and their composition. In particular, each component is characterized by a set of behavioral constraints which associate a sequence of operation calls to the interface exposed by the component. Based on this notion, a formal deﬁnition of composition is provided, examining its eﬀect on the individual components. A well-behaved composition is deﬁned as a composition which preserves the sequencing of operation calls supported by each component. The proposed framework can be used for guiding the composition of local models as it advocates formal reasoning before the actual composition takes place. In [119], a framework for component-based composition encompassing heterogeneous interaction and execution is described. It adopts an abstract layered model of components, where each component is described by: • a dynamic behavior; • a set of architectural constraints on that behavior; • a concrete execution model. Such descriptions are captured by using timed automata with dynamic priorities, which are then composed by means of a commutative and associative composition operator which preserves deadlock-freedom. Petri nets are used for design-time conformance and compatibility in [161, 162, 165, 214]. For example, [162] focuses on the problem of consistency between executable and abstract processes while [165] presents an approach where for a given composite service the required other services are generated. Automatic service composition has been addressed in OWL-S [164], which looks how atomic services interact with the real world, the Roman model approach [38] that uses ﬁnite state machines, and Mealy machine [51] that focuses on message exchange between services. Compatibility of synchronous communication via message exchange in web services is investigated in [46, 40, 35, 197], while ConDec allows asynchronous communication and focuses on the process perspective, rather than message exchange. ConDec contributes to this research area with the veriﬁcation techniques aimed at checking if a composition of local models meets certain properties,

284

12 Related Work and Summary

such as absence of conﬂicts and of dead activities. However, while the aforementioned approaches focus on the automatic composition of services, ConDec assumes that all relevant process models of the composition are already available, and focuses on verifying their interoperability. Finally, to the best of our knowledge the work presented in [173] is the ﬁrst attempt of automatically verifying declarative service models. Such models are graphically described by means of the DecSerFlow notation [242], which has been developed by the same authors of ConDec, and presents many similarities with it. Veriﬁcation of service compositions is carried out by exploiting the possibility of mapping DecSerFlow onto LTL and SCIFF, in the same way that has been described in this book. 12.1.4 Interoperability and Choreography Conformance Conformance and interoperability veriﬁcation are hot topics, especially in the Service Oriented Computing setting. In the literature, it is possible to ﬁnd several deﬁnitions of interoperability and conformance, and there is no complete agreement about their exact meaning. For example, in [23, 24], the authors deﬁne a notion of choreography conformance which is less restrictive than the one derived from classical bi-simulation techniques [54]. In their approach, both the choreography and the single services are speciﬁed in a procedural way, by means of ﬁnite state automata. Diﬀerently from the notion of conformance presented in Chap. 8, their deﬁnition guarantees that if a service conforms to a choreography, then it will correctly interoperate with any other service conforming to the choreography. Conformance veriﬁcation can be therefore carried out by considering each concrete service separately from the others. The advantage is that any single service can be replaced by another conforming service playing the same role, without needing to check whether the service composition will still work. The drawback is that the approach is sometime too restrictive: each concrete service must be able to handle all the incoming messages attached to its role by the choreography. Therefore, many possible acceptable compositions are ruled out, when their composing services cover only a portion of the choreography. The approach proposed in this book embraces the opposite philosophy: conformance veriﬁcation is carried out on a speciﬁc service composition as a whole, checking if the concrete services can fruitfully interact while respecting the choreography constraints. It is worth noting that, in [2], the SCIFF framework has been successfully adapted in order to address the types of interoperability and conformance veriﬁcation described in [23]. An interesting research activity would be to study whether they could ﬁt with the ConDec setting. A diﬀerent notion of interoperability is given in [72], where global choreographies and local services are speciﬁed in terms of transition systems, and their composition obtained as the product of transition systems. They deﬁne interoperability as a set of features that the resulting transition system should

12.2 Summary of the Part

285

guarantee. Although their idea of interoperability is in some sense broader than the one given in [23, 2], it is still related to the procedural aspects of interaction. The loosely-coupled characterization of interoperability and conformance in the ConDec setting comes from its declarativeness and openness, to the aim of leaving the interaction as much as possible unconstrained. The introduction of more restrictive forms of conformance and interoperability would clash with its open philosophy. Such a characterization presents several similarities with the problem of service contracting. In the Semantic Web, the search for a service is tackled at two levels of abstractions: 1. discovery – the service that must satisfy the user needs in terms of the desired outputs and eﬀects; 2. contracting – when invoked by the user, the behavior of the service must support a fruitful interaction with the requestor. Diﬀerently from model composition, the contracting level could involve a negotiation phase, in which the two parties partially disclose and negotiate their interaction policies, private information and mutual requirements. In this context, Roman and Kifer proposed a framework thought to model and reason about (semantic) web services [202]. Local services, as well as the global choreography, are declaratively represented as sets of Concurrent Transaction Logic (CTR) declarative formulae, which are able to express the ConDec constraints. A proof theory is then provided to solve a twofold problem: Contracting, to verify whether at least one execution trace exists, so that the policies of a service and a client, as well as the choreography constraints, are all guaranteed. Enactment, a variation of contracting whose purpose is to build a constructive proof for such an execution trace. The obtained proof can be seen as a way to carry out a course of interaction which respects the constraints and requirements of all the involved parties.

12.2 Summary of the Part In this part of the dissertation, we have tackled the static veriﬁcation of open declarative interaction models, speciﬁed using the ConDec notation. We have introduced a plethora of veriﬁcation tasks that can be applied during the design phase of a ConDec model, to the aim of assessing its correctness and consistency, and of checking its compliance with regulations and policies, again expressed in ConDec. We have also introduced the concepts of local and global ConDec models, discussing how compositions of local models as well as the conformance of a composition with a global model can be formalized and veriﬁed. All these veriﬁcations have been reduced to ∃- and ∀-entailment

286

12 Related Work and Summary

of properties, which respectively test whether a (composite) ConDec model meets a given property in at least one or all its supported executions. We have described the functioning of the sciff and g-sciff proof procedures, which are employed for the veriﬁcation of CLIMB speciﬁcations. sciff is devoted to check whether a given execution trace complies with a CLIMB model, while g-sciff is a generative extension of sciff, which exploits the integrity constraints of the speciﬁcation under study in order to generate compliant intensional execution traces. We have then shown how g-sciff is able to eﬀectively deal with ∃- and ∀-entailment of properties in the ConDec setting, pointing out its non termination issues. We have in turn established a connection between the non termination of g-sciff and the presence of loops inside the ConDec model under study. A preprocessing procedure has been introduced to detect the presence of loops and take proper countermeasures when needed. Thanks to the preprocessing procedure, some kinds of loop are correctly handled, whereas in other cases g-sciff must switch to a bounded search strategy, guaranteeing termination but undermining completeness. Finally, the eﬀectiveness of the approach has been quantitatively assessed by testing g-sciff on several benchmarks, which emphasize the performance and scalability of the proof procedure in both favorable and unfavorable cases. After having shown how the ∃- and ∀-entailment of properties can be also encoded as a model checking problem, we have compared g-sciff with explicit and symbolic model checkers, discussing their strenghts and limits.

Part III

Run-Time and A-Posteriori Veriﬁcation

13 Run-Time Veriﬁcation “Begin at the beginning”, the King said, very gravely, “and go on till you come to the end: then stop” — Lewis Carroll

Static veriﬁcation techniques are useful to assess the correctness, safety and consistency of the designed models. However, they suppose that all the business constraints of the model are completely accessible, i.e., they assume that the model is a white box. There is a plethora of situations in which this assumption is not reasonable. For example, a ConDec choreography could be applied to a pre-existing service composition, where several concrete services developed by diﬀerent organizations have been already combined. In this context, the internal speciﬁcation of services is unaccessible: they are black boxes, and can be analyzed only by observing the messages they exchange. Even if the service composition is being established with a choreography model in mind, static veriﬁcation is not suﬃcient to guarantee that the selected services will eﬀectively comply with the choreography constraints. Indeed, usually a (third-party) local model does not reveal its complete behavior, but only the portion dedicated to interact with the external world, i.e., its behavioral interface. In this situation, the interacting services are gray boxes, and there is no guarantee that their exposed behavior eﬀectively reﬂects the internal one. Potential mismatches between the behavioral interface and the internal implementation of a service may produce undesired courses of interaction, leading to violate the choreography prescriptions. In all these cases, veriﬁcation must shift from static to run-time, to the aim of checking if the actual behavior of the interacting entities eﬀectively adheres to the modeled business constraints. The sciff proof procedure is speciﬁcally devoted to accomplish this task: it is able to dynamically collect the events generated by the interacting entities, checking on-the-ﬂy whether they comply with the modeled business constraints, and reporting violations as soon as possible. In this chapter, we discuss how static veriﬁcation can be suitably complemented by run-time veriﬁcation, using sciff as the underlying reasoner. We then show that sciff is not always able to promptly evaluate a noncompliant course of interaction, and propose a combination of run-time and M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 289–304, 2010. c Springer-Verlag Berlin Heidelberg 2010

290

13 Run-Time Veriﬁcation

partial trace yes

model

Run-time Verification

no

Fig. 13.1. Run-time veriﬁcation

static veriﬁcation techniques towards the realization of a speculative run-time veriﬁer.

13.1 The Run-Time Veriﬁcation Task As deﬁned by Colin and Mariani [81]: Run-time veriﬁcation techniques are used to dynamically verify the behavior observed in the target system with respect to given requirements. Veriﬁcation is used both to check that the observed behavior matches speciﬁed properties and to explicitly recognize undesirable behaviors in the target system. When it comes to ConDec, run-time veriﬁcation aims at checking whether an evolving instance of the target system complies with all the business constraints contained in the model. During the instance execution, interacting entities generate events which are accumulated inside an execution trace. As exempliﬁed in Fig. 13.1, run-time veriﬁcation is therefore carried out on a partial, growing execution trace. A run-time veriﬁer must be able to deal with incomplete information: at each time, the observed execution trace is only a portion of the whole instance, and therefore a deﬁnitive answer cannot be always provided. For example, if the model prescribes that a certain event ev must eventually occur within the instance, and currently such an event has not yet been generated. the veriﬁer should not infer that the execution is wrong, but only that the requirement has not yet been satisﬁed so far. sciff is speciﬁcally thought to reason with incomplete information, and suspends the compliance evaluation by leaving the generated expectations pending (see Sect. 9.1.1), until either: • an event occurs and fulﬁlls a positive expectation; • an event occurs and violates a negative expectation;

13.2 SCIFF-Based Run-Time Veriﬁcation

291

• the course of interaction comes to an end. The second case reﬂects another important feature that a run-time veriﬁer must exhibit: when the course of interaction violates some requirement, then the veriﬁer must recognize and report the violation as soon as possible. In order to cope with partial execution traces, we will discuss three types of reasoning capabilities that must be tackled by a run-time veriﬁcation framework: Open reasoning, to deal with an ongoing course of interaction, managing incomplete information and handling the acquisition of new knowledge. Closed reasoning, to draw a deﬁnitive conclusion when the instance reaches its termination, i.e., the partial execution trace becomes a complete execution trace. Semi-open reasoning, to properly combine the ﬁrst two reasoning paradigms when the functioning of the system guarantees certain hypotheses. The most interesting case is the one in which the systems guarantees that events will always occur in ascending order; in this setting, reasoning can be closed on the past and open on the future.

13.2 SCIFF-Based Run-Time Veriﬁcation Most of the state of the art approaches face the run-time veriﬁcation problem by proposing ad-hoc solutions, which rely on speciﬁc software implementations or customized decision procedures, lacking a strong formal basis. This makes it impossible to study the formal properties of the veriﬁers, such as soundness, completeness and termination. However, these properties are of key importance, because they guarantee that compliance is correctly assessed by the veriﬁcation technique. As far as we are concerned, the sciff proof procedure [8] is one of the few methods which face run-time veriﬁcation with a strong formal basis. As we have pointed out in Sect. 9.2, sciff is sound and complete, and meets termination for any CLIMB speciﬁcation, hence also for Condec and ConDec++ models. The SCIFF framework has been originally developed for targeting run-time veriﬁcation, and has been later extended to deal also with static veriﬁcation. It is not surprising, then, that sciff have been applied in several application domains, such as: • • • •

Multi-agent Systems [8]; Business Contracts [7]; Service Choreography [3]; Clinical Guidelines [60].

292

13 Run-Time Veriﬁcation

13.2.1 Reactive Behavior of the SCIFF Proof Procedure As described in Sect. 9.1, sciff checks wether an execution trace complies with a given CLIMB speciﬁcation. This task can be seamlessly carried out on a complete trace, or by reasoning on a partial, evolving trace. In fact, the rewriting system of sciff is speciﬁcally thought for dealing with the dynamic occurrence of events. First, a sciff transition, called happening, is dedicated to acquire new event occurrences from an external queue. Second, sciff supports both an “open” and a “closed” reasoning modality, depending on whether the current trace is partial or complete. By default, sciff works in the open modality: each positive (negative resp.) generated expectation is kept in the pending state until it becomes fulﬁlled (violated) by an event occurrence. When sciff becomes aware that the course of interaction has reached its termination1 , it switches to the closed reasoning modality, assuming that no more events will occur. More specifically, it applies the closure transition, and consequently evaluates the still pending expectations: each pending positive expectation becomes violated; each pending negative expectation becomes fulﬁlled. Hence, sciff exhibits a reactive behavior. As soon as a happened event, say, H(ev, t), is inserted into the external queue of sciff, it is imported by means of the happening transition. This triggers a new reasoning phase in which sciff: 1. checks whether H(ev, t) fulﬁlls a pending positive expectation or violates a pending negative expectation; 2. combines H(ev, t) with the (partially solved) integrity constraints of the model, generating new expectations if H(ev, t) has the ability of triggering some of them. By supposing that sciff is working in the open modality, at the end of this “reasoning chunk” two possibilities may then arise: 1. sciff reaches a failure node; it then performs backtracking, trying a different derivation. If all the possible branches of the proof tree lead to a failure node, then sciff states that the trace does not comply with the speciﬁcation. 2. sciff reaches a non-failure node, in which no further transition is applicable; in this case, we say that the node is quiescent. The proof procedure will persist in the quiescent node until a new information is acquired, that is, a new event occurs or the execution terminates. 13.2.2 Open Derivations The fact that sciff has reached a quiescent node attests that the partial execution trace analyzed so far does not violate any constraint of the model. 1

This is usually done by delivering to sciff a special complete event.

13.2 SCIFF-Based Run-Time Veriﬁcation

293

Technically, we say that sciff has an open successful derivation for the (partial) instance. Deﬁnition 13.2.1 (sciff open successful derivation). Given a CLIMB speciﬁcation S, an initial execution trace Ti and a partial execution trace Tp ⊇ Ti , there exists an open successful derivation for STp starting from Ti if and only if the proof tree with root node the initial node2 I(STi ) has at least one T non-failure node containing Tp . In this case, we write STi ∼Δp true, where Δ is the abductive explanation computed in such a quiescent node. When sciff reaches a quiescent node for STp , no more transitions are applicable. sciff then waits until one between the following situations arises: • The course of interaction terminates, i.e., Tp is actually a complete execution trace. The “closure ﬂag” is set on sciff, which can then infer a deﬁnitive answer about the compliance of STp . In particular, if at least one positive expectation is still pending, then a failure node is generated, and the open successful derivation leads, in fact, to a closed failure derivation, attesting that Tp is not compliant with S. Contrariwise, if no positive expectation is pending at the closure time, then a success node is reached, and the instance is evaluated as compliant. • A new event occurs and is inserted into the external queue of sciff; sciff then imports it by means of the happening transition, which in turn triggers a new reasoning chunk. The following examples illustrate the reactive nature of sciff in two simple cases. The execution traces presented in the examples must obey to the following ConDec diagram: query •=== inform Thanks to the mapping of ConDec onto CLIMB, this model can beneﬁt from the run-time veriﬁcation facilities of sciff. In particular, the application of the translation function tIC (following the revised mapping, described in Example 10.4.1), produces the CLIMB speciﬁcation QI = ∅, {(ALTqi )} , where (ALTqi ) is: H(exec(query), Tq ) →E(exec(inform), Ti ) ∧ Ti > Tq ∧ EN(exec(query), Tq2 ) ∧ Tq2 > Tq ∧ Tq2 < Ti .

(ALTqi )

Example 13.2.1 (Violation at closure). Let us consider the run-time veriﬁcation of the following execution trace against QI.

2

See Def. 9.1.2.

294

13 Run-Time Veriﬁcation

Beginning At the beginning of the computation, the execution trace is empty. (ALTqi ) does not trigger, and therefore sciff reaches immediately a quiescent node N0 , waiting for new informations. T1 = {H(exec(query), 5)} The happening of the query activity triggers (ALTqi ), leading to generate a positive expectation about a consequent inform, and a negative expectation about another query in between. A new quiescence node N1 is reached, attesting that sciff has an open successful derivation for T1 : S∅ ∼TΔ11 true, where ) * ) ΔP 1 = E(exec(inform), Ti ), EN(exec(query), Tq2 ) * CS1 = Ti > 5, Tq2 > 5, Tq2 < Ti The two generated expectations are put into the pending set. Then, sciff becomes quiescent. Termination sciff is notiﬁed that no further event will happen in the current instance (hence, that T1 is a complete trace). The closure transition is consequently applied, leading to a failure node , which states that the positive expectation about the inform activitiy is violated. In other words, S∅ TΔ11 true, and thus T1 is not compliant with S. Example 13.2.2 (Successful veriﬁcation). Let us consider the run-time veriﬁcation of the following execution trace against QI. Beginning A quiescent node is immediately reached by g-sciff. T1 = {H(exec(query), 5)} As in Example 13.2.1, the following pending expectations are generated: ) * ) ΔP 1 = E(exec(inform), Ti ), EN(exec(query), Tq2 * ) > 5, Tq2 < Ti CS1 = Ti > 5, Tq2 T2 = {H(exec(query), 5), H(exec(inform), 10)} The occurrence of the inform activity at time 10 is able to fulﬁll the corresponding pending expectation. sciff generates two successor nodes N2a and N2b . In the ﬁrst one, fulﬁllment is applied, whereas in the second one fulﬁllment is avoided. N2a is characterized by the following state: ) * T2a = H(exec(query), 5), H(exec(inform), 10) ) * ΔF 2a = E(exec(inform), 10) ) * ) ΔP 2a = EN(exec(query), Tq2 ) * CS2a = Tq2 > 5, Tq2 < Ti

13.2 SCIFF-Based Run-Time Veriﬁcation

295

Termination sciff is notiﬁed that no further event will happen in the current instance (i.e., that T2a is a complete trace). Starting from node N2a , sciff applies closure and EN-fulﬁllment in sequence: since no further event will happen, the negative expectation concerning the query is satisﬁed. Since all the expectations are fulﬁlled, the ﬁnal node is a successful node , attesting that T2a is compliant with QI. Note that the second alternative, starting from N2b , would instead lead to a failure, because it is not possible to fulﬁll the inform expectation at a time diﬀerent than 10.

13.2.3 Semi-Open Reasoning In its basic form, sciff does not make any assumption about the ordering in which events occur and are fetched. On the one hand, this is a desired feature, because, in a distributed system, there is no guarantee that events generated by two diﬀerent parties will be delivered to sciff in the same order as they occurred. In other words, sciff is open both on the past and the future. On the other hand, in many cases this openness makes it impossible to evaluate whether an instance is compliant, unless the instance is completed. Let us for example consider the QI speciﬁcation introduced in the previous section, together with a partial execution trace containing only two occurrences of the query activity, at time 5 and 8. Intuitively, when the second occurrence happens, we would expect that sciff immediately detects a violation: there are two contiguous executions of the query activity, with no occurrence of inform between them. However, such a violation cannot be generated, because there could be an event occurrence of the inform activity, which has not yet been delivered to sciff, but has indeed happened between 5 and 8. Nevertheless, there exist many application domains in which the ordering of event occurrences is preserved (especially when the time granularity is coarse-grained). Think for example at the application of a Clinical Guideline to a speciﬁc patient, or at the instance of a Business Process whose activities execution are captured and persisted by a Workﬂow Management System. When the ordering of events is guaranteed, sciff can improve its veriﬁcation capabilities, providing a deﬁnitive answer about • the violation of a negative expectation; • the fulﬁllment or violation of a past-tense positive expectation; • the fulﬁllment of a positive expectation with a deadline. when the instance is still running. This is practically done by applying the times update transition, which has been described in Sect. 9.1.3 – p. 209. When a new event occurring at time t is fetched, the times update transition assumes that all the events fetched in the future will surely be associated to a time value greater than t. Such an information is then exploited to “close” the reasoning

296

13 Run-Time Veriﬁcation

on the past: since the partial execution trace provides a complete information about the interaction up to time t, all the time variables associated to pending positive expectations can be updated, imposing that they are greater or equal than t. Under the ordering assumption, the notion of current time can be therefore introduced. Deﬁnition 13.2.2 (Current time). Let T be a CLIMB execution trace. The current time associated to T is deﬁned as: ct(T ) max{t | H(e, t) ∈ T } If Tp represents the execution trace currently fetched by sciff, all the pending expectations will be possibly satisﬁed at a time greater or equal than ct(Tp ). This makes sciff “eager” to evaluate expectations, as shown by the following examples. Example 13.2.3 (Eager evaluation of interposition). Let us consider again the QI CLIMB speciﬁcation, introduced in Sect. 13.2.1, and the partial execution trace Tp = {H(exec(query), 5), H(exec(query), 8)} By reacting to the event occurrences of Tp , sciff has a successful open derivation; it reaches a quiescent node Nq where: Tq = Tp E(exec(inform), Ti1 ), E(exec(inform), Ti2 ), ΔP q = EN(exec(query), Tq2 ), EN(exec(query), Tq3 ) * ) CSq = Tq2 > 5, Tq2 < Ti1 , Tq3 > 8, Tq3 < Ti2 A graphical intuition of the computed answer is given in Fig. 13.2. Starting from Nq , sciff imposes E-consistency by applying the consistency transition. The CLP solver, in turn, infers that the ﬁrst positive expectation concerning the inform activity can be fulﬁlled only by a corresponding event occurring between time 5 and time 8: Ti1 > 5∧Ti1 < 8. Otherwise, the occurrence would violate the negative expectation EN(exec(query), Tq2 ). If sciff is working in a semi-open modality, then a new reasoning chunk is performed, in which the times update transition is applied with a current time of 8. The two constraints Ti1 ≥ 8 and Ti2 ≥ 8 are then asserted, imposing a lower bound on the positive pending expectations. However, Ti1 ≥ 8 contradicts constraints Ti1 < 8, which is already contained inside the CLP store. Hence, a failure node is encountered. No other quiescent alternatives exist, and therefore sciff terminates stating that Tp is not compliant with QI.

13.2 SCIFF-Based Run-Time Veriﬁcation

Expectations

CLIMB specification

query forbidden

query forbidden

inform expected

inform expected

query

297

inform

Execution trace H(exec(query),5)

H(exec(query),8)

Running system

Fig. 13.2. Example of answer computed by sciff when carrying out run-time veriﬁcation; under semi-open reasoning, a violation is detected at time 8

Example 13.2.4 (Eager evaluation of the precedence constraint). Let us consider a ConDec model involving the precedence constraint pay −−−• delivery which is formalized in CLIMB as: H(exec(delivery), Td ) → E(exec(pay), Tp ) ∧ Tp < Td . Let us now suppose that an occurrence of activity delivery is dynamically delivered to sciff at time 3. Such happened event matches with the antecedent of the integrity constraint. The rule consequently triggers, leading to generate the expectation E(exec(pay), Tp ) ∧ Tp < 8. The default open behavior of sciff would be then to wait for the occurrence of a further event, or for the notiﬁcation that no more events will happen. Conversely, under semi-open reasoning, sciff would infer that the expectation can be fulﬁlled only by a time greater or equal than 8, because no payment has occurred before. This assumption clashes with the CLP constraints expressing that the payment is expected to occur in the past. The expectation becomes consequently violated. Example 13.2.5 (Eager evaluation of a deadline expiration). Let us consider a ConDec++ model involving the metric response constraint (−,48)

pay •−−− delivery which is formalized in CLIMB as:

298

13 Run-Time Veriﬁcation

H(exec(pay), Tp ) → E(exec(delivery), Td ) ∧ Td > Tp ∧ Td < Tp + 48. Suppose that the execution of activity pay at time 21 is dynamically fetched by sciff. Such happened event matches with the integrity constraint. The rule is therefore triggered, and sciff consequently generates the expectation E(exec(delivery), Td ) ∧ Td > 21 ∧ Td < 69, where the deadline becomes bound to the actual value of 69. Suppose now that sciff is working in a semi-open way. Since sciff does not have an inherent ﬂow of time, but infers the actual current time from the stream of external events, it is not able to autonomously infer that the rule is violated when time 69 is reached and no delivery has been executed. However, thanks to the time updates transition, the proof procedure is able to detect that the deadline has expired when the ﬁrst event occurs after the expiration time. For example, imagine that the second happened event of the trace is H(exec(req info), 72). When sciff fetches such an occurrence, it infers that the current time is now 72. The times update transition is then applied, imposing Td ≥ 72, which is however in conﬂict with Td < 69 and consequently leads to a violation. In conclusion, the times update transition implements a sort of Closed World Assumption [200] on the past: given a trace T , it states that no further event can happen at a time lower than ct(T ) (that is, the execution trace is complete until the current time) but admits future event occurrences, i.e., events possibly occurring at a time greater or equal than ct(T ). The derivations computed by sciff under this hypothesis are called semi-open derivations, and will be identiﬁed with symbol ∼.

13.3 The SOCS-SI Tool SOCS-SI [4] is a tool for the run-time compliance veriﬁcation of execution traces. The tool is based on JAVA and on the SICStus implementation of the sciff proof procedure. It interfaces sciff with a graphical user interface and a component for the observation of interactions. The tool has a twofold purpose: • intercept event occurrences, acting as an external queue for sciff; • provide a feedback about the results computed by sciff, showing pending, fulﬁlled and violated expectations. As depicted in Fig. 13.3, the SOCS-SI software application is composed by a set of JAVA modules: Event recorder fetches events from external sources and stores them inside the history manager. Specialized modules can be developed to manage the acquisition of events from a speciﬁc external system, and plugged into

13.3 The SOCS-SI Tool

299

SOCS-SI Conformance Verifier SCIFF Proof Procedure

yes Init & Control Module

History Manager

GUI

no

SCIFF specification Event Recorder

execution traces

JADE infrastructure

cusom event collector

Fig. 13.3. Architecture of the SOCS-SI tool

the tool. To insert a new event acquisition module, the user must implement a RecorderInterface interface, which exposes the basic methods for fetching events. The new module can then be selected through the GUI. History manager receives events from the event recorder and is in charge of inserting them into a queue. It also awakes the social compliance veriﬁer when an event occurrence is inserted in the empty queue. Social compliance veriﬁer wraps the sciff proof procedure, managing the acquisition of events and the delivery of inferred results. As soon as sciff is ready to process a new event, it tries to import one from the history manager. If there is one, it is consumed and delivered to sciff; when sciff terminates the reasoning chunk, the computed result is sent to the user interface. If instead the history manager has an empty queue, then the social compliance veriﬁer suspends, waiting for new event occurrences. Init&control module manages the initialization of all components in the proper order. It receives as initial input a set of SCIFF speciﬁcations deﬁned by the user, passing them to the social compliance veriﬁer. Thanks to the translation of ConDec into CLIMB, SOCS-SI can be therefore seamlessly adopted for the run-time veriﬁcation of execution traces with respect to a ConDec model.

300

13 Run-Time Veriﬁcation select order

calculate price

prepare package

deliver order

empty stock

Fig. 13.4. An order management ConDec model with negative hidden dependencies (hidden dependencies are shown in dashed gray)

13.4 Speculative Run-Time Veriﬁcation The capability of detecting a violation as soon as possible is one of the most important features that a run-time veriﬁer must exhibit. Indeed, a violation is caused by a deviation from the intended business constraints, which is in turn caused by a misbehavior of the interacting entities. It could result from a critical situation, either costly to repair or potentially threatening the safety of the entire running system. The sooner is the violation detected, the greater are the chances to properly handle the failure. In the remainder of the chapter, we show that there are cases in which the course of interaction has reached a conﬂicting situation, but sciff needs further event occurrences for detecting the violation. To overcome this issue, an integration between sciff and g-sciff is proposed. The resulting reasoning procedure realizes a sort of speculative run-time veriﬁcation, where sciff is used to reason on the past, and g-sciff to speculate about the future. 13.4.1 The Need for Speculative Reasoning Fig. 13.4 shows a ConDec order management process consisting of a sequence of four steps: 1. 2. 3. 4.

an order is selected from the list of pending orders; the price of the order is calculated; a package for shipping the order is prepared; the order is ﬁnally delivered to the customer.

The process contains a further activity, modeling the exceptional situation in which the stock is empty. In this case, no delivery can be executed afterwards. The relation between empty stock and deliver order is therefore modeled as a negation response constraint. Let us now consider the following running instance: 1. at time 1, the warehouse signals that the stock is empty; 2. at time 5, the seller selects an order.

13.4 Speculative Run-Time Veriﬁcation

301

This partial trace is not compliant with the order management model: due to the sequence of response constraints, a selected order must be eventually delivered, but being the stock empty, the deliver order activity is forbidden. However, by merely looking at the current trace, no expectation is currently violated. In particular, by reasoning upon the trace sciff infers that the instance has a positive pending expectation concerning the price calculation, and a negative pending expectation stating that orders cannot be delivered. The problem is that the conﬂicting point has not yet been reached: expectations are not violated nor E-inconsistent, hence sciff would infer that the partial trace is indeed compliant. Nevertheless, we know that a conﬂicting point will be surely encountered in the future, either because one of the remaining three steps will not be performed (E-violation), or because the execution will eventually come to the deliver order activity, which is however forbidden (E-inconsistency). We can foresee such a conﬂict because we are able to perform speculative reasoning: we observe the model and the current trace, trying to check whether one possible way to continue the interaction exists such that all the business constraints will be respected. Speculative reasoning aims exactly at anticipating the detection of an undesired situation by answering to the following question: is it possible to extend the current trace so as to comply with the speciﬁcation? Another way of facing the same problem is to extract the hidden dependencies implicitly contained inside the ConDec model. Hidden dependencies are one of the cognitive dimensions proposed by Green [122] to assess the usability of languages and notations – see Sect. 3.5. In the order management process, there is an interplay between each response constraint and the negative response one: the execution of the empty stock activity does not only forbid the deliver order one, but it implicitly forbids also all the other activities of the sequence. By taking into account all the inferred business constraints, the execution of the empty stock activity at time 1 would generate a negative expectation concerning future occurrences of select order. Such an expectation would be then violated at time 5 in the aforementioned instance. 13.4.2 Speculative Veriﬁcation with the g-SCIFF Proof Procedure sciff is not able of inferring and using the hidden constraints implicitly contained inside a ConDec model, nor does it embody a form of speculative reasoning. In order to overcome the late detection of violations, it must be therefore extended with a speculative component, dedicated to carry out hypothetical reasoning on the future, in particular verifying whether at least one possible extension of the current trace exists, such that all the constraints of the model will be respected. If it is not the case, then a violation can be identiﬁed in advance. In our running example, speculative reasoning would complement sciff, anticipating the detection of a violation at time 5. We argue that such a speculative form of reasoning resembles very closely the conﬂict detection problem, introduced in Def. 8.3.3 – p. 181. In its original

302

13 Run-Time Veriﬁcation

formulation, conﬂict detection aims at ﬁnding if at least one possible execution supported by the model exists. The speculative version is instead focused on detecting if the model accepts at least one execution trace containing the events occurred so far. In Theorem 10.2.1 – p. 233 we have shown that the conﬂict detection problem can be suitably tackled by g-sciff: a ConDec model CM is conﬂictTf

free if and only if tCLIMB (CM)∅ g Δ true. Furthermore, as we have pointed out in Sect. 9.3, g-sciff can be seamlessly invoked by providing an initial execution trace: it then tries to extend the provided trace so as to make it compliant with the ConDec model. Technically, a partial execution trace Tp does not eventually lead to a conﬂict inside the ConDec model CM if and Tf

only if tCLIMB (CM)Tp g Δ true. Therefore, g-sciff can be employed to carry out speculative reasoning. Example 13.4.1 (Speculative reasoning with g-sciff). Let us consider the order management process shown in Fig. 13.4, and in particular the running instance described in Sect. 13.4.1. We will identify its CLIMB representation with OM. At time 5, the current partial trace is T5 = {H(exec(empty stock ), 1), H(exec(select order ), 5)} As we have already discussed, sciff computes a (semi-)open successful derivation for OMT5 . However, when considering g-sciff, it holds that Tf

OMT5 g Δ true . Indeed, . . . 1. g-sciff generates the following trace: a) H(exec(empty stock ), 1) b) H(exec(select order ), 5) c) H(exec(calculate price), Tc ), Tc > 5 d) H(exec(prepare package), Tp ), Tp > Tc 2. The ﬁrst happened event matches with empty stock •−− − deliver order leading to generate the negative expectation EN(exec(deliver order ), Td1 ) ∧ Td1 > 1 3. The last happened event matches with prepare package •−−− deliver order leading to generate the positive expectation E(exec(deliver order ), Td2 ) ∧ Td2 > Tp 4. Since Td2 > 1, the two expectations are contradictory, making the simulated instance E-inconsistent. At time 5, g-sciff does therefore discover the presence of an inevitable, future conﬂict.

13.4 Speculative Run-Time Veriﬁcation

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

303

function: SpeculativeRunTimeVerification(ConDec model CM) returns : f alse, if a violation is detected during the veriﬁcation, true otherwise begin enable the times update transition in g-sciff; [CMAug ,Bounded] ← PreProcess(CM); S ← tCLIMB (CMAug ); if ¬Bounded then Bound ← -1; else Bound ← ask a bound to the user; end Tcur ← ∅; while Open do Told ← Tcur ; Occurrence ← extract an event occurrence from the queue; Tcur ← Told ∪ {Occurrence}; if S Told ∼TΔcur true then return false; end [OKf uture , ] ← Call GSCIFF(S, Tcur , Bound); if ¬OKf uture then return false; end end if S Tcur TΔcur true then return true; else return false; end end

Function SpeculativeRunTimeVerification(CM)

13.4.3 Interleaving the Proof Procedures Speculative run-time veriﬁcation can then be eﬀectively realized by interleaving the application of sciff and g-sciff each time a new event occurrence is acquired. First, a sciff (semi-)open derivation is used to check whether the execution trace collected so far violates some mandatory constraint of the model; then, g-sciff is employed to check whether at least one compliant way to carry on the interaction exists. The complete veriﬁcation algorithm is listed inside the SpeculativeRunTimeVerification function. The function supposes that events are fetched in ascending order, but the two proof procedures could be seamlessly interleaved also when such an assumption cannot be placed. The veriﬁcation procedure is organized as follows:

304

13 Run-Time Veriﬁcation

1. The times update transition is enabled in g-sciff; in this way, g-sciff can generate happened events only after the current time, determined as the maximum time value contained in the actual trace; 2. The ConDec model is analyzed by the preprocessing algorithm, in order to guarantee the termination of g-sciff3; 3. While the interaction is open (i.e., new event occurrences may occur) . . . a) A new event occurrence is extracted from the external queue (if the queue is empty, then the operation waits until an event is inserted). b) sciff is employed to evaluate whether the trace, extended with the last fetched event, is violating the ConDec model; the evaluation is made under semi-open reasoning. c) If there does not exist a semi-open successful derivation for sciff, then the current trace violates the model, and the veriﬁcation procedure terminates, returning a failure. d) Otherwise, g-sciff is used to accomplish the speculative reasoning task4 . e) If speculative reasoning returns a negative answer, then the presence of a future, inevitable violation has been detected, and thus the procedure terminates with failure. 4. When the execution has reached an end such that no violation has been detected, a sciff closed derivation is performed to evaluate all the expectations that are still pending, computing the ﬁnal veriﬁcation result.

3 4

The preprocessing procedure has been described in Sect. 10.5. The g-sciff call is encapsulated into a dedicated function, which has been described in Sect. 11.1.

14 Monitoring and Enactment with Reactive Event Calculus

In Chap. 13, we have shown how sciff can be used to perform run-time veriﬁcation of a running execution with respect to some ConDec model. When providing execution support, it is not only important to oﬀer compliance veriﬁcation facilities, but also to give a constant feedback to the interacting entities, keeping them informed about the evolving state of aﬀairs and reporting undesired situations. This task is called monitoring and is illustrated in Fig. 14.1. Monitoring aims at dynamically observing the behavior of interacting entities, tracking its impact on the monitored speciﬁcation and capturing violations without terminating the computation; the detection of a violation could lead to generate a corresponding alarm, to warn the system administrator or even to start a special course of interaction, aimed at ﬁxing the violation. In this chapter, we show how a reactive form of the Event Calculus (EC) [146] can be encoded as a SCIFF-lite program, enabling the possibility of • monitoring ConDec optional constraints; • introducing compensation constructs in ConDec, modeling business constraints that express which countermeasures should be taken when an optional constraint is violated, and that are enforced only in such an exceptional situation; • tracking the evolution of constraints’ states as events occur. The latter topic provides the basis for supporting the enactment of ConDec models, which is discussed in the last part of the chapter.

14.1 Monitoring Issues and SCIFF When it comes to the monitoring problem, the sciff proof procedure has two limits. First of all, one could think that pending expectations are a suitable candidate for representing the current state of aﬀairs, provided that suitable

M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 305–341, 2010. c Springer-Verlag Berlin Heidelberg 2010

306

14 Monitoring and Enactment with Reactive Event Calculus

partial trace state of affairs

refuse order

commit order confirm order

Monitoring model

0..1

alarms warnings

Fig. 14.1. The monitoring task

assumptions, such as ascending order of event occurrences, hold1 . However, there are situations in which the generated expectations are not signiﬁcant. A typical case is when the model contains branching constraints, i.e., it leaves open alternatives to the interacting entities. The depth-ﬁrst nature of the current sciff implementation drives the proof procedure to investigate one alternative at a time, and there is no guarantee that the selected alternative is the same as the one chosen by the interacting entities. When such a mismatch exists, sciff will switch to the right alternative as soon as a violation related to the other one is detected. Thus, there is a lapse of time during which the pending expectations shown by sciff do not ﬁt with the actual behavior, and therefore they should not be exposed to the interacting entities. Example 14.1.1 (Run-time veriﬁcation of branching constraints). A care-ﬂow protocol involves the following business constraint: when a sample is sent to the laboratory, then either an error concerning the sample must be communicated by the laboratory within 5 time units, or a the analysis result must be produced within 15 time units. It can be modeled in ConDec by means of a metric branching response constraint, mapped onto CLIMB as follows: ⎛ ⎞ ⎧ sample ⎪ ⎜ ⎪ H(exec(send sample), Ts ) error ⎟ ⎜ ⎟ ⎪ ⎪ →E(exec(sample error ), Te ) (0,5) ⎜ send ⎟ ⎨ ⎟= ∧Te > Ts ∧ Te < Ts + 5 tIC ⎜ ⎜ sample ⎟ ⎪ ⎜ ⎟ ⎪ ∨E(exec(produce result), Tr ) (0,15) ⎪ ⎝ ⎠ ⎪ ⎩ produce ∧Tr > Ts ∧ Tr < Ts + 15 result

We now consider a speciﬁc execution of the care-ﬂow protocol. At time 9, a sample is sent to the laboratory. The integrity constraint is triggered, and one 1

If events do not occur in ascending order, then it is inevitable that sciff revises the computed results, because it becomes aware of new information about the past after having already processed it.

14.2 Event Calculus

307

of the two alternatives is investigated by the standard, depth-ﬁrst implementation of sciff. For example, sciff tries the ﬁrst alternative, generating the following pending expectation: E(exec(sample error ), Te ) ∧ Te > 9 ∧ Te < 14 At time 12, the laboratory produces a result for the sample, and at time 15, a further event occurs. If sciff is running in the semi-open modality, it becomes aware that the current time is now 15, and thus detects that no sample error activity has been executed within the deadline. It then tries the other alternative, generating the pending expectation E(exec(produce result), Tr ) ∧ Tr > 9 ∧ Te < 24 which is indeed fulﬁlled by the event happened previously occurred at time 12. The temporary discrepancy between the generated expectations and the effective course of interaction can be overcome by substituting the depth-ﬁrst search strategy with another one. However, there is a second lack of sciff, which is inherent to the proof procedure and cannot be eliminated by changing the search strategy: when a violation is detected by sciff, the proof procedure immediately terminates the computation, returning a negative answer. This aspect is reasonable for run-time veriﬁcation, which limits itself to compliance checking, and assumes that the violation will be handled outside of the running instance. Conversely, monitoring considers the detection and management of violations as part of the interaction, and therefore must be able capture and report violations; the consequent exceptional course of interaction could be then monitored as well, checking if the interacting entities are correctly reacting to the violation.

14.2 Event Calculus In the mid 80’s, Kowalski and Sergot [146] proposed the Event Calculus (EC) as a general framework to reason about time, events and change. EC overcomes the inadequacy of representing time in classical logic, as well as limitations of other previous approaches, such as the Situation Calculus [166], providing a solid theoretical basis for reasoning upon complex requirements in EventBased Systems. EC has many interesting features. Among them: an extremely simple and compact representation, symmetry of past and future, generality with respect to time orderings, executability and direct mapping with Computational Logic frameworks, modeling of concurrent events, immunity from the frame problem [166], and explicit treatment of time and events. Furthermore, EC can be completely axiomatized by relying on the Horn clause subset of classical logic augmented with Negation As Failure (NAF)

308

14 Monitoring and Enactment with Reactive Event Calculus

[77]. The advantage is twofold: on the one hand, it is equipped with an underlying declarative semantics, providing a basis for studying its formal properties; on the other hand, the resulting formalization is directly executable as a logic program. 14.2.1 The Event Calculus Ontology Let us now introduce the basic terminology of EC. As described in [218], EC “is a logical mechanism that infers what is true when, given what happens when and what actions do”. The three fundamental concepts are that of event, happening at a point in time, and of properties whose validity varies as time ﬂows. Such properties are called ﬂuents. “What actions do” is the background knowledge about actions and their eﬀects. It formalizes which ﬂuents becomes true or false when actions are performed, i.e., events occur. In the EC terminology, the event’s capability of making a ﬂuent true (false respectively) at some time is formalized by stating that the event initiates (terminates) the ﬂuent. “What happens when” is the execution trace characterizing some instance of the system under study. As in the case of CLIMB and ConDec, the basic forms of EC assume that each event is atomic, i.e., associated to a single time value. In this respect, an EC trace exactly corresponds to a CLIMB trace. The status of each ﬂuent is aﬀected by the event occurrences, according to the background knowledge. More speciﬁcally, from the combination of the background knowledge about actions and eﬀects and a concrete execution trace, “what is true when”, namely the intervals during which ﬂuents hold, can be inferred. The EC ontology used in this book is shown in Table 14.1. Note that EC adopts a time structure with a minimal element, usually associated to time 0. At time 0, the system is in its initial state, described by the set of ﬂuents holding at the beginning of the execution. To express that some ﬂuent holds in the initial state, the initially holds predicate is used. Table 14.1. The Event Calculus ontology happens at(Ev, T ) Event Ev happens at time T (corresponds to H(Ev, T ) in CLIMB) mvi(F, Ti , Tf ) Fluent F begins to hold from time Ti and persists to hold until time Tf : (Ti , Tf ] is a maximal validity interval for F holds at(F, T ) Fluent F holds at time T initially holds(F ) Fluent F holds from the initial time initiates(Ev, F, T ) Event Ev initiates ﬂuent F at time T terminates(Ev, F, T ) Event Ev terminates ﬂuent F at time T

14.2 Event Calculus

309

Diﬀerently from the simple EC ontology, our ontology also includes the concept of Maximal Validity Interval (MVI [70]), represented by the mvi/3 term. MVIs are maximal intervals during which ﬂuents uninterruptedly hold. When an event ev occurs at time t, so that initiates(e, f , t) and f does not already hold at time t, then e causes f to hold. In this case, we say that f is declipped at time t. Conversely, if terminates(e, f, t) and f holds at time t, then e causes f to not hold anymore, i.e., f is clipped at time t. Usually, a ﬂuent does not hold at the time it becomes declipped, but it holds at the time it is clipped: MVIs are open on the left and closed on the right. The evolution of each ﬂuent characterizes a partial state of the system, and the EC is in charge of establishing a relationship between event occurrences and the durations of ﬂuents’ MVIs. This is one of the main diﬀerences between EC and Situation Calculus [166], where situations capture complete states of aﬀairs. 14.2.2 Domain-Dependent vs. Domain-Independent Axioms The EC formalization of a system is constituted by two parts: • A domain-independent part, which formalizes the meaning of the EC ontology shown in Table 14.1. It is composed by a set of general axioms, capturing the relationships among the EC predicates and how they impact on the status of ﬂuents. • A domain-dependent part, which uses the predicates of the EC ontology to declaratively model the system. It introduces speciﬁc events and ﬂuents, describing the eﬀect of each action in terms of how its execution impacts on ﬂuents. Starting from the original contribution of Kowalski and Sergot, a number of EC dialects have been proposed [218, 71]. One possibility, inspired by the simple EC [211], is the following2 : holds at(F, T ) ← happens at(Ev, Tstart ) ∧ TStart < T

(ec1 )

∧ initiates(Ev, F, TStart ) ∧ ¬clipped(TStart, F, T ). clipped(T1 , F, T3 ) ← happens at(Ev, T2 ) ∧ T1 ≤ T2 ∧ T2 < T3 ∧ terminates(Ev, F, T2 ). initiates(Ev, F, T ) ← holds at(F1 , T ) ∧ ... ∧ holds at(FN , T ). terminates(Ev, F, T ) ← holds at(F1 , T ) ∧ ... ∧ holds at(FN , T ).

(ec2 ) (ec3 ) (ec4 )

(ec1 ) and (ec2 ) are the general EC axioms, while (ec3 ) and (ec4 ) are domainspeciﬁc axioms3 . Dual axioms and predicates, such as declipped, can be added 2 3

F stands for ﬂuent, E for event, T for time and ¬ for NAF. Fluents F1 –FN denote the context which determines whether F must be eﬀectively initiated or terminated[69].

310

14 Monitoring and Enactment with Reactive Event Calculus

to deﬁne when properties do not hold and to model non atomic actions with duration [218]. An example of a domain-dependent axiom is: “if someone touches the light, then the light becomes broken and it is no more on”, where “touch” is an action and “broken” and “on” are ﬂuents. It can be easily encoded in the EC as (L stands for light) initiates(touch(L), broken(L), T ).

terminates(touch(L), on(L), T ).

or, if the domain is not only composed by lights: initiates(touch(L), broken(L), T ) ← light(L). terminates(touch(L), on(L), T ) ← light(L). 14.2.3 Reasoning with Event Calculus By grounding the classiﬁcation of Peirce (see Sect. 4.3.1) on the EC, we obtain a variety of reasoning tasks over events, time and change: Deductive reasoning. (Table 14.2) – ﬁrst row) Given an EC-based speciﬁcation and an execution trace, it deduces when ﬂuents hold; in this way, queries can be placed to know whether some ﬂuent held at a given time or not. Abductive reasoning. (Table 14.2) – second row) Given an EC-based speciﬁcation of a system and a query, describing a desired state of aﬀairs, it tries to generate an execution trace which leads to the desired state and can be exhibited by the system; the synthesized trace is often considered as a plan. Inductive reasoning. (Table 14.2) – third row) Given an execution trace and the validity intervals of ﬂuents, it generalizes the connection between the event occurrences contained in the trace and the ﬂuents, producing a general theory of eﬀects and actions able to account for the observed data. All the aforementioned tasks take place after or prior to execution, but not during execution. By considering the deductive reasoning taks (carried out, for example, by a Prolog interpreter), the reason is that each time an event occurs, the EC enables a straightforward update of the theory (it suﬃces to add new happens at facts), but it incurs a substantial increase of the query time, since backward reasoning has to be restarted from scratch. However, run-time reasoning tasks, and monitoring in particular, would greatly beneﬁt from the EC’s expressive power. Hence, in the monitoring setting we advocate the need for an EC-based reactive reasoning task. It is illustrated in Table 14.2 – last row: given an EC speciﬁcation and an evolving trace, reactive reasoning constantly infers, updates and reports the status of each ﬂuent. To avoid the necessity of restarting the computation every time the execution trace is updated, Chittaro and Montanari proposed to cache the outcome

14.2 Event Calculus

311

Table 14.2. EC-based reasoning tasks initial state [initially]

deductive reasoning effects of actions

trace [happens]

EC deductive reasoning

[initiates/terminates] initial state [initially]

abductive reasoning effects of actions

trace [happens]

EC abductive reasoning

[initiates/terminates] initial state [initially]

inductive reasoning effects of actions

validity of fluents [holds_at]

trace [happens]

EC inductive reasoning

[initiates/terminates]

initial state [initially]

validity of fluents [holds_at]

validity of fluents [holds_at]

partial trace [happens]

reactive reasoning

effects of actions [initiates/terminates]

EC reactive reasoning

evolution of fluents [holds_at]

of the inference process when a new event occurrence is acquired. The resulting framework is called Cached Event Calculus (CEC) [70]. Diﬀerently from the simple EC, which has been sketched in Sect. 14.2.2, CEC does not reason upon the clipping and declipping transitions of ﬂuents, but aims instead at computing and storing their MVIs. The set of cached intervals is then extended or revised as new events get to be known. In the mid 90’s, following a diﬀerent line of research, Kowalski and Sadri [145] proposed to use Abuctive Logic Programming (ALP) as a way to reconcile backward with forward reasoning inside an intelligent agent architecture. However, beside planning, ALP has not been used in combination with the EC. Nor are we aware of other logical frameworks that implement the EC in a reactive way. For that reason, we only ﬁnd reactive EC implementations outside of logical frameworks, or else logic-based implementations of the EC that do not exhibit any reactive feature. Even the CEC of Chittaro and Montanari, which has been axiomatized in Prolog, makes use of the assert

312

14 Monitoring and Enactment with Reactive Event Calculus

and retract predicates for storing and revising MVIs, thus loosing a formal semantics. Large application domains such as run-time monitoring and event processing have been tackled so far by EC-inspired methods but only based on ad-hoc solutions without a strong formal basis. In particular, it is very difﬁcult to understand and prove the formal properties of current reactive EC implementations. We now show how to overcome this limitation. Building on Kowalski et al.’s work, we equip the EC framework with the reactive features of sciff, which have been matter of Chap. 13. We obtain a reactive version of the calculus, which we call Reactive Event Calculus (REC). REC formalizes the EC by means of a logic program and a set of integrity constraints, devoted to the dynamic generation and manipulation of MVIs as events occur.

14.3 The Reactive Event Calculus The EC can be elegantly formalized in Logic Programming, but as we said above, that would be suitable for top-down, goal-oriented computations, and not for run-time monitoring. For this reason, we resort to the SCIFF framework, which reconciles backward with forward reasoning and is equipped with the sciff proof procedure, speciﬁcally thought to accomplish reactive and dynamic reasoning. The CLIMB language is not suﬃcient to suitably formalize REC: the expressive power of SCIFF-lite is needed. SCIFF-lite has been described in Sects. 4.2.6 and 4.3.4, and extends CLIMB in two respects: ability of hypothesizing happened events, and support for generic abducible predicates. 14.3.1 Axiomatization of the Reactive Event Calculus REC is axiomatized as a SCIFF-lite speciﬁcation, drawing inspiration from Chittaro and Montanari’s CEC [70] and on their idea of MVIs. The axiomatization is fully declarative: no operational speciﬁcations are needed. In particular, REC uses the abduction mechanism to generate MVIs and deﬁne their persistence. Furthermore, it uses two special internal events (denoted by the reserved clip/declip words) to model that a ﬂuent is initiated/terminated. In this way, the real occurring events are decoupled from ﬂuents; the intuition is given in Fig. 14.2. In order to separate internal events from the real, external ones, we assume that external events are always wrapped into an event/1 term; for example, the fact that event ev occurs at time 5 is represented by H(event(ev), 5). Thanks to such a decoupling, the axiomatization is concise and, at the same time, enjoys interesting formal properties, that will be discussed in Sect. 14.5. The basic predicates of the calculus are presented below (Axioms (rec1 ) through (rec7 )). Events and ﬂuents are terms and times are CLP variables. The 0 time value corresponds to the initial time. Axiom (rec1 ) is a backward

14.3 The Reactive Event Calculus

fluents internal events

313

MVI of f declip(f)

clip(f)

external trace initiates f

terminates f

Fig. 14.2. Decoupling between execution traces and MVIs through the use of special internal events

rule (clause), as well as Axiom (rec7 ), whereas Axioms (rec2 ) through (rec6 ) are forward implications, i.e., SCIFF-lite integrity constraints. As we have discussed in Chap. 4, such a mixture of backward and forward inference rules is enabled by ALP. It represents the backbone of REC’s reactive behavior. Axiom 14.3.1 (Holding of ﬂuent). A ﬂuent F holds at time T if an MVI containing T has been generated for F . holds at(F, T ) ← mvi(F, Ts , Te ) ∧ T > Ts ∧ T ≤ Te .

(rec1 )

Axiom 14.3.2 (MVI semantics). If (Ts , Te ] is an MVI for F , then F must be declipped at time Ts and clipped at time Te , and no further declip nor clip event must occur in between. mvi(F, Ts , Te ) → E(declip(F ), Ts ) ∧ E(clip(F ), Te ) ∧ EN(declip(F ), Td) ∧ Td > Ts ∧ Td ≤ Te ∧ EN(clip(F ), Tc ) ∧ Tc ≥ Ts ∧ Tc < Te .

(rec2 )

Axiom 14.3.3 (Initial status of a ﬂuent). If a ﬂuent initially holds, then it is declipped at time 0. initially(F ) → H(declip(F ), 0).

(rec3 )

Operationally, rule (rec3 ) enforces the generation of a set of H events that are needed for the correct initial extension of MVIs. Axiom 14.3.4 (Fluent initiation). If: • event Ev occurs at time T • Ev has the capability of initiating ﬂuent F at time T • F does not hold at time T then F is declipped at time T . H(event(Ev), T ) ∧ initiates(Ev, F, T ) ∧ ¬holds at(F, T ) → H(declip(F ), T ).

(rec4 )

314

14 Monitoring and Enactment with Reactive Event Calculus

Axiom 14.3.5 (Impact of initiation). The happening of a declip(F) event causes ﬂuent F to start to hold. H(declip(F ), Ts ) → mvi(F, Ts , Te ) ∧ Te > Ts .

(rec5 )

Axiom 14.3.6 (Fluent termination). If: • event Ev occurs at time T • Ev has the capability of terminating ﬂuent F at time T • F holds at time T then F is clipped at time T . H(event(Ev), T ) ∧ terminates at(Ev, F, T ) ∧ holds at(F, T ) → H(clip(F ), T ).

(rec6 )

Axiom 14.3.7 (Final clipping of ﬂuents). All ﬂuents are terminated by the special complete event. terminates(complete, F, T ).

(rec7 )

The complete event is used to state that no more events will occur, and therefore it clips all the ﬂuents that still hold. The axioms provided so far are general, domain-independent rules. In order to obtain a concrete speciﬁcation, such as the personnel monitoring facility that will be described in Sect. 14.4.1, the user must provide a domaindependent knowledge base, which is then combined with the general knowledge base of REC. The result is a REC speciﬁcation, formalized inside the SCIFF framework. Deﬁnition 14.3.1 (REC speciﬁcation). Given a domain-dependent knowledge base KBdom , the REC speciﬁcation built upon KBdom , written REC (KB dom ), is deﬁned as the SCIFF-lite speciﬁcation: REC (KBdom ) KB REC ∪ KBdom , {E, EN, H, mvi}, IC REC where KBREC = {(rec1 ), (rec7 )} IC REC = {(rec2 ), (rec3 ), (rec4 ), (rec5 ), (rec6 )} With an abuse of notation, in the following REC will stand for an arbitrary REC speciﬁcation. Note that the proposed axiomatization completely adheres to the EC ontology described in Sect. 14.2.1. Therefore, arbitrary EC-based domain theories can be seamlessly used together with REC.

14.3 The Reactive Event Calculus

initial state [initially]

315

partial trace [happens]

REC KB

REC specification

effects of actions

KB Integrity Constraints

[initiates/terminates]

sciff Proof Procedure

evolution of fluents [holds_at]

REC Integrity Constraints

rec

Fig. 14.3. REC-based monitoring with sciff

14.3.2 Monitoring an Event Calculus Speciﬁcation with the SCIFF Proof Procedure We have shown how the EC ontology described in Sect. 14.2.1 can be accommodated inside the SCIFF framework, with a reactive ﬂavor. Thanks to the provided axiomatization, REC-based monitoring can be eﬀectively carried out by the sciff proof procedure. Fig. 14.3 gives the overall picture. Following the convention already adopted for SCIFF, in the remainder of the discussion we will use REC to denote an arbitrary REC speciﬁcation (Def. 14.3.1), and rec to denote the reasoning facility provided by the application of sciff on a REC speciﬁcation. rec shifts the focus from run-time compliance veriﬁcation to monitoring. Indeed, expectations are used only to ensure the consistency of the generated MVIs, and the interesting result produced by the veriﬁer is not the set of pending, violated and fulﬁlled expectations, but is instead the set of computed ﬂuents’ validity intervals. In particular, rec reacts to the occurring events, performing an open or semi-open reasoning chunk each time a new happened event is acquired. An abductive explanation is consequently produced. The set of computed MVIs can be extracted from each abductive explanation. When the ﬁnal complete event occurs (see Axiom rec7 ), rec is alerted that the monitored execution has reached its end, and can consequently apply the closure transition in a deterministic way (see Sect. 9.1.3).

316

14 Monitoring and Enactment with Reactive Event Calculus

14.4 REC Illustrated: A Personnel Monitoring Facility We illustrate the usage and potential impact of REC in a real-world case study. It was proposed to us by a local medium-sized enterprise based in Emilia Romagna (Italy), but the same situation can apply to any organization. It is about a personnel monitoring activity, which costs a considerable amount of human resources, but could be accomplished in a fully automated way using REC. A company wants to monitor its personnel’s time sheets. Each employee punches the clock when entering or leaving the oﬃce. The system recognizes two events: • check in(E) – employee E has checked in; • check out(E) – employee E has checked out. The following business constraints must be respected by the employees, and thus monitored by REC: Rule (RI/O ) states that an employee must check out within 8 hours from the last check in; Rule (Ralarm ) manages the generation of alarms at an operator’s desk. An alarm reports the employee ID, and an indication of the time interval elapsed between the deadline expiration and its detection. The alarm is turned oﬀ when the operator decides to handle it. The following activities are made available to the operator: • handle(E) states that the operator wants to handle the situation concerning the employee identiﬁed by E; • inquire is used to take a snapshot of the current situation of the system, and also to keep rec informed about the current time.

Note that the second requirement is activated when the ﬁrst one is violated. Hence, such a system cannot be modeled directly by means of a ConDec model or a CLIMB speciﬁcation, because there is no language construct for identifying violations, and when a violation is detected by sciff, then veriﬁcation is completed. 14.4.1 Formalizing the Personnel Monitoring Facility in REC We capture the business constraints (RI/O ) and (Ralarm ) with the following three ﬂuents: • in(E) – E is currently inside the company; • should leave(E, Td ) – E is expected to leave her oﬃce by Td ; • alarm(delay(E, D)) – E has not left the oﬃce in time; D represents the diﬀerence between the time at which the deadline expiration has been detected by rec, and the eﬀective expiration time.

14.4 REC Illustrated: A Personnel Monitoring Facility

317

The two requirements can be then declaratively captured using initiates and terminates predicate deﬁnitions. The obtained knowledge base is a standard EC-based theory, which can be seamlessly passed to rec for monitoring, or used in conjunction with a diﬀerent EC reasoner when other kinds of reasoning facilities are needed. In the formalization, we assume hour time granularity. Let us ﬁrst focus on the in(E) ﬂuent. E is in as of the time she checks in. She ceases to be in as of the time she checks out: initiates(check in(E), in(E), T ). terminates(check out(E), in(E), T ). When E checks in at Tc , a should leave ﬂuent is activated, expressing that E is expected to leave the oﬃce by Tc + 84 : initiates(check in(E), should leave(E, Td), Tc ) ← Td is Tc + 8. Such a ﬂuent can be terminated in two ways: either E correctly checks out within the 8-hour deadline, or the deadline expires. In the latter case, termination is imposed as soon as some event occurs after the deadline, making rec aware that the deadline is expired. terminates(check out(E), should leave(E, Td ), Tc ) ← ∧Tc ≤ Td . terminates(Ev, should leave(E, Td ), T ) ← T > Td . The same (generic) event also triggers the generation of an alarm: initiates(Ev,alarm(delay(E, D), T ) ← holds at(should leave(E, Td), T ) ∧ T > Td ∧ D is T − Td . First, the rule checks whether a should leave ﬂuent is currently active. Then, it tests whether the deadline is expired. If it is the case, the diﬀerence between the current time and the deadline is calculated. Note that in the time at which the alarm is triggered is the same time used inside the holds at atom of the rule’s body. This is perfectly normal, but it is not a requirement. In particular, times could be diﬀerent, as long as the times of holds at atoms do not follow event termination/start times. That again would be allowed, but it would amount to deﬁning properties that depend on future events: properties that are thus not suitable for run-time monitoring. For that reason, we assume that well-formed theories do not contain such kind of clauses. More details on this matter will be given below when we discuss the irrevocability property in a formal way. As a last fact, we capture that an alarm is turned oﬀ when the operator handles it: terminates(handle(E), alarm(delay(E, D)), T ). 4

Note that Tc is ground when the predicate is evaluated, due to Axiom (rec4 ).

318

14 Monitoring and Enactment with Reactive Event Calculus

Fig. 14.4. Fluents tracking in REC

14.4.2 Monitoring a Concrete Instance By combining the general REC theory proposed in Sect. 14.3 and the domainspeciﬁc theory shown in Sect. 14.4.1, we obtain a SCIFF-lite speciﬁcation which can be used to dynamically reason upon the employees’ ﬂow inside a company. In particular, rec can now compute and track the status of each employee, generating an “alarm ﬂuent” as soon as a deadline expiration is detected. Let us consider an execution trace involving two employees e1 and e2 , where e2 does respect the required deadline while e1 does not: H(event(check in(e1 )), 9), H(event(check in(e2 )), 12),

H(event(inquire), 10), H(event(inquire), 14),

H(event(inquire), 18),

H(event(inquire), 19).

Fig. 14.4 shows the global state of ﬂuents at 19, computed by rec when an alarm has just been generated because e1 was expected to leave the oﬃce no later than 17, but she has still not left at 18. The operator can check all pending alarms, and pick an employee to handle in case. The execution now proceeds as follows: H(event(check out(e2 )), 20), H(event(check out(e1 )), 23).

H(event(handle(e1 )), 22),

14.4 REC Illustrated: A Personnel Monitoring Facility

319

Fig. 14.5. Final result produced by REC at the end of the interaction

e2 correctly leaves the oﬃce within the deadline, bringing her corresponding in and should leave ﬂuents to termination. At 22 the operator handles e1 , who eventually leaves the oﬃce at 23. At time 25, the instance is then considered as completed. This is communicated to rec by generating a complete event occurrence: H(event(complete), 25). Fig. 14.5 shows the ﬁnal pictured produced by rec. 14.4.3 The Irrevocability Issue In general, a monitoring application is usable only if it provides stable, deterministic outputs, which do not ﬂutter due to algorithmic issues but only change as a sensible response to the inputs. The reasons of an undesired ﬂuttering behavior could be of two types: an unsuitable or bad set of speciﬁcations, or an unsuitable underlying reasoning machinery. In the EC setting, a ﬂuttering behavior results in some ﬂuent suddenly disappearing, or a ﬂuent suddenly appearing in the past. As an example of the former, imagine to replace initiates(check in(A), in(A), ) by initiates(check in(A), in(B), ).

320

14 Monitoring and Enactment with Reactive Event Calculus

This is an ambiguous speciﬁcation since it does not clearly state which employee should change status as a consequence of A checking in. Another different source of ambiguity could lay hidden in an alternative formulation of the ﬁring alarm rule: initiates(Ev,alarm(delay(E, D), T ) ← holds at(should leave(E, Td), T1 ) ∧ D is T − Td ∧ T1 > T. The meaning would be that the alarm is bound to a ﬂuent whose validity is checked in the future. Only speculations are possible in that case, and no run-time monitoring algorithm could provide deterministic answers (unless it freezes until the ﬂuent holds, but in that case the application would no longer be called “run-time”). Thus we need to isolate “good” sets of speciﬁcations. Once we have them, we must ensure that the reasoning machinery does not make unjustiﬁed retractions. In other words, we must guarantee irrevocability.

14.5 Formal Properties of REC We investigate some formal properties of REC, ranging from general properties (soundness, completeness and termination) to monitoring-speciﬁc properties (uniqueness of the monitoring outcome and irrevocability in particular). 14.5.1 Soundness, Completeness, Termination The soundness and completeness results for rec are seamlessly inherited from sciff5. These are important results: the operational behavior of REC is directly obtained from the sciff proof procedure, and it is therefore faithful to its axiomatization. We are unaware of other reactive implementations of the EC that provide such a guarantee. The same holds for the termination property. Without ﬂeshing out the formal details, the general axiomatization of REC is acyclic and bounded, and therefore enjoys termination: even if the integrity constraints contain happened events both in the body and in the head, the separation between external events and internal clip/declip ones guarantees the absence of cyclic chains. Therefore, given an arbitrary domain-dependent knowledge base KBdom , its acyclicity and boundedness are necessary and suﬃcient conditions for guaranteeing the termination of rec when reasoning upon REC(KBdom ). In other words, acyclicity and boundedness can be studied by considering KB dom separately, without taking into account the integrity constraints nor the clauses of the general, domain-independent part. 5

sciff’s soundness and completeness results have been recalled in Sect. 9.2 for the CLIMB fragment; the theorems and proofs for the general full-SCIFF language can be instead found in [8].

14.5 Formal Properties of REC

321

14.5.2 Irrevocability of REC In Sect. 14.4.1, we have shown that EC enables the possibility of explicitly modeling undesired states of aﬀairs (a deadline expiration in particular) in the language, using special ﬂuents to track their occurrence. As we have discussed in Sect. 14.1, this was the ﬁrst relevant limit of run-time veriﬁcation. The second is related to the fact that the results computed by sciff cannot always be used to properly characterize the current state of aﬀairs, even when events are processed in ascending order. In order to overcome this issue in rec, it is required that the generated MVIs are never retracted, but only extended or terminated as new events occur. If that is the case, the reasoning process is called irrevocable. Some target applications need irrevocable tracking procedures, which can give a continuously updated view of the status of all ﬂuents. Fluttering behaviours must be by all means avoided. This is true, e.g., when the modeled ﬂuents carry a normative or regulatory meaning, as in the case of business constraints. It would be undesirable, for instance, to attach a certain obligation to an agent at run-time, and see it disappear later only because the calculus revises its computed status. In the reminder of this section, we ﬁrst deﬁne a class of “well-formed” REC theories, then we show that semi-open reasoning is irrevocable when monitoring an arbitrary well-formed speciﬁcation. The proofs of theorems can be found in [171] – Sect. 14.4. Deﬁnition 14.5.1 (Well-formed EC-based theory). A knowledge base KB is well-formed if and only if: 1. KB is acyclic and bounded 2. for initiates(Ev, F, T ) clauses, ﬂuent F must always be resolved with a ground substitution. 3. for each holds at(F2 , T2 ) predicate used in the deﬁnition of an initiates/3 or terminates/3 predicate, it holds that T2 ≤ T . A REC speciﬁcation REC(KB) is well-formed if and only if KB is well-formed. The ﬁrst property is introduced to guarantee the termination of rec. The second property prevents non-determinism due to the case analysis transition of sciff, while the last property restricts us to reason on stable, past conditions. When the knowledge base is “past-tense” and the trace grows by ascending time values, at any point in time rec has complete information to decide whether a ﬂuent must be initiated or terminated. REC theories that violate one of such properties would instead introduce choice points that hinder irrevocability. In Sect. 14.4.1, the personnel monitoring facility was modeled by a well-formed REC theory. Using the same example, in Sect. 14.4.3 we have discussed the consequences of ill-formed speciﬁcations: they violate the well-formedness requirements, consequently causing a ﬂuttering behavior of rec.

322

14 Monitoring and Enactment with Reactive Event Calculus failure derivations

event acquisition

quiescent node failure derivations

event acquisition

quiescent node

Fig. 14.6. Proof tree generated by REC in case of a well-formed speciﬁcation and events processed in ascending order

Well-formed speciﬁcations enjoy two important formal results, which not only guarantee irrevocability, but have also a positive impact on the performance of rec. Theorem 14.5.1 (Uniqueness of derivation). Given an arbitrary wellformed domain-dependent EC theory KB, for each initial execution trace Ti and for each ﬁnal execution trace Tf there exists exactly one successful semiopen derivation computed by rec: T ∃ 1 Δ REC(KB)Ti ∼Δf true Proof. See [171] – Sect. 14.4. Theorem 14.5.1 ensures that exactly one Δ is produced by a semi-open derivation of rec. The behavior of rec then resembles the schema shown in Fig. 14.6. Each time a new event occurs, rec is awoken, and starts a new reasoning chunk. It may incur in a set of failure derivations, but ﬁnally reaches a successful quiescent node. We know that such a node is unique, and therefore all the open alternatives can be pruned without undermining the soundness and completeness of the proof. rec then waits until a new event occurs. The process is repeated until the complete event is fetched; in this case, the quiescent node represents the terminal point of the unique rec’s closed successful derivation. In every quiescent node, the computed abductive explanation contains the whole set of MVIs, as determined by the partial trace accumulated so far. We show that the sequence of MVIs conﬁgurations does not only enjoy the uniqueness property, but also obey to irrevocability.

14.5 Formal Properties of REC

323

First of all, let us precisely deﬁne the concepts of MVI state and of the progressive extension between states, which gives a formal account to irrevocability. The deﬁnitions rely on the concept of “current time” – Def. 13.2.2. Given an execution trace T , the current time ct(T ) corresponds to the maximum time at which some event contained in T happened. Deﬁnition 14.5.2 (MVI State). Given a REC speciﬁcation REC and an execution trace T , the resulting MVI state at time ct(T ) is the set of mvi abducibles contained in the (unique) computed explanation generated by rec: MVI(REC T ) {mvi(f, ts , Te ) ∈ Δ}, where REC ∅ ∼TΔ true Deﬁnition 14.5.3 (Closed and open sub-states). Given a REC speciﬁcation REC and a (partial) execution trace T , the current state MVI(REC T ) is split into two sub-sets6 . • MVI (REC T ) is the set of “closed” MVIs, i.e., MVIs which have been already terminated, and thus have ground extremes: MVI

(REC T ) = {mvi(f, ts , te ) ∈ MVI(RT ) | ground(ts )∧ground(te )}

• MVI (REC T ) is the set of “open” MVIs, i.e., MVIs which have not yet been terminated. They therefore have a variable upper bound, which will be surely grounded at a time greater than ct(T ): MVI (REC T ) = {mvi(f, ts , T ) ∈ MVI(REC T ) | ground(ts ) ∧ var(T )} Deﬁnition 14.5.4 (Trace extension). Given two execution traces T1 and T2 , T2 is an extension of T1 , written T1 ≺ T2 , if and only if ∀ H(e, t) ∈ T2 /T1 , t ≥ ct(T1 ) Deﬁnition 14.5.5 (State progressive extension). Given a well-formed REC speciﬁcation REC and two execution traces T1 and T2 , the state computed in REC T2 is a progessive extension of the state computed in REC T1 , written MVI(REC T1 ) MVI(REC T2 ), if and only if 1. the set of closed MVIs is kept unchanged in the new state: MVI (REC T1 ) ⊆ MVI (REC T2 ) 2. if the set of MVIs is extended with new intervals, these are declipped after the maximum time of T1 : ∀ mvi(f, s, t) ∈ MVI(REC T2 )/MVI(REC T1 ) s > ct(T1 ) 3. for each open MVI mvi(f, s, Te ) ∈ MVI (REC T1 ), either a) it is kept unchanged in the new state mvi(f, s, Te ) ∈ MVI (REC T2 ) 6

Note that every generated MVI surely has a ground starting time; the interested reader can refer to [171] – Sect. 14.4 – for a formal proof.

324

14 Monitoring and Enactment with Reactive Event Calculus

b) it is clipped after the maximum time of T1 mvi(f, s, e) ∈ MVI (REC T2 ), e > ct(T1 ) The notion of progressive extension intuitively expresses that one state extends another state if it keeps the already computed closed MVIs and aﬀects the status of ﬂuents only at times greater than the time at which the ﬁrst state was recorded. The extension consists in the addition of new MVIs or in the clipping of ﬂuents which held at the old state. In this respect, irrevocability expresses that when the execution trace grows in ascending order, each computed MVI state is a progressive extension of the previous ones. This property is always met by rec when reasoning upon a well-deﬁned REC speciﬁcation. Lemma 14.5.1 (Trace extension leads to a state progressive extension). Given a well-formed REC speciﬁcation REC and two execution traces T1 and T2 , it holds that: T1 ≺ T2 =⇒ MVI(RT1 ) MVI(RT2 ) Proof. See [171] – Sect. 14.4. Theorem 14.5.2 (Irrevocability of REC). Given a well-formed REC speciﬁcation and a trace growing in ascending order, each time rec processes a new event, the newly computed MVI state is a progressive extension of the previous one. Proof. See [171] – Sect. 14.4.

14.6 Monitoring Optional ConDec Constraints with REC REC-based monitoring is helpful in the management of ConDec optional constraints. Optional constraints express preferred scenarios: it is preferable to satisfy them, but their violation does not lead to undermine compliance. As pointed out by Pesic in [191], “allowing users to violate an optional constraint without any warning would totally hide the existence of the constraint”. Monitoring optional constraints is therefore important to warn the interacting entities when an optional constraint is (permanently) violated. We now exploit the advanced features provided by REC to express and monitor optional ConDec constraints. Being REC axiomatized on top of SCIFF-lite, it can be seamlessly combined with the CLIMB speciﬁcation formalizing the mandatory constraints of the model under study. In this way sciff provides a combined monitoring and run-time veriﬁcation framework (see Fig. 14.7).

14.6 Monitoring Optional ConDec Constraints with REC

325

ConDec model Mandatory constraints

Optional constraints

Fluent-based ConDec Formalization Reactive Event Calculus

SCIFF Framework Run-time verification

Monitoring

Fig. 14.7. ConDec execution support by combining run-time veriﬁcation and monitoring

14.6.1 Representing ConDec Optional Constraints in the Event Calculus To enable monitoring facilities, a translation of ConDec (optional) constraints into EC must be provided. We propose a formalization split into two parts: • a general part, which describes how each ConDec constraint can be modeled as a set of ﬂuents, and how such ﬂuents are initiated and terminated by the occurrence of involved the activities; • a model-speciﬁc part, whose purpose is to describe the structure of the targeted ConDec diagram, focusing in particular on its optional constraints. The combination of such two parts constitutes the domain-dependent knowledge base of the REC speciﬁcation. The model-speciﬁc part is simply a set of opt con/2 facts. Each fact corresponds to a ConDec optional constraint in the diagram, and it is associated to a unique identiﬁer. For example

opt con c1 , response(query, inf orm) expresses that the ConDec model contains an optional constraint query •−−− inform and identiﬁes it by c1 . The general part is a set of predicate deﬁnitions aimed at capturing the status of each ConDec optional constraint. The status is aﬀected as the activities interconnected to the constraint are executed. In order to elicit suitable ﬂuents, we split constraints into two families:

326

14 Monitoring and Enactment with Reactive Event Calculus

• constraints that must be eventually satisﬁed , and that could become temporarily violated, waiting for the execution of some activity; • constraints that forbid the presence of some activity when they are active. An example of constraint belonging to the ﬁrst family is the response constraint: • a •−−− b is initially satisﬁed; • every time a is performed, the constraint switches to a temporary violated state; • the constraint becomes satisﬁed again when b is executed. An example of constraint belonging to the latter family is the negation response constraint: − b is triggered; • when activity a occurs, a •−− • any future execution of b is forbidden; • if b is eventually executed, a permanent violation arises. We therefore rely on two diﬀerent ﬂuents: • sat(c) states that the optional constraint c is currently satisﬁed; • f orb(a, c) states that the optional constraint c is currently active, and forbids the execution of activity a. Table 14.3 indicates how such ﬂuents can be suitably employed in the formalization of some ConDec constraints. The full theory can be found in [64]. It is worth noting that the proposed theory is well-formed, and thus guarantees all the formal properties described above, including uniqueness of the rec successful derivation and irrevocability. Some parts of the formalization are left implicit for ease of presentation. In particular, Table 14.3 contains a simpliﬁed formalization, which grounds the clauses to the corresponding activities and constraint’s identiﬁer. Actually, the formalization is given once and for all in the general case, binding the clauses to opt con/2 facts. For example, the complete formalization of response it: initially holds(sat(C)) ← opt con(C, response(A, B)). terminates(A, sat(C), T ) ← opt con(C, response(A, B)). initiates(B, sat(C), T ) ← opt con(C, response(A, B)). The ﬁrst clause states that if the ConDec model under study contains an optional response constraint identiﬁed by C, then C is initially satisﬁed. The second clause points out that when the source of C occurs, then the constraint is no more satisﬁed. The last clause brings the constraint back to the “satisﬁed” state, when the target activity of C is performed. Note that, diﬀerently from the CLIMB formalization, all the ConDec constraints are now represented in a future-tense manner, for the sake of irrevocability. For example, constraint precedence(a,b), which is represented in

14.6 Monitoring Optional ConDec Constraints with REC

327

Table 14.3. Representing some optional ConDec constraint in EC constraint

intuition

formalization

1..∗{c}

sat(c)

a

initiates(a, sat(c), T ).

a n..∗{c}

sat(c)

a a ... a

{c}

a •−−− b {c}

a −−−• b

(n-th)a

initiates(a, sat(c), Tn ) ← H(exec(a), Tn−1 ) ∧ Tn−1 < Tn ∧ . . . ∧ H(exec(a), T1 ) ∧ T1 < T2 . initially holds(sat(c)).

sat(c)

sat(c) a

b

terminates(a, sat(c), T ). initiates(b, sat(c), T ). initially holds(f orb(b, c)).

forb(b,f)

terminates(a, f orb(b, c), T ).

a {c}

forb(b,c)

a •−− − b

initiates(a, f orb(b, c), T ).

a

initially holds(sat(c)). terminates(a, sat(c), T ).

forb(a,c)

{c}

a •=== b

sat(c)

sat(c) a

b

initiates(b, sat(c), T ). initiates(a, f orb(a, c), T ). terminates(b, f orb(a, c), T ).

{c}

a •= −= −= − b

forb(b,c) a

Xb

initiates(a, f orb(b, c), T ). terminates(X, f orb(a, c), T ) ← X = b.

CLIMB as “if b is executed, then a previous occurrence of a is expected”, is now represented as “b is forbidden unless a is executed”. Finally, the proposed formalization can be easily adapted to deal also with branching constraints, similarly to the approach followed for CLIMB in Sect. 5.5. To model branches, we extend the way constraints are represented by considering sets of activities instead of individual activities. We then adapt the formalization shown in Table 14.3, using membership constraints to specify that each activity belonging to the set has the capability of initiating or terminating the involved ﬂuent. For example, the formalization of the branching response optional constraint is extended as follows:

328

14 Monitoring and Enactment with Reactive Event Calculus

initially holds(sat(C)) ← opt con(C, response(Source, T arget)). terminates(A, sat(C), T ) ← opt con(C, response(Source, T arget) ∧ A :: Source. initiates(B, sat(C), T ) ← opt con(C, response(Source, T arget)) ∧ B :: T arget. To model a speciﬁc business constraint such as “if a shipment is requested to the warehouse, then the warehouse is in charge of delivering the package or communicating that some of the ordered items are out of stock”, the following fact must be added to the knowledge base: opt con(cwarehouse , [request shipment], [deliver package, out of stock]). When the shipment is requested, ﬂuent sat(cwarehouse ) is clipped; the ﬁrst following execution of deliver package or out of stock will declip it. 14.6.2 Identiﬁcation and Reiﬁcation of Violations Now that a mapping of the ConDec optional constraints onto EC has been established, it becomes possible to monitor an instance of the system, obtaining a constantly updated and irrevocable view of each optional constraint’s status. The last step is to identify which kinds of violation may occur, and to write down a set of further rules which handle their reiﬁcation. Roughly speaking, an execution trace complies with the optional constraints if and only if: • an activity a is never executed when it is forbidden by some constraint c, i.e., when f orb(a, c) holds; • each sat(C) ﬂuent contained in the speciﬁcation holds at the end of the trace, attesting that all Cs have been eventually satisﬁed. As for negative and positive expectations, a violation of the ﬁrst kind can be detected during the execution, when a forbidden event occurs. Conversely, unsatisﬁed constraints can de detected only at the end of the execution, i.e., when the monitoring framework has already completed its work and the generation of warnings is not useful anymore7 . Things change when positive ConDec relationships are augmented with metric temporal constraints (as speciﬁed in Sect. 6.1.4), because the expiration of a deadline can be detected on-the-ﬂy. Hence, in the context of monitoring we focus on two kind of violations: • violation of a prohibition; • deadline expiration8 . 7 8

This kind of violation can be simply detected by looking if all the sat(C) ﬂuents hold at the ﬁnal state. In the following, we will focus only on deadlines; delays can be handled in a complementary way.

14.6 Monitoring Optional ConDec Constraints with REC

329

Fig. 14.8. Violation of a negation response optional constraint

Both kinds of violations can be captured by a set of dedicated integrity constraints. If a violation takes place at time t , then a special event occurrence H(violation(f ), t) is generated, where f is the ﬂuent involved in the violation. Hence, violations are reiﬁed in terms of special happened events, which can be reported to the interacting entities, as well as used to trigger further rules.

Violation of a Prohibition A forb(A,C) ﬂuent is violated at time T if and only if: • forb(A,C) holds at time T ; • A is executed at time T . In this situation, a violation event is generated, by means of the following integrity constraint: H(event(A), T )∧holds at(forb(A, C), T ) → H(event(violation(forb(A, C))), T ). Fig. 14.8 illustrates a violation of the following negation response constraint: {c}

close order •−− − choose item In order to graphically show that the violation has been eﬀectively reiﬁed at time 15, the following fact is added to the REC speciﬁcation: initiates(violation(F ), violated(F ), T ).

330

14 Monitoring and Enactment with Reactive Event Calculus

Deadline Expiration The identiﬁcation of a deadline expiration resembles the Personnel Monitoring Facility realized in Sect. 14.4.1. The presence of a deadline is modeled as a deadline(C, D) fact, where C is the constraint identiﬁer and D the value of the deadline. For example, consider the business constraint “when an order is paid, a receipt must be delivered within 6 time unit”, which can be represented in ConDec++ by the metric response constraint (0,6)

pay •−−− deliver By identifying the constraint as pay-deliver, the corresponding REC-based representation would be: opt con(pay-deliver, response(pay, deliver)). deadline(pay-deliver, 6). A ﬂuent d check(C, Texp ) is then introduced, modeling that constraint C is associated to a deadline that expires at time Texp . This ﬂuent must be initiated when the “countdown” is started. Supposing that such a time is T and that the deadline value is D (D = 6 in the aforementioned example), then the actual expiration of the deadline will be Texp = T + D. For example, in the case of metric response constraints, the d check ﬂuent is initiated when the source of the constraint occurs: initiates(A, d check(C, Texp ), T ) ← opt con(C, response(A, B)) ∧ deadline(C, D) ∧ Texp = T + D. The d check ﬂuent is terminated either because the constraint is satisﬁed within the deadline, or because of the deadline expiration, which in turn leads to generate a violation. By considering again the response case, a correct termination occurs if the target activity is executed before the deadline expiration time: terminates(B, d check(C, Texp ), T ) ← opt con(C, response(A, B)) ∧ T ≤ Texp . The second possibility captures the expiration of the deadline. As we have discussed before, sciff (and this rec) is not equipped with an autonomous ﬂow of time: it becomes aware of the current time only when a new event occurs. Therefore, we can keep rec up-to-date by means of tic events. The deadline expiration is then detected and handled as soon as the ﬁrst tic event occurs such that the deadline has passed: terminates(tic, d check(F, Texp ), T ) ← T > Texp .

14.6 Monitoring Optional ConDec Constraints with REC

331

Fig. 14.9. Possible violations of a metric response optional constraint

Finally, an integrity constraint is dedicated to reify the violation: H(event(tic), T )∧holds at(d check(C, Texp ), T ) ∧ T > Texp → H(event(violation(d check(C, Texp ))), T ). Fig. 14.9 shows the result obtained by applying the proposed approach on two instances. In particular, two execution traces are monitored against the aforementioned metric pay-deliver constraint, detecting their noncompliance. In the ﬁrst case, tic events are generated by a clock, hence they have a rate of one time unit. The deadline expiration is then promptly detected by rec. In the second case, tic events are generated with a rate of two time units, and therefore the expiration is detected with a delay of one time unit. Furthermore, while in the ﬁrst case the deliver activity is never executed, in the second one it is executed late: ﬂuent sat(pay-deliver) is correctly brought about, but the deadline has been already declared as violated. The combination of ﬂuents’ states can be exploited to identify several degrees of noncompliance, ranging from a complete violation (e.g., the expected delivery never occurs) to partial ones (e.g., the expected delivery occurs late, running over deadline). 14.6.3 Compensating Violations Among the plethora of possibilities oﬀered by the reiﬁcation of violations, an interesting topic is to model further business constraints, dedicated to regulate the interaction when a violation takes place. Such constraints could specify: • how the interacting parties must compensate a violation; • a context for violations, modeling constraints which become optional only in certain situations. Compensation is a well-known topic in Service Oriented Computing. Diﬀerently from a pure roll-back approach, which assumes that activities can and their eﬀects can be undone, compensation is associated to a separate explicit interaction model, which is activated when the violation is encountered. In the ConDec setting, compensation mechanisms can be modeled by introducing

332

14 Monitoring and Enactment with Reactive Event Calculus

business constraints which involve violation events. For example, a response constraint having a violation event as source would state that when such a violation takes place, then the target activity must be eventually executed for compensation. In this respect, a chain response constraint could be employed to handle critical violations: it would state that when a violation is detected, the next immediate activity to be executed is the compensating one. Contextualization of violations and optional constraints can be instead modeled by means of past-tense ConDec mandatory constraints. For example, a precedence constraint spanning from violation(c) to activity a models the situation in which the constraint identiﬁed by c can be violated only if a has been previously executed (a thus represents somehow the idea of a context). If it is the case, then the constraint violation is reiﬁed and managed, otherwise a deﬁnitive, negative answer attesting noncompliance is computed. 14.6.4 Monitoring Example We now brieﬂy discuss a choreography fragment, where monitoring must be able to deal with a contextualized compensation. In order to show the ability of rec in tracking the status of each constraint, we suppose that all the involved constraints are optional. The choreography involves a customer, who creates an order by choosing one or more items, and a seller, who collects the ordered items and ﬁnally gives a receipt. Each selected item must be validated by the seller, who is in charge of communicating whether it can be eﬀectively sold or not. When the order is closed, the seller becomes committed to issue a ﬁnal receipt within a pre-established deadline of 3 time units. In the normal situation, the deadline is sharp, and the seller must respect it in order to comply with the choreography. However, the seller places an oﬀer to customers: if they accept the possibility of receiving a late receipt (by means of the accept delays activity), then in case of a delay the seller can compensate the deadline expiration by emitting a discounted receipt. More speciﬁcally, the following ConDec++ rules of engagement must be fulﬁlled by the interacting services. (c1 ) Every choose item activity must be followed by an answer from the seller, either positive or negative; no further upload can be executed until the response is sent. Conversely, each positive/negative answer must be preceded by a choose item activity, and no further answer can be provided until a new item is chosen. (c2 ) If at least one uploaded item has been accepted by the seller, then the customer can close the order. (c3 ) When an order has been closed, no further item can be chosen. (c4 ) When an order has been closed, the seller is committed to send a corresponding receipt by at most 3 time units. (c5 ) If the seller does not meet the deadline, then a discounted receipt must be eventually delivered; this requirement is modeled as a response constraint, triggered by the violation of constraint c4 ; the violation is

14.6 Monitoring Optional ConDec Constraints with REC

(customer)

(customer)

(customer)

choose item

close order

accept delays

c3 c2

c6

c4 (0..3)

c1

333

c5

(seller)

(seller)

(seller)

(seller)

refuse item

accept item

send receipt

send disc. receipt

Fig. 14.10. A ConDec++ choreography with a compensation mechanism Table 14.4. REC knowledge base formalizing the choreography fragment shown in Fig. 14.10 c1 ) c2 ) c3 ) c4 )

opt con(c1 , alternate succession([choose item], [ref use item, accept item])). opt con(c2 , precedence([accept item], [close order])). opt con(c3 , negation response([close order], [choose item])). opt con(c4 , response([close order], [send receipt])). deadline(c4 , 3). c5 ) opt con(c5 , response([violation(d check(c4 , )], [send discounted receipt])). c6 ) opt con(c6 , precedence([accept possible delays], [send discounted receipt])).

graphically depicted using the same notation of BPMN intermediate error events [263]. (c6 ) A discounted receipt can be emitted only if the customer has previously accepted the possibility of experiencing delays.

Fig. 14.10 shows the graphical ConDec representation of the choreography, while Table 14.4 illustrates how it can be formalized as a domain-dependent knowledge base. By combining this knowledge base with the ﬂuent-based formalization of ConDec (considering also the rules for the reiﬁcation of violations), it is possible to employ rec for monitoring the choreography instances. Fig. 14.11 illustrates the result produced by rec when monitoring a course of interaction. In particular, The right part of the diagram (from time 15 to time 23) shows how rec handles the deadline expiration: • at time 15, the order is closed, causing c4 to become unsatisﬁed; • a d check ﬂuent is initiated, checking whether the actual deadline is respected by satisfying c4 within time 18; • at time 19, a tic event makes the proof procedure aware that the deadline is expired; • rec reacts to the violation by terminating the d check ﬂuent and by reifying the violation, through the generation of the event occurrence H(event(violation(d check(c4 , 18)), 19)

334

14 Monitoring and Enactment with Reactive Event Calculus

Fig. 14.11. Monitoring result generated by rec when reasoning upon an instance of the ConDec++ choreography shown in Fig. 14.10

• the reiﬁed violation interacts with the sat(c5 ) ﬂuent – it is terminated, waiting for a discounted receipt to satisfy it again.; • at time 21 the receipt is sent, but since the deadline is already expired, a discounted receipt must be sent anyway; • at time 23 the discounted receipt is ﬁnally sent – the execution is hence completed in a correct way.

14.7 Enactment of ConDec Models

335

CLIMB model

block non executable activities show pending constraints

Enactment partial execution report whether the model is currently satisfied

continue

terminate

Fig. 14.12. Enactment of ConDec models

14.7 Enactment of ConDec Models The enactment of ConDec models consists in providing support to the interacting entities during the execution, keeping them informed about how the events occurred so far have aﬀected the business constraints, and how the execution can be carried on by respecting them. In the Business Process Management setting, the enactment is driven by a process engine, which takes a Business Process model and presents to the involved parties the so-called worklist, a todo list enumerating all the activities that must be currently executed. When one of such activities is performed, the process engine logs the operation (extending the partial execution trace of the instance) and then moves one step forward along the process model, updating the worklist. In the context of ConDec, the enactment task must be adapted to the declarative nature of the approach: it is unreasonable to show what to do next. In particular, the enactment of ConDec, schematized in Fig. 14.12, is about 1. highlighting the constraints that are temporarily violated, i.e., the pending ones, waiting for the execution of some activity; 2. showing the forbidden, non executable activities, i.e., the ones whose execution would lead to a conﬂict; 3. showing the enabled activities, i.e., the ones that are not forbidden;

336

14 Monitoring and Enactment with Reactive Event Calculus

4. reporting whether the execution can be currently completed, i.e., whether the interacting entities can quit without breaking some mandatory constraint. In other words, the aim of enactment is to compute and show the current status of each constraint, as well as to block all the activities that would cause a violation of one of the model’s mandatory constraints [193, 191]. Example 14.7.1 (Enactment of a ConDec model). Table 14.5 shows a possible enactment of an excerpt of the ConDec model shown in Fig. 3.2. At the beginning, refuse order and accept order are blocked, because they need a previous execution of close order. Then, an order is closed; the eﬀect is that • • • •

refuse order is no more blocked; accept order is blocked, because it needs a previous accept shipment; closed order is blocked, due to the 0..1 cardinality constraint; the branching response constraint is temporarily violated, because it waits for the execution of an order acceptance or refusal.

When the shipment is accepted, the possibility of accepting the order is enabled; at the same time, refuse shipment is blocked. Finally, the order is accepted, satisfying the pending response constraint. In this situation, the interacting entities can quit the interaction without undermining any constraint of the model: all (mandatory) constraints are satisﬁed, and the trace close order → accept shipment → accept order complies with the model. 14.7.1 Showing Temporarily Violated Constraints The enactment task presents many similarities with monitoring. Indeed, part of the enactment problem is related to compute and show the status of the constraints involved in the model. Hence, REC can be applied to cover this aspect: as time ﬂows, the partial execution trace collected so far can be passed to rec, exploiting its reasoning capabilities to highlight all the temporarily violated constraints. Indeed, nothing prevent us to apply the ConDec-REC translation discussed in Sect. 14.6.1 to mandatory constraints as well. More speciﬁcally, the enacted model can be formalized as a domaindependent theory, and combined with the ﬂuent-based formalization of ConDec; the rec veriﬁcation procedure can be then applied for monitoring a running instance. Let Tp denote the current partial execution trace of the instance; ct(Tp ) represents the current time of the instance. For each ConDec constraint identiﬁed by c and involving a sat(c) ﬂuent, if sat(c) does not hold at time ct(Tp ), then the constraint is considered as pending. 14.7.2 Blocking Non Executable Activities An activity is non executable if its execution would surely lead to encounter a violation. Obviously, the concept of non executability does not imply that a is a dead activity, but only that it is currently dead.

14.7 Enactment of ConDec Models

337

Table 14.5. Graphical result produced by the enactment of a ConDec model trace

enactment refuse shipment

refuse order 0..1

forbidden

close order forbidden

0..1

close order

accept shipment

refuse order

refuse shipment

pending

close order forbidden

0..1

accept shipment

accept order

forbidden

accept order

accept shipment

refuse order

refuse shipment

pending

forbidden

close order forbidden

accept order

accept shipment

refuse order

refuse shipment

0..1

accept order

forbidden

close order forbidden

accept order

accept shipment

rec can be exploited also to highlight (some of) the currently non executable activities: given a partial execution trace Tp , if at time ct(Tp ) some f orb(a, c) ﬂuent holds, then activity a is currently non executable. However, in the general case rec is not able to highlight the whole set of non executable activities. As in the case of run-time veriﬁcation, there could exist activities that are not explicitly forbidden, but that are implicitly non executable: their occurrence would surely bring the system, sooner or later, to violate some mandatory constraint. Hence, speculative reasoning is needed to complement rec in the detection of non executable activities. In the context of run-time veriﬁcation (Sect. 13.4), speculative reasoning was devoted to promptly evaluate whether the current partial trace is

338

14 Monitoring and Enactment with Reactive Event Calculus

noncompliant. This task has been accomplished by asking g-sciff about the possibility of completing the current partial execution trace so as to obtain a complete trace compliant with the ConDec model. Now g-sciff is used to answer to a slightly diﬀerent question: is it possible to extend the current trace by executing a at the next time, so that the instance complies with the speciﬁcation? If it is the case, then a is executable, otherwise it must be blocked. This test resembles very closely the discovery of dead activities, but now the discovery must start from the partial trace of the instance. In the general case, given • a ConDec model CM, which has been suitably preprocessed before the execution9 , • a partial trace Tp , containing the events occurred so far, the discovery of non executable activities proceeds as follows: 1. Using rec we obtain the set U expl of all the activities that are explicitly forbidden by some constraint. 2. For each activity a in ACM /U expl , . . . a) We place the hypothesis that a will be the next executed activity; this means that current trace will be extended as follows: a Tnext = Tp ∪ {H(exec(a), t) | t = ct(Tp ) + 1}

b) Check if the supposed execution of activity a will bring the system to a state which will surely lead to a conﬂict – if it is the case, then a is added to the set of implicitly non executable activities U impl . 3. All the activities which do not belong to U expl ∪ U impl are enabled at time ct(Tp ). Point (2–b) is accomplished by exploiting g-sciff under semi-open reasoning10 . This is needed because g-sciff must speculate only on the future: the evolution of the instance reached so far is completely determined by the happened events contained in the partial execution trace Tp . In particular, we check whether g-sciff has a successful derivation starting from the CLIMB a . A positive answer means that translation of CM and the execution trace Tnext a can be executed next; conversely, a negative answer attests that no possible a exists such that all the mandatory constraints of CM are extension of Tnext respected, and therefore a must be currently labeled as non executable. Example 14.7.2 (Discovery of non executable activities). Let us consider the ConDec model shown in Fig. 13.4 – p. 300, which has been already used to show the limits of sciff when performing run-time veriﬁcation. We suppose that the empty stock activity has been executed at time 1. The resulting 9

10

Using the preprocessing procedure described in Sect. 10.5, which aims at guaranteeing the termination of g-sciff when reasoning upon an arbitrary ConDec Model. Semi-open reasoning has been described in Sect. 13.2.3.

14.7 Enactment of ConDec Models select order forbidden

calculate price forbidden

prepare package forbidden

339

deliver order forbidden

empty stock

Fig. 14.13. Enactment of the ConDec model shown in Fig. 13.4, after the execution of activity empty stock

enactment state is shown in Fig. 14.13: all the other activities become (permanently) non executable. However, while the non executability of deliver order is directly established as an eﬀect of the negation response constraint, for the other activities non executability is discovered as a result of g-sciff’s speculative reasoning. For example, to check whether the select order activity is executable g-sciff veriﬁes the model against the hypothetical extended trace, containing the order selection at time 2. In other words, we check the model against the execution trace sel = {H(exec(empty stock ), 1), H(exec(select order ), 2)} Tnext

Due to the presence of empty stock, g-sciff generates a negative expectation concerning a future execution of deliver order. The hypothesized order selection, instead, triggers the chain of response constraints, ﬁnally leading to expect a deliver order activity. Such a positive expectation clashes with the negative one, undermining E-consistency. Hence, select order cannot be executed next. The non executability of the calculate price and prepare package activities is discovered in a very similar way.

14.7.3 Termination of the Execution The last task that must be accomplished to provide enactment support is checking whether, in a given state of aﬀairs, the enacted instance can be completed without violating any constraint. If the answer is positive, then the interacting entities can freely choose to quit or carry on the interaction; in the latter case, a new enactment cycle is triggered. Given the current execution trace Tp , the interacting entities have the possibility of correctly quitting if and only if Tp is a complete trace supported by CM. This can be veriﬁed by checking if Tp is supported by CM, a problem that can be solved with sciff. Indeed, remember that a trace is compliant with a ConDec model if and only if sciff has at least one successful closed derivation for CM and Tp .

340

14 Monitoring and Enactment with Reactive Event Calculus

initial state

partial trace

jREC queue manager

state

rec effects of actions

SWI Prolog

Fig. 14.14. jREC architecture

Let us for example consider the enactment shown in Table 14.5, by identifying the enacted ConDec model as CM. At the beginning of the execution, the interacting entities can quit, because no temporarily unsatisﬁed constraint is contained in the model. By reasoning at the CLIMB level, the absence of a pending constraint corresponds to the absence of pending positive expectations. The possibility to quit the execution is then attested by the fact that tCLIMB (CM)∅ ∅∅ true. In the second and third state, the interacting entities cannot quit without violating CM, because the branching response constraint binding the closed order activity with the refuse order and accept order ones is temporarily unsatisﬁed: it waits for the execution of one between the two target activities. In the last state, the execution trace T collected so far is %the sequence & close order → accept shipment → accept order. It holds that ∃ Δ S∅ TΔ true , and therefore the instance can be correctly closed at this stage.

14.8 jREC: Embedding REC Inside a JAVA-Based Tool jREC is a JAVA-based prototype which equips rec with a user interface and an event acquisition module, in the same spirit of SOCS-SI and sciff (see Sect. 13.3). It exploits the SWI Prolog-based implementation of sciff, and the JPL11 bidirectional Prolog–JAVA interface for managing the interaction between the veriﬁcation procedure and the JAVA environment. The overall architecture of the framework is depicted in Fig. 14.14. A JAVA queue is used to store the incoming event occurrences. A set of Prolog predicates are dedicated to synchronize rec with the event queue, consuming and processing events, or temporarily halting the computation when the 11

http://www.swi-prolog.org/packages/jpl/

14.8 jREC: Embedding REC Inside a JAVA-Based Tool

341

queue becomes empty. The computed MVIs are then delivered to the JAVA infrastructure, which graphically reports them back to the user. All the ﬁgures used in this chapter for showing the results computed by rec (namely Figs. 14.4, 14.5, 14.8, 14.9 and 14.11) have been produced using the graphical front-end of jREC.

15 Declarative Process Mining

When Event-Based Systems (EBSs) are executed inside a company, it is usually the case that all relevant event occurrences are collected and stored inside an information system. All the modern Business Process Management (BPM) systems used in the industry provide logging facilities. The importance of logging the performed operations is twofold. On the one hand, audit legislation (such as the Sarbanes-Oxley Act) needs complete information about past execution traces (also called audit trails), to determine whether the boundaries imposed by external regulations and norms are respected [250]; violation of rules enforced by law indicates malpractices or frauds. On the other hand, the extraction of information from event logs is of utmost importance also for the company itself. Indeed, while the designed speciﬁcations are strongly inﬂuenced by the perceptions of the modeler, event logs reﬂect reality, and can help business analysts and managers in the formation of an objective view of their organization. The extraction of information from event logs is called process mining 1 . Process mining can be considered as a special case of data mining, where the emphasis is on data characterizing the dynamics of EBSs. Diﬀerently from run-time veriﬁcation and monitoring, process mining techniques are applied a-posteriori, starting from complete traces that refer to past instances. During the last years, process mining has started to drawn the attention of industry [247]. Companies are interested in the application of process mining techniques on their own logs to point out ineﬃciencies, risky points, bottlenecks and sources of noncompliance. This information is then used to drive the revision and improvement of Business Processes (BPs), covering the diagnosis phase of the BP life cycle, shown in Fig. 2.1 – p. 21. Furthermore, process mining is a viable solution, because it is minimally intrusive. It simply requires to extract the event logs from the company’s information system, without any impact on its IT infrastructure. 1

http://www.processmining.org

M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 343–365, 2010. c Springer-Verlag Berlin Heidelberg 2010

344

15 Declarative Process Mining system refers to

(un)desired properties

models

records

interaction model

Conformance checking

Log-based

Discovery

verification

event log

Fig. 15.1. Some process mining techniques (from [251])

Fig. 15.1 depicts three relevant process mining techniques [251]2 : Log-based veriﬁcation checks whether the recorded instances comply with some property or regulatory model. It is also called trace analysis Conformance checking compares traces with a pre-existing model, verifying whether the executed instances have eﬀectively followed its prescriptions; it represents the “a-posteriori” version of the (a-priori) compliance veriﬁcation task (see Sect. 12.1.2) – instead of statically analyzing an interaction model, it focuses on the real behavior of interacting entities. Discovery aims at extracting a new interaction model starting from a set of execution traces; the obtained model accounts for reality, and can be therefore compared with pre-existing designed models to assess their discrepancy (delta analysis) as well as used to drive their revision and improvement. In this chapter, we focus on declarative process mining, i.e., on techniques which rely on the declarative paradigm for extracting information from event logs. In particular, ConDec++ (Chaps. 3 and 6) and CLIMB/SCIFF (Chap. 4), together with corresponding reasoning techniques, are exploited to realize two process mining tools. Both tools have been implemented as ProM [238] plugins, and are part of its last distribution. ProM is one of the most widespread process mining frameworks. We describe the peculiar features of the two plug-ins, reporting how they have been applied in the context of some real case studies.

2

Although process mining techniques have been initially applied to BPs and workﬂows, they can be seamlessly exploited for any EBS. Following the terminology proposed in this book, in its more general sense process mining then deals with “interaction models”.

15.1 Declarative Process Mining with ProM, SCIFF Checker and DecMiner

345

CLIMB/ ConDec++ model

compliant/ noncompliant traces event log

CLIMB regulatory model CLIMB property

MXML traces SCIFF Checker

DecMiner CLIMB regulatory model ProM

Fig. 15.2. Declarative process mining tools on top of the ProM framework

15.1 Declarative Process Mining with ProM, SCIFF Checker and DecMiner Two declarative process mining tools have been implemented to realize the three tasks shown in Fig. 15.1: SCIFF Checker is a trace analysis ProM plug-in. Its purpose is to classify execution traces as compliant or noncompliant with declarative business constraints, expressed in a textual pseudo-natural syntax which resembles the CLIMB language, and is therefore able to express all the ConDec++ constraints. The tool provides diﬀerent template rules whose activity types, originators and execution times can be constrained and specialized by the user through a graphical interface. Given a business constraint and a set of execution traces, SCIFF Checker produces a pie chart where the compliant and noncompliant subsets are separated. As we have discussed in Chaps. 8 and 10, ConDec models and CLIMB speciﬁcations can be adopted to seamlessly capture open declarative interaction models, regulatory models and properties. Therefore, log-based veriﬁcation and conformance checking collapse into a single task. DecMiner is a ProM plug-in which employs Inductive Logic Programming (ILP) techniques [177] for discovering a declarative constraint-based speciﬁcation starting from a set of execution traces. Before running the ILP algorithm, the traces must be labeled as compliant or noncompliant; the obtained model will be able to discriminate between the two sets. In its basic form, the algorithm is able to discover a general SCIFF speciﬁcation; however, it can be tuned to learn only the subset of SCIFF that corresponds to the formalization of ConDec++ constraints. Fig. 15.2 illustrates how SCIFF Checker and DecMiner concretely ground the general process mining schema shown in Fig. 15.1. ProM provides the glue environment, managing the load and ﬁltering of event logs, and taking care of visualizing the outcome of the mining tools.

346

15 Declarative Process Mining

ProM is an open source framework3 for process mining. Users can extend the ProM capabilities by developing and deploying plug-ins. Each plug-in focuses on the business logic, delegating to ProM the management of input and output data. Thanks to such a ﬂexible and open architecture, dozens of researchers have developed plug-ins for ProM [238]; at the time being, the framework is equipped with more than 200 plug-ins, and it is in continuous evolution. Beside a plethora of mining techniques, it oﬀers a wide range of model transformation and analysis plug-ins (e.g., veriﬁcation of soundness, deadlock detection, invariants, reductions, etc.). A prominent advantage of ProM is the management of event logs, which are represented using the universal MXML [253] format. MXML is an extensible XML-based meta model thought for standardizing the way event logs are represented. It aims at overcoming the heterogeneity of event storage formats owned by each vendor and solution. A third party must only provide a conversion mechanism able to parse internal event logs and produce a corresponding MXML representation. The peculiar features of MXML have been discussed in Sect. 6.2.2 of this book. The ProM import framework4 is speciﬁcally thought to assist third parties in such a conversion process; it provides more than 20 predeﬁned import ﬁlters, and it can be easily extended with new, custom ﬁlters. When a suitable ﬁlter is implemented, an organization can be seamlessly take advantage from all the functionalities oﬀered by ProM.

15.2 The SCIFF Checker ProM Plug-in SCIFF Checker [63] is a trace analysis ProM plug-in which targets the compliance checking of execution traces with reactive business constraints. Adherence to business constraints is not only needed due to external regulations and audit legislation. Indeed, the ﬂexibility of interaction models, strongly advocated (also) in this book, demands for run-time and a-posteriori veriﬁcations. In particular, among the several kinds of ﬂexibility (see Sect. 2.1.4), ﬂexibility by change and by deviation [194, 199] support the possibility of changing the current instance or deviating from the prescribed model during the execution. This makes a-priori compliance veriﬁcation vain. As claimed in [237] “deviations from the ‘normal process’ may be desiderable but may also point to ineﬃciencies or even fraud”. Therefore, ﬂexibility may cause the organization to miss its strategic goals or even to violate regulations and governance directives. Furthermore, trace analysis is useful when a huge number of complex execution traces must be analyzed. In this respect, it can be applied for verifying whether trends expected by domain experts have been exhibited by the 3 4

It is released under the Common Public License, and can be downloaded from http://www.processmining.org. http://promimport.sourceforge.net

15.2 The SCIFF Checker ProM Plug-in

347

recorded behavior. Such trends are an eﬀective and compact piece of knowledge that can drive the improvement and re-engineering of the current models and solutions. 15.2.1 CLIMB Textual Business Constraints To specify business constraints, SCIFF Checker provides a textual notation, which relies on a pseudo-natural language syntax. The syntax has the same expressiveness of CLIMB, and can therefore accommodate all the ConDec++ constraints. Using this notation, rules can be easily understood and customized by non-IT savvy. The structure of rules resembles ECA (Event Condition Action) rules [196], but since they are used for checking, they place expectations on activities rather than enforcing their execution. An excerpt of the rules’ grammar is reported here: Rule ::=[“IF” Body “THEN”] Head Body ::=Activity Exec [“AND” Activity Exec] [“AND” Constraints] Activity Exec ::=S Activity | R Activity S Activity ::=“activity” A ID “is performed” [“by” O ID] [“at time” O T ] R Activity ::=“activity” A ID“is performed” N “times” [“by” O ID][“between time” O T “and time” O T ] Head ::=Head Disjunct [“OR” Head Disjunct] Head Disjunct ::=Activity Exp [“AND” Activity Exp] [“AND” Constraints] Activity Exp ::=S Activity Exp|R Activity Exp S Activity Exp ::=“activity” A ID “should” [“not”] “be performed” [“by” O ID] [“at time” O T ] R Activity Exp ::=“activity” A ID“should be performed” N “times” [“by” O ID] [“between time” O T “and time” O T ] As in CLIMB, rules follow an “IF Body having BodyConditions THEN Head” structure, where Body is a conjunction of occurred events, with zero or more associated conditions BodyConditions, and Head is a disjunction of positive and negative expectations (or false). Each head element can be subject to conditions and restrictions as well. The concept of event is tailored to the one of audit trail entry in the MXML meta model. Each event is atomic and it is mainly characterized by: • the name of the activity it is associated to;

348

15 Declarative Process Mining

• an event type, which captures, according to the MXML transactional model, a transition inside the activity life cycle, such as “start”, “reassignment”, “completion”; • an originator , identifying the worker who generated the event; • an execution time, representing the time at which the event was generated. As far as now, other data are not taken into account, but they can be seamlessly introduced as well. The main distinctive feature of such rules is that all the listed parameters are treated, by default, as variables. To specify that an event has triggered a transition inside the life cycle of an unknown activity A, the body of the rule should simply contain a string like: activity A is performed by OA at time TA , where A stands for the activity’s name, OA and TA respectively represent the involved originator and execution time, and performed is a reserved keyword denoting any event type. To facilitate readability, the parts mentioning the originator and the execution time can be omitted when the corresponding variables are not involved in any condition. Positive (negative) expectations have a similar representation: the “is” part is substituted with “should (not) be”. The aforementioned generic sentence will match with any kind of event, because all involved variables (A, OA and TA ) are completely unconstrained, and the event type is unspeciﬁed. The sentence can then be conﬁgured to describe a more speciﬁc class of events. In particular, variables can be: • grounded to speciﬁc values; • constrained by means of explicit conditions. The event type can be instead speciﬁed by substituting the generic performed keyword with a speciﬁc type, chosen among the possibilities foreseen by the MXML transactional model. 15.2.2 A Methodology for Building Rules To clarify our methodology, let us consider a complete instantiation of the four eyes principle. It expresses that if a person executes a check activity, then the same person cannot execute the publish activity: IF activity A is perf ormed by OA having A equal to check THEN activity B should NOT be perf ormed by OB

(4eyes-Think3)

having B equal to publish and OB equal to OA . By looking at the rule, we can easily recognize two diﬀerent concerns: on the one hand, it contains generic elements (free variables and constraints), whereas on the other hand it refers to concrete activities. The former aspect captures re-usable patterns – in this case, the fact that the same person cannot perform

15.2 The SCIFF Checker ProM Plug-in

Templates Development

Execution Traces

349

Configuration Custom Rule

Rule Templates Compliance Checking

Fig. 15.3. A methodology for building, conﬁguring and applying business constraints

two diﬀerent activities A and B, which is a generic form of four eyes principle. The latter aspect instantiates the rules in a speciﬁc setting, grounding A and B to domain-dependent activity names. We foresee a three step methodology to build, conﬁgure and apply business constraints, reﬂecting the separation between these two aspects: 1. Re-usable rules, called rule templates, are developed and organized in a hierarchy by a technical expert (i.e., someone having a deep knowledge of the syntax and semantics of the language). As already pointed out, the notation of textual rules is based on the CLIMB language, and it is therefore more expressive than ConDec++ . For example, the following re-usable template models a synchronized response business constraint, which corresponds to a response triggered by the occurrence of two events: IF activity A is perf ormed at time TA and activity B is perf ormed at time TB THEN activity C should be perf ormed at time TC having TC af ter TA and TC af ter TB . 2. Rule templates are conﬁgured, constrained and customized by a business manager to deal with a speciﬁc domain. In particular, conditions are employed to restrict or ground the variables of the template. 3. The trace analysis task is carried out, checking whether the collected execution traces comply with the instantiated rules. The methodology is sketched in Fig. 15.3. 15.2.3 Speciﬁcation of Conditions Conditions are exploited to constrain the variables of event occurrences and expectations, namely activity names, originators and execution times. As shown in Fig. 15.4, two main families of conditions are currently supported: string and time conditions. String conditions are used to constrain an activity/originator, stating that it is equal to or diﬀerent from another activity/originator, either variable or constant. An example of a string condition,

350

15 Declarative Process Mining

Variable String Variable StringOP EQUAL TO DIFFERENT THAN

activity name originator

String Condition Variable Condition

execution time

Event eventType

Time Variable Time Condition

Constant Condition

Absolute Condition

String

DateTime

Constant

TimeOP AT NOT AT AFTER AFTER OR AT BEFORE BEFORE OR AT

Relative Condition 0..1 Displacement

DisplOP + -

Duration

Fig. 15.4. Basic hierarchy of string and time constraints

constraining two originator variables, is the “OB equal to OA ” part in rule (4eyes-Think3). Time conditions are instead applied to execution times, specifying ordering among events or metric relationships, such as deadlines and delays. The semantics of a time condition is determined by its time operator, which expresses one among the qualitative relationships between time points, such as before (<), at (=), after or equal (≥). Absolute time conditions express unanchored constraints, relating a time variable to a speciﬁc date-time, whereas relative time conditions anchor two time variables. Metric constraints can be introduced by attaching a displacement between the involved time variables. For example, to specify that the time variable TB must respect a deadline of 2 days after TA , we write TB BEFORE TA + 2 days. 15.2.4 Trace Analysis with Logic Programming The trace analysis phase aims at verifying whether a set of MXML execution traces comply with some rule. It can be then tackled by the sciff proof procedure (Sect. 9.1). In this case, the veriﬁcation procedure is as follows. For each MXML execution trace MT belonging to the log under study: 1. translate MT into a CLIMB execution trace T , mapping each MXML audit trail entry onto a corresponding CLIMB happened event; 2. express the textual rule in the CLIMB syntax, obtaining an integrity constraint BR; 3. embed BR into a CLIMB speciﬁcation S BR = ∅, {BR} ; 4. if sciff has a (closed) successful derivation for the instance STBR , i.e. S BR ∅ TΔ true then the execution trace is compliant with the rule.

15.2 The SCIFF Checker ProM Plug-in

351

The reactive features of sciff (which have been a matter of discussion in Chap. 13) are in this setting not exploited, because the analysis is carried out a-posteriori. An interesting question hence is: it is possible to substitute sciff with a backward resolution algorithm (such as Prolog)? The answer is yes, provided that we restrict ourselves to the CLIMB fragment of SCIFF. The idea is sketched below. An execution trace can be represented in Prolog as a knowledge base storing each audit trail entry as a fact of the type h(exec(EventType, ActivityName, Originator ), ExecutionT ime). The business constraint at hand is instead translated into a Prolog query by computing the negation of the implication. So, if the CLIMB rule is represented by the implication B → H, then the query would be B ∧ ¬H. Furthermore, positive expectations are ﬂattened into a corresponding happened event, and negative expectations to the absence (negation) of the corresponding happened event; in other words, the SCIFF notion of fulﬁllment is embedded into the translation procedure. The obtained query tries to ﬁnd a set of occurred events in the trace, so that the rule’s body is satisﬁed but the head is violated. If it succeeds, then a counterexample has been found inside the execution trace, attesting that the trace is not compliant with the original business constraint. For example, rule (4eyes-Think3) is translated into the following query: ?−A = ‘Check’, h(exec(EB , A, OA ), TA ),

not B = ‘Publish’, OB = OA , not h(exec(EB , B , OB ), TB ) .

15.2.5 Embedding SCIFF Checker in ProM Drawing inspiration from the LTL-Checker ProM plug-in [237], we have implemented SCIFF Checker as a ProM analysis plug-in. The implementation supports the three-steps methodology described in Section 15.2.2, providing a graphical user interface for guiding the user in the customization of rule templates. At start-up, templates are loaded from an XML-based template ﬁle. As far as now, all the templates covering the ConDec language are supported. In order to extend or modify the template hierarchy, the technical expert must simply change this conﬁguration ﬁle. As shown in Fig. 15.5, templates are displayed using a tree-like component; clicking on a template description causes its corresponding textual representation to become visible in the center panel. When the conﬁguration button is pressed, all the involved variables become visible (see Fig. 15.6). Each customizable element is then highlighted and can be conﬁgured by the

352

15 Declarative Process Mining

Fig. 15.5. A screenshot of the main SCIFF Checker window

Fig. 15.6. Visualization of a conﬁgurable business constraint

user. When selecting an highlighted element, a speciﬁc customization panel appears, supporting the user in setting the parameters (such as event types and repetitions) and specifying conditions. When the instantiation of the rule has been completed, it can be either saved to the group of user-deﬁned rules, or directly used for compliance checking. Before running the veriﬁcation procedure, the user must choose a time granularity, which ranges from milliseconds to months and is used to properly convert MXML date-times into integer values. In particular, for each execution trace contained in the target MXML log, three steps are performed transparently to the user:

15.3 Case Studies

353

Fig. 15.7. Compliance chart produced by SCIFF Checker as a result of the trace analysis

1. The execution trace is translated into a Prolog knowledge base, converting the involved time values as speciﬁed by the chosen granularity. 2. The textual business constraint is mapped onto a Prolog query, following the proof of concept shown in Sect. 15.2.4; if the rule contains quantitative temporal constraints, then the involved date-time values are converted to integers as well, using the chosen time granularity. 3. A tuProlog 5 [90] engine is exploited to verify whether the execution trace complies with the speciﬁed rule; tuProlog is a JAVA-based implementation of Prolog, and thus it eliminates the issue of interconnecting a JAVA program with an external Prolog interpreter. The outcome of the veriﬁcation procedure is collected and ﬁnally reported to the user as a pie chart, showing the number of compliant and noncompliant execution traces (see Fig. 15.7). The explicit list of the traces belonging to each subset is visualized as well. The user can then start a new classiﬁcation by considering the whole log or only the portion with (non)compliant execution traces. In this way, a conjunction of business constraints can be veriﬁed by executing a series of tests, each one dealing with a single rule, veriﬁed against the compliant subset as ﬁltered by the previous veriﬁcation. The ﬁnal result will contain the set of execution traces compliant with all the checked rules.

15.3 Case Studies We describe the application of SCIFF Checker to three real case studies. The ﬁrst case study focuses on the veriﬁcation of business rules against execution R traces generated by companies customers of Think36 , a corporation working in the Computer Aided Design (CAD) and Product Life-cycle Management 5 6

http://tuprolog.alice.unibo.it/ http://www.think3.com

354

15 Declarative Process Mining

(PLM) market. In the second case study, we have checked the conformance of health-care professionals when executing a screening process applied in the Emilia Romagna region of Italy. The last case study deals with an intelligent framework for the automatic monitoring, management and quality assessment of wastewater treatment plants; SCIFF Checker is used in this context to detect the presence of relevant high-level events in the plant, starting from signal-level events. 15.3.1 The Think3 Case Study An important challenge in the manufacturing industry is to handle, verify and distribute the technical information produced during the design, development and production phases of the company. The adoption of a system supporting the management of technical data and the coordination of the people involved in each project is of utmost importance, to improve productivity and competitiveness. The main issue is to provide solutions for managing the technical pieces of information and documentation (such as CAD projects, test results, photos, revisions), which are mainly produced by workers during the design phase. Since an important part of the design process is spent by testing, modifying and improving previously released versions, the traceability of relevant information concerning all the produced documents, projects and reports is necessary. Think3 is one of the leading global players in the ﬁeld of CAD and PLM solutions. It provides an integrated software which bridges the gap between CAD modeling environments and other tools involved in the design and manufacturing process. All these tools are transparently combined with a non-intrusive information system. This system manages the underlying production workﬂow, recording all the relevant informations and making them easily accessible to the involved workers, who can consult, use and revise them. The history of each design schema/product is tracked, providing a complete log of all the executed activities. Think3 Workﬂow Fig. 15.8 shows a reset workﬂow net [44, 75, 240] modeling the Think3 workﬂow, targeting the design of a manufacturing product. It speciﬁes how activities aﬀect the progress-status of a project, supporting its modiﬁcation and even the evolution of multiple co-existing versions. It is a general workﬂow, which is then adapted to each single Think3 customer, in order to meet its speciﬁc requirements. The process starts with the creation of a new project, which is associated to a unique identiﬁer. The project becomes now in progress: diﬀerent designers work cooperatively on it by developing CAD drawings, manuals and other documentation. In this phase, a vaulting system is exploited to handle concurrent accesses and modiﬁcations [230]: read accesses can be performed

15.3 Case Studies

New Version

355

Under Modify

Reject

Publish Work In Progress

Check

Create Rectify

Commit

Release

Release

Modify

Cancel Current

Fig. 15.8. A reset workﬂow net modeling the Think3 workﬂow

concurrently, whereas modiﬁcations are mutually exclusive. When a complete draft of the project has been designed, it is published and becomes ready to be checked by a technical reviewer. In the meanwhile, if it is recognized that the project is incomplete, it can be brought back to the previous state by executing the rectify activity. After the check, a decision is taken: if all the performed tests are successfully passed, the project is released, otherwise it is rejected, and comes back to the work in progress state. The release activity attests that a candidate ﬁnal version of the project actually exists. At this point, there are three possibilities. 1. Technical experts decide7 to save the current project and to generate a new version, triggering another design-and-test iteration; if this is the case, two diﬀerent versions start to coexist: the old version is put in an under modify state, whereas the new one is put in progress. 2. If at least one previous version of the project exists, it is possible to cancel the current one; as a consequence, one of the previous versions is retrieved from the under modify state. 3. The project is committed, i.e., presented to the manufacturing phase; all the previous versions of the project are consequently removed from the under modify state, and stored inside the information system for traceability reasons.

Think3 Requirements Think3 is investigating the development of a Business Intelligence dashboard, to provide a constantly updated feedback about the global trends of the 7

E.g., because some speciﬁc aspects of the project require further investigation.

356

15 Declarative Process Mining

manufacturing projects. As part of the italian TOCAI.IT FIRB Project8 , Think3 and the University of Bologna are collaborating to realize one of the dashboard components: a tool supporting compliance checking of projects’ development traces with conﬁgurable business constraints. This will facilitate a business manager in the identiﬁcation of behavioral trends and of noncompliance with regulations and internal policies. During a joint case study, we elicited the following non exaustive list of interesting properties: (Br1) Investigation of the time span separating the execution of two activities (e.g., was each project committed by 18 days after its creation? ). (Br2) Identiﬁcation of projects which went too many times through a certain activity (e.g., which projects have been modiﬁed at least twice? ). (Br3) Behavioral analyses of the workers involved in the process (e.g., was each project checked by a person diﬀerent than the one who published it? ). All these kinds of property can be easily speciﬁed using the CLIMB-inspired textual notation of SCIFF Checker. For example, rule (Br3) has been already modeled by (4eyes-Think3) – p. 348. Rule (Br1) can be instead modeled by conﬁguring the general response pattern IF activity A is performed at time TA THEN activity B should be performed at time TB and TB after TA . grounding the involved activities and introducing a before relative time constraint between TB and TA , with a displacement of 18 days. The result is: IF activity A is performed at time TA having A equal to Creation THEN activity B should be performed at time TB having B equal to Commit and TB after TA and TB before TA + 18 days. Applying SCIFF Checker to the Think3 Case Study SCIFF Checker has been concretely applied to analyze the execution traces of a Think3 customer. As a ﬁrst step, we have used ProM import to extract the relevant informations from the customer’s database, converting them into an MXML log. In particular, we extracted an event log composed by 9000 execution traces, ranging from 4 to 15 events. Then, together with a Think3 business manager, we used the plug-in to express and test the aforementioned business constraints. The average veriﬁcation time was around 10-12 seconds for the whole log. The computed results 8

http://www.dis.uniroma1.it/~ tocai/

15.3 Case Studies

357

have been ﬁnally analyzed with the business manager. For example, from the compliance veriﬁcation of rules (Br2) and (Br3), we discovered that only the 2% of traces involved more than two project revisions, and that in the 3,5% of total the project has been published and checked by the same person. The veriﬁcation of rule (Br1) was found interesting especially by changing the deadline of 18 days. In fact, both the executions taking too much and too short time to commit the project should be identiﬁed (and avoided). They respectively represent ineﬃciencies and potential inaccuracies. 15.3.2 Conformance Veriﬁcation of a Cervical Cancer Screening Process The Emilia Romagna Region of Italy proposes several screening programs for the early detection and treatment of cancer9 . In particular, we have collaborated with the sanitary organization of the Emilia Romagna region – Bologna unit – for evaluating the conformance of health-care professionals when applying the cervical cancer screening process. Cervical cancer is a disease in which malignant (cancer) cells grow in the tissues of the cervix. The screening program proposes several tests in order to early detect and treat cervical cancer, and it is usually organized in six phases: Screening Planning, Invitation Management, First Level Test (PAPtest), Second Level Test (Colposcopy), Third Level Test (Biopsy), and Therapeutic Treatment. Every participant is asked to repeat the screening process periodically (a round being thus three years long). The cervical cancer screening process applied by the Emilia Romagna region involves more than 50 activities performed by 15 diﬀerent healthcare structures. The activities range from administrative procedures (such as the emission of a letter containing the PAP-test result) to clinical and therapeutic actions (such as the analysis of a biological sample made by an anatomopathology laboratory). The process is applied to a huge amount of women at the same time. At december 31, 2009, the total number of the female population between 25 and 63 years was 1.226.395. The 93,5% of the total has been invited to undergo the PAP-test, and the 57% adhered to the screening program. The provision of suitable techniques for automatically comparing the actual execution of the screening process with the recommendations of the Emilia Romagna’s sanitary organization is important in many aspects. First of all, they could help in assessing whether the healthcare professionals conform to the recommendations, obtaining a feedback about how much the ideal process ﬁts with the actual one. Furthermore, they could be used to evaluate the quality of the real process, as well as the amount of undertaken resources. In this respect, the discovered noncompliant situations could be exploited: 9

http://www.saluter.it/screening_femminili/

358

15 Declarative Process Mining

• to individuate which concrete stakeholders are responsible, and take proper countermeasures (such as provide more resources to one laboratory); • to revise the screening process, so as to better account for the speciﬁc peculiarities of the local healthcare structures. In order to make SCIFF applicable in this context, we formalized a fragment of the screening process, starting from the recommendations provided by the sanitary organization of Emilia Romagna. The resulting careﬂow protocol is described in [59, 61]. It consists of a set of CLIMB/SCIFF-lite business constraints, constraining the behavior of administrative personnel, health-care professionals and patients. Rules cover many diﬀerent aspects, ranging from normative aspects (e.g., a letter must be sent to the patient after the PAP-test has taken place) to quality aspects (e.g., it is desirable that a PAP-test takes place no later than 15 days after the scheduled date). We then extracted 1950 traces from the sanitary information system. Each trace represents the application of a screening round to a single woman, and contains from 1 to 18 event occurrences. In order to fully test our veriﬁcation techniques, some wrong behaviors were artiﬁcially introduced. A ﬁrst run was performed, abstracting away from quality aspects, i.e., considering only the regulatory part of the screening process. 1091 executions resulted to be noncompliant. This result was analyzed by a domain expert, who realized that most of the 1091 traces were classiﬁed as noncompliant because of an apparent misbehavior of the patient during the initial phase of the process. In particular, at the beginning of the process an invitation is sent to the patient, expecting an acceptance or refusal from her. However, in several cases (around the 43% of the toal), the patient does not answer at all. The domain expert pointed out that this situation should be accommodated by the screening process, because the behavior of the patient is outside of the control of the sanitary organization. The business constraints have been therefore revised so as to foresee also this possibility. The number of noncompliant execution consequently fell to 44, in agreement with the artiﬁcially introduced misbehaviors. Finally, quality aspects were incorporated into the regulatory model. One of the quality assessment rules stated that each PAP-test should take place no more than 15 days after the scheduled date. We analyzed the whole log again, discovering that 200 executions did not met the desired deadline. The delays were checked by the domain expert; they can be ascribed to the fact that the screening center allocates a ﬁxed number of slots in advance: as a consequence, free slots for new bookings are sometimes not immediately available. 15.3.3 Quality Assessment in Large Wastewater Treatment Plans Large wastewater treatment plants are usually equipped with Software Control And Data Acquisition (SCADA) as well as Programmable Logic Controller (PLC) systems, but the vast amount of data acquired from the sensors

15.3 Case Studies

Plant

Samples (e.g., pH)

Signal-Level Events

Process-Level Event

359

Process Validation &Control

Fig. 15.9. Architecture of an intelligent monitoring and quality assessment framework for wastewater treatment plants [155]

is seldom used in real-time plant management. An intelligent control software could exploit these informations, acting as a “virtual operator” and providing continuous monitoring facilities. First, it could try to optimize the yield and detect faults at an early stage, possibly even correcting them. Second, the collected time series, properly validated and classiﬁed, could be stored inside a knowledge base describing the various operating conditions of a given plant. This knowledge could be in turn exploited to further improve the overall performance of the plant. Fig. 15.9 shows the overall architecture of the intelligent monitoring and quality assessment framework for wastewater treatment plants, which is currently under development by the University of Bologna and ENEA10 , as part of a collaboration with Hera, one of the leading italian groups in Waste, Gas and Electricity Business [225]. In the ﬁrst stage, a multi-parameter converter continuously measures physical signals (such as pH values) during the whole treatment process. The samples are acquired and stored inside a MySQL database for both immediate and later access. A neural network is then exploited to analyze each obtained signal, to the aim of extracting “signal-level’ events, such as the presence of an apex, step or knee in the signal. Such signal-level events are grouped inside an MXML execution trace, one for each plant cycle. In particular, the following correspondences have been established: • each MXML audit trail entry corresponds to the occurrence of low-level event associated to the signal, i.e., step{+/−} , apex{+/−} , knee{+/−} ; • the physical signal represents the originator of a signal-level event occurrence; • the date-time associated to an entry represents the timestamp at which the event occurrence has been recognized by the neural network. The whole MXML log is constituted by the set of recorded plant cycles. Starting from this log, SCIFF Checker is employed to identify the presence or absence of “process-level” events. Process-level events are high-level events, used to characterize the occurrence of some global situation inside the plant, such as the start or the completion of a reaction. A process-level event occurs when one or more of the monitored signals present certain trends at the same time. 10

Italian National Agency for New Technologies, Energy and Sustainable Economic Development

360

15 Declarative Process Mining

In particular, from the combination of the trends of three signals, namely pH, ORP (redox potential) and DO (dissolved oxygen concentration), three relevant process-level events may arise: • completion of a denitriﬁcation (pH apex+ and ORP knee− ); • completion of a nitriﬁcation (pH apex− and ORP knee+ and DO step+ ); • aerobic switch (pH knee− and ORP apex− and DO step+ ). The presence of a process-level event can be then easily expresses by means of a SCIFF Checker textual business constraint. For example, the completion of a denitriﬁcation corresponds to: IF activity A is started by Oa having A equal to cycle THEN activity B should be performed by Ob at time Tb and activity C should be performed by Oc at time Tc having B equal to apex+ and Ob equal to pH and C equal to knee− and Oc equal to ORP and Tb after Ta and Tb before Ta + 90 min and Tc after Ta and Tc before Ta + 90 min and Tc after Tb − 15 min and Tc before Tb + 15 min. The rule states that a maximum in pH and a knee in ORP must be detected almost contemporarily. The 30 minutes window has been introduced to deal with noise due to the measures themselves and the interpolation error. Furthermore, the completion of a denitriﬁcation eﬀectively occurs if the two signal-level conditions are met during the ﬁrst phase of the cycle, i.e., within 90 minutes after the beginning of the cycle. In order to assess the performance of the plant, each cycle is submitted to a sequence of rules. In particular, the application of a rule partitions the set of cycles into two subsets, the “correct” ones and the “wrong” ones. Each subset is further processed by applying the other rules in cascade. Therefore, starting from the denitriﬁcation, nitriﬁcation and aerobic switch rules, diﬀerent combinations can be exploited to deﬁne a global acceptance policy for the cycle. Even if a cycle is discarded, it is not necessarily a failed one: the occurrence of a false negative is a likely event since, in addition to errors of the neural network algorithm itself, probes tend to yield very noisy measurements (especially if not cleaned daily) which may not satisfy the required conditions. In order to overcome this problem, it is possible to deﬁne less constraining rules by removing or changing some of the conditions. This can be simply done through the user interface of SCIFF Checker.

15.4 The DecMiner ProM Plug-in

361

15.4 The DecMiner ProM Plug-in Process discovery deals with the extraction of a model starting from the real execution traces of an EBS. The extracted model is of utmost importance, because it accounts for the real behavior exhibited by the interacting entities. Traditional process discovery approaches derive procedural BP models, such as Petri Nets or Event-driven Process Chains [245]. However, it would be desirable to discover declarative, open models as well. In particular, discovering a set of declarative business constraints would be useful to obtain a concise and comprehensible representation of what is going on, abstracting away from implementation details. DecMiner is one of the few eﬀective tools which tackle declarative process discovery. It relies on ILP techniques and, given a set of execution traces, previously labeled as compliant or not with respect to some classiﬁcation criterion, is able to produce a SCIFF speciﬁcation which accounts for such a classiﬁcation. 15.4.1 Inductive Logic Programming for Declarative Process Discovery Roughly speaking, ILP [177] stands at the intersection of Machine Learning and Logic Programming. In particular, given a background knowledge, together with a set of positive and negative examples, the purpose of an ILP algorithm is to devise a (general) Logic Program which entails all the positive examples and none of the negative ones. The idea of exploiting ILP for declarative process discovery comes form the similarities between learning a SCIFF theory, composed by a set of integrity constraints, and learning a clausal theory as described in the learning from interpretation setting of ILP [178]. In particular: • both SCIFF and a general clausal theory can be used to classify a set of atoms (i.e., an interpretation) as positive or negative – in the case of SCIFF, examples represent compliant and noncompliant execution traces; • there is a strong similarity concerning the structure of the logical formulae composing the theory [150]. Starting from these similarities, Lamma et al. have extended the Inductive Constraint Logic (ICL) algorithm [178]. The new algorithm, called Declarative Process Model Learner (DPML), is able to learn a SCIFF speciﬁcation starting from a set of execution traces, previously labeled as compliant or not. Inductive algorithms rely on a clausal language L, which deﬁnes the structure of the theories that can be derived by the algorithm. The clausal language is usually described in an intensional way using a speciﬁc representation language. The description of L in this language is called language bias (LB for short). In the SCIFF setting, LB represents the structure of the learnable SCIFF integrity constraints.

362

15 Declarative Process Mining

As already pointed out, before applying DPML a classiﬁcation of the traces is needed, to the aim of partitioning them into a compliant and noncompliant subset (corresponding to positive and negative examples). The target of DPML is then to learn a SCIFF speciﬁcation S which “replays” the classiﬁcation given as input, namely: • for each execution trace T + initially classiﬁed as compliant, it holds that compliant (ST + ); • for each execution trace T − initially classiﬁed as noncompliant, it holds that ¬compliant (ST − ). To accomplish this task, DPML performs a covering loop in which noncompliant execution traces are progressively ruled out. At each step, DPML looks for the most general integrity constraint that correctly classiﬁes as many as possible compliant execution traces and, at the same time, rules out as many as possible non-compliant execution traces. DPML is able to learn integrity constraints speciﬁed using the CLIMB language. However, for the sake of readability, it would be desirable to ﬁnally obtain a ConDec++ speciﬁcation, giving a graphical feedback to the user while hiding the textual representation of CLIMB rules. To this purpose, Chesani et al. have restricted the syntax of the learnable integrity constraints, tuning LB so as to reﬂect exactly the forms of integrity constraints that are obtained by applying the ConDec to CLIMB translation11 [62, 149]. When a CLIMB speciﬁcation is derived by DPML, each learned integrity constraint is subject to an inverse translation, obtaining the corresponding ConDec++ graphical representation. 15.4.2 Embedding DecMiner into the ProM Framework The DPML algorithm has been embedded into a ProM plug-in which supports the user in all the process discovery phases, from data preparation to visualization of the learned ConDec model12 [62]. In particular, the tuned LB is automatically generated from a set of general templates, one for each ConDec constraint, that can be instantiated to generate speciﬁc assertions for the language bias. The number of all possible assertions is huge, while the user could be interested in targeting only a small, yet meaningful fragment of the ConDec language. For this reason, we let the user free to select a subset of the activities contained in the execution traces, and a subset of the ConDec constraints. DPML will use only the instantiation of these constraints with the selected activities for learning the model. This choice has a twofold beneﬁt: on the one hand, the obtained model will ﬁt with the user requirements, 11 12

The translation of ConDec and ConDec++ constraints into CLIMB has been extensively discussed in Chaps. 5 and 6 of this book. Visualization is currently limited to the basic ConDec language, but the algorithm is seamlessly able to learn ConDec++ models.

15.4 The DecMiner ProM Plug-in

363

Fig. 15.10. Trace classiﬁcation in DecMiner

whereas on the other hand restricting the language bias has a positive impact on the DPML’s performance. The accuracy and learning time are strongly related to the choice of these subsets. They inﬂuence the accuracy of the learned model because a business constraint discriminating between compliant and noncompliant execution traces cannot be learned if the appropriate template and the right activities are not chosen. The time complexity is linear in the number of traces and in the number of constraints. With respect to the number of activities, it is linear when only unary constraints are chosen, quadratic if also binary constraints can be learned. DecMiner implements all the data preparation and learning phases of the discovery process described above, guiding the user through ﬁve distinct steps. These steps are: Classiﬁcation. All the imported execution traces are classiﬁed as compliant and noncompliant, either using the graphical user interface of DecMiner (as shown in Fig. 15.10), or exploiting SCIFF Checker as a preprocessing procedure (see Sect. 15.5). Activities. The user can select, among the activities and their parameters, which information must be taken into account by the learning algorithm. Templates. The user interface, shown in Fig. 15.11, supports the user in the selection of the candidate constraint templates, to be used during the learning phase. Mining. When the start mining button is pressed, the language bias is generated, combining the choices made by the user during the previous two steps; DPML is then launched.

364

15 Declarative Process Mining

Fig. 15.11. ConDec template selection in DecMiner

Fig. 15.12. A learned ConDec model shown by DecMiner

Results. The learned CLIMB rules, together with the corresponding ConDec representation, are ﬁnally presented to the user (see Fig. 15.12).

15.5 The Checking–Discovery Cycle SCIFF Checker and DecMiner could take beneﬁt from each other, realizing the checking–discovery cycle shown in Fig. 15.13.

15.5 The Checking–Discovery Cycle

365

Translation

CLIMB specification

ConDec model

Compliant instances

SCIFF SCIFF Checker Checker Execution traces

DecMiner Noncompliant instances

Fig. 15.13. Integration of SCIFF Checker and DecMiner towards a checkingdiscovery cycle

The use of SCIFF Checker as a preprocessing step for DecMiner is helpful to deal with the most critical phase of the declarative discovery process, which is the labeling of each execution trace as compliant or not. Quite often, the execution traces taken as input do not contain any explicit hint about being positive or negative. Furthermore, it is not reasonable to assume that the annotation will be manually done by the human user, mainly due to the huge number of traces composing an event log. SCIFF Checker automatizes the annotation task: instead of explicitly labeling each single execution trace, the user can state a classiﬁcation criterion and exploit it to eﬀectively obtain the partition. This kind of integration has already been implemented: SCIFF Checker is able to export a log annotated with the classiﬁcation result, and annotated logs can be directly imported into DecMiner. If the language bias is opportunely tuned, the model learned by DecMiner could be noticeably diﬀerent from the adopted criterion, and hence interpreted as an explanation for the classiﬁcation. The integration between the two plug-ins could be exploited also in the opposite way. Indeed, the models discovered by DecMiner can be interpreted as regulatory speciﬁcations which account for the real behavior. They could be hence passed to SCIFF Checker, to verify whether new instances of the system conform to the discovered constraints or not.

16 Related Work and Summary

Related work concerning the enactment, run-time veriﬁcation, monitoring and mining of interaction models is presented. Then, the major contributions of this part of the book are brieﬂy summarized.

16.1 Related Work We separate the discussion of related work into three areas: • run-time veriﬁcation and monitoring; • enactment; • process mining. 16.1.1 Run-Time Veriﬁcation and Monitoring Run-time veriﬁcation and monitoring are open and challenging research topics, especially in the Service Oriented Computing setting. In [36], the authors present a broad survey of principles, techniques, and methodologies proposed in the literature for the monitoring and adaptation of (web) services. In particular, they classify the state of the art approaches along two diﬀerent dimensions: purpose (why) and target (what) of the monitoring task. Concerning the purpose of monitoring, they identify six areas: • fault monitoring, checking whether the system conforms to some speciﬁcation, and identifying correct and noncompliant situations; • monitoring as a ﬁrst step towards diagnosis and recovery of faulty services; • monitoring as part of a framework addressing the optimization of resource allocation; • monitoring for triggering and driving the dynamic adaptation of services; • Business Activity Monitoring, constantly measuring and evaluating key performance indicators and business rules; M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 367–376, 2010. c Springer-Verlag Berlin Heidelberg 2010

368

16 Related Work and Summary

• monitoring as part of a framework dealing with the long-term adaptation of services, taking into account both present and historical information. For what concerns the targeted information, monitoring approaches can be roughly classiﬁed into two groups: monitors dealing with functional and behavioral properties (such as pre and post-conditions in service calls, constraints over the messages exchange, and data-related properties), and monitors targeting non-functional properties (such as performance, reliability, and response time). Finally, monitoring applications distinguish themselves by their abstraction degree: some approaches are implementation-dependent, and focus on speciﬁc architectures and languages, whereas other approaches are abstract, and rely on business-level concepts abstracting away from implementation and technological details. In [27], Baresi and Guinea present an approach towards the dynamic monitoring of BPEL-based services. In particular, the BPEL speciﬁcation of interest is annotated with WS-Col (Web Service Constraint Language) assertions, mainly focusing on QoS aspects. A code weaving preprocessing procedure is then used before the BPEL process is deployed. The preprocessing phase parses the BPEL speciﬁcation, analyzes the monitoring assertions and introduces further activities dedicated to send the relevant informations to a monitoring manager, where needed. WS-Col properties are veriﬁed against each instance of the BPEL process, and can contain expressions referring to the actual values of data. During the execution, the monitoring manager dynamically decides whether some rule must be currently checked. If so, it acts as an interceptor: when a pre-condition rule must be checked, it processes the incoming message before the target BPEL process, whereas when a postcondition rule must be veriﬁed, it intercepts the message sent by the BPEL process; after having veriﬁed the property, it takes care of forwarding the message to the right recipient. The approach has been further elaborated in [28], where a complete architecture based on Aspect Oriented Programming is presented. The resulting framework, called Dynamo, does not only provide monitoring facilities, but supports also recovery strategies. In [26], Barbon et al. propose a JAVA-based framework for monitoring service orchestrations implemented in BPEL. A monitor intercepts all the incoming and outgoing messages exchanged by the controlled BPEL orchestration, without needing to change its implementation. Thus, diﬀerently from [27], the monitoring facility and the process are kept completely separated, and their execution engines run in parallel on the same application server. Two kinds of monitors are supported: • instance-level monitor, targeting a single instance of the BPEL process; • class-level monitor, aggregating information from the running process instances. Finally, the authors introduce the Run-Time Monitor speciﬁcation Language (RTML), a past-tense LTL language which accommodates data, time

16.1 Related Work

369

constraints and aggregation functions (such as sum and average). RTML formulae can be automatically embedded into a dedicated instance or class-level monitor. The conﬁgured monitor will intercept the messages exchanged by the monitored process, reporting all the relevant informations and misbehaviors concerning the speciﬁed formula. The framework is part of the Astro project1 , a research project in which services are exploited as the enabling technology for supporting distributed business processes, both within and across the organizational boundaries. The Dynamo and Astro approaches have been recently integrated in [29]. The resulting framework supports the combination of WS-Col and RTML for specifying monitoring properties, and employes an event bus to route the occurring events collected by Dynamo to the Astro monitors. In [176], the VieDAME system is proposed towards the non-intrusive monitoring and dynamic adaptation of BPEL processes. VieDAME is composed by a set of modules which handle monitoring, service selection and message transformations facilities, and can accommodate new BPEL engines, by simply implementing an adapter interface. Such adapters are based on Aspect Oriented Programming, providing an “interception and adaptation layer” between the BPEL processes and the underlying transport layer. The monitoring component is devoted to store the service invocation events, calculating QoS values like average response time, accuracy and availability of some operation. The dynamic adaptation and mediation module takes instead care of applying dynamic service replacement policies, to guarantee that the system always behave in an acceptable manner. In particular, the module applies a set of selector algorithms, which could trigger a service replacement during the execution, for example because a QoS value is under a threshold. The selector then looks for a candidate service able to substitute the faulty one. If an interface mismatch exists between the BPEL process and the newly selected service, VieDAME accommodates transformer components, that will act as a mediation layer between the two interacting parties. The monitoring of Service Level Agreement (SLA) is instead faced in [212]. The authors ﬁrst point out the necessity of providing a ﬂexible yet unambiguous language to specify an SLA-based contract and its Service Level Objectives (SLOs). They consequently propose an XML-based language which standardizes the way SLAs are modeled. In particular, an SLA contract is associated to a time period during which the contract must be enforced, and to a set of SLOs. Each SLO, in turn, is triggered by the occurrence of an event, such as a message exchange, the completion of an operation, or at ﬁxed, predetermined times. When the SLO is triggered, it evaluates a function over a set of measurable data, such as the average response time of a service. The authors also proposed a JAVA-based architecture for managing the acquisition of data and the dynamic evaluation of SLA contracts. In order to transparently acquire the exchanged messages, the SOAP toolkit is modiﬁed, providing 1

http://www.astroproject.org

370

16 Related Work and Summary

event interception and correlation facilities. In this way, the involved services are unaware of the monitoring infrastructures, and SOAP encryption can be seamlessly supported without undermining the monitoring facilities. The REC-based monitoring facility and the state of the art approaches here presented are complementary. REC provides a logic-based formal language for specifying event-based requirements (with a particular emphasis on functional properties), and focuses on the core reasoning task, abstracting away from implementation details: it is platform and implementation agnostic, and assumes that the relevant events are collected by an unknown external component. Conversely, frameworks like Dynamo and VieDAME aim at building a complete technological solution to service monitoring, tailored to speciﬁc languages and implementations (BPEL and SOAP in particular). However, all these approaches propose ad-hoc languages, lacking in a clear semantics, and custom veriﬁcation techniques, lacking in a strong formal basis. Thanks to such a complementarity, the integration of these frameworks and REC would bring to a complete monitoring framework, ranging from the dynamic acquisition of SOAP messages to the rigorous veriﬁcation of functional properties. The violation events generated by rec could be then injected into the underlying event bus or transport layer, possibly triggering a reconﬁguration or adaptation phase. Beside REC, a number of authors have proposed the adoption of logic-based methods to deal with the run-time veriﬁcation and monitoring of Event-Based Systems, focusing in particular on the Event Calculus (EC) and temporal logics. Diﬀerently from REC, as far as we are concerned all the EC-based monitoring approaches proposed in the literature rely on ad-hoc methods, outside of logical frameworks. For example, Mahbub and Spanoudakis present a framework [158] for monitoring the compliance of a BPEL-based service composition with assumptions expressed by the user, or with behavioral properties, automatically extracted from the composition process. EC is exploited to monitor the actual behavior of interacting services and to report diﬀerent kinds of violations. The approach is further investigated in [159], where an extension of WS-Agreement [17] is used to specify requirements. The monitoring framework relies on an ad-hoc event processing algorithm, which fetches the occurring events and updates the status of the aﬀected ﬂuents. A vast literature focuses on the application of EC before or after the execution. For example, in [205] Rouached et al. propose a framework for engineering and verifying BPEL processes. EC is used to provide an underlying semantics to BPEL, enabling veriﬁcation prior to and after the execution. In particular, EC is exploited to verify the consistency and safety of a service composition (i.e., to statically ensure that the speciﬁcation always guarantees some desired requirements), and to check whether an already completed execution has deviated from the prescribed requirements. The authors rely on an inductive theorem prover for the veriﬁcation task. As discussed in Chap. 14, REC formalizes the standard EC ontology in a reactive way; therefore, the

16.1 Related Work

371

BPEL formalization presented in [205] could be exploited on top of rec to monitor the adherence of a running service with a set of BPEL functional requirements. Many authors have investigated the use of temporal logics – propositional Linear Temporal Logic (LTL) in particular, as a declarative language for specifying requirements and properties to be veriﬁed at run-time. However, the construction of suitable monitors starting from an LTL formula poses a twofold challenge. First, the semantics of LTL must be modiﬁed to reﬂect that, during the execution, the reasoning process cannot always provide a deﬁnitive answer, but must be open to the acquisition of new knowledge, i.e., of new event occurrences (see Sect. 13.1). Let us for example consider a partial trace, which does not contain the execution of activity pay. A liveness property such as ♦pay should not lead to evaluate the instance as noncompliant: there is still the possibility to meet the property, by eventually executing the pay activity. To overcome this issue, Bauer et al. propose to switch to a three-valued semantics for the logic [31]; under a three-valued semantics, a run-time veriﬁer would evaluate ♦pay as unknown. Another possibility is to revise the LTL semantics so as to account for ﬁnite (partial) execution traces. In [131, 115], Giannakopoulou and Havelund introduce a ﬁnite-trace semantics for LTL, reﬂecting the fact that partial ongoing executions are ﬁnite; their semantics would state that ♦pay is violated, but in their setting the concept of violation is limited to the portion of execution observed so far. For a survey of the use of LTL for run-time veriﬁcation, the interested reader can refer to [32]. The second challenge is related to the generation of a suitable run-time veriﬁer. Automata-based techniques are usually employed, but they cannot take advantage from the standard transformations onto B¨ uchi automata, because of the non standard three-valued or ﬁnite trace semantics. The automata generation algorithms require ad-hoc modiﬁcations, making diﬃcult to prove the formal properties of the resulting approach. Diﬀerently from temporal logics, the CLIMB language and its declarative semantics are exploited without modiﬁcations along the whole life cycle of open declarative interaction models, spanning from design and static veriﬁcation to run-time veriﬁcation, monitoring, enactment and mining. Reasoning is addressed by combining the sciff and g-sciff proof procedures, for which the formal properties of soundness, completeness and termination have been assessed. REC consists of a fully declarative SCIFF-lite speciﬁcation, and therefore its speciﬁcations can be seamlessly monitored by sciff without any change. Furthermore, the EC-based formalization of ConDec supports the monitoring of optional constraints and the management of compensation mechanisms, two issues that can be hardly tackled by propositional logics.

372

16 Related Work and Summary

16.1.2 Enactment The enactment of ConDec models has been addressed by Pesic and van der Aalst in [193, 191]. They rely on the LTL-based formalization of ConDec (discussed in Sect. 3.7 of this book). The formula representing the ConDec model is translated into an automaton, following the ﬁnite trace algorithm of [115]. The enactment is then directly supported by the automaton. In particular, the automaton starts from the initial state, and moves to a successor state every time the activity associated to the corresponding transition is executed. If the automaton is currently in some state, only the activities associated to outgoing transitions of that state are executable. Hence, diﬀerently from the SCIFF and REC-based approach presented in this book, the automaton carries, by construction, complete information about the enabled and forbidden activities. On the one hand, the automata-based approach does not need speculative reasoning, eliminating a computational step which, in our case, must be executed each time a new activity is executed. On the other hand, as discussed in Chap. 11, the construction of the automation is an expensive process, exponential in the size of the formula. Timing aspects are not critical when the automaton is used for providing enactment facilities, because it is built once and for all before the execution phase. However, the space needed to store the automaton is exponential in the size of the formula as well, making it diﬃcult to handle even medium-sized models. The DECLARE management system [193] does not only provide enactment facilities. It also supports ﬂexibility by change: business constraints can be dynamically added or removed by the interacting entities. When the model is subject to a dynamic change (a constraint addition in particular), the automata-based enactment engine handles the migration of the running instances. In particular, it tries to replay each partial execution trace on the new automaton. If this is possible, the corresponding instance is migrated to the new model, otherwise it will continue to be associated to the old model. A recent work by Alberti, Gavanelli and Lamma [10] opens the possibility of accommodating this kind of ﬂexibility also in the CLIMB setting. They present an extension of SCIFF, where the dynamic acquisition of integrity constraints is supported. In particular, the declarative semantics of Abductive Logic Programming is modiﬁed so as to account for the runtime addition of constraints. Then, the sciff proof procedure is augmented with a further transition, which takes a new integrity constraint and adds it to the speciﬁcation. Soundness, completeness and termination of the approach are proven, showing that the proposed extension is well-founded and that it is operationally handled in a correct way. The enactment of declarative service interaction models, speciﬁed by means of Concurrent Transaction Logic (CTR) [45], has been addressed by Roman and Kifer in [202]. However, their notion of enactment diﬀers from the one considered in this book. In the ConDec setting, enactment aims at providing execution support to the interacting entities, showing the status

16.1 Related Work

373

of each constraints and identifying the enabled and forbidden activities. In [202], the authors focus instead on the static synthesis of one possible way to enact the service under study, so as to guarantee the conformance with a given choreography model. This is done by combining the CTR speciﬁcations of the service and the choreography, and trying to derive a constructive proof for the global speciﬁcation. 16.1.3 Process Mining Process mining is an active and growing research area. Several algorithms have been proposed to discover process models from event logs. Most of them aim at deriving procedural, closed speciﬁcations, such as Petri Nets or Event-driven Process Chains. In [1], Agrawal et al. introduce the idea of applying process mining to workﬂow management. The authors propose an approach for inducing a process representation in the form of a directed graph encoding precedence relationships. In [245], van der Aalst et al. present the α-algorithm for the discovery of Petri nets, identifying a class of models for which the approach is guaranteed to work. The α-algorithm is based on the discovery of binary relations in the log, such as the “follows” relation. In [252] van Dongen and van der Aalst describe an algorithm which derives causal dependencies between activities and use them for constructing instance graphs, represented in terms of Eventdriven Process Chains. In [121], a hierarchical approach to workﬂow mining is presented. Execution traces sharing similar behaviors are clustered together, and a specialized workﬂow schema is devised for each cluster. The resulting global model is a disjunctive schema that explicitly takes care of variants of the process. The discovery of procedural models has the main drawback that, in real situations, the obtained result tends to become an unreadable, spaghetti-like speciﬁcation. To overcome this issue, G¨ unther and van der Aalst have developed the Fuzzy Miner [125]. Fuzzy Miner adopts the metaphor of a roadmap: the discovered process can be observed at many diﬀerent levels of abstractions. The tool supports the dynamic aggregation and expansion of the model’s subparts, and highlights the most relevant aspects in the process. The spaghetti-like nature of the discovered procedural models comes from the fact that often reality is less structured than expected. DecMiner does not experience such a diﬃculty, because it aims at learning declarative and open models, which are speciﬁcally thought to accommodate ﬂexibility and unstructured behaviors. The works presented in [92, 101] are closer to DecMiner because they deal with the discovery of ﬂexible speciﬁcations. In particular, in [92] the learning process starts from “runs”, which are Petri Nets representing high level speciﬁcations of a set of audit trails. Mining is performed by merging the diﬀerent runs for the same process. The model that is obtained is hybrid, in the sense that it may contain sets of activities that must be executed but

374

16 Related Work and Summary

for which no speciﬁc order is required. We diﬀer from this work because we start from traces rather than runs: while runs are associated to a signiﬁcant information about the system, namely a partial order among activities, traces are simply event streams. A critical requirement of DecMiner is that each input trace must be previously classiﬁed as compliant or noncompliant, and event logs do not provide any hint about how their traces should be partitionated. In [116] Goedertier argues that the lack of negative information2 in event logs makes process discovery an inherent unsupervised learning problem. However, ﬁnding a suitable classiﬁcation criterion to extract such a negative information is not always reasonable, because it requires a deep pre-existing knowledge of the domain under study. To overcome this issue, Goedertier introduces a technique for automatically extracting artiﬁcial “negative” events from the execution traces. The integration of his proposal and DecMiner would be an interesting line of research. The same procedural vs declarative dichotomy is encountered also when it comes to a-posteriori conformance checking and trace analysis. In [207, 248], the authors present a technique for conformance checking of execution traces to a pre-existing procedural model, speciﬁed by means of a Petri Net. Roughly speaking, the approach consists in replaying each trace on the model, counting the number of missing and remaining tokens. Two metrics, namely ﬁtness and appropriateness, are introduced to aggregate the computed values, giving a feedback about how much the given model is able to describe the behaviors contained in the log. The approach has been concretely applied to verify the conformance of SOAP-based traces, generated from Oracle BPEL, with a Petri Net-based choreography model. Diﬀerently from the conformance checker proposed in [207, 248], SCIFF Checker employs a set of declarative business rules for veriﬁcation. In this respect, the closest work to SCIFF Checker is the ProM LTL-Checker [237], that shares with our tool motivation and purposes. While LTL-Checker exploits LTL for the formalization of properties, our checker belongs to the Logic Programming setting. The LTL-Checker uses a variant of LTL which supports some kinds of data (such as for example absolute time conditions), and exploits a veriﬁcation technique which does not rely on the translation of LTL formulae into auomata, thus avoiding the state-explosion problem. Nevertheless, SCIFF Checker’s rules are more expressive than the formulae of LTL-Checker, being they e.g. able to express relative metric time constraints. Furthermore, the conﬁguration of templates inside LTL-Checker is limited to assign a value to each parameter, while SCIFF Checker supports the speciﬁcation of many diﬀerent conditions, accommodating the generation of a variety of business rules starting from a single template. As discussed in Sect. 12.1.2, there are many proposals which assess compliance with rules and norms before the execution. For example, in [210, 120] 2

I.e., information about transitions that are not allowed to take place.

16.2 Summary of the Part

375

the compliance of processes with regulations and standards is enforced by design rather than being checked a posteriori. Obviously, a static approach is not applicable when the interacting entities are autonomous and behave in an unpredictable manner, nor when the systems support run-time forms of ﬂexibility, such as ﬂexibility by change and by deviation. Furthermore, it cannot deal with situations where the outcome of the compliance evaluation inherently depends on the actual conﬁguration (resources and data) of the instance. This is the case of the four eyes principle, which constrains the actual originators.

16.2 Summary of the Part In this part of the book, we have presented a set of veriﬁcation techniques for providing run-time and a-posteriori support in Event-Based System. We have described how the reactive nature of sciff can be exploited to accomplish the run-time veriﬁcation task: sciff is able to dynamically acquire the occuring events of an instance, checking on-the-ﬂy whether they comply with a prescriptive ConDec model or not. We have pointed out that sciff is not always able to detect a violation as soon as possible, and we have proposed to overcome this limitation by integrating the two proof procedures, interleaving a sciff derivation with a speculative reasoning step, carried out by g-sciff. We have then introduced the monitoring problem, diﬀerentiating it with run-time veriﬁcation, and arguing that sciff cannot suitably realize it when reasoning upon CLIMB speciﬁcations. We have consequently extended the framework so as to deal with monitoring issues. The extended framework encompasses a reactive SCIFF-based axiomatization of the Event Calculus (REC), which supports the possibility of explicitly capturing and reifying violations. The axiomatization is fully declarative, and brings therefore a twofold advantage: on the one hand, it can be directly executed on top of sciff to provide the desired monitoring capabilities; on the other hand, it is possible to investigate its formal properties. In particular, we have proven that, under the assumption that events occur in ascending order and that the provided domain-dependent theory is well-deﬁned, it exhibits an irrevocable behavior. Irrevocability guarantees that the veriﬁcation procedure will never retract an already computed result, but only extend it as new information is acquired. REC has been exploited to monitor optional ConDec++ constraints, supporting the possibility of reifying violations and handling compensation mechanisms, again expressed with the ConDec++ language. The combination of sciff, g-sciff and REC has been ﬁnally investigated to enact ConDec models, providing execution support to the interacting entities. Finally, this part of the book has focused on the a-posteriori veriﬁcation of Event-Based Systems, where the actual execution traces of the system are used to infer relevant information about the real behavior exhibited by the

376

16 Related Work and Summary

interacting entities. In particular, the application of the declarative languages and veriﬁcation techniques presented in this book has given birth to declarative process mining. Two declarative process mining techniques have been discussed. The ﬁrst tool, called SCIFF Checker, veriﬁes how many execution traces comply with a given business rule, speciﬁed using a pseudo-natural language which takes inspiration from CLIMB. The tool has been applied to some real and heterogeneous case studies: Business Process Management, Clinical Guidelines and Wastewater Treatment Plants. The second tool, called DecMiner, employs Inductive Logic Programming techniques to discover a declarative CLIMB model from two sets of execution traces, the former representing correct executions, the latter containing the unacceptable ones. The derived model provides an concise, declarative description of what is going on, abstracting away from procedural details and avoiding the generation of spaghetti-like models. DecMiner has been tuned to learn only those CLIMB rules that formalize some ConDec constraint. In this way, the discovered model can be graphically reported in the form of a ConDec diagram. Both tools have been fully implemented as ProM plug-ins, and are part of the last ProM distribution. The two tools can be combined to realize a discovery-checking cycle, where SCIFF Checker could be exploited for preparing the input data needed by DecMiner, and the discovered model could be adopted to check the conformance of new instances.

Part IV

Conclusion and Future Work

17 Conclusion and Future Work We can only see a short distance ahead, but we can see plenty there that needs to be done. — Alan Turing

17.1 Conclusion We have put forwards signiﬁcant evidence to support that declarativeness and openness are needed to deal with a plethora of systems, composed by several autonomous entities which collaborate and interact to the aim of achieving complex goals, impossible to be accomplished on their own. We have considered four challenging settings, namely Business Process Management, Clinical Guidelines, Service Oriented and Multi-Agent Systems. We have argued that all these application domains require a suitable balance between compliance and ﬂexibility, a goal that can be achieved only by complementing closed and procedural interaction models with an open, declarative counterpart. The Computational Logic-based CLIMB framework has been proposed to cover the entire life cycle of open declarative interaction models, supporting their speciﬁcation and veriﬁcation. In [222], it is argued that open systems should have a formal, declarative, veriﬁable, and meaningful semantics. We hope to have convinced the reader that Computational Logic, and in particular the CLIMB framework, meets all these essential requirements, and is therefore an eﬀective and signiﬁcant solution for supporting open and ﬂexible Event-Based Systems along their whole life cycle. Indeed, the CLIMB framework is: Declarative. It combines two languages, namely ConDec and (a fragment of) SCIFF, to capture the business constraints that must be respected during the interaction, without stating how the interacting entities must behave. Meaningful. Both ConDec and SCIFF adopt intuitive and relevant abstractions for characterizing the dynamics of the target systems. ConDec is a graphical notation that combines the two fundamental notions of activities and business constraints. SCIFF is a rule-based language which adopts the concepts of occurred, expected and forbidden events as ﬁrstclass abstractions, and the notion of integrity constraint to bind them together. SCIFF is not only able to provide an underlying semantics to

M. Montali: Declarative Open Interaction Models, LNBIP 56, pp. 379–383, 2010. c Springer-Verlag Berlin Heidelberg 2010

380

17 Conclusion and Future Work

each ConDec business constraint, but can be also exploited to extend its expressiveness. In particular, the ﬁrst-order nature of SCIFF has been exploited in the book to extend ConDec with data-aware conditions, metric temporal constraints and non atomic activities. Some of these meaningful extensions cannot be expressed by limiting to propositional (modal) logics (see e.g. the event correlation problem at p. 159). Formal. A complete translation of the ConDec constructs in terms of SCIFF rules has been devised. SCIFF is in turn equipped with a formal declarative semantics, which is based on Abuctive Logic Programming and provides a precise characterization of the compliance between an execution trace and a SCIFF speciﬁcation. Veriﬁable. Two sound and complete proof procedures constitute the operational counterpart of the SCIFF declarative semantics. They equip CLIMB with a-priori, run-time and a-posteriori veriﬁcation capabilities, targeting interaction models prior to, during and after their execution. Thanks to the SCIFF-based reactive axiomatization of the Event Calculus, also monitoring facilities are incorporated into the framework. The presented experimental evaluations and case studies show the applicability and effectiveness of such veriﬁcation techniques. The CLIMB framework attests that languages and techniques coming from diﬀerent research ﬁelds (Logic Programming, Business Process Management, Multi-Agent Systems, Knowledge Representation and Reasoning) can be fruitfully combined to specify and reason about declarative open interaction models, covering both theoretical and practical aspects. Computational Logic is the backbone of the entire framework: it binds all the involved components together, providing at the same time a uniform, underlying formal semantics as well as concrete veriﬁcation facilities. We hope that this work will stimulate new researchers in the application of open declarative interaction models and their corresponding Computational Logic-based reasoning techniques, towards the continuous integration and mutual cross-fertilization of ideas and approaches proposed by diﬀerent research communities.

17.2 Future Work The investigation presented in this book leaves many open challenges and issues for future research. We brieﬂy discuss some of them in the following. 17.2.1 Termination of Static Veriﬁcation and ConDec Extensibility In [193], Pesic et al. state that ConDec is an extensible language : new constraint templates can be added through the DECLARE tool, shaping their graphical representation and providing their LTL-based formalization. In our

17.2 Future Work

381

setting, extending the set of constraints could undermine the termination of the g-sciff proof procedure, even in presence of the preprocessing procedure described in Sect. 10.5. To ensure that the preprocessing algorithm would still be able to guarantee the identiﬁcation of all looping situations, the CLIMB representation of the new constraint should be written in a past- or futuretense way (see Sect. 10.4.2). However, this task is non trivial, nor applicable in the general case. To guarantee the termination of g-sciff when verifying arbitrary speciﬁcations, a general method for dealing with inﬁnite computations must be therefore incorporated into the framework. A promising approach to handle inﬁnite computations is Coinductive Logic Programming [127], which extends the usual declarative and operational semantics of Logic Programming to reason over inﬁnite and cyclic structures and properties. Obviously, being SCIFF an extension of Logic Programming, the CLIMB framework would need to suitably adapt the coinductive deﬁnitions, as well as the corresponding operational counterpart. 17.2.2 Reactive Event Calculus and Operational Support In [250], van der Aalst et al. foresee a new generation of auditing techniques, taking advantage from process mining algorithms and tools. Thanks to process mining, auditors “can evaluate all events in a business process, and do so while it is still running. The omnipresence of electronically recorded business events coupled with process mining technology enable a new form of auditing that will dramatically change the role of auditors” [250]. The application of process mining to running instances is called operational support. There are three main activities that an operational support framework can undertake: • analysis about the current state of the operational process; • prediction about the future of the operational process; • recommendation about what to do next in order to achieve some goal. Reactive Event Calculus (REC) is a suitable technology to provide operational decision support facilities, with particular emphasis on the analysis of the current state of the process. For example, it could be applied to monitor whether the running instances of the processes comply with business constraints. jREC, the JAVA-based software tool embedding the veriﬁcation capabilities of REC (see Sect. 14.8), attests that the integration of REC and the ProM process mining framework is practically feasible. 17.2.3 Integration of Regulative and Constitutive Rules The distinction between regulative and constitutive rules goes back to the seminal work by Midgley and Searle [168, 217]. In the context of interaction models, regulative rules focus on the behavioral aspects of interaction (such as occurred events, temporal relations, data) while constitutive rules deﬁne

382

17 Conclusion and Future Work

the meaning of actions and events in terms of their impact on the global state of the system [74, 25]. This book has mainly dealt with the speciﬁcation and veriﬁcation of the regulative aspect of interaction. Conversely, social commitments [56, 73, 105, 268] focus on the constitutive aspect of interaction, capturing the mutual obligations that are dynamically established by the interacting entities. The complementarity between the two approaches has been highlighted in Sect. 7.1.4 – p. 171. The integration of ConDec and social commitments is a research topic of great interest. Some preliminary works demonstrate the feasibility and the potentialities of a uniﬁed framework, embracing both regulative and constitutive aspects [66, 25]. It is worth noting that REC has been recently exploited to formalize and monitor commitment-based Multi-Agent Systems [65, 234, 67]. It is therefore a suitable candidate towards the harmonization of ConDec business constraints and commitments, providing at the same time a uniform formal semantics and eﬀective reasoning capabilities. 17.2.4 Development of an Editor and Enactment Prototype Although all the reasoning techniques presented in this book have been fully implemented, their combination towards the enactment of ConDec models has not yet been embedded into a concrete prototype. The prototype should support the graphical editing of ConDec diagrams, automatically generating their underlying computational logic-based representation. More speciﬁcally, two distinct translations procedures are required: • a translation procedure from ConDec to the CLIMB language, enabling past-tense compliance veriﬁcation and future-tense speculative reasoning; • a translation procedure from ConDec to REC, enabling the management of optional constraints as well as monitoring and compensation facilities. Model-driven engineering [108], and in particular model transformation techniques, would be an elegant and eﬀective choice to concretely realize such translation procedures. Given: • a source meta-model (the ConDec meta-model) • a target meta-model (the structure of CLIMB integrity constraints and of the Event Calculus ontology) • a set of rules mapping each entity of the source meta-model onto the target meta-model (the translation of each ConDec constraint unto CLIMB, and the ﬂuent-based representation of the constraints’ states) model transformation techniques automatically apply the general rule on a speciﬁc source model, producing the corresponding target model. For example, ATL [139] is a Model Transformation Language which supports the speciﬁcation of translation rules, supposing that both the source and the target

17.2 Future Work

383

meta-models are expressed in EMF1 , the core modeling framework used inside the well-known Eclipse environment2 . 17.2.5 Service Contracting and Discovery in the Semantic Web The SCIFF framework has been recently exploited in the context of Semantic Web (Services), to provide the reasoning machinery for building a dynamic discovery and contracting architecture, accommodating both behavioral and ontological knowledge [6, 9]. An open ongoing research activity concerns the harmonization of the veriﬁcation techniques described in such papers, and the ones addressed in this book. 17.2.6 Integration of Declarative and Procedural Models In Sect. 2.5, we have discussed the non-trivial interplay between the declarative, open background medical knowledge and the procedural, closed prescriptions of Clinical Guidelines. A deep theoretical and practical study of this challenging interplay still lacks: up to now, it has been naively tackled by layering the two perspectives, i.e., by taking a non atomic activity placed inside a procedural speciﬁcation, and expanding it in terms of a declarative subprocess (or vice-versa). Nevertheless, to provide a meaningful characterization of Event-Based Systems, and devise comprehensive supporting tools, we need to investigate the coexistence of the two perspectives at the same level, aiming at hybrid, semi-open interaction models.

1 2

http://www.eclipse.org/modeling/emf/ http://www.eclipse.org/

References

1. Agrawal, R., Gunopulos, D., Leymann, F.: Mining Process Models from Workﬂow Logs. In: Schek, H.-J., Saltor, F., Ramos, I., Alonso, G. (eds.) EDBT 1998. LNCS, vol. 1377, pp. 469–483. Springer, Heidelberg (1998) 2. Alberti, M., Chesani, F., Gavanelli, M., Lamma, E., Mello, P., Montali, M.: An Abductive Framework for A-Priori Veriﬁcation of Web Services. In: Bossi, A., Maher, M.J. (eds.) Proceedings of the 8th International ACM SIGPLAN Conference on Principles and Practice of Declarative Programming, pp. 39–50. ACM Press, New York (2006) 3. Alberti, M., Chesani, F., Lamma, E., Gavanelli, M., Mello, P., Montali, M., Storari, S., Torroni, P.: Computational Logic for the Run-time Veriﬁcation of Web Service Choreographies: Exploiting the SOCS-SI Tool. In: Bravetti, M., N´ un ˜ez, M., Zavattaro, G. (eds.) WS-FM 2006. LNCS, vol. 4184, pp. 58–72. Springer, Heidelberg (2006) 4. Alberti, M., Gavanelli, M., Lamma, E., Chesani, F., Mello, P., Torroni, P.: Compliance Veriﬁcation of Agent interaction: a Logic-Based Software Tool. Applied Artiﬁcial Intelligence 20(2-4), 133–157 (2006) 5. Alberti, M., Gavanelli, M., Lamma, E., Mello, P., Sartor, G., Torroni, P.: Mapping Deontic Operators to Abductive Expectations. Computational and Mathematical Organization Theory 12(2-3), 205–225 (2006) 6. Alberti, M., Chesani, F., Gavanelli, M., Lamma, E., Mello, P., Montali, M., Torroni, P.: Web Service contracting: Speciﬁcation and Reasoning with SCIFF. In: Franconi, E., Kifer, M., May, W. (eds.) ESWC 2007. LNCS, vol. 4519, pp. 68–83. Springer, Heidelberg (2007) 7. Alberti, M., Chesani, F., Gavanelli, M., Lamma, E., Mello, P., Montali, M., Torroni, P.: Expressing and Verifying Contracts with Abductive Logic Programming. Electronic Commerce, Special Issue on Contract Architectures and Languages 12(4), 9–38 (2008) 8. Alberti, M., Chesani, F., Gavanelli, M., Lamma, E., Mello, P., Torroni, P.: Veriﬁable Agent Interaction in Abductive Logic Programming: The SCIFF framework. ACM Transactions on Computational Logic (TOCL) 9(4) (2008)

386

References

9. Alberti, M., Cattaﬁ, M., Chesani, F., Gavanelli, M., Lamma, E., Montali, M., Mello, P., Torroni, P.: Integrating abductive logic programming and description logics in a dynamic contracting architecture. In: IEEE International Conference on Web Services (ICWS 2009), pp. 254–261. IEEE, Los Alamitos (2009) 10. Alberti, M., Gavanelli, M., Lamma, E.: Runtime addition of integrity constraints in abductive logic programs. In: Proceedings of the 26th International Conference on Logic Programming, ICLP 2010 (2010) 11. Allen, J.F.: Maintaining Knowledge about Temporal Intervals. Communications of the ACM 26(11) (1983) 12. Alur, R., Henzinger, T.A.: A Really Temporal Logic. In: Proceedings of the 30th Annual IEEE Symposium on Foundations of Computer Science, pp. 164– 169. IEEE Computer Society, Los Alamitos (1989) 13. Alur, R., Henzinger, T.A.: Real-Time Logics: Complexity and Expressiveness. Information and Computation 104, 35–77 (1993) 14. Alur, R., Henzinger, T.A.: Finitary Fairness. ACM Transactions on Programming Languages and Systems 20(6), 1171–1194 (1998) 15. Amnell, T., Behrmann, G., Bengtsson, J., D’argenio, P.R., David, A., Fehnker, A., Hune, T., Jeannet, B., Larsen, K.G., M¨oller, M.O., Pettersson, P., Weise, C., Yi, W.: UPPAAL: Now, Next, and Future. In: Cassez, F., Jard, C., Rozoy, B., Dermot, M. (eds.) MOVEP 2000. LNCS, vol. 2067, pp. 99–124. Springer, Heidelberg (2001) 16. Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F., Liu, K., Roller, D., Smith, D., Thatte, S., Trickovic, I., Weerawarana, S.: Business Process Execution Language for Web Services, Version 1.1. Standards proposal by BEA Systems. International Business Machines Corporation, and Microsoft Corporation (2003) 17. Andrieux, A., Czajkowski, K., Dan, A., Keahey, K., Ludwig, H., Nakata, T., Pruyne, J., Rofrano, J., Tuecke, S., Xu, M.: Web services agreement speciﬁcation (ws-agreement). Technical report, Grid Resource Allocation Agreement Protocol (GRAAP) WG (2007) 18. Apt, K.R.: A New Deﬁnition of SLDNF-Resolution. Technical report, CWI (Centre for Mathematics and Computer Science) (1992) 19. Apt, K.R., Bezem, M.: Acyclic Programs. In: Warren, D.H. (ed.) Logic Programming, pp. 617–633. MIT Press, Cambridge (1990) 20. Artikis, A., Pitt, J., Sergot, M.J.: Animated speciﬁcations of computational societies. In: Proceedings of the First International Joint Conference on Autonomous Agents & Multiagent Systems (AAMAS 2002), pp. 1053–1061. ACM, New York (2002) 21. Awad, A., Decker, G., Weske, M.: Eﬃcient Compliance Checking Using BPMNQ and Temporal Logic. In: Dumas, M., Reichert, M., Shan, M.-C. (eds.) BPM 2008. LNCS, vol. 5240, pp. 326–341. Springer, Heidelberg (2008) 22. Awad, A., Weidlich, M., Weske, M.: Speciﬁcation, Veriﬁcation and Explanation of Violation for Data Aware Compliance Rules. In: Baresi, L., Chi, C.-H., Suzuki, J. (eds.) Service-Oriented Computing. LNCS, vol. 5900, pp. 500–515. Springer, Heidelberg (2009) 23. Baldoni, M., Baroglio, C., Martelli, A., Patti, V., Schifanella, C.: Verifying the Conformance of Web Services to Global Interaction Protocols: A First Step. In: Bravetti, M., Kloul, L., Zavattaro, G. (eds.) EPEW/WS-EM 2005. LNCS, vol. 3670, pp. 257–271. Springer, Heidelberg (2005)

References

387

24. Baldoni, M., Baroglio, C., Martelli, A., Patti, V.: A Priori Conformance Veriﬁcation for Guaranteeing Interoperability in Open Environments. In: Dan, A., Lamersdorf, W. (eds.) ICSOC 2006. LNCS, vol. 4294, pp. 339–351. Springer, Heidelberg (2006) 25. Baldoni, M., Baroglio, C., Marengo, E.: Behavior-oriented Commitment-based Protocols. In: Coelho, H., Wooldridge, M. (eds.) Proceedings of the 19th European Conference on Artiﬁcial Intelligence (ECAI 2010). IOS Press, Amsterdam (2010) 26. Barbon, F., Traverso, P., Pistore, M., Trainotti, M.: Run-Time Monitoring of Instances and Classes of Web Service Compositions. In: Proceedings of the 2006 IEEE International Conference on Web Services (ICWS 2006), pp. 63–71. IEEE Computer Society, Los Alamitos (2006) 27. Baresi, L., Guinea, S.: Towards Dynamic Monitoring of WS-BPEL Processes. In: Benatallah, B., Casati, F., Traverso, P. (eds.) ICSOC 2005. LNCS, vol. 3826, pp. 269–282. Springer, Heidelberg (2005) 28. Baresi, L., Guinea, S.: A Dynamic and Reactive Approach to the Supervision of BPEL Processes. In: Shroﬀ, G., Jalote, P., Rajamani, S.K. (eds.) Proceedings of the 1st Annual India Software Engineering Conference (ISEC 2008), pp. 39–48. ACM, New York (2008) 29. Baresi, L., Guinea, S., Pistore, M., Trainotti, M.: Dynamo + Astro: An Integrated Approach for BPEL Monitoring. In: Proceedings of the 2009 IEEE International Conference on Web Services (ICWS 2009), pp. 230–237. IEEE, Los Alamitos (2009) 30. Barros, A., Dumas, M., Oaks, P.: A Critical Overview of the Web Services Choreography Description Language (WS-CDL). BPTrends (2005) 31. Bauer, A., Leucker, M., Schallhart, C.: Monitoring of Real-Time Properties. In: Arun-Kumar, S., Garg, N. (eds.) FSTTCS 2006. LNCS, vol. 4337, pp. 260–272. Springer, Heidelberg (2006) 32. Bauer, A., Leucker, M., Schallhart, C.: Comparing LTL Semantics for Runtime Veriﬁcation. In: Logic and Computation (2010) 33. Bauer, B., Cossentino, M., Craneﬁeld, S., Huget, M.P., Kearney, K., Levy, R., Nodine, M., Odell, J., Cervenka, R., Turci, P., Zhu, H.: The FIPA Agent UML Web Site (2007) (last update), http://www.auml.org/ 34. Benatallah, B., Casati, F., Toumani, F.: Analysis and Management of Web Service Protocols. In: Atzeni, P., Chu, W., Lu, H., Zhou, S., Ling, T.-W. (eds.) ER 2004. LNCS, vol. 3288, pp. 524–541. Springer, Heidelberg (2004) 35. Benatallah, B., Casati, F., Toumani, F.: Representing, Analysing and Managing Web Service Protocols. Data and Knowledge Engineering 58(3), 327–357 (2006) 36. Benbernou, S., Cavallaro, L., Hacid, M.S., Kazhamiakin, R., Kecskemeti, G., Poizat, J.-L., Silvestri, F., Uhlig, M., Wetzstein, B.: State of the Art Report, Gap Analysis of Knowledge on Principles, Techniques and Methodologies for Monitoring and Adaptation of SBAs. Technical report, S-Cube European Network (2008) 37. Bengtsson, J., Yi, W.: Timed Automata: Semantics, Algorithms and Tools. In: Desel, J., Reisig, W., Rozenberg, G. (eds.) Lectures on Concurrency and Petri Nets. LNCS, vol. 3098, pp. 87–124. Springer, Heidelberg (2004)

388

References

38. Berardi, D., Calvanese, D., Giacomo, G.D., Lenzerini, M., Mecella, M.: Automatic Service Composition Based on Behavioral Descriptions. Cooperative Information Systems 14(4), 333–376 (2005) 39. Berens, P.: The FLOWer Case-Handling Approach: Beyond Workﬂow Management. In: Process-Aware Information Systems. Wiley Interscience, Hoboken (2005) 40. Beyer, D., Chakrabarti, A., Henzinger, T.: Web Service Interfaces. In: Proceedings of the 14th International World Wide Web Conference (WWW 2005), pp. 148–159 (2005) 41. Bianculli, D., Morzenti, A., Pradela, M., San Pietro, P., Spoletini, P.: Trio2Promela: a model checker for temporal metric speciﬁcations. In: Proceedings of the 20th International Conference on Software Engineering (ICSE 2007), pp. 61–62. IEEE Computer Society, Los Alamitos (2007) 42. Biere, A., Cimatti, A., Clarke, E.M., Zhu, Y.: Symbolic Model Checking without BDDs. In: Cleaveland, W.R. (ed.) TACAS 1999. LNCS, vol. 1579, pp. 193–207. Springer, Heidelberg (1999) 43. Biere, A., Cimatti, A., Clarke, E.M., Strichman, O., Zhu, Y.: Bounded Model Checking. Advances in Computers 58, 118–149 (2003) 44. Billington, J.: Extensions to coloured petri nets. In: Proceedings of the Third International Workshop on Petri Nets and Performance Models (PNPM 1989), pp. 61–70. IEEE Computer Society, Los Alamitos (1989) 45. Bonner, A.J., Kifer, M.: Concurrency and communication in transaction logic. In: Proceedings of the Joint International Conference and Symposium on Logic Programming (JICSLP 1996), pp. 142–156. MIT Press, Cambridge (1996) 46. Bordeaux, L., Sala¨ un, G., Berardi, D., Mecella, M.: When are Two Web Services Compatible? In: Shan, M.-C., Dayal, U., Hsu, M. (eds.) TES 2004. LNCS, vol. 3324, pp. 15–28. Springer, Heidelberg (2005) 47. Bottrighi, A., Chesani, F., Mello, P., Molino, G., Montali, M., Montani, S., Storari, S., Terenziani, P., Torchio, M.: A Hybrid Approach to Clinical Guideline and to Basic Medical Knowledge Conformance. In: Combi, C., Shahar, Y., Abu-Hanna, A. (eds.) AIME 2009. LNCS, vol. 5651, pp. 91–95. Springer, Heidelberg (2009) 48. Bottrighi, A., Chesani, F., Mello, P., Montali, M., Montani, S., Storari, S., Terenziani, P.: Analysis of the GLARE and GPROVE Approaches to Clinical Guidelines. In: Ria˜ no, D., ten Teije, A., Miksch, S., Peleg, M. (eds.) KR4HC 2009. LNCS, vol. 5943, pp. 76–87. Springer, Heidelberg (2010) 49. Bratko, I.: Prolog Programming for Artiﬁcial Intelligence, 3rd edn. Pearson Education, Addison–Wesley (2001) 50. Bryant, R.E.: Graph-Based Algorithms for Boolean Function Manipulation. IEEE Transactions on Computers 35(8), 677–691 (1986) 51. Bultan, T., Fu, X., Hull, R., Su, J.: Conversation Speciﬁcation: A New Approach to Design and Analysis of E-Service Composition. In: Proceedings of the 12th International World Wide Web Conference (WWW 2003), pp. 403– 410. ACM Press, New York (2003) 52. Burch, J.R., Clarke, E.M., McMillan, K.L., Dill, D.L., Hwang, L.J.: Symbolic model checking: 1020 states and beyond. In: Proceedings of the IEEE Symposium on Logic in Computer Science, Washington, DC, USA, pp. 428–439. IEEE Computer Society, Los Alamitos (1990)

References

389

53. B¨ urckert, H.-J.: A Resolution Principle for Constrained Logics. Artiﬁcial Intelligence 66, 235–271 (1994) 54. Busi, N., Gorrieri, R., Guidi, C., Lucchi, R., Zavattaro, G.: Choreography and Orchestration Conformance for System Design. In: Ciancarini, P., Wiklicky, H. (eds.) COORDINATION 2006. LNCS, vol. 4038, pp. 63–81. Springer, Heidelberg (2006) 55. Casella, G., Mascardi, V.: West2East: exploiting WEb Service Technologies to Engineer Agent-based SofTware. In: Agent-Oriented Software Engineering, pp. 396–434 (2007) 56. Castelfranchi, C.: Commitments: From Individual Intentions to Groups and Organizations. In: Gasser, V.R.L.L. (ed.) Proceedings of the First International Conference on Multiagent Systems (ICMAS 1995), pp. 41–48. MIT Press, Cambridge (1995) 57. Chatterjee, K., Henzinger, T.A., Horn, F.: Stochastic Games with Finitary Objectives. In: Kr´ aloviˇc, R., Niwi´ nski, D. (eds.) MFCS 2009. LNCS, vol. 5734, pp. 34–54. Springer, Heidelberg (2009) 58. Chesani, F.: Speciﬁcation, Execution and Veriﬁcation of Interaction Protocols: an Approach based on Computational Logic. PhD thesis, University of Bologna (2007) 59. Chesani, F., Mello, P., Montali, M., Storari, S.: Testing Careﬂow Process Execution Conformance by Translating a Graphical Language to Computational Logic. In: Bellazzi, R., Abu-Hanna, A., Hunter, J. (eds.) AIME 2007. LNCS (LNAI), vol. 4594, pp. 479–488. Springer, Heidelberg (2007) 60. Chesani, F., Mello, P., Montali, M., Storari, S.: Testing Careﬂow Process Execution Conformance by Translating a Graphical Language to Computational Logic. In: Bellazzi, R., Abu-Hanna, A., Hunter, J. (eds.) AIME 2007. LNCS (LNAI), vol. 4594, pp. 479–488. Springer, Heidelberg (2007) 61. Chesani, F., Lamma, E., Mello, P., Montali, M., Storari, S., Baldazzi, P., Manfredi, M.: Compliance Checking of Cancer-Screening Careﬂows: an Approach Based on Computational Logic. In: ten Teije, A., Miksch, S., Lucas, P. (eds.) Book Chapter of Computer-Based Medical Guidelines and Protocols: a Primer and Current Trends. IOS Press, Amsterdam (2008) 62. Chesani, F., Lamma, E., Mello, P., Montali, M., Riguzzi, F., Storari, S.: Exploiting Inductive Logic Programming Techniques for Declarative Process Mining. In: Jensen, K., van der Aalst, W.M.P. (eds.) Transactions on Petri Nets. LNCS, vol. 5460, pp. 278–295. Springer, Heidelberg (2009) 63. Chesani, F., Mello, P., Montali, M., Riguzzi, F., Sebastianis, M., Storari, S.: Checking Compliance of Execution Traces to Business Rules. In: Ardagna, D., Mecella, M., Yang, J. (eds.) Proceedings of BPM 2008 Workshops. Revised Papers. LNBIP, vol. 17, pp. 134–145. Springer, Heidelberg (2009) 64. Chesani, F., Mello, P., Montali, M., Torroni, P.: Veriﬁcation of Choreographies During Execution Using the Reactive Event Calculus. In: Bruni, R., Wolf, K. (eds.) WS-FM 2008. LNCS, vol. 5387, pp. 55–72. Springer, Heidelberg (2009) 65. Chesani, F., Mello, P., Montali, M., Torroni, P.: Commitment Tracking via the Reactive Event Calculus. In: Boutilier, C. (ed.) Proceedings of the 21st International Joint Conference on Artiﬁcial Intelligence (IJCAI 2009), pp. 91– 96 (2009)

390

References

66. Chesani, F., Mello, P., Montali, M., Storari, S., Torroni, P.: On the Integration of Declarative Choreographies and Commitment-based Agent Societies into the SCIFF Logic Programming Framework. Multiagent and Grid Systems, Special Issue on Agents, Web Services and Ontologies: Integrated Methodologies 6(2) (2010) 67. Chesani, F., Montali, M., Mello, P., Torroni, P.: Monitoring Time-Aware Social Commitments with Reactive Event Calculus. In: Proceedings of the 7th International Symposium “From Agent Theory to Agent Implementation”, AT2AI-7 (2010) 68. Chinnici, R., Moreau, J.-J., Ryman, A., Weerawarana, S.: Web Services Description Language (WSDL) Version 2.0. Technical report, World Wide Web Consortium (W3C) Recommendation (2007), http://www.w3.org/TR/wsdl20 69. Chittaro, L., Montanari, A.: Eﬃcient Handling of Context Dependency in the Cached Event Calculus. In: Goodwin, S.D., Hamilton, H.J. (eds.) Proceedings of the TIME 1994 International Workshop on Temporal Reasoning, pp. 103– 112 (1994) 70. Chittaro, L., Montanari, A.: Eﬃcient Temporal Reasoning in the Cached Event Calculus. Computational Intelligence 12, 359–382 (1996) 71. Chittaro, L., Montanari, A.: Temporal Representation and Reasoning in Artiﬁcial Intelligence: Issues and Approaches. Annals of Mathematics and Artiﬁcial Intelligence 28(1-4), 47–106 (2000) 72. Chopra, A.K., Singh, C.P.: Producing Compliant Interactions: Conformance, Coverage, and Interoperability. In: Baldoni, M., Endriss, U. (eds.) DALT 2006. LNCS (LNAI), vol. 4327, pp. 1–15. Springer, Heidelberg (2006) 73. Chopra, A.K., Singh, M.P.: Commitments for Flexible Business Processes. In: Proceedings of the 3rd International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS 2004), pp. 1362–1363. IEEE Computer Society, Los Alamitos (2004) 74. Chopra, A.K., Singh, M.P.: Constitutive Interoperability. In: Padgham, L., Parkes, D.C., M¨ uller, J., Parsons, S. (eds.) Proceedings of the 7th International Joint Conference on Autonomous Agents and Multiagent Systems (AAMAS 2008), vol. 2, pp. 797–804. IFAAMAS (2008) 75. Christensen, S., Hansen, N.D.: Coloured petri nets extended with place capacities, test arcs and inhibitor arcs. In: Ajmone Marsan, M. (ed.) ICATPN 1993. LNCS, vol. 691, pp. 186–205. Springer, Heidelberg (1993) 76. Cimatti, A., Clarke, E.M., Giunchiglia, F., Roveri, M.: NuSMV: a New Symbolic Model Checker. Software Tools for Technology Transfer 2(4), 410–425 (2000) 77. Clark, K.L.: Negation as Failure. In: Gallaire, H., Minker, J. (eds.) Logic and Data Bases, pp. 293–322. Plenum Press, New York (1978) 78. Clark, K.L.: Predicate Logic as a Computational Formalism. Res. report doc 79/59, Imperial College, Department of Computing (1979) 79. Clarke, E.M., Grumberg, O., Peled, D.: Model Checking. MIT Press, Cambridge (1999) 80. Clarke, E.M., Grumberg, O., Jha, S., Lu, Y., Veith, H.: Progress on the State Explosion Problem in Model Checking. In: Wilhelm, R. (ed.) Informatics: 10 Years Back, 10 Years Ahead. LNCS, vol. 2000, pp. 176–194. Springer, Heidelberg (2001)

References

391

81. Colin, S., Mariani, L.: Run-Time Veriﬁcation. In: Broy, M., Jonsson, B., Katoen, J.-P., Leucker, M., Pretschner, A. (eds.) Model-Based Testing of Reactive Systems. LNCS, vol. 3472, pp. 525–555. Springer, Heidelberg (2005) 82. Colombetti, M., Fornara, N., Verdicchio, M.: A Social Approach to Communication in Multiagent Systems. In: Leite, J., Omicini, A., Sterling, L., Torroni, P. (eds.) DALT 2003. LNCS (LNAI), vol. 2990, pp. 191–220. Springer, Heidelberg (2004) 83. Crnkovic, I., Hnich, B., Jonsson, T., Kiziltan, Z.: Speciﬁcation, Implementation, and Deployment of Components. Communications of the ACM 45(10), 35–40 (2002) 84. Dadam, P., Reichert, M.: The ADEPT project: a decade of research and development for robust and ﬂexible process support. Computer Science - R&D 23(2), 81–97 (2009) 85. Decker, G., Zaha, J.M., Dumas, M.: Execution Semantics for Service Choreographies. In: Bravetti, M., N´ un ˜ez, M., Zavattaro, G. (eds.) WS-FM 2006. LNCS, vol. 4184, pp. 163–177. Springer, Heidelberg (2006) 86. Decker, G., Kopp, O., Barros, A.P.: An Introduction to Service Choreographies (Servicechoreographien - eine Einf¨ uhrung). IT - Information Technology 50(2), 122–127 (2008) 87. Delzanno, G., Podelski, A.: Model Checking in CLP. In: Cleaveland, W.R. (ed.) TACAS 1999. LNCS, vol. 1579, pp. 223–239. Springer, Heidelberg (1999) 88. Demri, S., Laroussinie, F., Schnoebelen, P.: A Parametric Analysis of the StateExplosion Problem in Model Checking. Computer and System Sciences 72(4), 547–575 (2006) 89. Denecker, M., Schreye, D.D.: SLDNFA: An Abductive Procedure for Abductive Logic Programs. Jorunal of Logic Programming 34(2), 111–167 (1998) 90. Denti, E., Omicini, A., Ricci, A.: tu Prolog: A Light-Weight Prolog for Internet Applications and Infrastructures. In: Ramakrishnan, I.V. (ed.) PADL 2001. LNCS, vol. 1990, pp. 184–198. Springer, Heidelberg (2001) 91. DeRemer, F., Kron, H.H.: Programming-in-the-Large Versus Programming-inthe-Small. IEEE Transactions on Software Engineering 2(2), 80–86 (1976) 92. Desel, J., Erwin, T.: Hybrid Speciﬁcations: Looking at Workﬂows From a RunTime Perspective. Computer System Science & Engineering 15(5), 291–302 (2000) 93. Deutsch, A., Sui, L., Vianu, V., Zhou, D.: Veriﬁcation of Communicating DataDriven Web Services. In: Proceedings of the 25th ACM SIGMOD-SIGACTSIGART Symposium on Principles of Database Systems (PODS 2006), pp. 90–99. ACM Press, New York (2006) 94. Dijkman, R.M., Dumas, M., Ouyang, C.: Semantics and analysis of business process models in BPMN. Information & Software Technology 50(12), 1281– 1294 (2008) 95. Dincbas, M., Hentenryck, P.V., Simonis, H., Aggoun, A., Graf, T., Berthier, F.: The Constraint Logic Programming Language CHIP. In: Proceedings of the International Conference on Fifth Generation Computer Systems, pp. 693–702 (1988) 96. Dourish, P., Holmes, J., MacLean, A., Marqvardsen, P., Zbyslaw, A.: Freeﬂow: Mediating Between Representation and Action in Workﬂow Systems. In: Proceedings of the CM Conference on Computer Supported Cooperative Work (CSCW 1996), pp. 190–198 (1996)

392

References

97. Dumas, M., van der Aalst, W.M.P., ter Hofstede, A.H.M.: Process-Aware Information Systems: Bridging People and Software through Process Technology. Wiley & Sons, Chichester (2005) 98. Dwyer, M.B., Avrunin, G.S., Corbett, J.C.: Property Speciﬁcation Patterns for Finite-State Veriﬁcation. In: Ardis, M.A., Atlee, J.M. (eds.) Proceedings of the Second Workshop on Formal Methods in Software Practice (FMSP 1998), pp. 7–15. ACM Press, New York (1998) 99. Emerson, E.A.: Temporal and Modal Logic. In: van Leeuwen, J. (ed.) Handbook of Theoretical Computer Science. Formal Models and Sematics, vol. B. Elsevier and MIT Press (1990) ISBN 0-444-88074-7, 0-262-22039-3 100. Euzenat, J., Montanari, A.: Time granularity. In: Fisher, M., Gabbay, D., Vila, L. (eds.) Handbook of Temporal Reasoning in AI. Foundations of AI, vol. 1. Elsevier Science, Amsterdam (2004) 101. Ferreira, H.M., Ferreira, D.R.: An Integrated Life Cycle for Workﬂow Management Based on Learning and Planning. Cooperative Information Systems 15(4), 485–505 (2006) 102. Field, M.J., Lohr, K.N.: Clinical Practice Guidelines. Directions for a New Program. National Academy Press, Washington (1990) 103. Fisher, M., Dixon, C., Peim, M.: Clausal Remporal Resolution. ACM Transactions on Computational Logic 2(1), 12–56 (2001) 104. Foundation for Intelligent Physical Agents. FIPA Communicative Act Library Speciﬁcation, Interaction Protocol XC00037H. Technical report, FIPA Consortium (2001) 105. Fornara, N., Colombetti, M.: Operational Speciﬁcation of a CommitmentBased Agent Communication Language. In: Proceedings of the First International Joint Conference on Autonomous Agents & Multiagent Systems (AAMAS 2002), pp. 535–542. ACM Press, New York (2002) 106. F¨ orster, A., Engels, G., Schattkowsky, T., van der Straeten, R.: Veriﬁcation of Business Process Quality Constraints Based on Visual Process Patterns. In: First Joint IEEE/IFIP Symposium on Theoretical Aspects of Software Engineering (TASE 2007), pp. 197–208. IEEE Computer Society, Los Alamitos (2007) 107. Foster, H., Uchitel, S., Magee, J., Kramer, J.: Model-based Veriﬁcation of Web Service Composition. In: Proceedings of 18th IEEE International Conference on Automated Software Engineering (ASE), pp. 152–161 (2003) 108. Frankel, D.S.: Model Driven Architecture: Applying MDA to Enterprise Computing. John Wiley & Sons, Chichester (2003) 109. Fridsma, D.B.: Special Issue on Workﬂow Management and Clinical Guidelines. Journal of the American Medical Informatics Association 22(1) (2001) 110. Fr¨ uhwirth, T.: Theory and Practice of Constraint Handling Rules. Logic Programming 37(1-3), 95–138 (1998) 111. Fung, T.H., Kowalski, R.A.: The Iﬀ Proof Procedure for Abductive Logic Programming. Logic Programming 33(2), 151–165 (1997) 112. Gastin, P., Oddoux, D.: Fast LTL to B¨ uchi Automata Translation. In: Berry, G., Comon, H., Finkel, A. (eds.) CAV 2001. LNCS, vol. 2102, pp. 53–65. Springer, Heidelberg (2001) 113. Ghezzi, C., Mandrioli, D., Morzenti, A.: TRIO: A Logic Language for Executable Speciﬁcations of Real-Time Systems. Systems and Software 12(2), 107–123 (1990)

References

393

114. Ghose, A., Koliadis, G.: Auditing Business Process Compliance. In: Kr¨amer, B.J., Lin, K.-J., Narasimhan, P. (eds.) ICSOC 2007. LNCS, vol. 4749, pp. 169–180. Springer, Heidelberg (2007) 115. Giannakopoulou, D., Havelund, K.: Automata-Based Veriﬁcation of Temporal Properties on Running Programs. In: Proceedings of the 16th IEEE International Conference on Automated Software Engineering (ASE 2001), pp. 412–416. IEEE Computer Society, Los Alamitos (2001) 116. Goedertier, S.: Declarative Techniques for Modeling and Mining Business Processes. PhD thesis, Katholieke Universiteit Leuven (2008) 117. Goedertier, S., Vanthienen, J.: Designing Compliant Business Processes with Obligations and Permissions. In: Eder, J., Dustdar, S. (eds.) BPM Workshops 2006. LNCS, vol. 4103, pp. 5–14. Springer, Heidelberg (2006) 118. Goedertier, S., Vanthienen, J.: Compliant and Flexible Business Processes with Business Rules. In: Regev, G., Soﬀer, P., Schmidt, R. (eds.) Proceedings of the CAISE*06 Workshop on Business Process Modelling, Development, and Support (BPMDS 2006). CEUR Workshop Proceedings, vol. 236 (2007), CEUR-WS.org 119. G¨ oßler, G., Sifakis, J.: Composition for Component-Based Modeling. Science of Computer Programming 55(1-3), 161–183 (2005) 120. Governatori, G., Milosevic, Z., Sadiq, S.W.: Compliance Checking Between Business Processes and Business Contracts. In: Proceedings of the 10th IEEE International Enterprise Distributed Object Computing Conference (EDOC 2006), pp. 221–232. IEEE Computer Society, Los Alamitos (2006) 121. Greco, G., Guzzo, A., Pontieri, L., Sacc`a, D.: Discovering Expressive Process Models by Clustering Log Traces. IEEE Transactions on Knowledge and Data Engineering 18(8), 1010–1027 (2006) 122. Green, T.R.G.: Cognitive Dimensions of Notations. People and Computers V, 443–460 (1989) 123. Green, T.R.G., Petre, M.: Usability Analysis of Visual Programming Environments: a ‘Cognitive Dimensions’ Framework. Visual Languages and Computing 7, 131–174 (1996) 124. Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J.-J., Nielsen, H.F., Karmarkar, A., Lafon, Y.: Simple Object Access Protocol (SOAP) Version 1.2. Technical report, World Wide Web Consortium (W3C) Recommendation (2007), http://www.w3.org/TR/soap 125. G¨ unther, C.W., van der Aalst, W.M.P.: Fuzzy mining - adaptive process simpliﬁcation based on multi-perspective metrics. In: Alonso, G., Dadam, P., Rosemann, M. (eds.) BPM 2007. LNCS, vol. 4714, pp. 328–343. Springer, Heidelberg (2007) 126. Gupta, G., Pontelli, E.: A Constraint-Based Approach for Speciﬁcation and Veriﬁcation of Real-Time Systems. In: Proceedings of the 18th IEEE Realtime Systems Symposium (RTSS 1997), pp. 230–239. IEEE Computer Society, Los Alamitos (1997) 127. Gupta, G., Bansal, A., Min, R., Simon, L., Mallya, A.: Coinductive Logic Programming and Its Applications. In: Dahl, V., Niemel¨a, I. (eds.) ICLP 2007. LNCS, vol. 4670, pp. 27–44. Springer, Heidelberg (2007) 128. Hall´e, S., Villemaire, R.: Runtime Monitoring of Web Service Choreographies Using Streaming XML. In: Proceedings of to the 24th Annual ACM Symposium on Applied Computing, ACM SAC 2009 (2009)

394

References

129. Halpern, J.Y., Vardi, M.Y.: Model Checking vs. Theorem Proving: A Manifesto. In: Artiﬁcial Intelligence and Mathematical Theory of Computation: Papers in Honor of John McCarthy, pp. 151–176 (1991) 130. Hartshorn, C., Weiss, P.: Collected Papers of Charles Sanders Peirce, vol. 2. Harvard University Press, Cambridge (1965) 131. Havelund, K., Rosu, G.: Testing Linear Temporal Logic Formulae on Finite Execution Traces. Technical Report TR 01-08, RIACS Technical Report (2001) 132. Hewitt, C.: Open Information Systems Semantics for Distributed Artiﬁcial Intelligence. Artiﬁcial Intelligence 47(1-3), 79–106 (1991) 133. Holzmann, G.J.: The SPIN Model Checker: Primer and Reference Manual. Addison-Wesley, Reading (2003) 134. Huhns, M.N., Singh, M.P.: Service-Oriented Computing: Key Concepts and Principles. IEEE Internet Computing 9(1), 75–81 (2005) 135. Jaﬀar, J., Maher, M.J.: Constraint Logic Programming: a Survey. Logic Programming (19-20), 503–582 (1994) 136. Jaﬀar, J., Michaylov, S., Stuckey, P.J., Yap, R.H.C.: The CLP(R) Language and System. ACM Transactions on Programming Languages and Systems 14(3), 339–395 (1992) 137. Jaﬀar, J., Maher, M.J., Marriott, K., Stuckey, P.J.: The Semantics of Constraint Logic Programs. Logic Programming 37(1-3), 1–46 (1998) 138. Joeris, G.: Decentralized and Flexible Workﬂow Enactment Based on Task Coordination Agents. In: Wangler, B., Bergman, L.D. (eds.) CAiSE 2000. LNCS, vol. 1789, pp. 41–62. Springer, Heidelberg (2000) 139. Jouault, F., Allilaire, F., B´ezivin, J., Kurtev, I.: ATL: A Model Transformation Tool. Science of Computer Programming 72(1-2), 31–39 (2008) 140. Kakas, A.C., Kowalski, R.A., Toni, F.: Abductive Logic Programming. Logic and Computation 2(6), 719–770 (1993) 141. Kavantzas, N., Burdett, D., Ritzinger, G., Fletcher, T., Lafon, Y., Barreto, C.: Web Services Choreography Description Language Version 1.0. Technical report, World Wide Web Consortium (W3C) Candidate Recommendation (2005) 142. Kindler, E.: Safety and Liveness Properties: a Survey. EATCS-Bulletin 53 (1994) 143. Kowalski, R.A.: Predicate Logic as a Programming Language. Information Processing 74 (1974) 144. Kowalski, R.A.: Algorithm = Logic + Control. Communications of the ACM 22(7), 424–436 (1979) 145. Kowalski, R.A., Sadri, F.: Towards a Uniﬁed Agent Architecture that Combines Rationality with Reactivity. In: Pedreschi, D., Zaniolo, C. (eds.) LID 1996. LNCS, vol. 1154, pp. 137–149. Springer, Heidelberg (1996) 146. Kowalski, R.A., Sergot, M.J.: A Logic-Based Calculus of Events. New Generation Computing 4(1), 67–95 (1986) 147. Kunen, K.: Negation in Logic Programming. In: Logic Programming, vol. 4, pp. 289–308 (1987) 148. Kupferman, O., Piterman, N., Vardi, M.Y.: From Liveness to Promptness. In: Damm, W., Hermanns, H. (eds.) CAV 2007. LNCS, vol. 4590, pp. 406–419. Springer, Heidelberg (2007)

References

395

149. Lamma, E., Mello, P., Montali, M., Riguzzi, F., Storari, S.: Inducing Declarative Logic-Based Models from Labeled Traces. In: Alonso, G., Dadam, P., Rosemann, M. (eds.) BPM 2007. LNCS, vol. 4714, pp. 344–359. Springer, Heidelberg (2007) 150. Lamma, E., Mello, P., Riguzzi, F., Storari, S.: Applying Inductive Logic Programming to Process Mining. In: Blockeel, H., Ramon, J., Shavlik, J., Tadepalli, P. (eds.) ILP 2007. LNCS (LNAI), vol. 4894, pp. 132–146. Springer, Heidelberg (2008) 151. Larsen, K.G., Pettersson, P., Yi, W.: UPPAAL in a Nutshell. International Journal on Software Tools for Technology Transfer 1(1-2), 134–152 (1997) 152. Leymann, F., Roller, D.: Production Workﬂow - Concepts and Techniques. Prentice-Hall, Englewood Cliﬀs (2000) 153. Liu, X., M¨ uller, S., Xu, K.: A Static Compliance-Checking Framework for Business Process Models - References. IBM Systems Journal 46, 335–362 (2007) 154. Lloyd, J.W.: Foundations of Logic Programming, 2nd edn. Springer, Heidelberg (1987) 155. Luccarini, L., Bragadin, G.L., Colombini, G., Mancini, M., Mello, P., Montali, M., Sottara, D.: Formal Veriﬁcation of Wastewater Treatment Processes Using Events Detected From Continuous Signals by Means of Artiﬁcial Neural Networks. Case Study: SBR Plant. Environmental Modelling and Software 25(5), 648–660 (2010) 156. Luckham, D.: The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems. Addison-Wesley, Reading (2001) 157. Ly, L.T., Rinderle, S., Dadam, P.: Integration and Veriﬁcation of Semantic Constraints in Adaptive Process Management Systems. Data and Knowledge Engineering 64(1), 3–23 (2008) 158. Mahbub, K., Spanoudakis, G.: Run-Time Monitoring of Requirements for Systems Composed of Web-Services: Initial Implementation and Evaluation Experience. In: Proeedings of the 3rd IEEE International Conference on Web Services (ICWS 2005), pp. 257–265. IEEE Computer Society, Los Alamitos (2005) 159. Mahbub, K., Spanoudakis, G.: Monitoring WS-Agreements: An Event Calculus-Based Approach. In: Baresi, L., Nitto, E.D. (eds.) Test and Analysis of Web Services, pp. 265–306. Springer, Heidelberg (2007) 160. Marques-Silva, J.: Model Checking with Boolean Satisﬁability. Algorithms 63(1-3), 3–16 (2008) 161. Martens, A.: Analyzing Web Service Based Business Processes. In: Cerioli, M. (ed.) FASE 2005. LNCS, vol. 3442, pp. 19–33. Springer, Heidelberg (2005) 162. Martens, A.: Consistency between Executable and Abstract Processes. In: Proceedings of International IEEE Conference on e-Technology, e-Commerce, and e-Services (EEE 2005), pp. 60–67. IEEE Computer Society, Los Alamitos (2005) 163. Martin, D., Paolucci, M., McIlraith, S., Burstein, M., McDermott, D., McGuinness, D., Parsia, B., Payne, T., Sabou, M., Solanki, M., Srinivasan, N., Sycara, K.: Bringing Semantics to Web Services: the OWL-S Approach. In: Cardoso, J., Sheth, A., Kalinichenko, L., Curbera, F. (eds.) SWSWPC 2004. LNCS, vol. 3387, pp. 26–42. Springer, Heidelberg (2005)

396

References

164. Martin, D.L., Burstein, M.H., McDermott, D.V., McIlraith, S.A., Paolucci, M., Sycara, K.P., McGuinness, D.L., Sirin, E., Srinivasan, N.: Bringing Semantics to Web Services with OWL-S. In: Proceedings of the 16th International World Wide Web Conference (WWW 2007), pp. 243–277 (2007) 165. Massuthe, P., Reisig, W., Schmidt, K.: An Operating Guideline Approach to the SOA. In: Proceedings of the 2nd South-East European Workshop on Formal Methods 2005, SEEFM 2005 (2005) 166. McCarthy, J., Hayes, P.J.: Some Philosophical Problems From the StandPoint of Artiﬁcial Intelligence. Machine Intelligence 4, 463–502 (1969) 167. Mecella, M., Presicce, F.P., Pernici, B.: Modeling E-service Orchestration through Petri Nets. In: Hogrefe, D., Wiles, A. (eds.) TestCom 2003. LNCS, vol. 2644, pp. 38–47. Springer, Heidelberg (2003) 168. Midgley, G.C.J.: Linguistic Rules. In: Proceedings of the Aristotelian Society. New Series, vol. 59, pp. 271–290. Blackwell Publishing, Malden (1959) 169. Miksch, S., Shahar, Y., Johnson, P.: Asbru: a Task-Speciﬁc, Intention-Based, and Time-Oriented Language for Representing Skeletal Plans. In: Proceedings of the 7th Workshop on Knowledge Engeneering Methods and Languages, pp. 9–20 (1997) 170. Milner, R., Parrow, J., Walker, D.: A Calculus of Mobile Processes. Information and Computation 100(1), 1–40 (1992) 171. Montali, M.: Speciﬁcation and Veriﬁcation of Declarative Open Interaction Models: a Logic-Based Approach. PhD thesis, University of Bologna (2009) 172. Montali, M., Torroni, P., Alberti, M., Chesani, F., Gavanelli, M., Lamma, E., Mello, P.: Veriﬁcation from Declarative Speciﬁcations Using Logic Programming. In: de la Banda, M.G., Pontelli, E. (eds.) ICLP 2008. LNCS, vol. 5366, pp. 440–454. Springer, Heidelberg (2008) 173. Montali, M., Pesic, M., van der Aalst, W.M.P., Chesani, F., Mello, P., Storari, S.: Declarative Speciﬁcation and Veriﬁcation of Service Choreographies. ACM Transactions on the Web 4(1) (2010) 174. Montali, M., Torroni, P., Alberti, M., Chesani, F., Lamma, E., Mello, P.: Abductive Logic Programming as an Eﬀective Technology for the Static Veriﬁcation of Declarative Business Processes. Technical report, DEIS - University of Bologna (2010) 175. Moschoyiannis, S., Shields, M.W.: A Set-Theoretic Framework for Component Composition. Fundamenta Informaticae 59(4), 373–396 (2004) 176. Moser, O., Rosenberg, F., Dustdar, S.: Non-intrusive monitoring and service adaptation for ws-bpel. In: Huai, J., Chen, R., Hon, H.-W., Liu, Y., Ma, W.-Y., Tomkins, A., Zhang, X. (eds.) Proceedings of the 17th International Conference on World Wide Web (WWW 2008), pp. 815–824. ACM, New York (2008) 177. Muggleton, S.: Inductive Logic Programming. New Generation Computing 8(4), 295–318 (1991) 178. Muggleton, S., Raedt, L.D.: Inductive Logic Programming: Theory and Methods. Logic Programming 19/20, 629–679 (1994) 179. M¨ uhl, G., Fiege, L., Pietzuch, P.: Distributed Event-Based Systems. Springer, Heidelberg (2006) 180. Mulyar, N., van der Aalst, W.M.P., Peleg, M.: A Pattern-based Analysis of Clinical Computer-Interpretable Guideline Modelling Languages. Journal of the American Medical Informatics Association 14, 781–787 (2007)

References

397

181. Mulyar, N., Pesic, M., van der Aalst, W.M.P., Peleg, M.: Declarative and Procedural Approaches for Modelling Clinical Guidelines: Addressing Flexibility Issues. In: ter Hofstede, A.H.M., Benatallah, B., Paik, H.-Y. (eds.) BPM Workshops 2007. LNCS, vol. 4928, pp. 335–346. Springer, Heidelberg (2008) 182. Naumovich, G., Clarke, L.A.: Classifying Properties: an Alternative to the Safety-Liveness Classiﬁcation. In: Proceedings of the 8th ACM SIGSOFT International Symposium on Foundations of Software Engineering: 21st Century Applications, pp. 159–168. ACM Press, New York (2000) 183. OASIS Web Services Business Process Execution Language (WSBPEL) Technical Committee. Web Service Business Process Execution Language Version 2.0. Technical report, OASIS Standard (2007) 184. Object Management Group. Business Process Modeling Notation Version 1.1. Technical report, Object Management Group Final Adopted Speciﬁcation (2008) 185. Object Management Group. OMG Uniﬁed Modeling Language (OMG UML), Superstructure. Version 2.2. Technical report, Object Management Group Standard (2009) 186. Ouyang, C., Verbeek, E., van der Aalst, W.M.P., Breutel, S., Dumas, M., ter Hofstede, A.H.M.: Formal semantics and analysis of control ﬂow in WS-BPEL. Science of Computer Programming 67(2-3), 162–198 (2007) 187. Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F.: Service-Oriented Computing: a Research Roadmap. Cooperative Information Systems 17(2), 223–255 (2008) 188. Pearl, J.: Embracing Causality in Formal Reasoning. In: Proceedings of the National Conference on Artiﬁcial Intelligence (AAAI 1987), pp. 369–373 (1987) 189. Peleg, M., Tu, S., Bury, J., Ciccarese, P., Jones, N., Fox, J., Greenes, R.A., Hall, R., Johnson, P., Jones, N., Kumar, A., Miksch, S., Quaglini, S., Seyfang, A., Shortliﬀe, E.H., Stefanelli, M.: Comparing Computer-Interpretable Guideline Models: A Case-Study Approach. Journal of the American Medical Informatics Association 10(1), 52–68 (2003) 190. Peltz, C.: Web Services Orchestration and Choreography. IEEE Computer 36(10), 46–52 (2003) 191. Pesic, M.: Constraint-Based Workﬂow Management Systems: Shifting Controls to Users. PhD thesis, Beta Research School for Operations Management and Logistics, Eindhoven (2008) 192. Pesic, M., van der Aalst, W.M.P.: A Declarative Approach for Flexible Business Processes Management. In: Eder, J., Dustdar, S. (eds.) BPM Workshops 2006. LNCS, vol. 4103, pp. 169–180. Springer, Heidelberg (2006) 193. Pesic, M., Schonenberg, H., van der Aalst, W.M.P.: DECLARE: Full Support for Loosely-Structured Processes. In: Proceedings of the 11th IEEE International Enterprise Distributed Object Computing Conference (EDOC 2007), pp. 287–300. IEEE Computer Society, Los Alamitos (2007) 194. Pesic, M., Schonenberg, M.H., Sidorova, N., van der Aalst, W.M.P.: ConstraintBased Workﬂow Models: Change Made Easy. In: Meersman, R., Tari, Z. (eds.) OTM 2007, Part I. LNCS, vol. 4803, pp. 77–94. Springer, Heidelberg (2007) 195. Pesic, M., Bosnacki, D., van der Aalst, W.M.: Enacting Declarative Languages using LTL: Avoiding Errors and Improving Performance. Computer Science Report 09-14, Technische Universiteit Eindhoven (2009)

398

References

¨ 196. Pissinou, N., Snodgrass, R.T., Elmasri, R., Mumick, I.S., Ozsu, T., Pernici, B., Segev, A., Theodoulidis, B., Dayal, U.: Towards an Infrastructure for Temporal Databases: Report of an Invitational ARPA/NSF Workshop. ACM SIGMOD Record 23(1), 35–51 (1994) 197. Ponnekanti, S.R., Fox, A.: Interoperability Among Independently Evolving Web Services. In: Jacobsen, H.-A. (ed.) Middleware 2004. LNCS, vol. 3231, pp. 331–351. Springer, Heidelberg (2004) 198. Pradella, M., Morzenti, A., Pietro, P.S.: Reﬁning Real-Time System Speciﬁcations through Bounded Model- and Satisﬁability-Checking. In: Proceedings of the 23rd IEEE/ACM International Conference on Automated Software Engineering (ASE 2008), pp. 119–127. IEEE Computer Society, Los Alamitos (2008) 199. Reichert, M., Rinderle, S., Kreher, U., Dadam, P.: Adaptive Process Management with ADEPT2. In: Proceedings of the 21st International Conference on Data Engineering (ICDE 2005), pp. 1113–1114. IEEE Computer Society, Los Alamitos (2005) 200. Reiter, R.: On Closed-Word Data Bases. In: Gallaire, H., Minker, J. (eds.) Logic and Data Bases, pp. 55–76. Plenum Press, New York (1978) 201. Rescher, N., Urquhart, A.: Temporal Logic. Springer, Heidelberg (1971) 202. Roman, D., Kifer, M.: Semantic Web Service Choreography: Contracting and Enactment. In: Sheth, A.P., Staab, S., Dean, M., Paolucci, M., Maynard, D., Finin, T., Thirunarayan, K. (eds.) ISWC 2008. LNCS, vol. 5318, pp. 550–566. Springer, Heidelberg (2008) 203. Roman, D., Keller, U., Lausen, H., de Bruijn, J., Lara, R., Stollberg, M., Polleres, A., Feier, C., Bussler, C., Fensel, D.: Web Service Modeling Ontology. Applied Ontology 1(1), 77–106 (2005) 204. Ross, R.G.: Business Rule Concepts: Getting to the Point of Knowledge. Business Rule Solutions, LLC (2009) 205. Rouached, M., Fdhila, W., Godart, C.: A Semantical Framework to Engineering WSBPEL Processes. Information Systems and E-Business Management 7(2), 223–250 (2008) 206. Rozier, K.Y., Vardi, M.Y.: LTL satisﬁability checking. In: Boˇsnaˇcki, D., Edelkamp, S. (eds.) SPIN 2007. LNCS, vol. 4595, pp. 149–167. Springer, Heidelberg (2007) 207. Rozinat, A., van der Aalst, W.: Conformance Testing: Measuring the Fit and Appropriateness of Event Logs and Process Models. In: Bussler, C.J., Haller, A. (eds.) BPM 2005. LNCS, vol. 3812, pp. 163–176. Springer, Heidelberg (2006) 208. Russo, A., Miller, R., Nuseibeh, B., Kramer, J.: An Abductive Approach for Analysing Event-Based Requirements Speciﬁcations. In: Stuckey, P.J. (ed.) ICLP 2002. LNCS, vol. 2401, pp. 22–37. Springer, Heidelberg (2002) 209. Sadiq, S.W., Orlowska, M.E., Sadiq, W.: Speciﬁcation and Validation of Process Constraints for Flexible Workﬂows. Information Systems 30(5), 349–378 (2005) 210. Sadiq, S.W., Governatori, G., Namiri, K.: Modeling Control Objectives for Business Process Compliance. In: Alonso, G., Dadam, P., Rosemann, M. (eds.) BPM 2007. LNCS, vol. 4714, pp. 149–164. Springer, Heidelberg (2007) 211. Sadri, F., Kowalski, R.A.: Variants of the Event Calculus. In: Sterling, L. (ed.) Proceedings of the 12th International Conference on Logic Programming (ICLP 1995), pp. 67–81. MIT Press, Cambridge (1995)

References

399

212. Sahai, A., Machiraju, V., Sayal, M., Jin, L.J., Casati, F.: Automated sla monitoring for web services. In: Feridun, M., Kropf, P.G., Babin, G. (eds.) DSOM 2002. LNCS, vol. 2506, pp. 28–41. Springer, Heidelberg (2002) 213. Sartor, G.: Legal Reasoning. Treatise, vol. 5. Kluwer, Dordrecht (2004) 214. Schlingloﬀ, B.H., Martens, A., Schmidt, K.: Modeling and Model Checking Web Services. Electronic Notes in Theoretical Computer Science: Issue on Logic and Communication in Multi-Agent Systems 126, 3–26 (2005) 215. Schonenberg, H., Mans, R., Russell, N., Mulyar, N., van der Aalst, W.M.P.: Towards a Taxonomy of Process Flexibility. In: Bellahsene, Z., Woo, C., Hunt, E., Franch, X., Coletta, R. (eds.) Proceedings of the Forum at the CAiSE 2008 Conference. CEUR Workshop Proceedings, vol. 344, pp. 81–84 (2008) 216. Schreiber, F.A.: Is Time a Real Time? An Overview of Time Ontology in Informatics. Real Time Computing F 127, 283–307 (1994) 217. Searle, J.: Speech Acts. Cambridge University Press, Cambridge (1969) 218. Shanahan, M.: The Event Calculus Explained. In: Wooldridge, M., Veloso, M.M. (eds.) Artiﬁcial Intelligence Today. LNCS (LNAI), vol. 1600, pp. 409– 430. Springer, Heidelberg (1999) 219. Shiﬀman, R.N.: Representation of Clinical Practice Guidelines in Conventional and Augmented Decision Tables. Journal of the American Medical Informatics Association 4(5), 382–393 (1997) 220. Simmonds, J., Gan, Y., Chechik, M., Nejati, S., O’Farrell, B., Litani, E., Waterhouse, J.: Runtime Monitoring of Web Service Conversations. IEEE Transactions on Services Computing 2(3), 223–244 (2009) 221. Singh, M.P.: Agent Communication Languages: Rethinking the Principles. IEEE Computer 31(12) (1998) 222. Singh, M.P.: A social semantics for agent communication languages. In: Dignum, F.P.M., Greaves, M. (eds.) Issues in Agent Communication. LNCS, vol. 1916, pp. 31–45. Springer, Heidelberg (2000) 223. Singh, M.P., Chopra, A.K., Desai, N.: Commitment-Based Service-Oriented Architecture. IEEE Computer 42(11), 72–79 (2009) 224. Sistla, A.P., Vardi, M.Y., Wolper, P.: The Complementation Problem for B¨ uchi Automata with Appplications to Temporal Logic. Jorunal of Theoretical Computer Science 49, 217–237 (1987) 225. Sottara, D., Luccarini, L., Mello, P.: AI Techniques for Waste Water Treatment Plant Control Case Study: Denitriﬁcation in a Pilot-Scale SBR. In: Apolloni, B., Howlett, R.J., Jain, L. (eds.) KES 2007, Part I. LNCS (LNAI), vol. 4692, pp. 639–646. Springer, Heidelberg (2007) 226. Spanoudakis, G., Mahbub, K.: Non-Intrusive Monitoring of Service-Based Systems. Cooperative Information Systems 15(3), 325–358 (2006) 227. Sterling, L., Shapiro, E.: The Art of Prolog, 2nd edn. MIT Press, Cambridge (1994) 228. ten Teije, A., Marcos, M., Balser, M., van Croonenborg, J., Duelli, C., van Harmelen, F., Lucas, P., Miksch, S., Reif, W., Rosenbrand, K., Seyfang, A.: Improving Medical Protocols by Formal Methods. Artiﬁcial Intelligence in Medicine 36(3), 193–209 (2006) 229. Ten Teije, A., Miksch, S., Lucas, P. (eds.): Computer-based Medical Guidelines and Protocols: A Primer and Current Trends. Studies in Health Technology and Informatics, vol. 139. IOS Press, Amsterdam (2008)

400

References

230. ter Beek, M.H., Massink, M., Latella, D., Gnesi, S., Forghieri, A., Sebastianis, M.: A Case Study on the Automated Veriﬁcation of Groupware Protocols. In: Roman, G.C., Griswold, W.G., Nuseibeh, B. (eds.) Proceedings of the 27th International Conference on Software Engineering (ICSE 2005), pp. 596–603. ACM, New York (2005) 231. ter Hofstede, A.H.M., van der Aalst, W.M.P., Adams, M., Russell, N.: Modern Business Process Automation - YAWL and its Support Environment. Springer, Heidelberg (2010) 232. Terenziani, P., Molino, G., Torchio, M.: A Modular Approach for Representing and Executing Clinical Guidelines. Artiﬁcial Intelligence in Medicine 23(3), 249–276 (2001) 233. Terenziani, P., Montani, S., Bottrighi, A., Torchio, M., Molino, G., Anselma, L., Correndo, G.: Applying Artiﬁcial Intelligence to Clinical Guidelines: The GLARE Approach. In: Cappelli, A., Turini, F. (eds.) AI*IA 2003. LNCS, vol. 2829, pp. 536–547. Springer, Heidelberg (2003) 234. Torroni, P., Chesani, F., Mello, P., Montali, M.: Social commitments in time: Satisﬁed or compensated. In: Baldoni, M., Bentahar, J., van Riemsdijk, M.B., Lloyd, J. (eds.) DALT 2009. LNCS, vol. 5948, pp. 228–243. Springer, Heidelberg (2010) 235. Torroni, P., Chesani, F., Yolum, P., Gavanelli, M., Singh, M.P., Lamma, E., Alberti, M., Mello, P.: Modelling Interactions via Commitments and Expectations. In: Handbook of Research on Multi-Agent Systems: Semantics and Dynamics of Organizational Models. IGI Global (2009) 236. UDDI Committee. Universal Description, Discovery and Integration (UDDI) Version 2.04 API Speciﬁcation. Technical report, OASIS Standard (2002) 237. van der Aalst, W., de Beer, H., van Dongen, B.: Process Mining and Veriﬁcation of Properties: An Approach based on Temporal Logic. In: Meersman, R., Tari, Z. (eds.) OTM 2005. LNCS, vol. 3760, pp. 130–147. Springer, Heidelberg (2005) 238. van der Aalst, W., van Dongen, B., G¨ unther, C., Mans, R., de Medeiros, A.A., Rozinat, A., Rubin, V., Song, M., Verbeek, H., Weijters, A.: ProM 4.0: Comprehensive Support for Real Process Analysis. In: Kleijn, J., Yakovlev, A. (eds.) ICATPN 2007. LNCS, vol. 4546, pp. 484–494. Springer, Heidelberg (2007) 239. van der Aalst, W.M., ter Hofstede, A.H., Kiepuszewski, B., Barros, A.P.: Workﬂow Patterns. Distributed and Parallel Databases 14(1), 5–51 (2003) 240. van der Aalst, W.M.P.: Veriﬁcation of Workﬂow Nets. In: Az´ema, P., Balbo, G. (eds.) ICATPN 1997. LNCS, vol. 1248, pp. 407–426. Springer, Heidelberg (1997) 241. van der Aalst, W.M.P., Jablonski, S.: Dealing with Workﬂow Change: Identiﬁcation of Issues and Solutions. Computer Systems, Science, and Engineering 15(5), 267–276 (2000) 242. van der Aalst, W.M.P., Pesic, M.: DecSerFlow: Towards a Truly Declarative Service Flow Language. In: Bravetti, M., N´ un ˜ez, M., Zavattaro, G. (eds.) WSFM 2006. LNCS, vol. 4184, pp. 1–23. Springer, Heidelberg (2006) 243. van der Aalst, W.M.P., Dumas, M., ter Hofstede, A.H.M.: Web Service Composition Languages: Old Wine in New Bottles? In: Chroust, G., Hofer, C. (eds.) Proceeding of the 29th EUROMICRO Conference: New Waves in System Architecture, pp. 298–305. IEEE Computer Society, Los Alamitos (2003)

References

401

244. van der Aalst, W.M.P., van Dongen, B.F., Herbst, J., Maruster, L., Schimm, G., Weijters, A.J.M.M.: Workﬂow Mining: A Survey of Issues and Approaches. Data and Knowledge Engineering 47(2), 237–267 (2003) 245. van der Aalst, W.M.P., Weijters, T., Maruster, L.: Workﬂow Mining: Discovering Process Models from Event Logs. IEEE Transactions on Knowledge and Data Engineering 16(9), 1128–1142 (2004) 246. van der Aalst, W.M.P., Dumas, M., ter Hofstede, A.H.M., Russell, N., Verbeek, H.M.W., Wohed, P.: Life After BPEL? In: Bravetti, M., Kloul, L., Zavattaro, G. (eds.) EPEW/WS-EM 2005. LNCS, vol. 3670, pp. 35–50. Springer, Heidelberg (2005) 247. van der Aalst, W.M.P., Reijers, H.A., Weijters, A.J.M.M., van Dongen, B.F., de Medeiros, A.K.A., Song, M., Verbeek, H.M.W.E.: Business Process Mining: An Industrial Application. Information Systems 32(5), 713–732 (2007) 248. van der Aalst, W.M.P., Dumas, M., Ouyang, C., Rozinat, A., Verbeek, E.: Conformance Checking of Service Behavior. ACM Transactions on Internet Technologies 8(3) (2008) 249. van der Aalst, W.M.P., Pesic, M., Schonenberg, H.: Declarative workﬂows: Balancing between ﬂexibility and support. Computer Science - R&D 23(2), 99–113 (2009) 250. van der Aalst, W.M.P., van Hee, K.M., Martijn, J., van der Werf, E.M., Verdonk, M.: Auditing 2.0: Using Process Mining to Support Tomorrow’s Auditor. IEEE Computer 43(3), 90–93 (2010) 251. van Dongen, B.F.: Process Mining and Veriﬁcation. PhD thesis, Eindhoven University of Technology (2007) 252. van Dongen, B.F., van der Aalst, W.M.P.: Multi-phase Process Mining: Building Instance Graphs. In: Atzeni, P., Chu, W., Lu, H., Zhou, S., Ling, T.-W. (eds.) ER 2004. LNCS, vol. 3288, pp. 362–376. Springer, Heidelberg (2004) 253. van Dongen, B.F., van der Aalst, W.M.P.: A Meta Model for Process Mining Data. In: Castro, J., Teniente, E. (eds.) Proceedings of the CAiSE 2005 Workshops EMOI-INTEROP Workshop, vol. 160, pp. 309–320. FEUP Edi¸co ˜es (2005) 254. van Hoeve, W.J.: The AllDiﬀerent Constraint: a Survey. In: Sixth Annual Workshop of the ERCIM Working Group on Constraints (2001) 255. Vardi, M.Y.: Branching vs. Linear Time: Final Showdown. In: Margaria, T., Yi, W. (eds.) TACAS 2001. LNCS, vol. 2031, pp. 1–22. Springer, Heidelberg (2001) 256. Veiga, G.M., Ferreira, D.R.: Understanding Spaghetti Models with Sequence Clustering for ProM. In: Proceedings of BPM 2009 Workshops. LNBIP. Springer, Heidelberg (2009) 257. Vila, L.: A Survey on Temporal Reasoning in Artiﬁcial Intelligence. AI Communication 7(1), 4–28 (1994) 258. Wainer, J., de Lima Bezerra, F.: Constraint-Based Flexible Workﬂows. In: Favela, J., Decouchant, D. (eds.) CRIWG 2003. LNCS, vol. 2806, pp. 151–158. Springer, Heidelberg (2003) 259. Weber, B., Rinderle, S., Reichert, M.: Change Patterns and Change Support Features in Process-Aware Information Systems. In: Krogstie, J., Opdahl, A.L., Sindre, G. (eds.) CAiSE 2007 and WES 2007. LNCS, vol. 4495, pp. 574–588. Springer, Heidelberg (2007)

402

References

260. Weiss, G.: Multiagent Systems - A Modern Approach to Distributed Artiﬁcial Intelligence. MIT Press, Cambridge (1999) 261. Weske, M.: Business Process Management: Concepts, Languages, Architectures. Springer, Heidelberg (2007) 262. White, S.A.: Introduction to BPMN. BPTrends (2004) 263. White, S.A.: Business Process Modeling Notation Speciﬁcation 1.0. Technical report, OMG (2006) 264. Wooldridge, M.: An Introduction to MultiAgent Systems, 2nd edn. Wiley & Sons, Chichester (2009) 265. Workﬂow Management Coalition. Process Deﬁnition Interface – XML Process Deﬁnition Language, 2.1a edn. (2008) 266. Wright, G.H.: Deontic logic. Mind 60, 1–15 (1951) 267. Xanthakos, I.: Semantic Integration of Information by Abduction. PhD thesis, Imperial College London (2003) 268. Yolum, P., Singh, M.P.: Flexible Protocol Speciﬁcation and Execution: Applying Event Calculus Planning Using Commitments. In: Proceedings of the First International Joint Conference on Autonomous Agents & Multiagent Systems (AAMAS 2002), pp. 527–534. ACM Press, New York (2002) 269. Zaha, J.M., Barros, A.P., Dumas, M., ter Hofstede, A.H.M.: Let’s Dance: A Language for Service Behavior Modeling. In: Meersman, R., Tari, Z. (eds.) OTM 2006. LNCS, vol. 4275, pp. 145–162. Springer, Heidelberg (2006) 270. Zhang, I.: Economic Consequences of the Sarbanes-Oxley Act of 2002. University of Minnesota - Twin Cities, 5 (2002)

Index

∃-entailment, see ConDec, property, ∃-entailment ∀-entailment, see ConDec, property, ∀-entailment ∃-entailment, 251 ∃-entailmentM C , 268 ∀-entailment, 251 ∀-entailmentM C , 268 a-posteriori veriﬁcation, 3, 5, 43 a-priori compliance veriﬁcation, 186–187 abduction, 96 integrity constraint, 97 Abductive Logic Programming, 95, 98, 170, 311, 313, 372 abductive explanation, 98 abductive logic program, 98 goal reformulation, 99 abductive reasoning, 96, 97 activity, 3, 12, 155, 347 instance, 148 non atomic, 139, 146, 148, 159 life cycle, 148–149 acyclicity, 217 acyclicity condition, 216 Adept semantic constraint, 168 dependency, 168 mutual exclusion, 168 aerobic switch, 360 agent, 34, 78 autonomy, 34 heterogeneity, 34 pro-activeness, 34

reactivity, 34 social ability, 34 Agent UML, 1, 35, 100, 280 all diﬀerent, see Constraint Logic Programming, all diﬀerent ALP, see Abductive Logic Programming α-algorithm, 373 Asbru, 167 Aspect Oriented Programming, 368, 369 Astro, 369 ATL, 382 audit trail, see execution trace auditing, 186, 381 AUML, see Agent UML backward reasoning, 93 Basic Medical Knowledge, 36–38, 167 behavioral equivalence, 134 behavioral interface, 43, 190, 289 boundedness, 217 BP, see Business Process BPEL, 1, 22, 27, 29, 30, 282, 368–371, 374 BPM, see Business Process Management BPMN, 1, 22, 30, 281, 282, 333 collaborative diagram, 30, 32 BPMN-Q, 281 BPSL, 282 BuildUniversalModel, 269 Business Activity Monitoring, 367 business constraint, 15 CLIMB textual

404

Index

grammar, 347 negative, 20 positive, 20 template, 349 business contract, 15, 16, 186, 281, 291 Business Intelligence, 355 Business Process, 20, 79, 186 life cycle, 21 Business Process Management, 1, 20–24, 44, 79, 163–166, 335 constraint-based, 163–164 business rule, 15, 23, 38, 281 B¨ uchi automaton, 265, 273, 278, 279, 371 cervical cancer, 357 screening process, 357 Chamaleon, 165 choice, 151 choreography, see service, choreography CHR, 227 chronometry, see time, chronometry CigDec, 167 Clark Equational Theory, 103 clausal temporal resolution, 280 CLIMB, 2, 44, 77–114, 282–283 ∃-entailment, 232 ∀-entailment, 232 architecture, 45 comparison with Deontic Logic, 171 compliance, 105–108 current time, 296, 336 E-consistency, 105 event, 79 event occurrence, 79–81 execution trace, 80 expectation, 78, 83–85 intensional, 105 negative, 83, 84 positive, 83, 84 ﬂexibility by change, 372 formal properties, 109–114 compositionality, 110 equivalence, 109 replaceability, 113 fulﬁllment, 202 happened event, see CLIMB, event occurrence instance, 101

integrity constraint, 78, 85 complementary, 234–235 syntax, 85–86 knowledge base, 78, 90–93 extensional, 90 intensional, 90 syntax, 91 language, 79–95 life cycle, 41 external, 43–44 internal, 42–43 model acyclic, 217 property, 230 rule, see CLIMB, integrity constraint semantics, 95–108 abductive explanation, 102 E-consistency, 202, 211–212, 296 fulﬁllment, 106 speciﬁcation, 99 Clinical Guideline, 1, 36–39, 163, 166–168, 291 semi-open, 38–39 Closed World Assumption, 208 CLP, see Constraint Logic Programming cognitive dimensions, 47, 64 abstractions, 64 closeness of mapping, 64 consistency, 65 hidden dependencies, 66, 180, 301 premature commitment, 65 progressive evaluation, 67 Coinductive Logic Programming, 381 commitment, see social commitment compact, 120 compaction function, see compact compatibility veriﬁcation, see static veriﬁcation, compatibility compensation, 5 Complex Event Processing, 94 compliance, 3, 14–16, 39, 77, 96, 107, 186 rules, 15 Component-Based Software Engineering, 190 component, 283 Computation Tree Logic, 280 Computational Logic, 2, 6, 44, 307, 379, 380

Index computee, 78 Concurrent Transaction Logic, 285, 372 enactment, 373 ConDec, 2, 44, 47–75 a-priori compliance, 187 activity non executable, 336 branching constraint, 56–57 translation into CLIMB, 128–129 choice constraint, 49–51 translation into CLIMB, 123–125 comparison with commitments, 171 compatibility, 189 strong, 195 trivial, 189 compatibility veriﬁcation, see static veriﬁcation, compatibility compensation, 305, 331–332 compliance, 49, 53, 56 CLIMB, 117 LTL, 72 with optional constraints, 328–329 component, 190 composite model, 187–189 constraint equivalence, 130 constraint state forbid, 326 satisﬁed, 326 declarativeness, 47 existence constraint, 49–50 translation into CLIMB, 121–123 extensibility, 380 ﬁnite support, 73, 261 ﬂexibility by change, 372 global model, 4 goal-oriented constraint, 51 integration with commitments, 382 interposition constraint, 125 legal composition, 192, 194 local model, 191 loop, 241–245 ∨-loop, 244–245, 247–249 ∧-loop, 244–245, 247, 249 model, 48 abstract, 190 augmented, 190–191 augmented composite, 192 choreography, 196 concrete, 190

405

fully abstract, 190 global, 187 grounding, 191 local, 187, 190 negation constraint, 49, 54–56 translation into CLIMB, 125–128 openness, 48, 55 optional constraint, 5, 48, 116, 305 monitoring, 324–334 translation into EC, 325–328 preprocessing, 4, 246–249, 304, 338 property, 230–231 ∃-entailment, 181, 262 ∀-entailment, 181, 263 conﬂict, 181–182, 192, 194, 255, 256, 262 dead activity, 181–182, 185, 263 reduction of ∀-entailment to ∃-entailment, 236–239, 263 termination, 73, 184, 261, 263, 278 translation into CLIMB, 231 relation constraint, 49, 51–54 translation into CLIMB, 125–128 role, 190 strong conformance, 196–199 support, see ConDec, compliance translation into CLIMB, 115–130 soundness, 132–137 translation into LTL, 70 violation contextualization, 331–332 weak conformance, 196–199 ConDec++ , 139–161, 278, 347, 349 activity, 147–149 representation, 149 translation into CLIMB, 159–161 constraint, 150 data, 139, 145–147, 149–154 representation, 149 translation into CLIMB, 155 data condition, 147, 150–153 translation into CLIMB, 155–156 metric constraint, 139–144 representation, 142–143 translation into CLIMB, 143–144 originator, 149 quantitative constraint, see ConDec++ , metric constraint role, 147, 149 translation into CLIMB, 156–159

406

Index

constitutive rule, 381 Constraint Logic Programming, 81–83, 103, 227 membership, 123, 124, 128 Contraﬂow, 164 control-ﬂow, 15, 22, 164, 166, 168 deadlock, 182 decision table, 167 augmented, 167 conventional, 167 declarative approach, 17 declarative process mining, see process mining, declarative DECLARE, 166, 277, 372 DecMiner, see process mining, declarative, DecMiner DecSerFlow, 284 deduction, 96 deferred choice, 50, 128 deﬁnitional rule, 90 denial, 97 denitriﬁcation, 360 Deontic Logic, 170–171, 281 depth-ﬁrst strategy, 227, 244, 271 bounded, 247, 252 discovery, 43 Dynamo, 368–370 EC, see Event Calculus Eclipse, 383 EM-BrA2 CE, 165–166 EMF, 383 enactment, 3, 5, 42, 305, 367, 372–373 ConDec, 335–340 non executable activities, 336–339 temporarily violated constraints, 336 termination, 339–340 Enron, 186 event, 3, 12, 78 correlation, 159 identiﬁer, 155, 160 log, 148 type, 148, 155, 348 Event Calculus, 5, 169, 172, 307–312, 370 abductive reasoning, 310 Cached, 311

deductive reasoning, 310 ﬂuent, 308 inductive reasoning, 310 ontology, 308–309 reactive, see Reactive Event Calculus reactive reasoning, 310 Event Condition Action rule, 165, 347 event log, 12 event trail, see execution trace Event-Based System, 3, 12 Event-driven Process Chain, 373 discovery, 373 Event-driven process chain, 361 execution trace, 12, 147 compact, 119–121 ﬁnite, 72 semantics, 74 inﬁnite, 182 totally ordered, 73 export interface, 190, 191 FindAndLoops, 245 FindOrLoops, 245 ﬂexibility, 3, 16–18, 20, 39 by change, 17, 346 by design, 17 by deviation, 17, 346 by underspeciﬁcation, 17 taxonomy of, 17 ﬂexible Business Process, 24 Formal Contract Language, 281 formal veriﬁcation, 180 forward reasoning, 93 four eyes principle, 16, 87, 154, 348, 349, 375 FreeFlow, 163–164 Fuzzy Miner, 373 g-SCIFF proof procedure, see g-sciff g-sciff, 3, 201, 218–227, 277, 279, 282, 300, 302–304 abductive explanation, 220 Call GSCIFF, 252 completeness modulo trace generation, 223–224 derivation, 221–222 implementation, 227 node, 220 performance, 251–260, 269–275

Index proof tree, 255 scalability, 253–260 simulation by abduction, 219 soundness, 223 successful derivation, 220–221 termination, 4, 225–227, 380–381 transitions, 221–222 fulﬁller, 221 weak completeness modulo trace generation, 224–225 gateway, 22 Glare, 1, 37 Global Computing, 2, 77 granularity, see time, granularity IFF proof procedure, 202, 206 import interface, 190, 191, 195 induction, 96 Inductive Constraint Logic, 361 Inductive Logic Programming, 6, 345, 361 instance, 12 interaction model closed, 19, 31 declarative, 18 life cycle, see CLIMB, life cycle open, 3, 19–20 procedural, 18 semi-open, 19, 39, 383 interaction protocol, 1, 34, 78 query-ref, 100 JAVA, 298, 340, 353, 368, 369 JPL, 340 jREC, see Reactive Event Calculus, jREC language bias, 361 Let’s Dance, 169 level mapping, 217 Linear Temporal Logic, 4, 47, 67–70, 169, 261, 264, 277, 278, 371 ∃-entailment, 261–262 ∀-entailment, 262 execution trace, 68 ﬁnite, 72–73 model, 68 satisﬁability, 262, 269 semantics, 69

407

ﬁnite trace, 73–75, 184, 261, 371, 372 three-valued, 371 syntax, 68 validity, 262–263 LTL, see Linear Temporal Logic LTL-Checker, 351, 374 MAS, see Multi-Agent System Maximal Validity Interval, 309 Mealy machine, 283 membership constraint, see Constraint Logic Programming, membership message sequence chart, 169 metric temporal constraint, 140 Metric Temporal Logic, 269, 275, 278 model checking, 4, 251, 261, 264–266, 274–275, 277 bounded, 279 explicit, 265–266, 269, 279 ﬁnite trace, 278 Kripke model, 264 universal, 266–267, 278 satisﬁability, 267, 268 state explosion, 265 symbolic, 266, 269 termination, 274 validity, 267, 268 model composition, 43 model transformation, 382 model-driven engineering, 382 ModelChecking, 269 monitoring, 3, 5, 43, 187, 305, 367–371 with rec, 315 Multi-Agent System, 1, 34, 44, 163, 170–172, 291 open society, 35 MXML, 139, 145, 147–148, 155, 347, 350, 352, 359 transactional model, 148, 348 MySQL, 359 Negation As Failure, 308 neural network, 359 nitriﬁcation, 360 NuSMV, 266, 269, 279 open computational society, 170 open MAS, 34, 77, 95

408

Index

openness, see interaction model, open orchestration, see service, orchestration originator, 148, 155, 156, 348 over-constraining, 32 over-speciﬁcation, 32 OWL-S, 170, 283 PENELOPE, 281 Petri Net, 169, 283, 361, 373, 374 discovery, 373 π-calculus, 169, 282 pocket of ﬂexibility, 164 premature commitment, 31 PreProcess, 246 procedural approach, 17 process mining, 3, 5, 43, 343–344, 367, 373–375, 381 conformance checking, 344, 374 declarative, 5, 344 checking–discovery cycle, 364–365 Declarative Process Model Learner, 361 DecMiner, 6, 345, 361–365, 373–374 SCIFF Checker, 5, 345–353, 365 delta analysis, 344 discovery, 344 log-based veriﬁcation, 344 operational support, 381 analysis, 381 prediction, 381 recommendation, 381 trace analysis, 344–346 with sciff, 350–351 with Prolog, 351 production workﬂow, 23 programming-in-the-large, 1 programming-in-the-small, 1 Prolog, 18, 90, 271, 280 ProM, 6, 344, 346, 362, 381 ProM import, 346, 356 Promela, 279 property conﬂict, see ConDec, property, conﬂict dead activity, see ConDec, property, dead activity fairness, 183, 184 general, 181 good atomicity, 181

invariant, 183 liveness, 182, 183 LTL, 183–184 particular, 181, 185, 186 promptness, 183 safety, 182, 183 LTL, 183–184 termination, 73 propositional Linear Temporal Logic, see Linear Temporal Logic Protocure, 167 QoS, see Quality of Service Quality of Service, 144, 368, 369 Reactive Event Calculus, 5, 305, 312–324, 370 axiomatization, 312–314 complete event, 314, 315 ﬂuent initiation, 313–314 ﬂuent termination, 314 holding of ﬂuent, 313 initial status, 313 internal events, 312 irrevocability, 319–320 jREC, 340–341, 381 MVI closed sub-state, 323 MVI open sub-state, 323 MVI semantics, 313 MVI state, 323 operational support, 381 REC, see Reactive Event Calculus, speciﬁcation rec, 315, 333–334, 336, 337 completeness, 320 irrevocability, 321–324 soundness, 320 termination, 320 uniqueness of derivation, 322 speciﬁcation, 314, 315 well-formed, 321 state progressive extension, 323 trace extension, 323 violation reiﬁcation, 328 deadline expiration, 330–331 prohibition, 329 REC, see Reactive Event Calculus rec, see Reactive Event Calculus, rec regulative rule, 381

Index role, 91, 147, 190, 191 strong eﬀect, 158 weak eﬀect, 158 Roman model, 283 RTML, 368, 369 run-time veriﬁcation, 3, 5, 43, 289–304, 367–371 closed reasoning, 291, 292 open reasoning, 291, 292 semi-open reasoning, 291, 304 speculative reasoning, 300–304 with g-sciff, 302 with sciff, 291–298 with LTL, 371 Sarbanes-Oxley Act, 15, 186 SAT, 279 SBVR, 165 SCIFF, 2, 36, 44, 77, 85, 95, 170, 281, 284 comparison with LTL, 137–138 proof procedure, see sciff semi-decidability, 216 SCIFF Checker, see process mining, declarative, SCIFF Checker SCIFF-lite, 85, 93–95, 172, 305, 312 composite event, 94 semantics, 101–102 speciﬁcation, 101 syntax, 93 sciff, 3, 201–218, 282, 289, 290, 298–300, 302, 304–307, 339, 372 abductive explanation, 204 intensional, 205 complete event, 208 completeness, 215–216 derivation, 204, 212–214 closed, 304 open successful, 293, 294, 296 semi-open, 298, 303, 304 successful, 205, 214 fulﬁlled expectation, 202–203 generative extension, 222 implementation, 227 node, 204 failure, 204, 292, 294 initial, 204 quiescent, 204, 292, 296 success, 204, 295

409

open reasoning, 292–295 pending expectation, 202–203, 290 proof tree, 204 semi-open reasoning, 295–298 soundness, 214 termination, 216–218 w.r.t. ConDec, 218 transitions, 203, 205–214 abduction, 207 case analysis, 206, 321 closure, 208, 292, 294, 295 CLP, 208 consistency, 211–212, 255, 256, 296 E-fulﬁllment, 209–210, 295 E-violation, 209 EN-fulﬁllment, 211 EN-violation, 210–211 happening, 208, 292 logical equivalence, 207 propagation, 206 splitting, 208 times update, 209, 295, 296, 298, 304 unfolding, 207 violated expectation, 202–203 Semantic Process Network, 282 semantic Web Service, 170 sequence ﬂow, 22 service adaptation, 367 choreography, 28–30, 57, 130, 169, 188, 196, 289, 291, 332 B2B, 28, 188 composition, 26, 169, 187, 188 consumer, 26 contracting, 285, 383 discovery, 285, 383 orchestration, 1, 27–28 provider, 25 registry, 25 Service Level Agreement, 369 Service Level Objective, 369 Service Oriented Architecture, 25–26 Service Oriented Computing, 1, 25–33, 163, 169–170, 331, 367 SICStus Prolog, 227, 251, 298 Situation Calculus, 307, 309 SOA, see Service Oriented Architecture SOAP, 26, 369, 370, 374

410

Index

SOC, see Service Oriented Computing social commitment, 171–172 conditional, 171 social commitments, 382 integration with ConDec, 382 SOCS, 77, 170 SOCS-SI, 298–299, 340 event recorder, 298 history manager, 299 init&control module, 299 social compliance veriﬁer, 299 spaghetti model, 32, 373 SpeculativeRun-TimeVerification, 303 SPIN, 265, 269, 279 state machine, 169 static veriﬁcation, 3–4, 42, 177–199 of a composition, 177, 179 a-priori compliance, 42, 229, 277, 281–283, 374 benchmark, 251 alternate responses, 255–258 branching responses, 253–255 chain responses, 258–260 O&Psat , 270 O&Punsat , 270 compatibility, 188, 189 conﬂict detection, 229, 233, 278, 301 conformance checking, 43, 177, 277, 284–285 discovery of dead activities, 189, 229, 237–238, 248, 278 interoperability, 284 of a composition, 277, 283–284 of properties, 42, 177, 180–186, 189, 201, 277–281 ∃-entailment, 233–234 ∀-entailment, 234–239 with g-sciff, 229–239 support, 16 SWI Prolog, 227, 340 tCLIMB , 116, 141, 218, 231 soundness with tLTL , 134 tCLIMB , 141–142, 231 theorem proving, 277 theory completion, 103 R , 353, 354 Think3 workﬂow, 354–355

three-valued logics, 103 tIC , 116, 121, 141, 258, 293 tIC , 141, 259 time, 3, 13–14 bounded, 13 branching, 13 chronometry, 118 contiguity, 118, 127, 139, 140, 258, 259 deadline, 142, 328, 330–331 delay, 142 dinstance, 140 granularity, 118 interval-based, 13 latency, 142 linear, 13 point-based, 13 qualitative, 4, 13, 49, 127, 140, 258 quantitative, 4, 13, 127, 258, 259 structure, 13, 79 temporal primitives, 13 unbounded, 13 timed automaton, 279 Timed Propositional Temporal Logic, 278 tLTL , 70, 262 tm, 133 TOCAI.IT, 356 trace analysis, 43 trace mapping, see tm transition system, 264 TRIO, 279 Trio2Promela, 279 tuProlog, 353 Tyco International, 186 UDDI, 26 UML, 49 activity diagram, 282 UPPAAL, 278 veriﬁcation a-posteriori, see a-posteriori veriﬁcation, see process mining a-priori, see static veriﬁcation run-time, see run-time veriﬁcation static, see static veriﬁcation, see static veriﬁcation VieDAME, 369, 370

Index wastewater treatment plant, 358–359 Web Service, 26 West2East, 280 workﬂow net, 354 worklist, 43, 335 WorldCom, 186 WS-Agreement, 370 WS-BPEL, see BPEL WS-CDL, 29, 30

WS-Col, 368, 369 WSDL, 26, 27 WSMO, 170 XPDL, 22 YAWL, 22, 168 Zot, 279

411

Metrics for Process Models: Empirical Foundations of Verification, Error Prediction, and Guidelines for Correctness (Lecture Notes in Business Information Processing)

Perspectives in Business Informatics Research. BIR 2011 Proceedings (Lecture Notes in Business Information Processing)

Semantic Methods for Execution-level Business Process Modeling: Modeling Support Through Process Verification and Service Composition (Lecture Notes in Business Information Processing)

Theoretical Foundations of Quantum Information Processing and Communication: Selected Topics (Lecture Notes in Physics)

Software Business: First International Conference, ICSOB 2010, Jyväskylä, Finland, June 21-23, 2010, Proceedings (Lecture Notes in Business Information Processing)

Specification and Verification of Declarative Open Interaction Models: A Logic-Based Approach (Lecture Notes in Business Information Processing)

Metrics for Process Models: Empirical Foundations of Verification, Error Prediction, and Guidelines for Correctness (Lecture Notes in Business Information Processing)

Perspectives in Business Informatics Research. BIR 2011 Proceedings (Lecture Notes in Business Information Processing)

Vlsi Specification, Verification and Synthesis

Specification and Verification of Multi-agent Systems

Advanced Manufacturing and Sustainable Logistics (Lecture Notes in Business Information Processing, 46)

The Practice of Enterprise Modeling (Lecture Notes in Business Information Processing, 39)

Lecture Notes on Principles of Plasma Processing

Information Hiding (Lecture Notes in Computer Science)

State-Space Models of Lumped and Distributed Systems (Lecture Notes in Control and Information Sciences)

Interaction models

Interaction models

Colloids and the Depletion Interaction (Lecture Notes in Physics, 833)

Conditional Specification of Statistical Models

Reactive Systems: Modelling, Specification and Verification

Reactive Systems: Modelling, Specification and Verification

Reactive systems: modelling, specification and verification

Recursive Nonlinear Estimation: A Geometric Approach (Lecture Notes in Control and Information Sciences)

Semantic Methods for Execution-level Business Process Modeling: Modeling Support Through Process Verification and Service Composition (Lecture Notes in Business Information Processing)

Theoretical Foundations of Quantum Information Processing and Communication: Selected Topics (Lecture Notes in Physics)

Information, Interaction, and Agency

A Constructional Approach to Resultatives (Center for the Study of Language and Information - Lecture Notes)

Lattice Models of Polymers (Cambridge Lecture Notes in Physics)

Macrosystems Theory and its Applications: Equilibrium Models (Lecture Notes in Control and Information Sciences)

Magnetism: A Synchrotron Radiation Approach (Lecture Notes in Physics)

Models of ZF-set theory (Lecture notes in mathematics 223)

Nonsmooth Impact Mechanics: Models, Dynamics and Control (Lecture Notes in Control and Information Sciences)

Software Business: First International Conference, ICSOB 2010, Jyväskylä, Finland, June 21-23, 2010, Proceedings (Lecture Notes in Business Information Processing)

Ensuring Control Accuracy (Lecture Notes in Control and Information Sciences)

Networked Control Systems (Lecture Notes in Control and Information Sciences)

Singular Control Systems (Lecture Notes in Control and Information Sciences)

Specification and Verification of Declarative Open Interaction Models: A Logic-Based Approach (Lecture Notes in Business Information Processing)

Metrics for Process Models: Empirical Foundations of Verification, Error Prediction, and Guidelines for Correctness (Lecture Notes in Business Information Processing)

Perspectives in Business Informatics Research. BIR 2011 Proceedings (Lecture Notes in Business Information Processing)

Vlsi Specification, Verification and Synthesis

Specification and Verification of Multi-agent Systems

Advanced Manufacturing and Sustainable Logistics (Lecture Notes in Business Information Processing, 46)

The Practice of Enterprise Modeling (Lecture Notes in Business Information Processing, 39)

Lecture Notes on Principles of Plasma Processing

Information Hiding (Lecture Notes in Computer Science)

State-Space Models of Lumped and Distributed Systems (Lecture Notes in Control and Information Sciences)

Interaction models

Interaction models

Colloids and the Depletion Interaction (Lecture Notes in Physics, 833)

Conditional Specification of Statistical Models

Reactive Systems: Modelling, Specification and Verification

Reactive Systems: Modelling, Specification and Verification

Reactive systems: modelling, specification and verification

Recursive Nonlinear Estimation: A Geometric Approach (Lecture Notes in Control and Information Sciences)

Semantic Methods for Execution-level Business Process Modeling: Modeling Support Through Process Verification and Service Composition (Lecture Notes in Business Information Processing)

Theoretical Foundations of Quantum Information Processing and Communication: Selected Topics (Lecture Notes in Physics)

Information, Interaction, and Agency

A Constructional Approach to Resultatives (Center for the Study of Language and Information - Lecture Notes)

Lattice Models of Polymers (Cambridge Lecture Notes in Physics)

Macrosystems Theory and its Applications: Equilibrium Models (Lecture Notes in Control and Information Sciences)

Magnetism: A Synchrotron Radiation Approach (Lecture Notes in Physics)

Models of ZF-set theory (Lecture notes in mathematics 223)

Nonsmooth Impact Mechanics: Models, Dynamics and Control (Lecture Notes in Control and Information Sciences)

Software Business: First International Conference, ICSOB 2010, Jyväskylä, Finland, June 21-23, 2010, Proceedings (Lecture Notes in Business Information Processing)

Ensuring Control Accuracy (Lecture Notes in Control and Information Sciences)

Networked Control Systems (Lecture Notes in Control and Information Sciences)

Singular Control Systems (Lecture Notes in Control and Information Sciences)

Recommend Documents