Hybrid Parallel Execution Model for Logic-Based Specification Languages

HYBRID PARALLEL EXECUTION MODEL FOR LOGIC-BASE SPECIFICATION ' LANGUAGE HYBRID PARALLEL EXECUTION MODEL FOR LOGIC-BASE...

Author: Jeffrey J. P. Tsai | Bing Li

67 downloads 517 Views 8MB 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

HYBRID PARALLEL EXECUTION MODEL FOR LOGIC-BASE SPECIFICATION ' LANGUAGE

HYBRID PARALLEL EXECUTION MODEL FOR LOGIC-BASED SPECIFICATION LANGUAGES

SERIES ON SOFTWARE ENGINEERING AND KNOWLEDGE ENGINEERING Series Editor-in-Chief S K CHANG (University of Pittsburgh, USA)

Vol. 1 Knowledge-Based Software Development for Real-Time Distributed Systems Jeffrey J.-P. Tsai and Thomas J. Weigert (Univ. Illinois at Chicago) Vol. 2

Advances in Software Engineering and Knowledge Engineering edited by Vincenzo Ambriola (Univ. Pisa) and Genoveffa Tortora (Univ. Salerno)

Vol. 3

The Impact of CASE Technology on Software Processes edited by Daniel E. Cooke (Univ. Texas)

Vol. 4

Software Engineering and Knowledge Engineering: Trends for the Next Decade edited by W. D. Hurley (Univ. Pittsburgh)

Vol. 5

Intelligent Image Database Systems edited by S. K. Chang (Univ. Pittsburgh), E. Jungert (Swedish Defence Res. Establishment) and G. Tortora (Univ. Salerno)

Vol. 6

Object-Oriented Software: Design and Maintenance edited by Luiz F. Capretz and Miriam A. M. Capretz (Univ. Aizu, Japan)

Vol. 7

Software Visualisation edited by P. Eades (Univ. Newcastle) and K. Zhang (Macquarie Univ.)

Vol. 8

Image Databases and Multi-Media Search edited by Arnold W. M. Smeulders (Univ. Amsterdam) and Ramesh Jain (Univ. California)

Vol. 9

Advances in Distributed Multimedia Systems edited by S. K. Chang, T. F. Znati (Univ. Pittsburgh) and S. T. Vuong (Univ. British Columbia)

Forthcoming titles: Acquisition of Software Engineering Knowledge edited by Robert G. Reynolds (Wayne State Univ.) Monitoring, Debugging, and Analysis of Distributed Real-Time Systems Jeffrey J.-P. Tsai, Steve J. H. Yong, R. Smith and Y. D. Bi (Univ. Illinois at Chicago)

HYBRID PARALLEL EXECUTION MODEL FOR LOGIC-BASED SPECIFICATION LANGUAGES

Jeffrey J P Tsai Bing Li University of Illinois at Chicago

V f e World Scientific wb

Singapore Sinaapore • New Jersey •LLondon • Hong Kong

Published by World Scientific Publishing Co. Pte. Ltd. P O Box 128, Farrer Road, Singapore 912805 USA office: Suite IB, 1060 Main Street, River Edge, NJ 07661 UK office: 57 Shelton Street, Covent Garden, London WC2H 9HE

British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library.

HYBRID PARALLEL EXECUTION MODEL FOR LOGIC-BASED SPECIFICATION LANGUAGES Copyright © 2001 by World Scientific Publishing Co. Pte. Ltd. All rights reserved. This book, or parts thereof, may not be reproduced in any form or by any means, electronic or mechanical, including photocopying, recording or any information storage and retrieval system now known or to be invented, without written permission from the Publisher.

For photocopying of material in this volume, please pay a copying fee through the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, USA. In this case permission to photocopy is not required from the publisher.

ISBN 981-02-4096-1

Printed in Singapore by Uto-Print

Contents 1

Introduction

1

2

Current Approaches 2.1 Data Dependency Analysis 2.2 OR-Parallelism 2.3 AND-Parallelism 2.4 Backtracking

7 7 7 9 10

3

Overview of the N e w Approach 3.1 Non-monotonic Inheritance Expansion 3.2 Static Data Dependency Analysis 3.3 Automatic Transformation 3.4 Hybrid AND-OR Parallel Execution 3.5 Simplified OR-Parallel Model 3.6 Backtracking Elimination

13 15 15 17 17 18 19

4

FRORL Requirements Specification Language and Its Decomposition 4.1 Knowledge Representation through Object-Oriented Model . . 4.2 The Modeling Primitives of FRORL 4.2.1 Object Frame 4.2.2 Activity Frame 4.2.3 Reserved Words 4.3 Decomposition of a FRORL Requirements Specification . . . . 4.3.1 FRORL and its Non-monotonic Inheritance Mechanism 4.3.2 Transformation of FRORL into Horn-clause Logic-based Specification 4.3.3 Algorithms for Non-Monotonic Inheritance Handling . . v

21 22 23 23 25 27 27 28 29 30

vi

Contents

5

Rewriting and Data Dependency, Control Flow Analysis of a Logic-Based Specification 53 5.1 Rewriting of a Logic-Based Specification 54 5.1.1 Equal-Introduction 56 5.1.2 Equal-Substitution 58 5.1.3 Decomposition 60 5.1.4 Simplification 66 5.2 Data Dependency and Control Flow Analysis 74 5.2.1 Matrix Representation of Mode Information 75 5.2.2 Data Flow and Dependency Analysis Algorithm . . . . 78

6

Hybrid A N D - O R Parallelism Implementation 6.1 The Usage of Mode Information in the Parallel Model 6.2 AND-OR Parallel Execution 6.3 Synchronization in OR-Parallel Execution Model 6.4 Calculation of the Currently Executable Predicate Set 6.5 Hybrid Execution Algorithm 6.6 Comparison with the Conventional BFS and DFS 6.7 Advantages of the New Approach 6.8 Analysis of Non-functional Requirements in the New Parallel Execution Model

89 89 90 92 95 98 100 101 105

7

Efficiency Considerations and Experimental Results 107 7.1 Execution Evaluation 107 7.2 Communication Evaluation 107 7.3 Criteria for Simulation and Evaluation 108 7.4 A Simulator for Parallel Logic-based Specification Evaluation . 114 7.5 Experimental Results and Comparison 121 7.5.1 Simulation for Various Values of Error JEtate 122 7.5.2 Simulation for Values of Deep_Jumping_Distance . . . . 124 7.5.3 Simulation for Values of Deep.Jumping_Rate 126 7.5.4 Simulation for Values of Variable_Related_Rate 127 7.5.5 Simulation for Values of Nondeterminism_Rate 128

8

M o d e Information Support for Automatic Transformation Sys^ tem 161 8.1 Architecture of a Logic-based Specification Transformation System 162 8.2 Determination of Control Sequence 162 8.3 Data Type Generation and Procedural Function Formation . . 167 8.3.1 Rules-based Data Type Inference 168 8.3.2 Data Type Propagation Analysis and Generation . . . . 171

Contents

8.4 9

vii 8.3.3 Data Type Analysis in a FRORL Specification 8.3.4 Procedural Program Generation Intelligent Backtracking for Transformation System

172 173 183

Describing Non-Functional Requirements in FRORL 185 9.1 Functional Requirements vs. Non-functional Requirements . . . 185 9.2 Issues in Non-functional Requirements 186 9.3 Non-functional Requirements Modeling in FRORL 190 9.4 Adjusting Non-functional Requirements 196

10 Summary

201

List of Tables 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 7.23 7.24 7.25 7.26 7.27 7.28 7.29 7.30

TEST RESULTS FOR ERROR-RATE = 0.0 (a) 130 TEST RESULTS FOR ERROR-RATE = 0.0 (b) 131 TEST RESULTS FOR ERROR-RATE = 0.50 (a) 132 TEST RESULTS FOR ERROR-RATE = 0.50 (b) 133 TEST RESULTS FOR ERROR-RATE = 0.99 (a) 134 TEST RESULTS FOR ERROR-RATE = 0.99 (b) 135 TEST RESULTS FOR SMALL DISTANCE RANGE (a) . . . 136 TEST RESULTS FOR SMALL DISTANCE RANGE (b) . . . 137 TEST RESULTS FOR MEDIUM DISTANCE RANGE (a) . . 138 TEST RESULTS FOR MEDIUM DISTANCE RANGE (b) . . 139 TEST RESULTS FOR LARGE DISTANCE RANGE (a) . . . 140 TEST RESULTS FOR LARGE DISTANCE RANGE (b) . . . 141 TEST RESULTS FOR DEEP-JUMPING-RATE = 0.1 (a) . . 142 TEST RESULTS FOR DEEP-JUMPING-RATE = 0.1 (b) . . 143 TEST RESULTS FOR DEEP.JUMPING-RATE = 0.5 (a) . . 144 TEST RESULTS FOR DEEP-JUMPING-RATE = 0.5 (b) . . 145 TEST RESULTS FOR DEEP-JUMPING-RATE = 0.9 (a) . . 146 TEST RESULTS FOR DEEP_JUMPING-RATE = 0.9 (b) . . 147 TEST RESULTS FOR VARIABLE-RELATED .RATE = 0.0 (a) 148 TEST RESULTS FOR VARIABLE-RELATED .RATE = 0.0 (b) 149 TEST RESULTS FOR VARIABLE-RELATED-RATE = 0.5 (a) 150 TEST RESULTS FOR VARIABLE-RELATED-RATE = 0.5 (b) 151 TEST RESULTS FOR VARIABLE-RELATED-RATE = 0.9 (a) 152 TEST RESULTS FOR VARIABLE-RELATED-RATE = 0.9 (b) 153 TEST RESULTS FOR NON J)ETERMINISMJtATE = 1 (a) . 154 TEST RESULTS FOR NONJDETERMINISM.RATE = 1 (b) . 155 TEST RESULTS FOR NON .DETERMINISM-RATE = 2 (a) . 156 TEST RESULTS FOR NON-DETERMINISM-RATE = 2 (b) . 157 TEST RESULTS FOR NON-DETERMINISM-RATE = 3 (a) . 158 TEST RESULTS FOR NON J)ETERMINISM_RATE = 3 (b) . 159

IX

List of Figures 3.1

An overview of the system

16

4.1 4.2 4.3 4.4 4.5

An example decomposition process The flow chart of "NMJmageGenerator_for_Object_Frame" . . The flow chart of "NMJmageGenerator_for_Activity_Frame" . . The flow chart of the algorithm "inherit_from_parents" Graphical explanation of the procedure "inherit_from_parents"

28 35 36 37 38

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8

An illustration of data transformation by a clause head literal . The partial result matrix for clause 2 The final result matrix for clause 4 The final result matrix for clause 2 Initial attempt to construct a matrix for clause 6 The final result matrix for clause 7 The final result matrix for clause 3 The final result matrix for clause 5

77 84 85 85 86 87 87 88

6.1 6.2

6.5 6.6

An illustration of the new parallel execution model 91 A comparison of execution sequence between current and new models 96 A simple comparison between current and the new parallel evaluation model 104 An example illustrating reduced duration of communication channel 104 An illustration of early-shortcut 105 Parallel evaluation and its reference to non-functional specification 106

7.1

An example evaluation tree

113

9.1 9.2

Non-functional requirements for security attributes Hierarchical model of the object frames for security

189 193

6.3 6.4

xi

List of Figures

Xll

9.3 9.4 9.5 9.6 9.7

Illustration quirements Illustration Illustration Illustration Illustration

of a FRORL specification with non-functional reattached of rule 37 of rule 38 of rule 39 of rule 40

195 197 198 198 199

Chapter 1

Introduction Software maintenance is a crucial phase for the longevity of any application. However, undiscovered errors in a requirements specification will result in maintenance costs exceeding ten times the original [95, 96]. Errors in the requirement phase can be reduced through validation and verification of the requirements specification. Many logic-based requirements specification languages have been developed to achieve these goals [9, 27, 37, 38, 47, 53, 54, 55, 56, 57, 58, 59, 67, 73, 77, 80, 82, 90, 91, 94]. Through the execution of the logic-based requirements specification, customers and developers can validate their disagreement or misunderstanding in the requirement phase. By reasoning over the logic-based requirements specification, developers can verify desired properties such as consistency, liveness and so on. Developers can also verify whether or not non-functional requirements specification describing the executional behavior of the specification have been satisfied. However, the execution and reasoning of logic-based requirements specification is very slow. An effective way to improve their performance is to execute and reason the logic-based requirements specification in parallel. In order to reach this goal, this book presents a hybrid parallel execution model for Horn-clause logicbased requirements specification languages such as FRORL [93]. This model is built on a static data dependency and mode analysis mechanism . Another application of the data dependency and mode analysis, a transformation system which transforms a logic-based specification into a procedural language program, is also discussed. The logic foundation of FRORL is based on Horn-clause logic augmented with non-monotonic inheritance . This book first discusses the automatic nonmonotonic inheritance handling of a FRORL specification. After the automatic expansion mechanism is applied to a FRORL specification for eliminating nonmonotonic inheritance, the specifications will contain only Horn-clause logic1

2

Introduction

based specification clauses. In order to evaluate the generated specification in parallel such that multiple solutions can be explored at the same time, and the executional behavior can be checked to see if they meet certain requirements, the executional behavior of a Horn-clause logic-based specification has to be studied. A Horn-clause logic-based specification consists of a set of clauses. For each clause, the clause head and body are formed by predicates. The execution of a Horn-clause logic-based specification is based on the resolution principle. A data value is transferred among clauses and within the bodies of clauses based on the unification rule. The execution of a logic-based specification is similar to a depth first search of an AND-OR tree [24, 78, 103], where AND nodes represent the predicates within a clause, and OR nodes represent the clauses unifiable within a calling predicate. In order for an answer to be generated from the specification, a successful search has to be found. A unit clause succeeds if it is a built-in predicate or is included in the input data base. The success of a predicate is defined by the clauses which are unifiable with the predicate, i.e. the clauses with their heads having identical name and being unifiable with the current predicate. If any of the clauses unifiable with the predicate is successful, then the predicate is successful. The success of a clause is defined by the predicates in the clause body. If all the predicates in the clause body succeed, only then the clause itself can be proved successful. Along with the resolution process, data values are transferred within clause body and among clauses by data sharing and unification. The parallelism of a Horn-clause logic-based requirements specification can be extracted from an AND-OR execution model. It follows the top-down searching strategy of the AND-OR tree. The parallel execution of OR-branches is relatively easy to implement because the execution of clauses unifiable with a predicate are independent of each other. The parallel execution of ANDbranches is much more complex, since it may create binding conflicts during execution [33]. An effective and common method to solve this problem is to rely on data flow and dependency analysis, which allows exactly one producer and multiple consumers for each parameter in a clause. Currently, most approaches adopt the method of dynamic mode inference to do data flow analysis [17, 32, 64, 88, 104]. The basic idea of this approach is to rely on the user's query to generate data dependency information, then use this information to spawn processes which can be executed in parallel. The nature of these methods can be described as a demand-driven model which executes in a top-down fashion. Even though these approaches can extract AND-parallelism during the execution, they have a common drawback; the mode information can only be obtained during the actual execution, and this dynamic determination of parameters' mode and parallel execution combination puts tremendous overhead on the model, which may jeopardize any ad-

Hybrid Parallel Execution Model

3

vantage these parallel execution models might obtain. A few other approaches use data dependency analysis by static mode inference [16, 28, 31], which is based on the analysis of the structure of a logic program to generate the parallelly executable components, but again they suffer the problems of either being unable to generate all the solutions to the input logic program, or they sacrifice the degree of parallelism of the program. For example, in [16], Chang et. al. implement the static data dependency analysis by considering only the worst case clause invoking pattern, which eliminates the possible advantage of generating multiple solutions of a logic program at the same time. As a result, the approach has to explicitly handle the backtracking problem during the parallel execution of the AND-OR tree , which can still slow the system execution. In this book, a new parallel execution model for a Horn-clause logic-based requirements specification based on a novel static data dependency analysis is proposed. This model can preserve maximum parallelism while guaranteeing to generate all the solutions of a logic-based specification without backtracking . The power of this model comes from the fact that the static data dependency is capable of representing all execution sequences and all multiple solutions implied by a logic-based specification [98, 94]. Since the complete mode information is available through mode inference even without actual execution, the new parallel execution model can apply some extra analysis processes during compiling compared to other approaches and obtain more parallel execution information of the underlying logic-based specification. The overall parallel execution behavior of the logic-based specification can be improved. Specifically, the new execution model extracts the necessary mode information from the static data dependency analysis to facilitate the combination of top-down and bottom-up searching of the AND-OR tree of a logic-based specification. In this process, all solutions implied by the logic-based specification can be generated and explored based on the same data dependency information, which may result in the preservation of correctness of the results while eliminating backtracking from consideration. Regarding the top-down execution direction of this hybrid model, it adopts the method similar to the current approaches, i.e., a predicate is executable only if all of its input parameters have received values from some other predicates within the same clause. This execution direction mainly reflects the interrelation among the predicates within a clause. On the other hand, the new execution along the bottom-up direction relies on the detection of ground variables from the static data dependency information to facilitate the evaluation of those predicates with all of its required value being available. This direction mainly deals with the possible adjustment of execution sequence among clauses of a logic-based specification. By adopting this strategy, overhead of the parallel execution of a logic-based specification can be reduced. In this

4

Introduction

book, other improvements related to this new parallel evaluation model are also discussed. Among them are reduced duration of processes, and reduced communication cost, reduced number of total nodes need to be searched in the AND-OR tree , as well as simplified OR-parallel synchronization data structure. It is possible that under certain conditions parallel execution is actually worse than sequential execution because of the extra management overhead. Using a simulator all different combinations of the properties which control the structure of the AND-OR search tree can be explored. By adjusting these control parameters, AND-OR trees with different structures are applied by the sequential, currently available parallel, and the new parallel execution model. Significant improvement has been achieved under most of the situations. The execution behavior of the specification explored by the new parallel execution model can also be used to verify whether or not the non-functional requirements attached to the functional requirements written in FRORL has been satisfied. The early discovery of non-match information can be fed back to the specification phase to adjust the non-functional requirements accordingly. Another application of the static mode information is to apply it to facilitate the automatic transformation of a FRORL logic-based specification into a procedural language program. This automatic transformation system can be used to implement new software development paradigms like rapid prototyping , transformational implementation, and operational specification. User can describe a problem using formal specification language FRORL, the equivalence preserving transformation system can then be applied to transform the specification into an executable model which is written in procedural language program. The behavior of the model can then be shown to the user. The transformation system has to make use of the mode information to find the multiple execution paths within a logic-based specification. The book is organized as follows. Chapter 2 summarizes current approaches in realizing the automatic data flow analysis and parallelism of a logic-based specification. Chapter 3 provides an overview of the proposed new system and how it handles major problems in the parallelizing process. Chapter 4 introduces requirements specification language FRORL . Chapter 5 discusses the static data dependency analysis method and the mode information it generates. Chapter 6 explains in detail the new AND-OR parallelism based on the static data dependency information. Chapter 7 discusses a simulator for the new parallel execution model and compares the experimental results it generates under various conditions with current approaches. The reasons why improvements can be achieved are discussed along with each comparison tables. Chapter 8 discusses an application of using mode information to realize an automatic transformation system. Chapter 9 gives another application of how to use FRORL to describe non-functional requirements specification. We conclude the book in Chapter 10 with a brief summary.

Hybrid Paxallel Execution Model

5

The research presented in the book would have been impossible without the assistance and contribution of our graduate students involved in the development of the FRORL software development environment. T. Weigert contributed to the development of FRORL language discussed in Chapter 4. R. Sheu and B. Li implemented the data dependency and data flow analysis techniques presented in Chapter 5. B. Li developed the simulator for the new parallel execution model of Chapter 6 and conducted experiments described in Chapter 7. A. Liu contributed the application of how to use FRORL to describe non-functional requirements specification presented in Chapter 9. M. Lu helped the editing of the book. The work described in the book was supported, in part, by Fujitsu America, Inc.; by the United States National Science Foundation and the U.S. Defense Advanced Research Projects Agency under Grant No. CCR-9633536; and by the U.S. Air Force Rome Laboratory under Grant No. F30602-95-1-0035.

Chapter 2

Current Approaches Many problems exist in realizing parallelism in logic programs. However, various approaches exist in dealing with the three main problems: 1) data dependency analysis; 2) realization of AND-OR parallelism; 3) reducing the effect of backtracking in parallel execution.

2.1

Data Dependency Analysis

Traditionally, data flow and data dependency analysis have been investigated within the framework of logic programming. One approach to deal with the multi-directionality of a logic program has been to provide mode information for each clause (e.g., Parlog, Concurrent Prolog). Bruynooghe [10] and Smolka [87] have investigated the issue of verifying the consistency of mode declarations for arguments to predicates, as supplied by programmers. Automatic mode inference has been discussed by Mellish [70] and Reddy [80], and more recently by Bruynooghe [11] and Mannila and Ukkonen [68]. The most promising approach to mode inference so far has been presented by Debray in [29, 30]. Debray uses an interpreter to reason upon the four-valued lattice of modes don't know, empty, free, and ground. Its purpose is to enable a compiler to optimize a logic program. Mannila and Ukkonen [68] limit themselves to the simple modes ground and unground. Reddy relies on syntactic analysis to assign modes to predicates .

2.2

OR-Parallelism

If an OR-branch has more than one clause which can be unified with a predicate (a goal), then these clauses can be executed concurrently. The successful evaluation of any one of these clauses indicates the successful evaluation of the 7

8

Current Approaches

invoking predicate. This kind of parallelism is called OR-parallelism . Because the execution of unifiable clauses in this case are independent of each other, the implementation of OR-parallelism is relatively simple. The main problem in handling the OR-parallelism is how to represent the different bindings of the same variable generated from different branches. The following two classes of approach exist in this area, according to our observations. Solution OR-parallelism: Almost all systems and approaches realizing ORparallelism fall into this category. The major problem which needs to be handled is the synchronization of the multiple solutions generated from different clauses [14, 17, 42, 64]. David H.D. Warren provided a concise summary of the current approaches available within this category [102]. These methods developed various synchronization and ordering algorithms to identify and control the solutions generated from the different branches of the clause. The final results of the OR predicate is basically a join of all the possible results generated from unifiable ORclauses. In order to insure the proper join and facilitate the further cross production at the AND-nodes one level higher, various data structures and identifications have been presented. These identifications attached to a result have been presented which determine the bindings generated by different clauses. These data structures basically have to form a hierarchical structure to store the value generated at each level of the AND-OR search tree. The major data structures used under this context can be categorized as shown below: • Binding array [13, 102]; • Synchronization timestamp [41, 92]; • Version vectors [42]; The data structures listed above have the following common characteristics, which lead to inefficient implementations: • Binding data structures defined at each OR-branch point exist when the OR-parallel point is first entered and continue to exist throughout the parallel execution process until all the branches of the ORparallel point have finished execution; • Binding data structures are dynamically modified along with the execution at each branch of the OR-parallel point. This modification may come from the deeper-level predicates in the OR-parallel branches when that branch finishes execution and generates the corresponding binding.


9

The first point forces a system to bear a large overhead by maintaining many complex synchronization data structures. To make things worse, some of the data structures may not be necessary for the current ORparallel execution if some processes are not interested in the variables at the current OR-branch point [102]. The second point makes the control of the synchronization data structures complex. Specifically, the cost for creating and accessing variable bindings becomes prohibitively high. In order to cope with this problem, some of the current approaches consider an AND-OR search tree as a hierarchical structure and use the inheritance mechanism to reduce the complexity of maintaining the synchronization data structures [41, 92]. Since all possible OR-parallel branches are explored simultaneously, if all the solutions are guaranteed to be found when the OR-branches are explored, there is virtually no need for backtracking. The merging of ORparallel processes has to cooperate with the spawning of AND-parallel processes. For example, in [64] the results are gathered at OR-branches by taking a join, and only selected information is passed to the above AND-branches to reduce the complexity of control at the AND-parallel nodes. OR-parallelism combined with backtracking: This model [103] adopts the lazy approach in spawning the processes. Only when processor is idle and asks for a process, will another branch at an OR-parallel point be generated and executed. If a failure occurs at the current branch, then the remaining untouched branches of the OR-parallel point are searched. So this approach is a combination of the traditional sequential and the advanced parallel execution models. The incompleteness in the parallelism which originates from the inadequate number of processes at evaluation time requires the approaches under this category to retain the backtracking mechanism. This kind of approach can be considered as a special case of the previous approaches with a special focus on the ORparallelism and a limitation on the number of processes which can exist at the same time. So the implementation has to consider those controls which usually occur in the sequential realization, like task switching and backtracking . This is a mixture of the OR-parallelism and the general sequential evaluation of a logic program. When the number of processes existing at any time is limited to one, then the execution is sequential.

2.3

AND-Parallelism

With AND-parallelism , all predicates within a clause body must be true for a clause to be successful. The exploration of the predicates within a clause

10

Current Approaches

body can be carried out concurrently. Handling the binding conflict [33] is the major task in any implementation, and a number of approaches exist. Programmer's annotation: Programmer's annotation is the simplest method to handle AND-parallelism . It requires the users to explore and define explicitly the parallel component of a logic program [25, 83]. Even though the control is relatively simple, human involvement is definitely not our intention. Independent AND-parallelism: In this kind of parallelism, there is no variable dependency between AND-parallel goals. Predicates which share variables must have these variables bound to ground upon entering the clause [43, 46,102]. This approach restricts the AND-parallelism to a relatively simple case similar to OR-parallelism. A comparison of different independent AND-parallel models can be found in [40]. Data flow analysis for dependent AND-parallelism: One ofthe most pop ular methods is to assign only one producer for each parameter and allow multiple consumers ofthe same parameter in the program [16, 17, 28, 64]. Data-flow analysis is used to determine the producer and consumers. With a single producer, the dependency of variables between predicates can be monitored. The spawning of processes is based on this data flow information. The data flow analysis can be done either dynamically or statically, however dynamic analysis is the dominant method at the current time. Dynamic analysis generates binding information from the user's input at each step of unification. This variable instantiation changes during execution and is adjusted dynamically. Static analysis [16] generates binding information which is independent of the user's input, so that the overhead of parallelization can be reduced. But currently available static analysis approaches impose various limitations or restrictions on the results, because they either limit the number of solutions generated or the degree of parallelism. Other approaches impose similar sequential restrictions to a logic program to achieve dependent ANDparallelism [84]. Also, the accuracy of the statically generated mode information is worse than dynamically generated ones.

2.4

Backtracking

Handling backtracking is not critical in AND-parallelism and OR-parallelism, because it is possible to totally eliminate backtracking from the parallel execution model [17, 64] under the following conditions.


11

• AND-OR parallelism is supported so that all branches at all choice-points can be searched simultaneously. • All solutions implied by the logic program can be expressed and generated from the parallel execution model. Even though some of the interesting developments in various approaches for handling backtracking are not necessarily under the context of parallel logic program model, they are still worth mentioning. There still exist a lot of approaches in the logic program parallelization community which explicitly handle backtracking because of the insufficient power to guarantee the above two criteria. Basically, there are two different kinds of backtracking mechanisms, shallow backtracking and deep backtracking . Shallow backtracking backtracks to alternative candidate clauses when the head of the current candidate clause cannot be proved a success by the unification with the calling literal. Deep backtracking backtracks to any previously invoked procedure which has a choice-point. This is also called intelligent backtracking . Intelligent backtracking: Conventionally, whenever a failure occurs during a search, backtracking is done to the nearest choice-point to explore other branches. In intelligent backtracking , instead of backtracking to the nearest choice-point, backtracking goes to the choice-point where the binding of the variable which causes the failure can be bounded to another variable [60]. Research in intelligent backtracking which handles other related aspects, like cut, tail recursion, etc., also exists. In [23], the pruning of the paths which could be explored several times by the conventional backtracking scheme is studied. Improving backtracking by using data dependency information was first proposed in [24]. Later on various researches considered intelligent backtracking handling in the AND-parallelism of the AND-OR parallel execution model of a logic program [8, 22, 34, 105]. Semi-Intelligent backtracking: Semi-intelligent backtracking uses static data dependency analysis for the AND-parallelism . Chang and Despain [15] use this technique to find the optimal choice-point for intelligent backtracking . Since the mode information is not sufficient to support the multiple solutions exploration, backtracking is necessary in their model. The binding status considered is only the worst case binding combination, which may involve inaccurate binding information. As a result, their approach can only achieve semi-intelligent backtracking . Elimination of backtracking: The AND-OR parallel execution model can completely eliminate backtracking from the execution of a logic program [17, 64]. Few results have been produced because most current

12

Current Approaches approaches are unable to find all the solutions implied by the underlying logic program. Another problem is that in order to eliminate backtracking, a lot of nodes have to be searched simultaneously. So the total number of processes exist at any time is much larger compared to backtracking models. In practice, the management of these processes and communication cost among them may offset any advantages achieved by eliminating backtracking . So even though many approaches declare that they have excluded backtracking from their model, nobody so far has addressed the problem of how to manage the vast processes generated during the parallel evaluation process. Backtracking elimination only stays at a theoretical level. Instead, most of the current approaches realize parallelism by adopting some degree of backtracking .

Chapter 3

Overview of t h e New Approach In the previous chapter we explored the current approaches for dealing with data dependency analysis, AND-parallelism , OR-parallelism , and backtracking of a logic program. In this chapter, we will outline a new approach and discuss how it handles the problems mentioned in Chapter 2. Figure 3.1 shows the major components of the model and their interrelations. The system starts from a FRORL logic-based requirements specification with non-monotonic inheritance mechanism. There are two different kinds of frames within a FRORL specification, namely, object frame and activity frame. Object frames describe entities within the problem domain. Activity frames describe actions taking place within the problem domain. The system then applies the inheritance expansion algorithms to eliminate the non-monotonic inheritance within a FRORL specification [98]. There are three algorithms to implement the expansion of the object and activity frames in a FRORL specification. After eliminating inheritance mechanism from a FRORL specification, all that remains is a pure Horn-clause logic-based requirements specification. In order to facilitate static data flow and dependency analysis, rewriting rules is applied to the Horn-clause logic-based specification. There are four kinds of operations for rewriting. The rewritten logic-based specification is applied by the static data flow and dependency analysis. The mode generated here is used to support both a hybrid AND-OR parallel execution model and an automatic transformation system, which transforms a logic-based specification into a procedural language program. The executional behaviors demonstrated during AND-OR parallel execution can be used to compare with the functional and non-functional requirements described in FRORL to see if any mismatches 13

14

Overview of the New Approach

exist. Basically, our approach is a combination of the following four techniques. A comparison of the new model with the best first search and depth first search will be discussed in a later chapter. Automatic non-monotonic inheritance expansion: This is the starting point of the whole execution model. The object and activity inheritance hierarchies in a FRORL specification are expanded so that each frame is represented by its ultimate frame image. The expanded logic-based specification has a format similar to a Horn-clause logic-based specification. Static data flow analysis: In this step the multiple execution sequences in a logic-based specification are found. These results are consulted during parallel execution to determine those predicates which can be evaluated in parallel. In order to facilitate the data flow analysis, non-monotonic expansion is followed by rewriting rules, which include equal-introduction , equal-substitution , decomposition and simplification . The logic-based specification is thus converted into a form suitable for the application of data flow and dependency analysis. Note that these rewriting operations often need to be repeated considerably. In the process of transformation, new conclusion of the analysis may cause the operations to become applicable, thus the rewriting process stops only when the specification reaches a stable state. Based on the analysis of data dependencies and flow analysis, mode status is inferred. Automatic transformation: The transformation of FRORL into a procedural language program discussed in this book relies on an integration of the analytical approach for transforming the nondeterminism of logic-based specifications and the knowledge-based approach for generating target code. This helps to avoid some of the complexity pitfalls like deductive program synthesis. The main problem in the transformation system is the efficient handling of backtracking . The approach presented here tries to adopt the accurate mode information to support the intelligent backtracking . Hybrid A N D - O R parallel execution model: This AND-OR parallel model uses mode information gathered statically and the user's input to explore all the predicates which can be executed in parallel. These predicates may come from different levels of the corresponding AND-OR tree. The parallelism of the predicates determined by the static data dependency information will be carried out in a bottom-up fashion. If there is no predicate which can be executed in this way, then the general top-down execution model will be used.


15

Simplified OR-parallel synchronization model: The synchronization data structure at OR-parallel nodes can be realized with reduced complexity compared to the current approaches. According to the new AND-OR execution model depicted above, the duration of the synchronization data structure can also be reduced. Backtracking elimination: Since our approach can generate all the solutions based on the static mode information, it can eliminate backtracking from consideration by implementing the new AND- and OR-parallelism . The cost to manage parallelism is also reduced. In fact, by reducing the number of processes generated and the duration of these processes, our research is the first to consider what the management cost of the total parallelism will be. We also find a way to reduce the complexity so that the elimination of backtracking actually becomes applicable.

3.1

Non-monotonic Inheritance Expansion

This is the first transformation step in the system. The purpose of this step is to transform a FRORL specification with inheritance mechanism into a Hornclause logic-based specification without containing inheritance structures. This step is necessary since inheritance structures cannot be handled by the transformation steps, and almost all of the conventional procedural programming languages do not support inheritance. The transformation of a FRORL specification into a Horn-clause logic-based specification can be divided into two different approaches based upon different ways to handle non-monotonic inheritance. The first approach is to expand the entire frame into its ultimate set thereby eliminating the inheritance mechanism used in FRORL. This approach will transform a FRORL specification into a pure Horn-clause logicbased specification without inheritance. The second approach is to preserve the non-monotonic inheritance mechanism of FRORL during the transformation process. This approach will require a meta interpreter along with the specification. Every time the specification is called, this meta interpreter will be invoked to generate the corresponding specification without inheritance. Currently the first approach is used in our system and a detailed comparison of these two approaches can be found in later.

3.2

Static Data Dependency Analysis

The system relies on a new data dependency analysis algorithm, which can find out all the possible mode combinations within a logic clause, to implement the


16

(_ FRORL Logic-based Requirements Specification

J

Non-monotonic Inheritance Expansion [_ Horn-clause Logic-based Requirements Specification

j

V Rewriting Equal-Introduction

Equal-Substitution

Decomposition

Simplification

'' Rewrited Logic-based Specification

\' Static Data Flow and Dependency Analysis

' [ D a t a Flow and Dependency M a t r i x )

Execution Control Sequence Determination

User's Query

Hybrid AND-OR Parallel Execution Model

Adjusted Rewrited Logic-based Specification

Intelligent Backtracking

Figure 3.1: An overview of the system

new parallel execution of logic-based specification. A comparison with the other approaches realizing data dependency analysis [98, 97] shows that our approach has the following advantages: (1) four-valued lattice to represent the mode value in a data dependency matrix; (2) multiple mode preservation in the resulting data dependency matrix. These two points, especially the second one, are very important for the new parallel execution model. It is the basis for eliminating backtracking from the model. This static mode information will also be used in the hybrid AND-parallel model to find the predicates at different


17

levels of the AND-OR tree which can be executed simultaneously. The static analysis algorithm is followed by the AND-OR parallelism generation process.

3.3

Automatic Transformation

The automatic transformation is supported by mode information generated above [98, 99, 97]. This mode information is essential to make adjustments to the execution sequence of a logic-based specification so that the resulting execution sequence can be expressed in a sequential, procedural language. Next, the functional procedures are generated for each clause in the specification, and the backtracking control mechanism behind a logic-based specification is implemented by a revised WAM. This WAM is included in a run-time system which will select the actual procedures and execute them based on the decision made by the WAM. As another effect, this run-time system is also responsible to resolve the multiple executional directions of clauses in the logic-based specification. Mode information can be used to achieve the effect of intelligentbacktracking.

3.4

Hybrid AND-OR Parallel Execution

In order to handle AND-OR parallelism , a bottom-up combined with topdown scheme is used. Current approaches always work from the top of an AND-OR tree and search all the way down it. Instead, my approach can find all the mode combination before the user's query is available, it is possible that while the execution goes on, some information about the operation which will be executed several steps further may be available in advance. If we carry out those operations first, then the efficiency may be improved. The approach uses the result generated from the static data flow analysis, combined with the user's input, to find out the portion of the AND-OR tree of which the execution behavior is deterministic under the current variable binding. This portion of the AND-OR tree is executed in a bottom-up fashion. The checking process is applied whenever a new unification occurs which changes the binding of a variable. The algorithm is based on the generation of grounded variables as the start point for the checking of statically executable portions. The dynamic checking will only focus on the detection of the newly generated grounded variables. Comparing with other approaches, which rely totally on the user's input query to initiate the analysis, the execution of theirs thus are based on the dynamic determination of data flow information. So the analysis is dynamic and the parallel processing executes in a top-down manner, which inevitably puts tremendous overhead on the system.

18


In our model, instead of evaluating dynamically, all the possible variable binding and execution information is included in the statically generated data dependency matrix and the execution sequence is adjusted by this matrix. A very important property of data dependency matrix is that it has all the possible execution sequences based on the multiple data dependency information. The only role a user's query plays is to initiate the analysis. At each step of the execution, especially whenever a new binding of a variable is generated, this information is used to restrict the multiple data dependency choices existing in the data dependency matrix and the possible execution sequences they imply. This restriction may result in only one possibility for the execution of a clause. The execution of this clause, along with the deterministic portion of other clauses, is carried out in the next step. So large part of the analysis of our approach is done statically instead of dynamically. The execution proceeds like this: we start from the root of an AND-OR tree , which corresponds to the user's query, then at each step of the unification, which is the case where a predicate is unifying with the heads of unifiable clauses, a variable binding is generated which will restrict the meaning and execution behavior of the clause. The system locates the branch of the AND-OR tree, which may not be the predicates from a single clause based on the multiple binding, so that the execution behavior of this branch is restricted to a single choice, and then execute this branch in a bottom-up fashion. All the remaining branches which can not be restricted to a single choice will be executed in the general top-down way. This is where multiple solutions of a query arise. Even in this case, the static data dependency matrix can still help to improve performance. Since all the solutions have been represented in the data dependency matrix, the place where this multiple choices occurs is also decidable from the same matrix. So the generation of multiple choices can be predicted by the parallel execution model.

3.5

Simplified OR-Parallel Model

The problem of preserving the multiple choices generated from the OR-branches can be handled with the help of the same data dependency matrix. As mentioned above, the major problem of OR-parallelism is to synchronize the multiple bindings of the same variable from different branches. The only thing we need to do here is to build a simple synchronization mechanism above the data dependency matrix, considering that all the binding information is supported by the matrix. Based on the analysis of the AND-OR parallelism, there exist two execution models, top-down and bottom-up . The synchronization of OR-parallelism is also closely related to these two models. During the execution, if we find out


19

that the current parallel execution of a logic program is in the top-down fashion similar to the current approach, then the OR-parallelism synchronization is identical to the current approaches by using any of the currently available data structures and methods. If the execution proceeds in a bottom-up fashion, then the binding data structure is also generated in a bottom-up fashion, which will eliminate data structures for binding purposes to only one level. Comparing with other approaches, which have to keep a binding data structure for all the OR-processes spawned now and before, this is a major improvement. Also the creation of all these binding data structures can be delayed until all the variable bindings have been generated from all the branches of an OR-parallel point. The current approaches have to generate a binding data structure upon the first entry of the OR-branch, and keep changing the binding data structure to reflect the change of binding status of variables. Our approach can reduce the life cycle of the binding data structures until they are actually needed to generate the complete binding combinations from OR-branches.

3.6

Backtracking Elimination

The above new execution approach deals the AND-OR parallelism of a logicbased specification, i.e., it tries a new hybrid executional model to improve the efficiency of the system. Because all the execution possibilities and all possible binding status of variables in a logic program can be found out from the data dependency matrix, it is possible to totally eliminate backtracking from the model. The basic idea is to explore all possible AND- and ORbranches in parallel, thus all possible paths are searched and backtracking can be eliminated from the scheme. The most significant property of our method is that it can preserve the multiple solutions a logic-based specification can generate even before any actual execution.

Chapter 4

F R O R L Requirements Specification Language and Its Decomposition Early artificial intelligence systems relied on first-order predicate logic as a language to represent domain knowledge. Even though this scheme is general and semantically clear, it has been found to be inadequate for organizing large knowledge bases and for encoding complex objects. As a result, various framebased languages have emerged. These languages are designed to support the natural representation of structured objects and taxonomies. They have been proven to be well suited for representing many useful relations. FRORL (Frame-and-Rule Oriented Requirement Specification Language) [93] was developed to facilitate the specification, analysis and development of a software system. FRORL uses frame representation for object-oriented modeling and employs production rules for specifying actions and constraints of the real world. Object-oriented design enhances the naturalness of representation. A frame representation is used for structural description of domain objects, while a production rule is able to specify the behaviors of objects and interactions/relationships among them. A frame, as a node, lies in a cycle-free hierarchical network. The links which connect the frames represent the abstract relations among the frames. The root node represents the most general concept of the family of all its descendants, while nodes in the lower levels of the frames stand for more specific instances of those concepts. The nodes in the lower levels may have some abstract relations to their higher level nodes. The surface syntax of FRORL is based on the concepts of frames and production rules which may bear hierarchical relationships amongst each other, 21

22

FRORL Requirements Specification Language and Its Decomposition

relying on multiple inheritance . However, to provide thorough semantic foundations, FRORL has been based on a non-monotonic variant of Horn-clause logic. Using the machinery of Horn-clause logic, various properties of a FRORL specification can be analyzed. The underlying logic of FRORL is sound and complete. Among the external properties of FRORL are formality , objectorientedness , wide-spectrum of life cycle phases; while the intrinsic properties are modularity , provision for incremental development, inheritance , refinement , re-usability , prototyping , executability , knowledge base environment, theorem proving capability and graphics support.

4.1

Knowledge Representation through ObjectOriented Model

In an object oriented model, object, classification , inheritance , and communication with messages are the components of the model. The object is an encapsulation of attributes or abstraction of something in the problem domain. A class groups homogeneous objects with identical properties as its instances. An object is referenced to by a unique identifier and possibly by one or more keys. A class may have several superclasses from which it inherits properties. It may also have several subclasses . A class definition includes a set of attributes describing the instances of the class. All the information concerning an object is stored in its attributes. Attributes describe the state of objects. The state of an object is captured in the instance variables. The class hierarchy captures the hierarchical relations between a class and its subclass (also, a class and its superclass). All subclasses of a class inherit all properties defined for the class, and can have additional properties local to them. The notion of property inheritance along the hierarchy facilitates top-down design of the database as well as applications. The behavior of an object is captured in messages to which an object responds. The messages define the semantics and the functionalities of the object. Using FRORL to specify a software system is similar to the object-oriented design strategy as described in [21]*. As far as inheritance goes, the three reserved words anJnstance-of, a-kind-of, and a-part-of represent the hierarchical relations of instantiation , generalization , and aggregation , respectively, among frames. Generalization allows a class to capture common characteristics shared by a group of individuals. For example, if X is a generalization of Y then the abstract relation says that Y is a-kind.of X. Instantiation instantiates an individual from a class of entities. For example, if X represents a class of EECS graduate students, and Dean Schulz is an EECS graduate student, then the abstract relation says that Dean Schulz is anJnstance-of X. Aggregation is ' M a n y researchers have also applied object-oriented approach to deductive database to offer structured object and deductive capability. See [50].


23

the abstraction by which an entity is constructed from its constituent entities. For example, if X is composed of W, Y, Z then the abstract relation says that Z is ajpart-of X. The developers are encouraged to apply the proposed three kinds of abstract relations to represent hierarchical inheritance among frames. Thus the requirements specifications will be more concise, and one can get more inferential information via abstract relations .

The system using FRORL is based on the following overall strategy. Given an informal description of the problem domain, we construct a representation of the problem and the domain using frames and production rules. People tend to have little difficulty in constructing object hierarchies using frames. Production rules can be easily understood by domain experts. FRORL also supports the feature of operational interpretation. The production rules serve to guide the execution mechanism in the application domain. The operational interpretation of the FRORL representation can understand and validate the system behavior against the informal user requirements. The machinery of FRORL base logic [56, 57, 59] is available to perform properties checking of the specifications. The prototype specifications are continually tested and modified until the original requirements and constraints are shown to meet the model of the prototype.

4.2

The Modeling Primitives of FRORL

The FRORL modeling primitives are objects and activities. Each object in the model stands for some entity in the world being modeled. Changes taking place in the world and relations between entities of the world are represented as activities in the requirement model. Each object and activity has certain properties, assumptions, or constraints associated with it. The information related to objects and activities is expressed using the frame representation. The structure of the executable specification written in FRORL is modularized into different activities. Because of this modularization, frames are relatively easy to reuse.

4.2.1

Object Frame

In FRORL, the objects are the entities that represent "things" in the world being modeled. An object also can be seen as a data format (a data structure) or a data type in a software system. Each object has its own attributes or properties. The syntax for the object frame is given below:

24

FRORL Requirements Specification Language and Rs Decomposition Object: object^name abstract-relation: parent-name; attribute-namei: valuei; attribute-namen:

valuen.

There are two kinds of slots in each object frame, abstract relation and attribute. The abstract-relation slot represents the inheritance relations between the current frame and its parent frame. The name of an abstract-relation slot can be aJtind-of, a.part-of, or anJnstance-of. The value set of the abstractrelation slot, parent_name, permits multiple object names because FRORL allows multiple inheritance representation. The attribute slot represents the particular properties of an object. Each property has a value set associated with it from which it can draw the value. The value set may contain either a single element or a list of elements. We introduce the following example of object frames to represent their inheritance properties. Object phone-call, which is a general class, has two attributes namely, caller J d and callee Jd, for the main characteristics. Object three-way-call is a subclass of phone_call. The three_way_call means that three parties can be on the same line and talk simultaneously. According to the proposed approach, we can say that three-way-call is a kind of phone-call. One major attribute of three-way-call is 2nd_calleeJd. John_Joe_David-call is an individual of the three.way.call class. According to the definition of abstract relations , three-way_call is the class of John.Joe_David_call. We can say that John_Joe_David_call is an instance of three-way-call. These three hierarchical objects bear inheritance relations among each other. The three-way-call class and JohnJoe_David_call can inherit all attributes presented in the phone^call class naturally. We can depict the special condition or treatment in the object John_Joe_David.call because John_Joe_David-call has general attributes of the three-way-call class. These three objects are as follows.

Object: phone-call callerdd: ; calleedd: . Object: three.way-call a-kind.of: phone.call; 2nd.calledJd:. Object: John-Joe-David-call anJnstance.of: three^way.call;


25

callerJd: 226-7083; calleeJd: 996-7251; 2nd.calleeJd: 413-5352. E x a m p l e 1 This example is adopted from the Local Switching System General Requirement (LSSGR) protocol [93] which is written in FRORL. The LSSGR protocol is proposed for automatic completion of reverting telephone calls. Here we present only two object with their meanings.

object: reverting-call callerJd:; callee-id:. object: two-party-call a-kind-of: reverting-call; party-line-type: two-party. The first frame defines a reverting call to be a call in which a party line customer dials the number of another party on the same line. The second frame shows that reverting call allows a two-party line customer to complete a call to other party sharing the same line without the assistance of an operator (the second frame). Based on the functionality of the two frames, the second one should be a child of the first one, thus the hierarchy.

4.2.2

Activity Frame

The changes that take place in the actual world are referred to as activities in FRORL. Each activity is represented as a frame. The activity frame has four slots, namely: parts, precond (precondition), actions, and alt_actions (alternate actions). The structure of the activity frame is as given below.

Activity: activity-name(attr-valuei,..,attr-valuen) parts: attr-valuei: valuei; attr-valuen: valuen; precond: boolean combinations of activities or facts; actions: sequence of activities or facts; alt-actions: sequence of activities or facts.

26


The parts slot contains the objects or the attributes of objects participating in an activity. The precond slot is the constraints associated with an activity. If the contents of the precond slot are satisfied, then the actions slot will be executed. The contents of the actions slot could be either the other activities or some facts* about the world. The alt_actions slot contains the sequence of activities to be performed or the assertions to be made in case the precond slot is not satisfied. Activities are initiated with values as arguments or they may be passed as uninstantiated variables which will receive values as a result of performing the activity. Variables may be instantiated to lists. Here we use an example to illustrate activity frame representation. Suppose in a telephone system, a caller wants to dial a number. It is required that the dial tone is available before dialing a number, otherwise the switching system will give an alarm (a reorder tone) and the caller has to redial the number. In this system, we can create an activity called dial_a_number(Phone_number). In this activity, the "parts" slot is composed of the phone number to be dialed. If a dial tone (sound(diaLtone)) is available then it proceeds to complete the call (complete_the_call(Phone_number)). Otherwise, the reorder tone is on (reorder.tone()) and the caller has to re-dial the number (diaLagain(Phone-number)).

Activity: dial-a-number(Phone.number) parts: Phone-number; precond: sound (dial-tone); actions: complete-the-call(Phone-number); alt-actions: reorder.toneQ; dial-again (Phone-number). E x a m p l e 2 The two activity frames in LSSGR are discussed in the following along with their meaning.

activity:

complete(X) parts: X: reverting-call; actions: initiate.busy-tone(X); ringing (X).

activity:

initiate.busy-tone(X) parts: X: reverting-call;

tFact is some assertion about the world, it could be either asserted objects or activities which do not have any precondition, action.

Hybrid Parallel Execution Model actions:

27

apply.busy-tone(X.callerJd); wait-for-disconnect(X).

The first activity frame means that the system should attempt to complete reverting calls automatically by initiating a busy tone to the calling party and then ringing the two parties. A busy tone should be applied to the line as soon as the call is recognized as a reverting call. The second activity frame indicates that communication line should be monitored for disconnect and the tone should be removed on disconnect.

4.2.3

Reserved Words

Reserved words contain keywords and built-in operations in the FRORL system. Some of the keywords in FRORL are object, activity, parts, precond, actions, alt-actions, and so on. Built-in operations, such as findstate(X), get-word(X), and increase(X,Y,Z), are predefined to save time for the developers. Common primitive functions can be defined as built-in operations and embedded in the system for direct access. There are two kinds of built-in operations: domain-independent operations and domain-specific operations. The domain-independent operations are basic operations in general applications; the contents of these operations will not be changed in any application. The domain-specific operations are just the converse. The developers should avoid redefining reserved words as having other meanings. To allow for the executability of the specification, we have provided a number of frequently used operations in five categories: state operations, conditional operations, arithmetic operations, list operations, and input/output operations. They are organized in the knowledge base . Domain-specific operations are primitive operations in some application domain. For example, the operations send(Command) and receive(Command) are basic operations in a fire control system. If the system can provide these particular operations, the developers only need to define higher-level activities. Even though the definition of these particular operations is highly recommended, it is not a decisive part to form a correct FRORL specification. Experience shows that these primitive operations can alleviate the burden from user to form a complete specification.

4.3

Decomposition of a FRORL Requirements Specification

This is the first transformation step in the system. The purpose of this step is to transform a FRORL specification with inheritance into a Horn-clause logicbased specification without inheritance structures, since inheritance cannot be

28


handled by the future analysis steps. A simple decomposition of a FRORL specification is given in Figure 4.1. After discussing the non-monotonic inheritance mechanism in FRORL, three algorithms to achieve this kind of transformation will be presented. In the end, a LSSGR protocol example [93] and its transformation process will be illustrated. Image(A)={

Figure 4.1: An example decomposition process

4.3.1

FRORL and its Non-monotonic Inheritance Mechanism

As mentioned before, one of the important properties in FRORL is the multiple inheritance relations among hierarchical frames. Property inheritance can reduce a redundant depiction and allows one to concentrate on the differences between parent and child frames rather than on what must be described at each level of specification representation. In FRORL, we use three reserved words An-Instance-Of, A-Kind.Of, and A-Part-Of to represent the hierarchical relations of instantiation , generalization , and aggregation , respectively, among frames. Instantiation allows an instance to capture common characteristics of its superclass shared by a group of entities in a problem domain. Generalization allows a superclass to capture the common characteristics of several subclasses. Aggregation is the abstraction by which an entity is declared to be a component of another entity. If child entities and parent entities have the relations of instantiation {AnJnstance-Of) or generalization (A-Kind-Of), the children will naturally inherit the full properties from the parent unless the children have exception declarations. An instance of aggregation (A-Part-Of) abstract relations means that a frame declares itself as a component part of


29

its parent (whole) frame. The child entity only inherits the partial properties from the parent entity.

4.3.2

Transformation of FRORL into Horn-clause Logicbased Specification

The transformation of FRORL into ultimately a procedural language program is our goal. To realize it, careful study of the logic semantics and its nonmonotonic inheritance mechanism is necessary. As a logic-based specification language, FRORL embodies non-determinism concerning the selection of next clause in the execution sequence. In addition, its non-monotonic inheritance mechanism makes it very difficult to directly apply other transformation processes, such as data flow analysis, execution sequence determination and so on, to a FRORL specification. Consequently, we have to find an intermediate form so that (1) it is relatively convenient to apply data flow and dependency analysis, and (2) it can provide a way to handle the FRORL's non-monotonic inheritance feature. In this system, Horn-clause logic-based specification is selected to play this role since the logic foundation of FRORL is built on Horn-clause logic extended with non-monotonic inheritance. The transformation of a FRORL specification into a Horn-clause logic-based specification can be divided into two different approaches based upon the characteristics of nonmonotonic inheritance. The first approach is to expand the entire frame into its ultimate set and therefore eliminate the inheritance mechanism used in FRORL. The second approach is to preserve the non-monotonic inheritance mechanism of FRORL during the transformation process. At first glance, it seems that the first approach achieves the transformation much more easily. However, it has a serious drawback when a FRORL specification contains large and deep frame hierarchies. The expansion of frames can grow at an exponential rate. This problem is further complicated by having multiple inheritance among the frames. Maintenance of the expanded clauses presents another problem. Whenever there is a change to a parent frame, we must regenerate the frames of its children and descendants' frames in order to maintain consistency . In order to effect the second method, it will be natural to keep the inheritance mechanism in the transformed specification using some kind of inheritance meta-interpreters. However, this approach has its own problem: the efficiency of execution during query of goals suffers since the specification interpreter will have to perform the inheritance inference every time. This problem will make the slow execution of a Horn-clause logic-based specification interpreter even slower. It is very clear that the choice between these two approaches is the trade-off between computing time and storage space. We choose to expand the entire frame into a Horn-clause logic-based specification.

30

FRORL Requirements Specification Language and Rs Decomposition

4.3.3

Algorithms for Non-Monotonic Inheritance Handling

In this section we will discuss in detail the transformation of a FRORL specification into a Horn-clause logic-based specification. This will require special procedures to generate the expanded image of a given frame in an inheritance structure . In the following, we will focus on three algorithms for handling multiple inheritance . Before the algorithms for image expansion are presented, it is necessary to introduce some definitions in order to facilitate the expansion. Definition 1 An inheritance structure of FRORL is defined as the 3-tuple G = (F, Map, L); where F is the set of frame nodes, Map is a function from a pair of frames in F to an inheritance link, and L is the set of possible inheritance links as defined in the following. F: Name x Argument x {<slot> : <slotjvalue> }" Map: F x F —> L is a mapping function from a pair of frames to a link. L: {Aio, Ako, Apo} is a finite set of inheritance links, in which Aio, Ako, Apo represent An_instance_of, A_kind_of, A_part_of respectively. Definition 2 In an inheritance structure G, a PList(Inh, F) is a parent list, i.e. the set of frames which correspond to the slot values of the inheritance slot Inh of the frames, F; where Inh 6 {Aio, Ako, Apo}; In an inheritance structure G, a CList(Inh, F) is the set of child frames of a given frame, F; where Inh € {Aio, Ako, Apo}. The above definition defines the parent frame set and the child frame set. Specifically, the frames in PList set are the ones we need to consider to do expansion. Definition 3 The inheritance distance , ID, for an attribute, A, in a slot Slot, of a given frame, F, is the number of inheritance links required to "trace back" to an ancestor frame with the attribute A included in it. That is, lD(A,Slot,F) lD(A,Slot,F) m(A,Slot,F)

= 0iiAe F = liiAePA =niiAePnA

DirReach(P, Inh, F) IndReach(P n , Inh, F);


31

where Pn is obtained by recursive definitions as follows: IndReach(P\ 7n/i,F) = DirReach ( P , / n / i , F ) ; IndReach(P n , Inh,F) = DirReach(P n , I n ^ P " " 1 ) A IndReach(P n - 1 ,7nft,P), where n > 2.

This attribute is necessary when there is a conflict existing in the multiple inheritance . i.e., if the attributes inherited from different paths contradict each other, then the attribute with smaller ID value will be inherited by the current frame. This value is maintained by increasing the value by one whenever the search goes one level deeper. Definition 4 An ancestor frame, P , is directly reachable , DirReach(P, Inh, F) = True, from a given frame, F, through inheritance links of FRORL. DirReach(P, Inh, F) = True & P 6 PList( Jn/i, F) A Inh € { Aio, Ako, Apo } An ancestor frame, P , is indirectly reachable , IndReach(P, Inh, F) = True, from a given frame, F, through inheritance links of FRORL. IndReach(P, Inh, F) = True & DirReach(P', Inh, F) A DirReach(P, Inh, P') IndReach(P, Inh, F) = True & DirReach(P',Inh,F) A IndReach(P, Inh, P') If an ancestor frame is directly reachable , then it must be in the PList set. As mentioned above, these are the frames we need to consider when doing a frame expansion. Definition 5 An inheritance image , Image(P), of a given frame, F, is a frame with all the attribute slots inherited from its ancestor frames reachable through inheritance links. This image information is exactly what we need to find for each frame in the inheritance hierarchy. Definition 6 A group of frames, G= { < Fi, ...., F„ > } in FRORL is consistent iff there does not exist a pair of < F;, F^ >, where Fj, Fj € G, such that

32

FRORL Requirements Specification Language and Its

Decomposition

IndReach(Fj,Inh,Fj) A IndReach(F,-,/n/i,Fj). This definition ensures that a FRORL specification is acyclic so that the search will never go into an infinite loop. Definition 7 An ancestor frame, P, is reachable, Reach(P, Inh, F) = True, from a given frame, F, through inheritance links of FRORL. Reach(P, Inh, F) = True O DirReach(P, Inh, F) V IndReach(P, Inh, F) This definition helps us understand that only reachable frames from the current frame being expanded can contribute to the attribute set of the frame. Definition 8 The slot attribute membership function, Attribute(F, Slot), for an attribute slot, Slot, of a given frame, F, is "true" iff "Slot" exists syntactically in the frame, F, i.e., slot is a syntactically "visible" attribute slot of frame, F. Attribute^, Slot) = True <s> F.Slot exists. This set includes all the attributes which should exist in the final image of the expanded frame. The attributes in this set can come from two sources. One is the set of attributes explicitly defined in the current frame, another is the set of attributes inherited from the hierarchy. The purpose of forming the final image of a frame is to find these two sets for each frame. Definition 9 The set of non-inherited (direct) attribute slots, DirSlot(F), for a given frame, F, is as follows: DirSlot(F) = {Slot | (V Slot) Attribute^, Slot) = True} The set of inherited (indirect) attribute slots, IndSlot(F), for a given frame, F, is as follows: IndSlot(F) = {Slot | (V Slot) Attribute(P, Slot) = True A (DirReach(P, Inh, F) V IndReach(P,7n/i,P))} The attributes in DirSlot correspond to the first set in the previous definition, while those in InDslot are inherited from the hierarchy. These two sets combine to form the complete definition of a specific frame.

33

Hybrid Parallel Execution Model Definition 10 The function for a set of slot values in predicate form, SlotValue(F, Slot, V), will take any two variables from the set {F, Slot, V} as the bound inputs with the third variable unbound. The result of invoking this predicate function is to "bind" the third variable with a proper value and the bound value could be a unique value or a multiple value set. It can also act as a constraint checking predicate by taking all three values as input: SlotValue(F, Slot, V) = True <S> Slot G IndSlot(F) U DirSlot(F) A Slot.value = V.

This is a very useful function for retrieving frame slot value information when doing expansion. Example 3 Consider the object frames of the simplified FRORL specification for LSSGR protocol introduced in the previous section.

object: reverting-call caller-id:; calleeJd:. object: two-party-call a-kind-of: reverting-call; party-line-type: two-party.

We have the following results PList(afco, two-party -call) = {revertingxall} CL\st{ako,reverting-call) = {two.party_call}

Definition 2 Definition 2

lD(two-party,party Jine-type,two-party-call) = 0 ID(Va,l\iecauer_id,caller Jd,two-party-call) = 1


DivKeach.(revertingjcall,ako, IndReach(revertingjcall,ako,


two-party-call) = True two-party .call) = False

lmage(twojparty -call) = jailer .id :; calleeJd :; partyJineJype

: two-party. }

Definition 5

Ccms\stent(r everting-call, two-party-call)

= True

Definition 6

34


Reach(reverting -call, ako,two-party -call) = True

Definition 7

Attribute(two-party-call,partyJineJype) = true Attribute(iwo_part2/_ca/Z, caller-id) = False


T>\xS\ot{two-party .call) = { party line-type } IndSlot {two-party-call) = { caller Id, calleeld }


S[otValue(two-party-call,party line-type,two jparty) — True Definition 10 Slot\&\ue{two-party-call,partylinelype, X) o X — two-party Definition 10

In the following we introduce three algorithms to perform the nonmonotonic image generation. These algorithms deal with the hierarchical structure of a FRORL specification and generate the expanded specification from the original one in a top-down manner. They start from the root of an activity or object frame hierarchy, and generate the expanded image layer by layer, i.e., they will first generate the expanded image for the root frame, and then generate the expanded images of the direct children of the root, and their direct children and so forth. When the three algorithms are arranged in this way, it can be shown that even if the inheritance may involve the retrieval of attributes from more than one level toward the root of the hierarchical structure, the formation of the attribute set for a frame will only need to consider one level above the inheritance hierarchy, instead of possibly going through a large number of levels in the hierarchy. Consider two levels in an inheritance hierarchy of frames, namely levels i and j , i < j . Assume there is an inheritance path from a frame Fi in the level i and another frame Fj in the level j , and there is an attribute Attr^ which is denned in the frame Fj and no other definition of the same attribute exists along the inheritance path from Fi to Fj. According to the formal definition of the inheritance structure , in order to define the attribute Attr^ in the frame Fj, the search must go all the way along the inheritance path back to the frame Fi to find the definition of the same attribute. But in our algorithm, instead of going back to the frame Fi in the level i, only one level of retrieving, i.e. we only need to go up one level to find the frame, say -Fj-i in the level j — 1 of the inheritance path in order to find the desired definition of the attribute. This is true since our algorithm adopts a top-down mechanism, and it guarantees that the attribute in question has already been included in the frame F j - i in the level j — 1 before the expansion mechanism reaches the frame Fj in the level j . Note that the first algorithm is used only for the image expansion of object frames in an inheritance hierarchy. The algorithm for expansion of activity frames will be introduced in the second algorithm. These two algorithms will call a common subroutine to accomplish expansion.

35


The algorithm for expansion of object frames and the algorithm for expansion of activity frames have different main functions. This difference comes from the fact that the inheritance mechanism for object frames and activity frames are different based on the formal definition of FRORL[93]. But considering the body of these two main functions, they all call the same subroutine "inherit-from-parents". It is possible to share an identical main routine for these two functions since all the different aspects of inheritance have been considered and dealt with in the algorithm and only the identical operations are defined in the subroutine. ( Begin ) G = FRORL Specification mark all frames in G as unexpanded

Output expanded object frames in G

Select an unexpanded object frame F from G which meets one of the two criteria listed to the right.

( Stop )

Add all F' s direct slots to Image(F) Let ID[A11 predicates in F] be 0.

(l)Fhasno antecedent, or (2) All F's antecedents have been expanded.

Y yS¥ has no \ N parents? Set "Parents" to be all the parent object frames of F.

T

Call inherit_from_parent with "Parents", F, and Image(F) as parameters.

wait for return value Image*(F).

Mark F as expanded.

Figure 4.2: The flow chart of "NMJmageGenerator_for_ObjectJFrame"

36


( Begin ) G = FRORL Specification mark all frames in G as unexpanded

Y ^ ^ A l l Activity^ ^frames have been^ .expanded in G^ (1)F has no part, or Output expanded activity frames in G

Select an unexpanded activityframeF from G which meets one of the two criteria listed to the right.

( Stop )

Add all F's direct slots to Image(F) Let ID[A11 predicates in F] be 0.

' F has no \ parents?

(2) If one of the antecedents of F's parts acts as a part of activity frame G, while G has the same name as that of F, then G is expanded.

N

Set "Parents" to be all those frames similar to G.

Call inherit_from_parent with "Parents", F, and Image(F) as parameters.

wait for return value Image' (F).

Mark F as expanded.

Figure 4.3: The flow chart of "NMJmageGenerator_for_Activity_Frame"

37


(Begin) Initiate F, Image(F), and "Parent", mark allframesin "Parents" as unparsed.

All frames in "Parents" have been expanded and F is unexpanded.

| Select an unparsed frame Gfrom"Parents". I For the next unchecked Direct slot "Slot" in G r If Slot Image(F)

Mark G as parsed

Figure 4.4: The flow chart of the algorithm "inherit.from_parents"

38


Parents Set: ParentJ

Parent_n

Q Slot

'd

Image(F)

' Same name

Domain Relation

Add in

Emfry

Combine

has " Su per"

Unchan

Sed

has its own value but no "Super"

Figure 4.5: Graphical explanation of the procedure "inherit_from_parents"


39

The flow charts for each of the algorithms are provided in Figure 4.2 through Figure 4.4. Figure 4.5 gives an intuitive idea of what the condition (a) through (d) mean in the flow chart of the subroutine "inherit-from-parents". The example starts by generating the expanded image of frame F from its parents frames, and in this case the specific parent frame G is considered. The value of Image(-F) is the current value defined in frame F. In the flow chart: • Condition (a) means that if there is a slot which is not defined in the current slot we want to expand, then simply combine them together; • Condition (b) is the case where a slot in the parent frame is also defined in the current slot; based on the case (6), case (c) is when the same slot in the current frame is empty and case (d) is when the current slot has a key word super while case (e) is when the current slot is not empty and also no key word super in it. The detailed algorithm follows: Assumption: The input inheritance network is consistent . Input: A group of consistent frames G = {F\, ,Fn} in the hierarchy Output: The expanded inheritance image for G. Algorithm 1 N M J m a g e G e n e r a t o r Jbr_Object_Frame(G,/n/i, Image(G)) NotEmpty(G); % check that the inheritance network is non-empty. % while (not (all the object frames in G have been expanded)) Select an unexpanded object frame F from G such that (1) F has no antecedent, or (2) all F's antecedents have been expanded; Image(F) = Null; for each Slot € DirSlot(F) Image(.F) = Image(F) + Slot; for each attribute A in Slot ID[A,Slot,F}=0; if (F has no parent frames) then Mark F as "expanded" else Parents = {P \ P e DirReach(P,/n/i,F)}; Call inherit_from_parents(Paren£s,F); Mark F as "expanded" Output the expanded image of object frames in G; Example 4 Consider the expansion of the object frames in Example 3 using the algorithm 1 above.

40


object: reverting-call caller-id:; calleeJd:. object: two-party-call a-kind-of: reverting-call; partyJine-type: two-party.

Since only the frame reverting-call meets the two requirements, it is selected as the current frame to do the expansion.

Image(r•everting-call)

= { caller-id, calleeJd } .

On the other hand, the expansion of the frame two-party-call generates in the resulting image of itself the attribute party Jine.type, and then it invokes the kernel algorithm with the calling pattern of inherit -from_parents({reuerim ( . . . ) « - . . . A trrrii — vark A . . . A trrrij = vark A . . . =$• vark is a variable A vark does not appear elsewhere within the clause < p r e d > ( . . . ) « - . . . A trrrii — trrrij A . . . This rule makes explicit (in the clause body) the data dependency due to transitivity of unification implicit in the clause head of the original clause. Correctness Proof: The only effect of the two unifications is to introduce a transitive unification. Because Vark does not appear elsewhere in the clause, the correctness is preserved during the elimination of the transitive unification. R U L E - 4 (Equal-Substitution) <pred>(...)«—... A trrrii = trrrij A . . . =>• trrrij is a constant prohibit Equal-Substitution Because a constant is already minimal according to the partial ordering used to measure the degree of groundedness, equal substitution should not be applied in this case (less additional complexity is introduced by later canonicalizing transformations). R U L E - 5 (Equal-Substitution) <pred>(. ..)(...)«—... A trrrii = trrrij A . . . mgu{trrrii, trrrij} This rule maintains consistency throughout the clause. Chances can be created by applying this rule for the elimination of newly-introduced unnecessary variable, as discussed in simplification . +The degree of groundedness is used to measure the degree of boundness of a clause. The more bound variables a clause has, the lower the degree of the clause is. §The partial ordering is defined in that constants are more ground than variables, which are more ground than function or predicate symbols, which in turn are more ground than literals.

60

Rewriting and Data Dependency, ...

Correctness Proof: If trrrii and trrrij are unifiable, then applying the most general unifier of these two terms does not change the semantic of the clause. Correctness thus follows. E x a m p l e 9 Considering Example 8, Equal-introduction had left several unifications behind, which are now put into a consistent representation. p(Ai) = , = < (trmi,trm,2) let be a testing condition mode < o p > ( " + " , "+") = = , "=, , > = , = < stand for logic operators of "equal", "not equal", "less than", "greater than", "greater or equal", "less or equal". R U L E - 1 1 (Decomposition) <pred>(£rmi) =>• <pred> is one of var, nonvar, atom, integer, atomic "<pred>"(irmi) let "<pred>" be a testing condition mode is not <pred>("—") Correctness Proof: In the cases involving logic operators, the operands have to be bounded to provide a nontrivial logic value. In Rule-11, trmi can be either bounded or unbounded, based on the context, but it can not happen that trmi receives a value by executing this test case, which is ruled out by the rule. These two rules are used to handle test conditions. If the result of a literal in a clause body is "true" or "false" and there is no other side effect by

63


invoking the literal, then we call it a testing condition. Later on, when we generate code in a procedural programming language implementing the logicbased specification, these testing conditions will serve as the condition parts of conditional statements. Some built-in predicates considered in these two rules are used to test if the arguments are ground or not, so in these cases the mode information we obtain can only be used to reduce some impossible mode combinations. They cannot provide a definite mode status like the previously discussed rules. RULE-12 (Decomposition) u =" {trmutrm2) => mode(trmi)="-" mode "="("-», "+»)

Correctness Proof: In a unification, if one of the arguments receives a value during execution, then the other argument must provide this value. Unification cannot bind both of its operands. This rule infers the mode of one operand in a unification, when the mode status of another operand is restricted. Note that matching rules modulo commutativity of "=" allows us to cut down on the number of rules, since we need not consider the opposite case here. RULE-13 (Decomposition) (£rmi,..., trrnn) "" {trm\,..., trmn) mode ("+", • • •, "+") If there is a function name in the clause being analyzed, then the modes of all arguments in the function can be set to input. In this discussion it is assumed that a function always requires that all of its arguments be ground and that the value of the function depends on the arguments." Correctness Proof: Correctness follows from the assumption above. RULE-14 (Decomposition) <pred 1 >(...) (trm2l, • • • ,trm2n))

A ... A

II This assumption reflects the usual meaning of a function call, but may be too strict for some advocates of logic programming.

64

Rewriting and Data Dependency, ... . . . A <pred2>(irmi 1 ,... ,trm\n) A . . . =>• pred2 has not been defined elsewhere within the specification 6 is a most general unifier between trm,21 , • ••, trrri2n and trm\x,..., trmin (<predi >(...) < - . . . ) *

Correctness Proof: If a clause is asserted and called only within the same clause, and there is no other definition of the same clause within the same specification, then this pair of assertion and calling can be resolved without affecting the logic value of the clause if there exists a most general unifier 0 between the arguments of the predicate <pred2> within the assertion, and the arguments of the predicate <pred2> outside the assertion. R U L E - 1 5 (Decomposition) liti A liti liti,liti mode "+" A "+"

Correctness Proof: This rule is used to construct the compound goals in the query. It reflects exactly the meaning of the 'and' construct. As a result of the application of this rule we can assume that both X and Y have input mode. An assumption of the don't-care nondeterminism of the logic-based specification language is that no binding of variables occurs before successful evaluation of the precondition. Therefore, no output can be generated from variables occurring in the precondition, and we may safely assume that all variables occurring in a precondition are of mode " + " , as expressed in the following rule. RULE-16 (Decomposition) . . . A < p r e d > ( . . . , trm,...)

A ...

= > •

mode < p r e d > ( . . . , "+", ...)

Correctness Proof: An assumption of the don't-care nondeterminism of the logic based specification language is that no binding of variables occurs before successful evaluation of the precondition. Therefore, no output can be generated from variables

65

Hybrid Paxallel Execution Model

occurring in the precondition, and we may safely assume that all variables occurring in a precondition are of mode "+". Many other built-in predicates may occur in a logic-based specification. Again mode information is implicit and can be used to eliminate redundant mode combinations during flow analysis. These built-in predicates include: • File Handling • Procedure Augmentation • Clause Handling • Term Modification Obtaining the mode information contained in these built-in predicates is straightforward. Whenever the predicates we discussed here occur in a logic-based specification, we first restrict the possible mode combinations to a set which can meet the mode requirements of these built-in predicates. And then build procedures in a target language which can realize the semantic meanings contained in these predicates . Example 10 Note that in Example 9 the body of clause p contains an assert statement. Also there is no other clause with head q(). So we can apply Rule-14 to simplify p. After applying rules in decomposition we have p(A1) M M | / , „ = " - " M±V fail

According to the unique-producer assumption, any mode information that includes more than one literal marked "-" for the same variable can be discarded. Thus this rule can be used to eliminate choices for modes marked "B", or terminate a particular search branch during flow analysis. R U L E - 2 3 (FlowAnalysis) MMl>v => / is a clause head A I' is a recursively called literal which matches with I A v and v' are the corresponding arguments let MMi>y — opposite MM^V This rule is built to handle the case that a recursive literal in the clause body calls the same clause head. Based on the different sign conventions between predicates in the clause head and body, we have to adjust the sign when this case occurs. R U L E - 2 4 (FlowAnalysis) MMi:V =>• I is a clause head A I' is a recursively called literal which matches with I A v and v' are the corresponding arguments A MMi>y ^ opposite MMitV fail

If the corresponding modes are not opposite, as discussed earlier, then the mode assignments constructed so far are inconsistent, and we have to backtrack and attempt to find a different assignment. In contrast to the data dependency and flow analysis technique presented here, Debray and Warren's approach lacks the power to handle multiple-mode


83

combinations. As a result, the mode pattern of the arguments of a predicate have to be generated by taking the least upper bound of all the possible success patterns generated by different calling patterns. Our approach explicitly considers the multiple-mode possibility of a logic-based specification and is flexible enough to determine all possible mode combinations. For Debray and Warren, a logic program may just mean a single mode transformation process, whereas in our approach it may result in different data dependencies and execution sequences. Therefore, different target programs may be generated. In addition, our approach performs significantly better than Debray and Warren's method. The general procedure of mode analysis in Debray and Warren's approach consists of a computation of the set of success patterns and calling patterns of a predicate, and a computation of the mode of a predicate by taking the least upper bound of all the success patterns. The first one contributes most to the complexity of the algorithm. In order to compute the success pattern, the control of the algorithm must go from left to right, according to the evaluation order assumed, through each predicate of a clause, and then calculate the possible mode changes of all parameters of the predicates in the clause body. This will contribute 0(n2) to the algorithm. But in order to calculate the mode modifications of each predicate in the clause body, the control must recursively transfer to the analysis of success patterns of clauses with the predicates as their head. So the overall complexity is 0 ( n 3 ) . The best case occurs when all the predicates in the clause body are defined by fact clauses. In this case the complexity will reduce to 0(n2). In the worst case (if there is a recursive call to the clause itself), the algorithm may not terminate. Mode analysis in our approach proceeds sequentially through the matrix. If there exists a "B" in the matrix, then some modifications of the entries of a matrix need to be applied. However, because of the close relationship between modes in the column direction, which is represented by the two assumptions, and the row direction, which is represented by the constraints of arguments within a predicate, a change of only a few of the "B"s to either "+" or "-" can completely specify all the modes in a matrix. So the average complexity of our algorithm is 0(n2). The best case occurs when all the parameters of the predicates in a clause body are constants or ground variables, in which case all the predicates become test conditions and the mode analysis can be accomplished in linear time. The worst case arises when all the cells marked with mode "B" are totally independent such that the analysis of each predicate in the clause body must return to modify the matrix of the clause itself. Such backtracking may raise the complexity of the algorithm to 0(nz). E x a m p l e 17 Example 15 shows the state of our example after finishing the canonicalizing transformations of the logic-based specification. We are now ready to enter into the stage of flow analysis. For clause (2), we select one of two possible choices (see Figure 5.2). In

84

Rewriting and Data Dependency, ...

this case, the results in r having mode "+" in clause (1). Prom the mode information of r, we further partially infer the modes of the parameters of s and t. Because in column W there is no information about the mode status, it is marked with "B" in the two entries of the column. Mode status may change due to more specific mode information obtained at a later stage. Since the only entry in column N is not a constant, its mode has to be "-". (This entry is a "dead end", in that the value of this variable is not needed during the computation.). This information can be used to reduce the possible mode combinations for the clauses with the head s. In the following data dependency matrices shown, we mark entries that result from either the results of data flow analysis on other clauses, or from the Alg. 4 by circling them. Ai

Ai

N

W

"B'

->- "B' Figure 5.2: The partial result matrix for clause 2 Figure 5.3 shows the data dependency matrix obtained for clause (4). The selected decomposition for the list constructs of the FRORL specification allows us to eliminate from consideration the situation where the argument A3 of clause (4) has mode "+". This in turn determines completely the mode information for clause (2). Note that the mode information for the literal = is determined by Rule-13. The final matrix for clause (2) is given in Figure 5.4. To analyze clause (6) we obtain the mode of the clause head t from the matrix of clause (2). However, as Figure 5.5 shows, the resulting matrix is not consistent. Rule-23 of the second stage of the data flow analysis detects that the entries for the argument literal Ai of clause (6) conflict in both having mode "-". However, the selection of this particular decomposition for the list construct in clause (6) does not jeopardize mode analysis . When we fail to find a consistent mode assignment, we will backtrack to the decomposition phase of canonicalization and choose an alternate decomposition. ^ As a consequence, we also have to change this clause to t t T h e decomposition of the list may also need to be changed in case the user requests other possible mode combinations, in which case we might have to explore all alternatives that can be generated from using different ways of decomposing lists.

85


s

A,

Ai

Q

©

As

L,

N

fiN)

LI

1-"

0

car

Y

cdr

X

©

©

"f

f"

,1

listconstr

0 0

append

——^,,+"

s

.. »:-

!

Figure 5.3: The final result matrix for clause 4

Ai

Ai

N

W

"+" "+"

-W"+"^


[A2]

86

Rewriting and Data Dependency, ... Ai

A2

H

Li

Li

g(H)

[g(H\

0 0 car

I+

cdr

("+"

0 "B"

"B" listconstr

append r

fail by Rule-22

(v)

(jvJ)

(vj) "B"

Q) (vj)

"B"

Figure 5.5: Initial attempt to construct a matrix for clause 6 (7)

t(Ai, A2) 4- car(Ai, H) A cdr {Ai, i i ) A «g»(H,g(H)) A car(A2,g(H)) A cdr(A2,L2)

A t(L!,L 2 ).

Figure 5.6 shows the successful decomposition choice and the obtained mode assignments. In Figure 5.7 and Figure 5.8, we show the final data dependency matrices for clauses (3) and (5), respectively. Note that for clause (3), the meaning of the = predicates vary based on different mode combinations of their arguments. The = predicate in the second row is that of a logical comparison since both of its arguments are grounded; the ones in the third and fourth rows are simply assignment expressions (e.g., A2 will receive a value from the constant "0"). For the example of LSSGR protocol, the data flow and dependency combination is simple. For the possibilities related to the first parameter, it can be either a function call with the parameter (Ai) coming from the outside or either a function call with the same parameter receives the value from the call and transfer to the outside. For the possibilities related to the second parameter {A2), it can be either an assignment clause or a test condition exists within the clause body.

87


Ai

A2

Li

H

L2

g(H)

Q ©

,

© cdr

y

cdr

&-


Ai

A2

A3

1 1

"="1

"="2

"="3


Rewriting and Data Dependency,

A,

"="1

A2

[ ]

"+"

"="2


Chapter 6

Hybrid AND-OR Parallelism Implementation After the static mode analysis is finished, the system then uses the generated mode information to actually fulfill the parallelizing of the original Hornclause logic-based specification.

6.1

The Usage of Mode Information in the Parallel Model

As mentioned above, most current approaches put tremendous overhead on the parallel execution system by doing dynamic analysis of the data flow (also termed demand-driven). Few of them employ static data flow analysis, but none of them solve the problem satisfactorily. The main reason being that the static approach cannot guarantee that it will generate all the implied solutions of a logic program. In our approach, by using the four-valued mode combination and generating all possible mode combinations using bi-directional mode "B" in the matrix for each of the parameters of a predicate, all the solutions of a logic-based specification can be found from the matrix statically. The most significant advantage of this data dependency analysis is that the data flow information is available before any execution of the logic-based specification and any parallelization is attempted. Making use of this early available mode information is the key contribution of the new approach. At each step of the dynamic evaluation of the logic-based specification, when the binding of a variable changes, the static data flow and dependency matrix is consulted to see if there exist some predicates in the logic-based specification clauses (not necessarily clauses from the same level) which can be 89

90

Hybrid AND-OR Parallelism

Implementation

evaluated in parallel. The results generated from this simultaneous evaluation will enable further evaluation of other predicates in those clauses. These predicates can be executed in parallel and can come from different clauses which may reside in different levels in the searching tree. If there are no predicates which can be evaluated in the bottom-up fashion, then the general top-down evaluation process is invoked. The current approaches which employ mode information to solve binding conflicts generate and modify mode information at each step of the logic program. As a result, after each step of evaluation, mode analysis process is re-employed and mode status of arguments is changed. This changed mode information is used to facilitate further parallel evaluation of a logic program. So the parallel evaluation goes in a level by level fashion from a search tree perspective. After each step, mode analysis has to be invoked to find a more specific mode for arguments of a predicate in the lower level. Since the complete mode information is available before any actual evaluation of the logic-based specification in our model, the parallel evaluation can go more than one level in the search tree. So a predicate in a deeper-level of the search tree can be invoked if all its arguments which require value have been bounded by other predicates within the same clause, and this decision is made by checking the static mode information. In this case, the evaluation goes in a bottom-up fashion. That is, the parallel evaluation will explore predicates in a deeper-level in the search tree, collect the value there, and pass to other predicates within the same clause. The decision of when and where this bottom-up evaluation should be applied is solely decided by the static mode information. So the static mode information here serves to find predicates which can be executed in parallel from various levels of the search tree.

6.2

AND-OR Parallel Execution

In order to handle AND-parallelism , a bottom-up approach combined with a top-down evaluation scheme is used. Current approaches always work from the top of an AND-OR tree and search all the way down to the tree. In contrast, our approach can find all the mode combinations before the user's query is available, it is possible that while the execution continues, some information about the predicates which will be executed several steps later in the old topdown model is available in advance. If we carry out those operations first, then more information of mode for unsearched predicates can be gathered in advance and the efficiency of the whole process can be improved. The approach uses the results generated from the static data flow analysis, combined with the user's input, to find out the portion of the AND-OR tree of which the execution behavior is deterministic under the current variable binding. This portion of the AND-OR tree is executed in a bottom-up fashion. Compare this to other

91


approaches, which rely completely on the user's input query to initiate the analysis, their execution is based completely on the dynamic determination of the data flow information. So the analysis is completely dynamic and executes in a top-down manner, which puts a tremendous overhead on the system. An example execution sequence of the new parallel model is illustrated in Figure 6.1. In the graph, the left side branch represents the new bottom-up evaluation, the left side represents the general top-down evaluation sequence. The new execution behavior at the left branch is supported by the static mode information included in data dependency matrices. Query(Goal)

Bottom-up

The hybrid parallel evaluation model Figure 6.1: An illustration of the new parallel execution model The overhead for the new model is the cost of the static mode analysis . The new model applies the static mode analysis to obtain the mode information to facilitate the new model. In the previous section the cost for static mode analysis has been discussed and, it is shown that when a mode can be obtained, the cost for the new approach is better than current approaches in the best and average cases, and is the same in the worst case. So among the approaches applying mode to resolve binding conflicts , our approach is substantially better than the current approaches in obtaining mode information. The new hybrid evaluation model also uses the mode matrices during execution to obtain the actual mode status for arguments of the predicates. This portion of the cost is the same among all the approaches which utilize mode information. The cost to finish a mode check for a predicate is 0(n * m), where n is the average predicates within a clause, m is the number of arguments within a clause. If we assume there is a central process which contains mode matrices for all the

92


Implementation

specification clauses, then an extra overhead is two communication channels to sent the current binding to and receive the currently executable predicates from the centered process. In the other word, one of these two channels sends the mode status for input query, the other returns generated parallelly executable predicates. These predicates will then be assigned processes and begin evaluation. The new approach shows significant improvement over the current approaches when the corresponding search tree has large height. The algorithm to check for predicates which can be executed in parallel begins by generating grounded variables. Dynamic checking of parallelly executable predicates focuses only on the detection of newly generated grounded variables. In our new model, instead of only dynamic evaluation, all possible variable bindings and execution information have been included in the statically generated data dependency matrix. A very important property of our data dependency matrix is that it has all the possible execution sequences based on the multiple data dependency information. The only role a user's query plays is to initiate the analysis. At each step of the execution, especially whenever a new binding of a variable is generated, this information is used to restrict the multiple data dependency choices existing in the data dependency matrix and the possible execution sequences they imply. This restriction may result in only one possibility for the execution of a clause. So a large part of the analysis of our approach is done statically instead of dynamically. The execution starts from the root of an AND-OR tree , which corresponds to the user's query, then at each step of the unification, a variable binding is generated which will restrict the meaning and execution behavior of the clause. The system locates the branch of the AND-OR tree, which may not be the predicates from a single clause based on the multiple binding, so that the execution behavior of this branch is restricted to a single choice, and then executes this branch in a bottom-up fashion. All the remaining branches which cannot be restricted to a single choice will be executed top-down. This is how multiple solutions of a query are derived. Even in the top-down case, the static data dependency matrix can still help. Since all the solution have been predicted and represented in the data dependency matrix, the place where this multiple choice occurs can be determined from the same matrix. So the generation of multiple choices is still under the control of the system.

6.3

Synchronization in OR-Parallel Execution Model

The problem of preserving the multiple choices generated from the OR-branches can be handled with the help of the same data dependency matrix. The major problem of OR-parallelism is to synchronize the multiple bindings of the


93

same variable generated from different branches. A simple synchronization mechanism must be built according to the mode information included in data dependency matrix, considering that all the binding information is supported by these matrices. Based on the analysis of the AND-OR parallelism , there are two execution models, top-down and bottom-up . The realization of OR-parallelism is also closely related to these two models. During execution, if we find that the parallel execution of the logic program is in the top-down fashion similar to the current approaches, then the OR-parallel synchronization structure is identical to the current approaches using any of the currently available data structures and methods. If the execution proceeds in a bottom-up fashion, then the binding data structure will also be generated in a bottom-up fashion, which will simplify the data structures proposed for synchronization to only one level in the search tree. Compare with other approaches, which have to keep a binding data structure for all the processes existing at the same time, this is a major improvement in our approach. Also the creation of all these binding data structures can be delayed until all the variable bindings have been generated from all branches of an OR-parallel point. The current approaches have to generate a synchronization data structure upon the first entry of a OR-parallel branch point, and continue changing the synchronization data structure to reflect changes in the binding status of variables when the execution in any of its OR-parallel branches changes. Our approach reduces the life cycle of the synchronization data structures by waiting until they are actually needed to generate the complete binding combinations from OR-branches. Also the complexity of the OR-parallel binding data structure is sharply reduced because we use a one level control structure. In contrast, current approaches have to use a synchronization hierarchy when dealing with the OR-parallel synchronization problem. Current approaches use various data structures to synchronize the multiple bindings generated from different subtrees of an OR-branch [13, 14, 17, 41, 42, 64]. Following common characters are shared among almost all of them: • Binding data structures defined at each OR-branch point exist when the OR-parallel point is first entered and exists throughout the whole parallel execution process until all the branches of the OR-parallel point have finished execution; • Binding data structures are dynamically modified along with the execution at each branch of the OR-parallel point. This modification may come from the predicates very deep in the OR-parallel branches when that branch finishes execution and generates corresponding binding. The first point forces a system to bear large overhead by maintaining all

94


Implementation

those complex synchronization data structures. To make things worse, some of the data structures may not be necessary for the current OR-parallel execution if some processes are not interested in the current variables at the current OR-branch point [102]. The second point also makes the control of the synchronization data structures complex. Specifically, the cost for the creation and accessing variable bindings become prohibitively high. In order to cope with this problem, some of the current approaches consider a AND-OR search tree as a hierarchical structure and use the inheritance mechanism to reduce the complexity of maintaining the synchronization data structures [41, 92]. Based on the two points elaborated above, the synchronization data structure can be sharply simpler than the conventional data structures used now. The simplicity comes from that (1) the duration of synchronization data structure is shorter comparing with the conventional approach, it is not needed until all the solution has been generated and gathered from the lower level, (2) there is no need to maintain more than one level of the synchronization data structure. Because of the hybrid approach we adopt here, the control of the synchronization is much simpler than the conventional approach while achieve the same result. The simplification of the synchronization data structure comes from the control structure of the AND-OR parallelism . The choice of a specific synchronization data structure will not affect the improvement the new model can derive. Currently a lot of synchronization data structures have been proposed and studied, all of them consider control structure for the synchronization data structure and operations which can apply on them. Because of the simplicity of the new approach, all the current data structures, like array, harsh table, version vector, etc., can all be used, only with sharp simplicity. In here the detail data structure will not be discussed, instead, some principles of the design will be listed here. • Synchronization data structure is used to hold the results generated from the lower level, it contain the binding of the variables with the predicate which initiates the OR-parallel branch. • The result in synchronization data structure is necessary to be retrieved to take the cross product to form the complete result for the specification clause. • No special control mechanism has to be developed to handle the multilevel synchronization problem. The control for the synchronization data structure in the new approach only needs to deal with the adjacent levels to generate answers.


6.4

95

Calculation of the Currently Executable Predicate Set

In order to find predicates which can be evaluated in parallel, a search of the data dependency matrices is necessary to find all predicates which can be evaluated concurrently. The predicates are calculated dynamically according to the binding status of the clause and the static data flow and dependency matrix. All these currently evaluable predicates are gathered into a data structure which has enough space to hold the syntax structure of any of the clauses in the logic-based specification. This data structure is called E X E C , which represents all the predicates at the current stage whose parameters' requirements for value in order for them to be evaluable have been satisfied by the other predicates within the respective clauses. This set will include the parallelly executable predicates at any time in the process. The formal definition of E X E C is followed. Definition 15 E X E C is a set which contains the predicates from the logic-based specification clauses which can be executed in parallel. A predicate is in E X E C if all of the input variables of the predicate have been bounded by other predicates within the same clause. Here we assume that EXEC is a data structure defined to be able hold the syntax structure of predicates appropriately. The predicates within this set can come at any time during the process from clauses of different levels in the search tree, based on the binding status of the parameters within the predicate. The binding generated from the execution of this set will enable both the calculation of the new E X E C set and the general top-down evaluation of the logic-based specification, according to the binding status of the other predicates in the clause. If the predicates form more than one level are found to be executable, then they will be included in the new E X E C set, otherwise, the general top-down evaluation is invoked. So the proper calculation and application of this set become the center point of the whole approach. Fig.6.2 provides a simple comparison of the EXEC set under the conventional and new parallel execution models. In the following, an example is used to illustrate how this mechanism works. The example is based on the data flow and dependency matrices generated in Example 2, where generating the mode information is discussed. Example 18 Let's consider the case where the specification is called with a mode combination of r(bound,unbound), i.e., r is called with the first parameter being bounded to a list and the second parameter being unbounded. The currently available approaches will first check the predicates in the body of the

96


Implementation

Query(Goal)

The hybrid parallel evaluation model Figure 6.2: A comparison of execution sequence between current and new models

clause (1), which corresponds to the AND-parallelism at the first level. In this case, there is no possible parallel execution, so a process corresponds to predicate s will be created and the OR-parallelism of the predicate s is explored, and so on by checking in a top-down fashion. Instead, in our approach, after the user's query is available, the input mode combination of r(—, +) is checked with the data dependency matrices to find the possible execution set E X E C . From the matrices for clause (1), we can see that the list provided from the clause head predicate r is consumed by the first parameter of the predicate s. Since the predicate is a user defined predicate, the search goes into the clauses unifiable with the predicate s which define an OR-branch. Based on the algorithm described below, all the predicates in the clause (2) can be executed simultaneously since for all of these predicates, all their parameters with the input mode have been satisfied. Thus after examining the data dependency matrix for clause (2), E X E C = { = i , = 2 , = 3 } - Meanwhile the search for executable predicates is also carried on at clause (3). In this case, the two predicates car, and cdr are detected to be also executable. Finally E X E C becomes { = i , =2, =3, car, cdr}. In this example, instead of only the predicate s in the clause (1) being executed, the five predicates in E X E C can be executed in parallel. After the execution of the predicate s in clause (1) is completed, the bounded value in Xi by the execution of predicate s will be passed to the predicate t in the same clause, and the same process will go on for t. The E X E C set corresponds to the first step of the execution of predicate t will be {=1, =2, car, cdr}, which comes from clause (4) and clause (5) respectively. Please notice that within a clause, the executional behavior of our approach is similar to Chen and Wu's model [17]. A predicate within a clause has to have


97

all its parameters with input mode be satisfied with some producers in order for it to be executable. So after the parallel execution of the above E X E C set being carried out, the next EXEC set of {s} will be executed. The same process goes on until the parameter Bi and B3 in clause (3) receive the value from the execution of the clause. As this example shows, the execution of the new model is to rely on the statically built data dependency matrix to spawn as many parallelly executable processes as early as possible along the dynamic evaluation of the logic-based specification. In the following, an algorithm is introduced, which calculates the data structure E X E C set at each step whenever a new binding is introduced in the execution of the logic-based specification. The algorithm uses the E X E C to hold the predicates which are found to be parallelly executable by the algorithm. In the algorithm, E X E C is an external variable, similar to that in language C. The reason is that in any invocation of the algorithm, predicates which may be included in EXEC may come from various clauses in the logicbased specification, and the algorithm has to recursively call itself for each of the clauses involved in the calculation. In order to preserve the predicates in the E X E C set in the process of a multiple clause call, and form the complete image after the calling is finished, the data structure must be external. The same thing happens with the data structure CLAUSE, which holds the clauses which contributes to the current E X E C set. Other predicates in the clause in this set will be searched for further evaluation when the current parallel evaluation of the EXEC is over. Expanded is a two dimensional data structure. It is built up for each of the clauses in the logic-based specification, which forms the first dimension. The second dimension is similar to the EXEC, which holds the predicates in each clause which has been expanded or searched. It is similar to the dead set in the conventional DFS or BFS [66] algorithms. The only difference is that we have to consider the case when the clause is recursively called, the predicate may be moved from the expanded set, which means that the predicate has to be reevaluated under the new binding status in the new round of evaluation. Expanded^ is a duplicate of expanded except that it is defined locally. It is used to hold the partial results during the execution. In the algorithm, we assume there are iV clauses in the logic-based specification, and the specification is called with the predicate Predi, with arity of a, in the clause body of clausej. Further assume that clause Clausej has p predicates within its body, marked from 1 to P. Algorithm 5 Calculate_Current_EXEC(Predi(parai,... ,paraa), External: EXEC; External: Clause;

Clausej)

98


Implementation

Static: expanded[l..N]; expandedi [l..iV]; for each I, (l• The value of NFR is explicitly denned in frame A; Not all of A's children Bi,...,Bn have explicit definitions of NFR. Create an explicit NFR value in each child frame without defining NFR; Assign the value of NFR in A to the newly created NFR in child frames; Adjust NFR in frame A.

This rule indicates that if not all of the A's children have explicitly denned the value of NFR, then in order to prevent the case that the adjustment made in A affect the NFR value in those child frames, an explicit definition is necessary for them. Figure 9.5 illustrates this rule. RULE-39 (Non-functional Adjustment) =>The value of NFR is not explicitly defined in frame A; All of .A's children Bi,...,Bn have explicit definitions of the value of NFR. Create an explicit value of NFR in A;

198

Describing Non-Functional Requirements in FRORL

Operator 2 >

Figure 9.5: Illustration of rule 38

Figure 9.6: Illustration of rule 39


199

Figure 9.7: Illustration of rule 40 This rule is similar to the Rule 37 except that NFR is not explicitly defined in A. In this case, NFR value has to be defined in A. But this definition will not affect the value of NFR at the child frames because all of them have explicit NFR value definitions. Figure 9.6 illustrates this rule. RULE-40 (Non-functional Adjustment) =>The value of NFR is not explicitly defined in frame A; Not all of A's children B\,..., Bn have explicit definitions of NFR. Create an explicit NFR value in each child frame without defining NFR; Assign the value of NFR inherited by A to the newly created NFR in child frames; Adjust NFR in frame A.

This rule is similar to the Rule 38 except that the value of NFR in the frame A is inherited instead of explicitly defined in it. By the same token, explicit definition has to be provided in each of the child frame to override the possible impact the change of NFR value in A on themselves. Figure 9.7 illustrates this rule.

Chapter 10

Summary The main topic of this book is a parallel execution model for a Horn-clause logic-based requirements specification. The model handles AND-parallelism , OR-parallelism , and eliminates of backtracking related to a logic-based specification. The significant points of this model are: • It is the first model to discuss the parallel execution of a logic-based requirements specification. Current approaches all focus on the parallelism of various logic programs. • The new model uses a static data dependency approach to generate mode information for each of the variables in the predicate of a clause. This static mode information is the basis for the whole parallel evaluation process. • The new model is guaranteed to find the maximum degree of AND- and OR-parallelism by adopting a new hybrid execution model. This model finds a parallel executable set of predicates at each step when a new variable binding is created based on the static mode information. • Because the static data dependency analysis is guaranteed to find all possible execution paths and all solutions of a logic-based specification, this model can eliminate the backtracking structure from the execution control structure. • At each step of the execution, the correct processes are divided into several clusters by the clauses. These clauses have predicates which are currently executable or have been active because of the static analysis. As a result, the total idle time of communication channels needed for the parallel processes is substantially lower than the idle time of the current 201

202

Summary approaches, where it is possible for a communication channel to be idle for a long time before a message is collected from deep predicate of one branch and been sent to the deep predicate of another branch.

• During the AND-parallel execution, since we do not generate all intermediate processes from the initial calling predicate to the current predicates, then if all those intermediate nodes do not contribute to the binding of the related variables, we do not need to generate these intermediate processes, which reduces the overhead of the parallelizing scheme. During the OR-parallel execution, the creation of the binding structure can also be delayed until the variable bindings actually are generated form the branches of the OR-parallel points. • Since at each step the search goes into the AND-OR tree of a logicbased specification and the evaluation is applied to the clauses which have predicates currently executable, it is possible to apply the classical short-cut algorithm here earlier than other approaches can and thereby reduce the space of the AND-OR tree searched to generate the complete multiple solutions. As a consequence, the time and space saved using the short-cut algorithm will be maximized. • The hybrid execution of OR-parallelism reduces the complexity of the synchronization data structures used for management of different bindings generated from different branches. This is reflected in the possibility of delaying the creation of binding data structure s and the one-layered binding data structure synchronization. The bottom-up execution will first search the AND-OR tree hierarchy, a data structure at an ORparallel merging point will not be created until all the variable bindings are actually generated from the evaluation of the OR-branches below the OR-parallel point. According to the bottom-up execution model, all the bindings generated from different branches of an OR-parallel predicate are already available before the merging algorithm at the same OR-branch point is called. So there is no need to maintain synchronization data structure for more than one level below the OR-parallel branch point. This will sharply reduce the complexity of creation and maintenance of all the synchronization data structures most the current approaches share without any limitation on the level of information a binding list needs to maintain. The only overhead we have here is a tag which distinguishes solutions generated one level deep of one OR-parallel sub-branch from others.

References [1] H. Alshawi, D.B. Moran, "The Delphi Model and Some Preliminary Experiments," Proceedings of the Fifth International Conference and Symposium on Logic Programming, pp. 447-465, Seattle, Washington, August 1988. [2] R. A. Ammar and C. P. Rosiene, "Visualizing a Hierarchy of Performance Models for Software Systems," Software - Practice and Experience, vol. 23, pp. 293-315, Chicago, IL, March 1993. [3] D. Barstow, "An Experiment in Knowledge-Based Automatic Programming," Artificial Intelligence, Vol. 12, pp. 73-119, 1979. [4] D. Barstow, "Automatic Programming for Streams II: Transformation Implementation," Proceedings of 10th Int. Conf. on Software Eng., pp. 439447, Singapore, 1988. [5] F.L. Bauer, et al., "The Munich Project CIP: The Program Transformation Systems CIP-S," Lecture Notes in Computer Sciences, No. 292, Springer, Berlin, 1987. [6] H. Berlinger, "The B tree Search Algorithm: A best-first proof procedure," Artificial Intelligence, Vol. 12, No. 1, pp. 23-40, 1979. [7] P. Biswas, S.C. Su, and D. Y.Y. Yu, "A Scalable Abstract Machine Model to support Limited-OR(LOR/Restricted-AND Parallelism(RAP) in Logic Programs," Proceedings of the Fifth International Conference and Symposium on Logic Programming, pp. 1161-1179, Seattle, Washington, August 1988. [8] P. Borgwardt, "Distributed Semi-intelligent Backtracking for a Stackbased AND-parallel Prolog," Proceedings of IEEE 1986 Symposium on Logic Programming, pp. 211-222, Salt Lake City, Utah, September 1986. 203

204

References

[9] A. Bossi, N. Cocco, and S. Dulli, "A Method for Specializing Logic Programs," A CM Trans, on Programming Languages and Systems, Vol. 12, No. 2, pp. 253-302, April 1990. [10] M. Bruynooghe, "Adding Redundancy to Obtain More Reliable and More Readable Prolog Programs," Proceedings of the first International Logic Programming Conference, Marseille, France, 1982. [11] M. Bruynooghe, B. Demoen, A. Callebaut and G. Janssens, "Abstract Interpretation: Towards the Global Optimization of Prolog Programs," Proceedings of the 4th IEEE Symposium on Logic Programming, San Francisco, California, September 1987. [12] R.M. Burstall and J. Darlington, "A Transformation System for Developing Recursive Programs," Journal of the ACM, Vol. 24, No. 1, pp. 44-67, March 1977. [13] R. Butler, E.L. Lusk, R. Olson, and R.A. Overbeek, "ANLWAM: A Parallel Implementation of the Warren Abstract Machine," Internal Report, Argonne National Laboratory, U.S.A., 1986. [14] R. Butler et. al., "ANLWAM: A Parallel Implementation of the Warren Abstract Machine," Internal Report, Argonne National Laboratory, U.S.A., 1986. [15] J.-H. Chang, and A.M. Despain, "Semi-Intelligent Backtracking of Prolog Based on Static Data Dependency Analysis," Proceedings of IEEE 1985 Symposium on Logic Programming, pp. 10-21, Boston, Massachusetts, July 1985. [16] J.-H. Chang, A.M. Despain, and D. DeGroot, "AND-parallelism of Logic Programs Based on A Static Data Dependency Analysis," Digest of Papers, COMPCON Spring '85, pp. 218-225, February 1985. [17] A. Chen, and C.-L. Wu, "A Parallel Execution Model of Logic Programs," IEEE Trans, on Parallel Distributed Sys., pp. 79-92, VOL. 2, No. 1, January 1991. [18] L. Chu, and B. Wah, "Band Search: an Efficient Alternative to Guided Depth-first Search," Proceedings of 1992 IEEE International Conf. on Tools with AI, pp. 154-161, Arlington, VA, November 1992. [19] A. Ciepielewski, and B. Hausman, "Performance Evaluation of a Storage Model for OR-Parallel Execution of Logic Programs," Proceedings of IEEE 1986 Symposium on Logic Programming, pp. 246-257, Salt Lake City, Utah, September 1986.

References

205

[20] W. F. Clocksin and C. S. Mellish, Programming in Prolog, Springer-Verlag, Berlin Heidelberg, 1984. [21] P. Coad and E. Yourdon, Object-Oriented Analysis, Yourdon Press Computing Series, Englewood Cliffs, New Jersey, Prentice Hall, 1989. [22] C. Codognet, and P. Codognet, "Non-deterministic Stream ANDParallelism Based on Intelligent Backtrackings," Logic Programming, Proceedings of the Sixth International Conference, pp. 63-80, Lisborn, Portugal, June 1989. [23] C. Codognet, "Yet Another Intelligent Backtracking Method," Proceedings of the Fifth International Conference and Symposium on Logic Programming, pp. 447-465, Seattle, Washington, August 1988. [24] J. S. Conery, The AND/OR Model for Parallel Interpretation of Logic Program, PhD Thesis, Dept. of Information and Computer Science, Univ. of California, Irvine, 1983. [25] T. Conlon, Programming in PARLOG publisher: Addison-Wesley Publishing Company, New York, NY, 1989. [26] J. Darlington, "An Experimental Program Transformation and Synthesis System," Artificial Intelligence, Vol. 16, pp. 1-46, 1981. [27] R.E. Davis, Generating Correct Programs from Logic Specifications, Ph.D. dissertation, University of California, Santa Cruz, March 1977. [28] S. K. Debray, "Static Analysis of Parallel Logic Programs," Proceedings of the Fifth International Conference and Symposium on Logic Programming, pp. 711-732, Seattle, Washington, August 1988. [29] S. K. Debray, "Flow Analysis of Dynamic Logic Programs," Journal of Logic Programming, Vol. 7: pp. 149-176, 1989. [30] S. K. Debray and D. S. Warren, "Automatic Mode Inference for Logic Programs," Journal of Logic Programming, Vol. 5: pp. 207-229, 1988. [31] D. DeGroot, "Alternate Graph Expressions for Restricted ANDparallelism," Proceedings of COMPCON Spring '85, pp. 206-210, Chicago, IL, February 1985. [32] D. DeGroot, "Restricted AND-parallelism and Side Effects," Proceedings of 1987 IEEE Symposium on Logic Programming, pp. 80-89, San Francisco, California, August 1987.

206

References

[33] D. DeGroot, "Restricted AND-parallel Execution of Logic Programs," Parallel Computation and Computers for Artificial Intelligence, pp. 91107, editor: Janusz Kowalik, publisher: Kluwer Academic Publishers, San Francisco, CA, 1988. [34] P. Dembinski, and J. Maluszynski, "AND-parallelism with Intelligent Backtracking for Annotated Logic Programs," Proceedings of the 1985 IEEE Symposium on Logic Programming, pp. 29-38, Boston, Massachusetts, July 1985. [35] M. S. Feather and P.E. London, "Implementing Specification Freedoms," Science of Computer Programming, Vol. 2, pp. 91-131, New York, NY, 1982. [36] C. J. Fidge and A. M. Lister, "Disciplined Approach to Real-Time Systems Design," Journal of Information and Software Technology, vol. 34, pp. 603-610, Chocago, IL, September 1992. [37] J. Gallagher, "Transforming Logic Programs by Specializing Interpreters," Proceedings of the Seventh European Conf. on Artificial Intelligence, Brighton Center, United Kingdom, pp. 109-122, 1986. [38] M. Genesereth and M.L. Ginsberg, "Logic Programming," Communications of the ACM, Vol. 28, No. 9, pp. 933-941, September 1985. [39] A. Goto, et. al., "Lazy Reference Counting: An Incremental Garbage Collection Method for Parallel Inference Machines," Proceedings of the Fifth International Conference and Symposium on Logic Programming, pp. 447-465, Seattle, Washington, August 1988. [40] G. Gupta, et. al., "IDIOM Integrating Dependent and-, Independent and-, and Or-parallelism," Proceedings of the 1991 International Symposium on Logic Programming, pp. 152-166, San Diego, California, October, 1991. [41] M. Hailperin, and H. Westphal, "A Computational Model for PEPSY," Technical Report CA-16, ECRC, Cambridge, British, 1985. [42] B. Hausman, A. Ciepielewski, and S. Haridi, "OR-parallel Prolog Made Efficient on Shared Memory Multiprocessors," Proceedings of the 1987 IEEE Symposium on Logic Programming, pp. 69-79, San Francisco, California, August 1987. [43] M. V. Hermenegildo, "An Abstract Machine for Restricted AND-parallel Execution of Logic Programs," Proceedings of the Third International Conference on Logic Programming, "Lecture Notes in Computer Science," Springer-Verlag, Vol. 225, San Francisco, CA, 1986.

References

207

[44] M. V. Hermenegildo, R. Warren and S. K. Debray, "Global Flow Analysis as a Practical Compilation Tool," Journal of Logic Programming, vol. 13, pp. 349-366, 1992. [45] P. Hsia, A. Davis, and D. Kung, "Status Report: Requirements Engineering," IEEE Software, vol. 10, pp. 75-79, November 1993. [46] D. Jacobs, and A. Langen, "Compilation of Logic Programs for Restricted AND-parallelism," Proceedings of the European Symposium on Programming, Nancy, France, 1988. [47] J. Jaffar and J.L. Lassez, "Constraint Logic Programming," Proceedings of the Fifteenth Annual ACM Symp. Conf. on Principles of Programming Languages, Munich, Germany 1987. [48] M. Jarke et al., "Theories underlying Requirements Engineering: an overview of NATURE at genesis," in Proceedings of the IEEE International Symposium on Requirements Engineering, pp. 19-31, San Diego, CA, January 1992. [49] S. E. Keller, L. G. Kahn, and R. B. Panara, "Specifying Software Quality Requirements with Metrics," in System and Software Requirements Engineering (R. H. Thayer and M. Dorfman, eds.), IEEE Computer Society Press, pp. 145-153, Los Alamitos, CA, 1990. [50] W. Kim and F.H. Lochovsky, Object-Oriented Concepts, Databases and Applications, Addison-Wesley, New York, NY, 1989. [51] D. E. Knuth, and R. W. Moore, "An Analysis of Alpha-Beta Pruning," Artificial Intelligence, Vol. 6, No. 4, pp. 293-326, 1975. [52] R.E. Korf, "Depth-First Iterative Deepening: An Optimal Admissible Tree Search," Artificial Intelligence, Vol. 27, pp. 97-109, North-Holland, 1985. [53] R. Kowalski, "Predicate Logic as a Programming Language," Proceedings of 1974 IFIP, North-Holland, pp. 569-574, Amsterdam, Holland, 1974. [54] R. Kowalski, "The Semantics of Predicate Logic as a Programming Language," Journal of the ACM, Vol. 23, No. 4, pp. 733-742, April 1976. [55] R. Kowalski, "Algorithm = Logic + Control," Communications ACM, Vol. 22, No. 7, pp. 424-436, July 1979.

of the

[56] R. Kowalski, Logic for Problem Solving, North-Holland, New York, 1979.

208

References

[57] R. Kowalski, "Software Engineering and Knowledge Engineering in New Generalization Computing," Future Generation Computer Systems, pp. 39-50, Chicago, IL, January 1984. [58] R. Kowalski, "The Limit of Logic and Its Role in Artificial Intelligence," Proceedings of Wksp. on Knowledge Base Managements, pp. 477-489, Crete, Germany, June 1985. [59] R. Kowalski, "The Relation between Logic Programming and Logic Specification," Mathematical Logic and Programming Languages, (eds, C.A.R. Hoare, and J.C.Shepherdson), pp. 1-24, Prentice-Hall, Englewood Cliffs, CA, 1985. [60] V. Kumar, and Y. Lin, "An Intelligent Backtracking Scheme for Prolog," Proceedings of the 1987 IEEE Symposium on Logic Programming, pp. 406414, San Francisco, California, August 1987. [61] E.L. Lawler, and D.W. Wood, "Branch and Bound Methods: A Survey," Operation Research, Vol. 14, pp. 699-719, Chicago, IL, 1966. [62] R. K.S. Lee, "Concurrent Prolog in a Multi-process Environment," Proceedings of the 1985 IEEE Symposium on Logic Programming, pp. 100-109, Boston, MA, July 1985. [63] G. Li, and B. Wah, "Computational Efficiency of Parallel Combinatorial OR-Tree Searches," IEEE Trans, on Software Engineering, Vol. 16, No. 1, pp. 13-31, January 1990. [64] P. P. Li, and A. J. Martin, "The SYNC Model: A Parallel Execution Method for Logic Programming," Proceedings of the IEEE 1986 Symposium on Logic Programming, pp. 223-234, Salt Lake City, Utah, September 1986. [65] Y. J. Lin, and V. Kumar, "AND-parallel Execution of Logic Programs on a Shared Memory Multiprocessor: A Summary of Results," Proceedings of the Fifth International Conference and Symposium on Logic Programming, pp. 1124-1141, Seattle, Washington, August 1988. [66] G. F. Luger, and W. A. Stubblefield, Artificial Intelligence, jamin/Cummings Co., New York, NY, 1989.

Ben-

[67] Z. Manna and R. Waldinger, Studies in Automatic Programming Logic, North-Holland, New York, 1977. [68] H. Mannila and E. Ukkonen, "Flow Analysis of Prolog Programs", Proceedings of the 4th IEEE Symposium on Logic Programming, San Francisco, California, September 1987.

References

209

[69] A. Martelli, and U. Montanari, "Optimizing Decision Trees through Heuristically Guided Search," Communication ACM, Vol. 21, pp. 1025-139, 1978. [70] C. S. Mellish, "Some Global Optimizations for a Prolog Compiler", Journal of Logic Programming, Vol. 2, No.l: pp. 43-66, April 1986. [71] J. Mylopoulos, L. Chung, and B. Nixon, "Representing and using nonfunctional requirements: a process-oriented approach," IEEE Trans. Software Engineering, vol. 18, pp, 483-497, June 1992. [72] N.J. Nilsson, Problem Solving Methods in Artificial Intelligence. McGrawHill, New York, NY, 1971. [73] J.S. Ostroff, "Temporal Logic for Real-Time Systems," Research Studies Press, Taunton, IN, 1989. [74] H.A. Partsch, "The CIP Transformation System," in P. Pepper, Program Transformation and Programming Environments, Springer Verlag, New York, pp. 305-322, 1983. [75] H.A. Partsch, "Specification and Transformation of Programs: A Formal Approach to Software Development," Springer Verlag, New York, NY, 1990. [76] H. Partsch and R. Steinbruggen, "Program Transformation Systems," ACM Computing Surveys, Vol. 15, No. 3, pp. 199-236, 1983. [77] A. Pnueli, "Applications of Temporal Logic to the Specification and Verification of Reactive Systems: A Survey of Current Trends," in J.W. de Bakker, W.P. de Roever, and G. Rozenberg , Current Trends in Concurrency, Overviews and Tutorials, Lecture Notes in Computer Science, Vol. 224, Springer Verlag, New York, NY, pp. 510-584, 1986. [78] P. Raman, and W. Stark, "Fully Distributed AND/OR-parallel Execution of Logic Programs," Proceedings of the Fifth International Conference and Symposium on Logic Programming, pp. 1189-1203, Seattle, Washington, August 1988. [79] B. Ramesh and V. Dhar, "Supporting Systems Development by Capturing Deliberations during Requirements Engineering," IEEE Trans, on Software Engineering, vol. 18, pp. 498-510, June 1992. [80] U. S. Reddy, "Transformation of Logic Programs into Functional Programs", Proceedings of the 1984 International Symposium on Logic Programming, Atlantic City, New Jersey, IEEE Computer Society: pp. 187196, February 1984.

210

References

[81] G.-C. Roman, "A Taxonomy of Current Issues in Requirements Engineering," IEEE Computer, vol. 18, pp. 14-21, April 1985. [82] T. Sato and H. Tamaki, "Transformational Logic Program Synthesis," Proceedings of the International Conf. on Fifth Generation Computer Systems, pp. 195-201, Tokyo, Japan, 1984. [83] E. Y. Shapiro, "A Subset of Concurrent Prolog and Its Interpreter," TR003, ICOT-Institute for New Generation Computer Technology, Japan, January 1983. [84] K. Shen, "Exploiting Dependent And-parallelism in Prolog: the Dynamic Dependent And-parallel Scheme(DDAS)," Proceedings of the Joint International Conference and Symposium on Logic Programming, pp.717-731, Boston, MA, 1992. [85] K. Shen, and D. H.D. Warren, "A Simulation Study of the Argonne Model for OR-oarallel Execution of Prolog," 1987 IEEE Symposium on Logic Programming, pp. 54-68, San Francisco, California, August 1987. [86] C. U. Smith and L. G. Williams, "Software Performance Engineering: a case study including performance comparison with design alternatives," IEEE Trans, on Software Engineering, vol. 19, pp. 720-741, July 1993. [87] G. Smolka, "Making Control and Data Flow in Logic Programs Explicit", Proceedings of the 1984 Symposium on LISP and Functional Programming, Austin, Texas, August 1984. [88] K. Steer, "Testing Data Flow Diagrams with PARLOG," Logic Programming, Proceedings of the Fifth International Conference and Symposium, pp. 96-110, Seattle, Washington, August 1988. [89] G.C. Stockman, and L.N. Kanal, "Problem Reduction Representation for the Linguistic Analysis of Waveforms," IEEE Trans, on Pattern Anal. Machine Intell, Vol. PAMI-5, No. 3, pp. 287-298, 1983. [90] D. Syners and A. Thayse, "From Logic Design to Logic Programming," Springer, Berlin, 1987. [91] H. Tamaki and T. Sato, "Unfold/Fold Transformation of Logic Programs," Proceedings of the Second International Logic Programming Conference, Upssala, pp. 127-138, July 1984. [92] P. Tinker and G. Lindstrom, "A Performance-Oriented Design for ORparallel Logic Programming," Proceedings of the Fourth International Conference on Logic Programming, pp. 601-615, Melbourne, Australia, May 1987.

References

211

[93] J. J.-P. Tsai, T. Weigert and H. C. Jang, "A Hybrid Knowledge Representation as a Basis of Requirement Specification and Specification Analysis," IEEE Trans, on Software Engineering, Vol. SE-18, No. 12, pp. 1076-1100, December 1992. [94] J. J.-P. Tsai, and T. Weigert, Knowledge-Based Software Development of Real-Time Distributed Systems, World Scientific, Singapore, 1993. [95] J. J.-P. Tsai and S. Yang, Monitoring and Debugging Distributed RealTime Systems, IEEE Computer Society Press, Washington D.C., November 1994. [96] J. J.-P. Tsai, Y. Bi, S. Yang, and R. Smith, Distributed Real-Time Systems, Wiley k Sons Inc., NY, 1996. [97] J. J.-P. Tsai, B. Li, and E. Juan, "Parallel Evaluation of Software Architecture Specifications," Communication of the ACM, Vol. 40, No. 1, pp. 63-70, January 1997. [98] J. J.-P. Tsai, B. Li, and T. Weigert "A Logic-Based Transformation Systems," IEEE Trans, on Knowledge and Data Engineering, Vol. 10, No.l, pp. 91-107, January 1998. [99] J. J.-P. Tsai, A. Liu, E. Juan, and A. Sahay, "Knowledge-Based Software Architecture," IEEE Trans, on Knowledge and Data Engineering, Vol. 11, No. 1, pp. 187-201, January/February 1999. [100] B. Wah, An IDA* Search with Dynamic Control, Research Report CRHC-91-09, Center for Reliable and High Performance Computing, Coordinated Science Laboratory, Univ. of Illinois, April 1991. [101] B. Wah, "Population-Based Learning: A Method for Learning from Examples Under Resource Constraints," IEEE Trans, on Knowledge and Data Engineering, Vol. 4, No. 5, pp. 454-474, October 1992. [102] D. H.D. Warren, "The SRI Model for Or-Parallel Execution of PrologAbstract Design and Implementation Issues," Proceedings of the 1987 IEEE Symposium on Logic Programming, pp. 92-102, San Francisco, California, August 1987. [103] H. Westphal, et al., "The PEPSys Model: Combining Backtracking, AND- and OR-parallelism," Proceedings of the 1987 IEEE Symposium on Logic Programming, pp. 436-448, San Francisco, California, August 1987.

212

References

[104] W. Winsborough, "Semantically Transparent Selective Reset for AND Parallel Interpreters Based on the Origin of Failures," Proceedings of the 1987 IEEE Symposium on Logic Programming, pp. 134-152, San Francisco, California, August 1987. [105] N. S. Woo, and K. M. Choe, "Selecting the Backtracking Literal in the AND/OR Process Model," Proceedings of the IEEE 1986 Symposium on Logic Programming, pp. 200-210, Salt Lake City, Utah, September 1986. [106] C. Yu, and B. Wah, "Efficient Branch-and-Bound Algorithm on a TwoLevel Memory System," IEEE Trans, on Software Engineering, Vol. 14, No. 9, pp. 1342-1356, September 1988.

Index abstract relation, 19, 21, 22, 27 abstract-relation slot, 22 accuracy, 8, 181-183, 187, 190 aggregation, 20, 26 AND-OR parallelism, 4, 9, 15, 17, 91, 92, 96, 100 AND-OR tree, 2-4, 15, 16, 88, 90, 100, 101, 103, 198 AND-parallelism, 2, 7-9,11, 88, 93, 117, 120, 197, 200, 201 anomaly management, 182 attribute, 22, 24, 29, 30, 53, 164, 182 Average speed up, 107 backtracking, 3, 5, 7-12, 15, 59, 81, 100, 105, 160, 165, 170, 173, 179, 197 backtracking elimination, 10,13,17 binding conflicts, 2, 88, 89 binding data structure, 17, 91, 198 bottom-up, 3, 12, 15-17, 88, 91, 101, 106, 114, 116, 198 classification, 20 consistency, 5, 27, 57, 73 consistent, 29, 37, 58, 82, 97, 108, 124 conventional parallel tree searching, 117 CPU Time, 107 data dependency, 13,16, 51, 55, 57, 72, 73, 76-78, 80, 82, 84,

87, 89-91, 93, 103, 107, 118, 208 data flow, 11, 12, 15, 27, 51, 73, 74, 82, 84, 87, 89, 93, 100, 159, 165, 168, 169 decomposition, 12, 23, 26, 41, 55, 59, 63, 78, 79, 82, 84, 167 deep backtracking, 9 Degree of Parallelism, 107,110,112 directly reachable, 29 dynamic mode inference, 2 economic constraints, 182 equal-introduction, 12, 55, 56 equal-substitution, 12, 52, 56, 57 EXEC, 93-95 executability, 20, 25 formality, 20 FRORL, 1, 4, 11-13,19, 20, 25, 31, 32 generality, 182 generalization, 20, 26 Horn-clause, 1-3, 11-13, 20, 26, 27, 41, 47, 51, 55, 70, 87, 99, 164,197 independent AND-parallelism, 8 indirectly reachable, 29 inheritance, 1, 20-22, 26, 28, 32, 38, 186, 192 inheritance distance, 28

214 inheritance image, 29, 37 inheritance structure, 28, 32, 51 instantiation, 8, 20, 26 intelligent backtracking, 9, 12, 159, 160, 179 interface constraints, 182 knowledge base, 19, 20, 25, 169 life-cycle constraints, 182 liveness, 1 logic-based, 1-4, 11-13 Maintainability, 185 metric-aggregation, 185 mode analysis, 1, 52, 54, 76, 79, 81, 82, 87-89 modularity, 20 multiple inheritance, 20, 22, 26-29 non-monotonic, 1, 11-13, 160, 186, 188, 192 non-monotonic inheritance expansion, 13 Number of Processes, 107 object, 20 object-oriented design, 20 object-orientedness, 20 operating constraints, 182 OR-parallelism, 6, 11, 13, 16, 17, 90, 91, 94, 100, 101, 117, 197, 198, 205 performance, 106,125,181-183,185 performance constraints, 182 political constraints, 182 precond slot, 24 predicate, 3, 5-8,12, 14, 16, 52, 54, 57-59, 63, 72, 76, 78, 80, 87, 88, 93 programmer's annotation, 8 prototyping, 4, 20

Index Ratio of Deeper Channel, 110 re-usability, 20 refinement, 20, 55, 182, 188 requirements specification, 1 reserved words, 25, 26 security, 181-183, 187, 189 semi-intelligent backtracking, 9 sequential tree searching, 117 shallow backtracking, 9 simplification, 12, 53, 57, 66-69, 92 static data dependency, 1, 3, 4, 9, 12, 16, 90, 197 static data dependency , 72, 99,107, 118 subclasses, 20 superclass, 20, 26 synchronization, 6, 7, 13, 16, 17, 91, 92, 101 synchronization overhead, 107 theorem proving, 20 top-down, 2, 3, 12, 15-17, 20, 32, 88, 89, 97, 99, 101, 110 Total Communication Channel Cost, 109,111 Total CPU Time, 109, 111 Total Evaluation Steps, 108, 111 Total Execution Time, 107 Total memory Usage, 107 Total Nodes Searched, 107, 108 Total number of instructions executed, 107 user-friendliness, 182, 183 validation, 1 verification, 1 Weighted Communication Channel Cost, 109 wide-spectrum, 20

m m \ m,

BBjfMMfflB 9 6 H . ffiRH I

:

;"

9

>• I '- '•'•' r .

H

H

Series on Software Engineering and Knowledge Engineering - Vol. 10 HYBRID PARALLEL EXECUTION MODEL FOR LOGIC-BASED SPECIFICATION LANGUAGES by Jeffrey j p Tsai & Bing Li (University of Illinois, Chicago)

B

EUni

J

•

Parallel processing is a very important technique for improving the performance of various software development and maintenance activities. The purpose of this book is to introduce important techniques for parallel executation of highlevel specifications of software systems. These techniques are very useful for the construction, analysis, and transformation of reliable large-scale and complex software systems.

I • I

_J

•

Mm •

!•

-A •.*•.{• s: «:..:•.H •. I S • ; • •'

'•.'•''!

L ::i

www. worldscientific. com 4242 he

•"'"•"1"

I 1 I

Hybrid Parallel Execution Model for Logic-Based Specification Languages

Parallel Execution of Parlog

Larch: Languages and Tools for Formal Specification

Languages and Tools for Hybrid Systems Design

Compiler Optimizations for Scalable Parallel Systems Languages

Languages and Compilers for Parallel Computing

Languages and Compilers for Parallel Computing

Execution

Large Infinitary Languages, Model Theory

Real Time Programming: Languages, Specification & Verification

Advances in Design and Specification Languages for Embedded Systems

Constraint Programming Languages: Their Specification and Generation

Advances in Design and Specification Languages for SoCs

Advances in Design and Specification Languages for Embedded Systems

Execution

Execution

Execution

Specification for Tunnelling

Specification for Foamed Concrete

Specification for Ground Treatment

Execution

Languages and Compilers for Parallel Computing, 5 conf

Languages and Compilers for Parallel Computing, 14 conf., LCPC 2001

Languages and Compilers for Parallel Computing, 10 conf., LCPC'97

Languages and Compilers for Parallel Computing, 18 conf., LCPC 2005

Languages and Compilers for Parallel Computing, 21 conf., LCPC 2008

Languages and Compilers for Parallel Computing, 11 conf., LCPC'98

Languages and Compilers for Parallel Computing, 20 conf., LCPC 2007

Languages and Compilers for Parallel Computing, 15 conf., LCPC 2002

Languages and Compilers for Parallel Computing - LCPC 2010

Languages and Compilers for Parallel Computing, 16 conf., LCPC 2003

Hybrid Parallel Execution Model for Logic-Based Specification Languages

Parallel Execution of Parlog

Larch: Languages and Tools for Formal Specification

Languages and Tools for Hybrid Systems Design

Compiler Optimizations for Scalable Parallel Systems Languages

Languages and Compilers for Parallel Computing

Languages and Compilers for Parallel Computing

Execution

Large Infinitary Languages, Model Theory

Real Time Programming: Languages, Specification & Verification

Advances in Design and Specification Languages for Embedded Systems

Constraint Programming Languages: Their Specification and Generation

Advances in Design and Specification Languages for SoCs

Advances in Design and Specification Languages for Embedded Systems

Execution

Execution

Execution

Specification for Tunnelling

Specification for Foamed Concrete

Specification for Ground Treatment

Execution

Languages and Compilers for Parallel Computing, 5 conf

Languages and Compilers for Parallel Computing, 14 conf., LCPC 2001

Languages and Compilers for Parallel Computing, 10 conf., LCPC'97

Languages and Compilers for Parallel Computing, 18 conf., LCPC 2005

Languages and Compilers for Parallel Computing, 21 conf., LCPC 2008

Languages and Compilers for Parallel Computing, 11 conf., LCPC'98

Languages and Compilers for Parallel Computing, 20 conf., LCPC 2007

Languages and Compilers for Parallel Computing, 15 conf., LCPC 2002

Languages and Compilers for Parallel Computing - LCPC 2010

Languages and Compilers for Parallel Computing, 16 conf., LCPC 2003

Recommend Documents