a uml-based solver tool for combinatorial problems

A UML-BASED SOLVER TOOL FOR COMBINATORIAL PROBLEMS

A THESIS

SUBMITTED TO THE FACULTY OF GRADUATE STUDIES AND RESEARCH

IN PARTIAL FULFILLMENT OF THE REQUIREMENTS

FOR THE DEGREE OF

MASTER OF SCIENCE

IN COMPUTER SCIENCE

UNIVERSITY OF REGINA

By

Xiaofeng Li

Regina, Saskatchewan

October, 2006

© Copyright 2006: Xiaofeng Li

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

A UML-BASED SOLVER TOOL FOR COMBINATORIAL PROBLEMS

A T h e s is

S u b m i t t e d t o t h e F a c u l t y o f G r a d u a t e S t u d i e s a n d R e s e a r c h

I n P a r t ia l F u l f il l m e n t o f t h e R e q u i r e m e n t s

f o r t h e D e g r e e o f

M a s t e r o f S c ie n c e

in C o m p u t e r S c ie n c e

U n i v e r s i t y o f R e g in a

By

Xiaofeng Li

Regina, Saskatchewan

October, 2006

© Copyright 2006: Xiaofeng Li


1+1 Library and Bibliotheque et Archives Canada Archives Canada

Published Heritage Direction du Branch Patrimoine de redition

395 Wellington Street Ottawa ON KlA ON4 Canada

395, rue Wellington Ottawa ON KlA ON4 Canada

NOTICE: The author has granted a non-exclusive license allowing Library and Archives Canada to reproduce, publish, archive, preserve, conserve, communicate to the public by telecommunication or on the Internet, loan, distribute and sell theses worldwide, for commercial or non-commercial purposes, in microform, paper, electronic and/or any other formats.

The author retains copyright ownership and moral rights in this thesis. Neither the thesis nor substantial extracts from it may be printed or otherwise reproduced without the author's permission.

Your file Votre reference ISBN: 978-0-494-29148-1 Our file Notre reference ISBN: 978-0-494-29148-1

AVIS: L'auteur a accord& une licence non exclusive permettant a la Bibliotheque et Archives Canada de reproduire, publier, archiver, sauvegarder, conserver, transmettre au public par telecommunication ou par ('Internet, preter, distribuer et vendre des theses partout dans le monde, a des fins commerciales ou autres, sur support microforme, papier, electronique et/ou autres formats.

L'auteur conserve la propriete du droit d'auteur et des droits moraux qui protege cette these. Ni la these ni des extraits substantiels de celle-ci ne doivent etre imprimes ou autrement reproduits sans son autorisation.

In compliance with the Canadian Privacy Act some supporting forms may have been removed from this thesis.

While these forms may be included in the document page count, their removal does not represent any loss of content from the thesis.

1*1

Canada

Conformement a la loi canadienne sur la protection de la vie privee, quelques formulaires secondaires ont ete enleves de cette these.

Bien que ces formulaires aient inclus dans la pagination, it n'y aura aucun contenu manquant.


Library and Archives Canada

Bibliotheque et Archives Canada

Published Heritage Branch

395 Wellington Street Ottawa ON K1A 0N4 Canada

Your file Votre reference ISBN: 978-0-494-29148-1 Our file Notre reference ISBN: 978-0-494-29148-1

Direction du Patrimoine de I'edition

395, rue Wellington Ottawa ON K1A 0N4 Canada

NOTICE:The author has granted a nonexclusive license allowing Library and Archives Canada to reproduce, publish, archive, preserve, conserve, communicate to the public by telecommunication or on the Internet, loan, distribute and sell theses worldwide, for commercial or noncommercial purposes, in microform, paper, electronic and/or any other formats.

AVIS:L'auteur a accorde une licence non exclusive permettant a la Bibliotheque et Archives Canada de reproduire, publier, archiver, sauvegarder, conserver, transmettre au public par telecommunication ou par I'lnternet, preter, distribuer et vendre des theses partout dans le monde, a des fins commerciales ou autres, sur support microforme, papier, electronique et/ou autres formats.

The author retains copyright ownership and moral rights in this thesis. Neither the thesis nor substantial extracts from it may be printed or otherwise reproduced without the author's permission.

L'auteur conserve la propriete du droit d'auteur et des droits moraux qui protege cette these.Ni la these ni des extraits substantiels de celle-ci ne doivent etre imprimes ou autrement reproduits sans son autorisation.

In compliance with the Canadian Privacy Act some supporting forms may have been removed from this thesis.

While these forms may be included in the document page count, their removal does not represent any loss of content from the thesis.

Conformement a la loi canadienne sur la protection de la vie privee, quelques formulaires secondaires ont ete enleves de cette these.

Bien que ces formulaires aient inclus dans la pagination, il n'y aura aucun contenu manquant.

i * i

CanadaReproduced with permission of the copyright owner. Further reproduction prohibited without permission.


FACULTY OF GRADUATE STUDIES AND RESEARCH

SUPERVISORY AND EXAMINING COMMITTEE

Xiaofeng Li, candidate for the degree of Master of Science, has presented a thesis titled, A UML-Based Solver Tool for Combinatorial Problems, in an oral examination held on October 20, 2006. The following committee members have found the thesis acceptable in form and content, and that the candidate demonstrated satisfactory knowledge of the subject material.

External Examiner:

Co-Supervisor:

Co-Supervisor:

Committee Member:

Chair of Defense:

Dr. Andrei Volodin, Department of Mathematics and Statistics

Dr. Samira Sadaoui Mouhoub, Department of Computer Science

Dr. Malek Mouhoub Department of Computer Science

Dr. Boting Yang, Department of Computer Science

Dr. Mohamed EI-Darieby, Faculty of Engineering



FACULTY OF GRADUATE STUDIES AND RESEARCH

SUPERVISORY AND EXAMINING COMMITTEE

Xiaofeng Li, candidate for the degree of Master of Science, has presented a thesis titled, A UML-Based Solver Tool for Combinatorial Problems, in an oral examination held on October 20, 2006. The following committee members have found the thesis acceptable in form and content, and that the candidate demonstrated satisfactory knowledge of the subject material.

External Examiner: Dr. Andrei Volodin,Department of Mathematics and Statistics

Co-Supervisor: Dr. Samira Sadaoui Mouhoub,Department of Computer Science

Co-Supervisor: Dr. Malek MouhoubDepartment of Computer Science

Committee Member: Dr. Boting Yang, Department of Computer Science

Chair of Defense: Dr. Mohamed El-Darieby, Faculty of Engineering


ABSTRACT

With the increasing of intelligent software requirements, constraint programming has

attracted high attention from many areas because of its potential for solving real-life com-

binatorial problems. Today, users need to solve more complex combinatorial problems with

more intelligent solving techniques. A more challenging task is the description of combina-

torial problems. In fact, we extend an existing specification language, called OCL (Object

Constraint Language), to facilitate the descriptions of complex constraints of combinatorial

problems. Therefore, in this thesis, we propose a novel tool to assist end-users in specifying

and solving their combinatorial problems. The tool provides generic OCL-based templates

that can be customized to describe any combinatorial problem. From the combinatorial

problem description, the proposed tool automatically generates the corresponding constraint

network composed of a constraint graph and solutions.


ABSTRACT

W ith the increasing of intelligent software requirements, constraint programming has

attracted high attention from many areas because of its potential for solving real-life com

binatorial problems. Today, users need to solve more complex combinatorial problems with

more intelligent solving techniques. A more challenging task is the description of combina

torial problems. In fact, we extend an existing specification language, called OCL (Object

Constraint Language), to facilitate the descriptions of complex constraints of combinatorial

problems. Therefore, in this thesis, we propose a novel tool to assist end-users in specifying

and solving their combinatorial problems. The tool provides generic OCL-based templates

tha t can be customized to describe any combinatorial problem. From the combinatorial

problem description, the proposed tool automatically generates the corresponding constraint

network composed of a constraint graph and solutions.

i


ACKNOWLEDGEMENTS

With sincere gratitude, I would like to express my appreciation to Dr. Malek Mouhoub

and Dr. Samira Sadaoui, my co-supervisors, for providing me with the sequential learning

program and financial support, and for helping me conduct the research outlined in this

program. They always worked hard supervising me, and training me to become a good

writer. Their constant guidance and encouragement will be appreciated forever.

I would also like to thank Dr. B. Yang for his insightful comments, suggestions, and

constructive criticisms that resulted in an improved thesis.

I am grateful to the Faculty of Graduate Studies and Research and the Department of

Computer Science for the financial assistance that allowed me to concentrate on my research.

I am also grateful to my wife, Qianru Guo, my daughter, Zhonghua Li, my father, Huai

Li, my mom, Fengxian Hou, and my sisters, Xiaojia Li and Xiaoming Li.

fi


ACKNOWLEDGEMENTS

W ith sincere gratitude, I would like to express my appreciation to Dr. Malek Mouhoub

and Dr. Samira Sadaoui, my co-supervisors, for providing me with the sequential learning

program and financial support, and for helping me conduct the research outlined in this

program. They always worked hard supervising me, and training me to become a good

writer. Their constant guidance and encouragement will be appreciated forever.

I would also like to thank Dr. B. Yang for his insightful comments, suggestions, and

constructive criticisms that resulted in an improved thesis.

I am grateful to the Faculty of Graduate Studies and Research and the Department of

Computer Science for the financial assistance tha t allowed me to concentrate on my research.

I am also grateful to my wife, Qianru Guo, my daughter, Zhonghua Li, my father, Huai

Li, my mom, Fengxian Hou, and my sisters, Xiaojia Li and Xiaoming Li.

ii


TABLE OF CONTENTS

ABSTRACT i

ACKNOWLEDGEMENTS ii

TABLE OF CONTENTS iii

LIST OF TABLES vi

LIST OF FIGURES vii

ACRONYM LIST ix

1. INTRODUCTION 1

1.1 Problem and motivations 1

1.2 Proposed solution: a new way for solving combinatorial problems 2

1.2.1 New UML frameworks for CSPs and TCSPs 3

1.2.2 OCL extensions for describing and solving CSPs and TCSPs 3

1.3 Thesis organization 5

2. COMBINATORIAL PROBLEMS AND CONSTRAINT PROGRAM-

MING 6

2.1 Introduction to CSPs 6

2.2 Introduction to temporal CSPs 10

2.3 Introduction to distributed (temporal) CSPs 11

2.4 Constraint programming 13

2.5 Conclusion 15

3. AGENT AND OBJECT-ORIENTED SPECIFICATIONS 17

3.1 Introduction to UML 17

3.2 Introduction to OCL 20

iii


TABLE OF CONTENTS

ABSTRACT i

ACKNOWLEDGEMENTS ii

TABLE OF CONTENTS iii

LIST OF TABLES vi

LIST OF FIGURES vii

ACRONYM LIST ix

1. INTRODUCTION 1

1.1 Problem and m otivations......................................................................................... 1

1.2 Proposed solution: a new way for solving combinatorial p ro b le m s ............... 2

1.2.1 New UML frameworks for CSPs and T C S P s .......................................... 3

1.2.2 OCL extensions for describing and solving CSPs and T C S P s ............. 3

1.3 Thesis organ ization ................................................................................................... 5

2. COMBINATORIAL PROBLEMS AND CONSTRAINT PROGRAM

MING 6

2.1 Introduction to C S P s ......................................................................................... 6

2.2 Introduction to temporal CSPs ...................................................................... 10

2.3 Introduction to distributed (temporal) C S P s ................................................. 11

2.4 Constraint program m ing.......................................................................................... 13

2.5 Conclusion.................................................................................................................... 15

3. A G EN T A N D O BJEC T-O R IEN TED SPECIFICATIO NS 17

3.1 Introduction to U M L ......................................................................................... 17

3.2 Introduction to O C L ......................................................................................... 20

iii


3.3

3.4

3.5

Introduction to agent-UML

Examples

3.4.1 Map colouring problem

3.4.2 Time scheduling problem

Conclusion

23

25

25

28

30

4. GENERIC CSP FRAMEWORKS WITH UML AND OCL 31

4.1 A generic CSP framework 31

4.1.1 Generic CSP class diagram 31

4.1.2 OCL extensions 33

4.1.3 Generic CSP template 34

4.1.4 Examples of "map colouring problem" and "share apples" 35

4.2 A generic temporal CSP framework 39

4.2.1 Generic TCSP class diagram 40

4.2.2 OCL extensions 41

4.2.3 Generic TCSP template 42

4.2.4 A time scheduling problem example 43

4.3 Conclusion 46

5. GENERIC DISTRIBUTED CSP FRAMEWORKS WITH AGENT-UML

AND OCL 47

5.1 Generic distributed (temporal) CSP agent class diagram 47

5.2 OCL extensions 48

5.3 Generic distributed CSP and TCSP templates 49

5.4 Examples 52

5.4.1 Map colouring problem 52

5.4.2 Time scheduling problem 55

5.5 Conclusion 57

6. IMPLEMENTATION AND EXPERIMENTATION 58

6.1 UML-based solver 58

iv


3.3 Introduction to agent-UML .................................................................................... 23

3.4 E x a m p le s .................................................................................................................... 25

3.4.1 Map colouring p rob lem .................................................................................. 25

3.4.2 Time scheduling problem .............................................................................. 28

3.5 Conclusion.................................................................................................................... 30

4. GENERIC CSP FRAMEWORKS WITH UML AND OCL 31

4.1 A generic CSP fram e w o rk ........................................................................................ 31

4.1.1 Generic CSP class d iagram ........................................................................... 31

4.1.2 OCL extensions............................................................................................... 33

4.1.3 Generic CSP te m p la te .................................................................................. 34

4.1.4 Examples of “map colouring problem” and “share apples” ................. 35

4.2 A generic temporal CSP fram ew ork ........................................................................ 39

4.2.1 Generic TCSP class d iag ram ........................................................................ 40

4.2.2 OCL extensions............................................................................................... 41

4.2.3 Generic TCSP te m p la te ............................................................................... 42

4.2.4 A time scheduling problem exam ple............................................................. 43

4.3 Conclusion.................................................................................................................... 46

5. GENERIC DISTRIBUTED CSP FRAMEWORKS WITH AGENT-UML

AND OCL 47

5.1 Generic distributed (temporal) CSP agent class diagram .................................... 47

5.2 OCL ex tensions.......................................................................................................... 48

5.3 Generic distributed CSP and TCSP te m p la te s ...................................................... 49

5.4 Examples .................................................................................................................... 52

5.4.1 Map colouring p rob lem .................................................................................. 52

5.4.2 Time scheduling problem ............................................................................... 55

5.5 Conclusion.................................................................................................................... 57

6. IMPLEMENTATION AND EXPERIMENTATION 58

6.1 UML-based so lver....................................................................................................... 58

iv


6.2 Examples 60

6.2.1 Map colouring problem 62

6.2.2 Time scheduling problem 65

6.2.3 N-queens problem 67

6.2.4 Benchmark 69

6.3 Conclusion 69

7. CONCLUSIONS AND PROSPECTS 70

7.1 Contribution 70

7.2 Future work 71

8. BIBLIOGRAPHY 73

v


6.2 Examples ................................................................................................................... 60

6.2.1 Map colouring p rob lem ................................................................................. 62

6.2.2 Time scheduling problem .............................................................................. 65

6.2.3 N-queens problem ........................................................................................... 67

6.2.4 Benchmark .................................................................................................... 69

6.3 Conclusion.................................................................................................................... 69

7. CONCLUSIONS AND PROSPECTS 70

7.1 C ontribution................................................................................................................ 70

7.2 Future w o rk ................................................................................................................ 71

8. BIBLIOGRAPHY 73

v


LIST OF TABLES

1.1 Steps of proposed solution development 4

2.1 Min-conflicts-random-walk algorithm 9

3.1 Basic type, values, and operations 21

4.1 CSP specification template 35

4.2 TCSP specification template 43

5.1 Distributed CSP specification template 50

5.2 Distributed TCSP specification template 51

6.1 Choco code of 3-colouring 63

6.2 N-queens OCL specification 67

6.3 Time taken for solving combinatorial problems 69

vi


LIST OF TABLES

1.1 Steps of proposed solution developm ent................................................................ 4

2.1 Min-conflicts-random-walk a lg o ri th m .................................................................... 9

3.1 Basic type, values, and operations.......................................................................... 21

4.1 CSP specification tem p la te ....................................................................................... 35

4.2 TCSP specification te m p la te .................................................................................... 43

5.1 Distributed CSP specification te m p la te ................................................................ 50

5.2 Distributed TCSP specification te m p la te ............................................................. 51

6.1 Choco code of 3 -co lo u rin g ....................................................................................... 63

6.2 N-queens OCL specifica tion .................................................................................... 67

6.3 Time taken for solving combinatorial problem s................................................... 69

vi


LIST OF FIGURES

1.1 Ways of solving combinatorial problems 2

2.1 A CSP example 7

2.2 Dual encoding 8

2.3 Depth-first algorithm 9

2.4 Allen logic relations 10

2.5 Structure of SOPO 10

2.6 Multi-agent truth maintenance system 12

2.7 CSP represented by graphic 14

2.8 Extending language semantics by class library 14

3.1 Dependency relationship of UML 17

3.2 Generalization relationship of UML 18

3.3 Association relationship of UML 18

3.4 Class diagram 19

3.5 Object diagram 19

3.6 Agent class diagram 23

3.7 UML example with AUML 25

3.8 4-colouring 26

3.9 3-colouring 26

3.10 3-colouring constraint graph 27

3.11 Map colouring problem with distributed CSP 28

3.12 An example of temporal CSP 29

3.13 Time scheduling problem with distributed TCSP 29

4.1 Generic CSP class diagram 32

4.2 Constraint network of 3-colouring 38

4.3 Generic TCSP class diagram 40

4.4 Constraint network of the time scheduling problem 45

5.1 Generic agent class diagram 48

vii


LIST OF FIGURES

1.1 Ways of solving combinatorial problem s............................................................... 2

2.1 A CSP ex am p le .......................................................................................................... 7

2.2 Dual encoding ............................................................................................................. 8

2.3 Depth-first a lg o rith m ................................................................................................ 9

2.4 Allen logic re la tions................................................................................................... 10

2.5 Structure of S O P O ................................................................................................... 10

2.6 Multi-agent tru th maintenance s y s t e m ................................................................ 12

2.7 CSP represented by g r a p h ic ................................................................................... 14

2.8 Extending language semantics by class l ib r a r y ................................................... 14

3.1 Dependency relationship of U M L ......................................................................... 17

3.2 Generalization relationship of U M L ...................................................................... 18

3.3 Association relationship of U M L ............................................................................. 18

3.4 Class d ia g ra m ............................................................................................................. 19

3.5 Object d ia g ra m .......................................................................................................... 19

3.6 Agent class diagram ................................................................................................ 23

3.7 UML example with AUML ................................................................................... 25

3.8 ^-colouring ................................................................................................................. 26

3.9 5-colouring ................................................................................................................. 26

3.10 5-colouring constraint g r a p h .................................................................................... 27

3.11 Map colouring problem with distributed CSP ................................................... 28

3.12 An example of temporal CSP ................................................................................ 29

3.13 Time scheduling problem with distributed TCSP ............................................ 29

4.1 Generic CSP class d iag ram ....................................................................................... 32

4.2 Constraint network of 5-colouring.......................................................................... 38

4.3 Generic TCSP class d iag ram ................................................................................... 40

4.4 Constraint network of the time scheduling problem ......................................... 45

5.1 Generic agent class d ia g ra m ................................................................................... 48

vii


6.1 UML-based solver for CSP and TCSP 59

6.2 GUI of the UML-based solver 59

6.3 Class diagram of the UML-based solver 60

6.4 Combinatorial problem type options of the UML-based solver 60

6.5 Constraint graph area of the UML-based solver 61

6.6 Solution areas of the UML-based solver 61

6.7 3-colouring problem screen shot 64

6.8 Time scheduling problem screen shot 66

6.9 4-queens screen shot 68

viii


6.1 UML-based solver for CSP and T C S P ..................................................................... 59

6.2 GUI of the UML-based s o lv e r .................................................................................. 59

6.3 Class diagram of the UML-based so lv er.................................................................. 60

6.4 Combinatorial problem type options of the UML-based solver ....................... 60

6.5 Constraint graph area of the UML-based solver ................................................... 61

6.6 Solution areas of the UML-based so lv er.................................................................. 61

6.7 3-colouring problem screen s h o t ............................................................................... 64

6.8 Time scheduling problem screen s h o t ..................................................................... 66

6.9 4-queens screen shot .................................................................................................. 68


ACRONYM LIST

1. AI

2. CP

3. CSP

4. DCSP

5. DTCSP

6. OCL

7. OOCP

8. SOPO

9. TCSP

10. UML

11. GUI

ix

Artificial Intelligence

Constraint Programming

Constraint Satisfaction Problem

Distributed CSP

Distributed Temporal CSP

Object Constraint Language

Object-Oriented Constraint Programming

Set Of Possible Occurrences

Temporal CSP

Unified Modeling Language

Graphic User Interface


ACRONYM LIST

1. AI Artificial Intelligence

2. CP Constraint Programming

3. CSP Constraint Satisfaction Problem

4. DCSP Distributed CSP

5. DTCSP Distributed Temporal CSP

6. OCL Object Constraint Language

7. OOCP Object-Oriented Constraint Programming

8. SOPO Set Of Possible Occurrences

9. TCSP Temporal CSP

10. UML Unified Modeling Language

11. GUI Graphic User Interface


1. INTRODUCTION 1.1 Problem and motivations

Combinatorial problems are mathematical and logical problems for which one must find

objects in a system that satisfy a number of constraints [31, 35]. In this thesis, we segregate

them into two classes: (i) constraint satisfaction problems (CSPs) [15, 38] in which domains

of variables are often discrete numbers, and (ii) temporal CSPs (TCSPs) [16], specialized

CSPs taking place in a continuous time space. Many real-life applications can be consid-

ered as instances of combinatorial problems [31, 35] such as scheduling problems, natural

language processing, business applications, and so on. Because of the importance of solving

combinatorial problems in so many different fields, constraint programming (CP) [22, 4, 3]

was developed. However, today users still have many difficulties when describing and solving

their CSP and TCSP applications, including the following.

• Users do not have enough Artificial Intelligence (AI) foundations. A lot of time and

effort are spent in describing CSPs and TCSPs and also studying their solving tech-

niques.

• Requirements of CSPs and TCSPs written in natural languages are prone to ambiguity

and misinterpretation. On the other hand, when CSPs and TCSPs are formalized with

formulas or specialized models, other users still have difficulty understanding them.

• Problems become more complex as the variables and constraints increase. This makes

the CSP and TCSP descriptions very difficult.

• Solving algorithm selection is another challenge. Most users lack knowledge about the

solving techniques for CSPs/TCSPs. In addition, they cannot decide which algorithms

best suit their problems.

Solving the above problems is the objective of this thesis. Most developers and users are

engaged in developing CSP and TCSP applications, but they do not have enough knowledge

on CSP and TCSP representations and algorithms. Experiences in software development

1


1. INTRODUCTION1.1 Problem and motivations

Combinatorial problems are mathematical and logical problems for which one must find

objects in a system that satisfy a number of constraints [31, 35]. In this thesis, we segregate

them into two classes: (i) constraint satisfaction problems (CSPs) [15, 38] in which domains

of variables are often discrete numbers, and (ii) temporal CSPs (TCSPs) [16], specialized

CSPs taking place in a continuous time space. Many real-life applications can be consid

ered as instances of combinatorial problems [31, 35] such as scheduling problems, natural

language processing, business applications, and so on. Because of the importance of solving

combinatorial problems in so many different fields, constraint programming (CP) [22, 4, 3]

was developed. However, today users still have many difficulties when describing and solving

their CSP and TCSP applications, including the following.

• Users do not have enough Artificial Intelligence (AI) foundations. A lot of time and

effort are spent in describing CSPs and TCSPs and also studying their solving tech

niques.

• Requirements of CSPs and TCSPs written in natural languages are prone to ambiguity

and misinterpretation. On the other hand, when CSPs and TCSPs are formalized with

formulas or specialized models, other users still have difficulty understanding them.

• Problems become more complex as the variables and constraints increase. This makes

the CSP and TCSP descriptions very difficult.

• Solving algorithm selection is another challenge. Most users lack knowledge about the

solving techniques for CSPs/TCSPs. In addition, they cannot decide which algorithms

best suit their problems.

Solving the above problems is the objective of this thesis. Most developers and users are

engaged in developing CSP and TCSP applications, but they do not have enough knowledge

on CSP and TCSP representations and algorithms. Experiences in software development

1


have shown that software projects are always over budget and past deadlines [10]. Un-

derstanding requirements and algorithm selections are the vital factors [10]. Therefore,

describing and solving CSPs and TCSPs are very important tasks.

1.2 Proposed solution: a new way for solving combinatorial prob-

lems

The three ways of solving combinatorial problems are shown in Figure 1.1

Operational Research

At Techniques (CSP algorithms, —

Solving a Combinatorial Problem

OOCP

Constraint Solver (Prolog, Choco, ...)

GUI

Wrapping operational research and OOCP

behind GUI

Figure 1.1: Ways of solving combinatorial problems

In operational research, developers have to implement solving algorithms with program-

ming languages such as C. So, they must have knowledge in many operational research

techniques. The second way is to describe and solve combinatorial problems with constraint

programming [22, 20] such as Prolog. Object-oriented constraint programming (OOCP) is a

combination of object-oriented programming and constraint programming [13]. The OOCP

methodology is not meant to be a totally new object-oriented methodology but instead an

extension that will work with any existing object-oriented methodology and notation, such

as UML. The OOCP analysis and design are almost the same with any other object-oriented

software system but some constraint solvers are provided by the third-party products such

as Choco and Java Cream. These constraint solvers provide solving algorithms. Thus,

the developers and users can smoothly integrate traditional object-oriented techniques with

constraint-based programming. However, users still need to know programming languages

2


have shown that software projects are always over budget and past deadlines [10]. Un

derstanding requirements and algorithm selections are the vital factors [10]. Therefore,

describing and solving CSPs and TCSPs are very important tasks.

1.2 Proposed solution: a new way for solving combinatorial prob

lems

The three ways of solving combinatorial problems are shown in Figure 1.1

Solving a Combinatorial Problem

Operational Research

Constraint Solver (Prolog, C hoco ,...)

Wrapping operational research and OOCP

V. behind GUI .

Al Techniques (CSP algorithms,...)

Figure 1.1: Ways of solving combinatorial problems

In operational research, developers have to implement solving algorithms with program

ming languages such as C. So, they must have knowledge in many operational research

techniques. The second way is to describe and solve combinatorial problems with constraint

programming [22, 20] such as Prolog. Object-oriented constraint programming (OOCP) is a

combination of object-oriented programming and constraint programming [13]. The OOCP

methodology is not meant to be a totally new object-oriented methodology but instead an

extension tha t will work with any existing object-oriented methodology and notation, such

as UML. The OOCP analysis and design are almost the same with any other object-oriented

software system but some constraint solvers are provided by the third-party products such

as Choco and Java Cream. These constraint solvers provide solving algorithms. Thus,

the developers and users can smoothly integrate traditional object-oriented techniques with

constraint-based programming. However, users still need to know programming languages

2


and (temporal) CSP solving techniques to implement and choose the most appropriate al-

gorithms for their problems.

In this thesis, we propose a third way for solving combinatorial problems. We provide a

tool to assist end-users. OOCP and operational research are wrapped and hidden into the

tool. End-users just describe their combinatorial problems with a formal language. They

do not have to know programming languages or (temporal) CSP solving algorithms. The

tool analyzes and models (temporal) CSP descriptions with OOCP and generates solutions

automatically.

1.2.1 New UML frameworks for CSPs and TCSPs

In this thesis, we build two generic object-oriented [34] frameworks to describe any CSP

and TCSP application. These frameworks are based on the (Unified Modeling Language)

UML [19] class diagrams and the proposed Object Constraint Language (OCL) extensions

that we will describe in the next section.

UML is a standard modeling language for capturing the requirements, architectures, and

design of object-oriented software systems [19]. A widely accepted language used by software

developers, it is an excellent fit for the graphic representation of the user's applications.

Applying the UML to the development of a multidisciplinary software tool increases the

software's quality and potential for reuse.

We use UML to specify the CSPs and TCSPs, but it is only a visual notation to represent

the relationship between each object. Users could not know problem details only depending

on the CSP and TCSP models. Thus, we must use a formal language to represent these

details such as variables, constraints and solution rules.

1.2.2 OCL extensions for describing and solving CSPs and TCSPs

A few specialized formal languages, such as CDL [26], CCEL [30], were developed to

describe constraints for CSPs. However, these languages are difficult to study and are not

popular. Worse, these languages are platform and programming language dependent.

In this thesis, we use OCL to describe the constraints for combinatorial problems. The

3


and (temporal) CSP solving techniques to implement and choose the most appropriate al

gorithms for their problems.

In this thesis, we propose a third way for solving combinatorial problems. We provide a

tool to assist end-users. OOCP and operational research are wrapped and hidden into the

tool. End-users just describe their combinatorial problems with a formal language. They

do not have to know programming languages or (temporal) CSP solving algorithms. The

tool analyzes and models (temporal) CSP descriptions with OOCP and generates solutions

automatically.

1.2.1 New UML frameworks for CSPs and TCSPs

In this thesis, we build two generic object-oriented [34] frameworks to describe any CSP

and TCSP application. These frameworks are based on the (Unified Modeling Language)

UML [19] class diagrams and the proposed Object Constraint Language (OCL) extensions

tha t we will describe in the next section.

UML is a standard modeling language for capturing the requirements, architectures, and

design of object-oriented software systems [19]. A widely accepted language used by software

developers, it is an excellent fit for the graphic representation of the user’s applications.

Applying the UML to the development of a multidisciplinary software tool increases the

software’s quality and potential for reuse.

We use UML to specify the CSPs and TCSPs, but it is only a visual notation to represent

the relationship between each object. Users could not know problem details only depending

on the CSP and TCSP models. Thus, we must use a formal language to represent these

details such as variables, constraints and solution rules.

1.2.2 OCL extensions for describing and solving CSPs and TCSPs

A few specialized formal languages, such as CDL [26], CCEL [30], were developed to

describe constraints for CSPs. However, these languages are difficult to study and are not

popular. Worse, these languages are platform and programming language dependent.

In this thesis, we use OCL to describe the constraints for combinatorial problems. The

3


reason is that OCL is a part of UML. Developers use OCL to describe constraints on UML

models and it is a well-defined and flexible constraint description language for object-oriented

models [41]. However we need to extend OCL to be able to specify (temporal) constraints of

combinatorial problems because it lacks of constraint description for CSPs and TCSPs. So,

we extend OCL with new keywords, expressions, and functions. Now end-users just need to

represent their problems and solution rules with the OCL extensions. From these specifica-

tions, the corresponding constraint networks and solutions will be obtained automatically.

For supporting this proposed solution, we build a novel solver tool to assist users in

specifying and solving their constraint applications. We use OCL as a simple and well-known

language to easily specify constraints. In addition, our solver can include any existing solving

algorithms implemented in any object-oriented programming language. The tool provides

generic OCL-based templates that can be customized to describe any (temporal) CSP. In

fact, users just need to fill in the constraints and solution rules. The assistance consists

of (1) checking the correctness of entered values and the consistency of the whole CSP

specification and (2) selecting the correct solving algorithm depending on the solution rules.

From the (temporal) CSP specification, the solver automatically generates the constraint

graph, solution graph, and text. To sumarize, several steps of the proposed solution are

given in Table 1.1.

Table 1.1: Steps of proposed solution development

• Performing object-oriented design based on generic CSP and TCSP. The result of the design is that UML frameworks of generic CSP and TCSP are specified.

• Transforming user requirements to (temporal) CSPs.

• Representing (temporal) CSPs and goals with OCL extensions.

• Generating the OOCP code with constraint class libraries.

• Showing constraint graphs and solutions.

For simple CSPs and TCSPs, the generic CSP and TCSP frameworks are a good choice.

However, for complex CSPs and TCSPs, using these frameworks to represent the problems

is still difficult because there are too many variables and constraints. Users will be confused

4


reason is that OCL is a part of UML. Developers use OCL to describe constraints on UML

models and it is a well-defined and flexible constraint description language for object-oriented

models [41]. However we need to extend OCL to be able to specify (temporal) constraints of

combinatorial problems because it lacks of constraint description for CSPs and TCSPs. So,

we extend OCL with new keywords, expressions, and functions. Now end-users just need to

represent their problems and solution rules with the OCL extensions. Prom these specifica

tions, the corresponding constraint networks and solutions will be obtained automatically.

For supporting this proposed solution, we build a novel solver tool to assist users in

specifying and solving their constraint applications. We use OCL as a simple and well-known

language to easily specify constraints. In addition, our solver can include any existing solving

algorithms implemented in any object-oriented programming language. The tool provides

generic OCL-based templates that can be customized to describe any (temporal) CSP. In

fact, users just need to fill in the constraints and solution rules. The assistance consists

of (1) checking the correctness of entered values and the consistency of the whole CSP

specification and (2) selecting the correct solving algorithm depending on the solution rules.

FYom the (temporal) CSP specification, the solver automatically generates the constraint

graph, solution graph, and text. To sumarize, several steps of the proposed solution are

given in Table 1.1.

__________________ Table 1.1: Steps of proposed solution development___________________

• Performing object-oriented design based on generic CSP and TCSP. The result of the design is tha t UML frameworks of generic CSP and TCSP are specified.

• Transforming user requirements to (temporal) CSPs.

• Representing (temporal) CSPs and goals with OCL extensions.

• Generating the OOCP code with constraint class libraries.

• Showing constraint graphs and solutions.

For simple CSPs and TCSPs, the generic CSP and TCSP frameworks are a good choice.

However, for complex CSPs and TCSPs, using these frameworks to represent the problems

is still difficult because there are too many variables and constraints. Users will be confused

4


when they read (temporal) CSP descriptions. Therefore, we use agent-oriented techniques

and agent-UML to build a new framework with distributed CSP and TCSP techniques to

solve complex CSPs and TCSPs. OCL is also used to represent the variables and constraints.

This framework is more complex but it is more flexible and powerful. However, there is no

tool to assist us in drawing agent-UML class diagram. So we do not show all the details in

this framework.

1.3 Thesis organization

This thesis is organized as follows. There are three parts in Chapter 2. First, we introduce

CSPs, TCSPs, and the solving techniques in details. Then, we present distributed (temporal)

CSP techniques and how to map a (temporal) CSP into a distributed (temporal) CSP.

Finally, the implementation techniques and constraint programming are presented.

In Chapter 3, we introduce UML and OCL. Then, the details of agent-UML are shown.

Following this, we specify two examples, map colouring and time scheduling problems, using

CSP, TCSP, and distributed (temporal) CSP techniques.

In Chapter 4, we describe generic CSPs and TCSPs with UML class diagrams and then

explain each class. Furthermore, we extend OCL keywords and expressions based on the

generic CSP and TCSP class diagrams. The following CSP and TCSP description templates

assist users in their descriptions with these extensions. Finally, the examples given in Chapter

3 are used to support these OCL extensions and description templates.

In Chapter 5, we use up-to-date (temporal) CSP solving techniques to solve (temporal)

CSPs. First, we give the generic distributed (temporal) CSP agent class diagrams. Then,

we extend OCL based on these agent class diagrams. In the following, the distributed CSP

and TCSP templates are given to assist users in their descriptions. Finally, we again use the

examples shown in Chapter 3 to support these OCL extensions and description templates.

In Chapter 6, we implement the UML-based (temporal) CSP tool to demonstrate the

effectiveness of our combinatorial problem descriptions. We illustrate the usability of the

novel tool through some real-world CSP and TCSP applications.

Chapter 7 concludes this thesis with a summary and further works.

5


when they read (temporal) CSP descriptions. Therefore, we use agent-oriented techniques

and agent-UML to build a new framework with distributed CSP and TCSP techniques to

solve complex CSPs and TCSPs. OCL is also used to represent the variables and constraints.

This framework is more complex but it is more flexible and powerful. However, there is no

tool to assist us in drawing agent-UML class diagram. So we do not show all the details in

this framework.

1.3 Thesis organization

This thesis is organized as follows. There are three parts in Chapter 2. First, we introduce

CSPs, TCSPs, and the solving techniques in details. Then, we present distributed (temporal)

CSP techniques and how to map a (temporal) CSP into a distributed (temporal) CSP.

Finally, the implementation techniques and constraint programming are presented.

In Chapter 3, we introduce UML and OCL. Then, the details of agent-UML are shown.

Following this, we specify two examples, map colouring and time scheduling problems, using

CSP, TCSP, and distributed (temporal) CSP techniques.

In Chapter 4, we describe generic CSPs and TCSPs with UML class diagrams and then

explain each class. Furthermore, we extend OCL keywords and expressions based on the

generic CSP and TCSP class diagrams. The following CSP and TCSP description templates

assist users in their descriptions with these extensions. Finally, the examples given in Chapter

3 are used to support these OCL extensions and description templates.

In Chapter 5, we use up-to-date (temporal) CSP solving techniques to solve (temporal)

CSPs. First, we give the generic distributed (temporal) CSP agent class diagrams. Then,

we extend OCL based on these agent class diagrams. In the following, the distributed CSP

and TCSP templates are given to assist users in their descriptions. Finally, we again use the

examples shown in Chapter 3 to support these OCL extensions and description templates.

In Chapter 6, we implement the UML-based (temporal) CSP tool to demonstrate the

effectiveness of our combinatorial problem descriptions. We illustrate the usability of the

novel tool through some real-world CSP and TCSP applications.

Chapter 7 concludes this thesis with a summary and further works.

5


2. COMBINATORIAL PROBLEMS AND

CONSTRAINT PROGRAMMING First, this chapter presents the formal definitions and solving techniques of constraint

satisfaction problems [38, 27, 28, 29] and temporal constraint satisfaction problems [16, 36,

33, 32]. It also introduces a famous technique, called distributed (temporal) constraint

reasoning [44, 9, 45, 43], that solves complex (temporal) constraint problems using the agent

paradigms. A model is also presented to show how to transform qualitative and quantitative

(temporal) constraint satisfaction problems into distributed (temporal) ones.

Next, this chapter reviews constraint programming, one of the combinatorial problem

implementation and solving techniques. Then, some constraint class libraries are introduced

to specify and solve any combinatorial problem.

2.1 Introduction to CSPs

Many real-life applications can be considered as instances of constraint satisfactions prob-

lems (CSP) [35] such as scheduling problems, natural language processing, business applica-

tions, and so on. A CSP includes a finite set of variables defined on a finite domain of values

and a finite set of constraints restricting the values that the variables can be assigned. The

goal is to obtain a set of assigned values to variables satisfying all the constraints. Generally,

the domain of a variable is a finite set of discrete values. A constraint is an arbitrary relation

over the set of variables. It can be represented by mathematical or logical formulas.

Generally, any combinatorial problem is represented as a (hyper) graph, which we call

a constraint graph. The constraint graph can help users to validate and understand their

problems, but it is difficult to represent complex logic relations.

Example 2.1. This is a simple mathematic problem that has six variables and four formulas.

The value of each variable can be 0 or 1. So, the problem can be represented as:

Variables: xl , x2, x3, x4, x5, x6

Domain: 0, 1

6


2 . COMBINATORIAL PROBLEMS AND

CONSTRAINT PROGRAMMINGFirst, this chapter presents the formal definitions and solving techniques of constraint

satisfaction problems [38, 27, 28, 29] and temporal constraint satisfaction problems [16, 36,

33, 32]. It also introduces a famous technique, called distributed (temporal) constraint

reasoning [44, 9, 45, 43], tha t solves complex (temporal) constraint problems using the agent

paradigms. A model is also presented to show how to transform qualitative and quantitative

(temporal) constraint satisfaction problems into distributed (temporal) ones.

Next, this chapter reviews constraint programming, one of the combinatorial problem

implementation and solving techniques. Then, some constraint class libraries axe introduced

to specify and solve any combinatorial problem.

2.1 Introduction to CSPs

Many real-life applications can be considered as instances of constraint satisfactions prob

lems (CSP) [35] such as scheduling problems, natural language processing, business applica

tions, and so on. A CSP includes a finite set of variables defined on a finite domain of values

and a finite set of constraints restricting the values tha t the variables can be assigned. The

goal is to obtain a set of assigned values to variables satisfying all the constraints. Generally,

the domain of a variable is a finite set of discrete values. A constraint is an arbitrary relation

over the set of variables. It can be represented by mathematical or logical formulas.

Generally, any combinatorial problem is represented as a (hyper) graph, which we call

a constraint graph. The constraint graph can help users to validate and understand their

problems, but it is difficult to represent complex logic relations.

E xam ple 2.1. This is a simple mathematic problem tha t has six variables and four formulas.

The value of each variable can be 0 or 1. So, the problem can be represented as:

Variables: aq, x2, X3 , X4 , X5 , Xe

Domain: 0, 1

6


Constraints: C1: xi+x2+x6 = 1, C2: xi-x3-+4 = 1, C3: X4+X5- x6 > 0, C4:

X2H- X5-x6 = 0

C4

Variables: x1..x6 Domain: (0,1} Constraints:

C1: x1+x2+x6=1 C2: xi -x 3+x4=1 C3: x4+x5-x6>0

C4: x2+x5-x6=0

C1

0,1 0 1 0,1 0,1 0,1 0,1

'11 1P PW'4411111111 ,

C2

Figure 2.1: A CSP example

C3

A binary CSP has unary and binary constraints only. Many CSPs are not binary, which

means the maximal variable number of constraints is more than two. Many CSP algorithms

are usually designed for solving binary combinatorial problems. However, most real-world

CSPs are not binary. Some research has shown that a CSP involving non-binary constraints

can be converted into an equivalent binary CSP [2]. The general transformation technique

is a dual encoding [2]. The basic idea is to swap variables and constraints. First, a n-ary

constraint ci is converted to a dual variable v„ with the domain consisting of compatible

tuples. The domain is a finite set of the possible combinations that satisfy ci. Then, for each

pair of constraints ci and c3 sharing some variables, there is a binary constraint between v„

and vc, restricting the dual variables to tuples in which the original shared variables take

the same value. If the dual variables v„ and ye., share a variable x, We use rki to represent

this binary constraint, where k is the x position of v, tuples and 1 is the x position of vc, tuples.

Example 2.2. We transform the example in Figure 2.1 to a binary CSP with the dual

encoding technique. The result is shown below.

Variables: vet , vc3, ve4

Domain of v,: (0,0,1), (0,1,0), (1,0,0)

Domain of v„: (0,0,1), (1,0,0), (1,1,1)

Domain of v„: (0,1,0), (1,0,0), (1,1,0), (1,1,1)

7


Constraints: C\\ xi-\-x2+x§ = 1, C2: X1-X3+X4 = 1, C3: x^+x^-xq > 0, C4:

x 2+ x5-x6 = 0

C4

Variables: x1,.x6 Domain: {0,1}Constraints:

C1: x1+x2+x6=1 C2: x1-x3+x4=1 C3: x4+x5-x6>0 C4: x2+x5-x6«0

Figure 2.1: A CSP example

A binary CSP has unary and binary constraints only. Many CSPs are not binary, which

means the maximal variable number of constraints is more than two. Many CSP algorithms

are usually designed for solving binary combinatorial problems. However, most real-world

CSPs are not binary. Some research has shown that a CSP involving non-binary constraints

can be converted into an equivalent binary CSP [2]. The general transformation technique

is a dual encoding [2], The basic idea is to swap variables and constraints. First, a n-ary

constraint ct is converted to a dual variable vCi with the domain consisting of compatible

tuples. The domain is a finite set of the possible combinations that satisfy ct. Then, for each

pair of constraints c* and Cj sharing some variables, there is a binary constraint between vc%

and vCj restricting the dual variables to tuples in which the original shared variables take

the same value. If the dual variables vCi and vCj share a variable x, We use r^t to represent

this binary constraint, where k is the x position of vc tuples and I is the x position of vc> tuples.

E xam ple 2.2. We transform the example in Figure 2.1 to a binary CSP with the dual

encoding technique. The result is shown below.

Variables: vCl, vC2, vC3, vCA

Domain of vCl: (0,0,1), (0,1,0), (1,0,0)

Domain of vC2: (0,0,1), (1,0,0), (1,1,1)

Domain of vC3: (0,1,0), (1,0,0), (1,1,0), (1,1,1)

7

C1

x5x2 x4 x6

C3C2


Domain of v„: (0,0,0), (0,1,1), (1,0,1)

Constraints: NCI: r11 in v„ and vQ , NC2: r33 in v„, v„, NC3: r21 in v„ , v„,

NC4: r33 in v„, v„, NC5: r31 in v„, v„ r22 in v„, v„, NC7: r33 in v„, v„

NC3

NC1

Vc2 NC5

Vcs

NC7

VV4

Figure 2.2: Dual encoding

The following briefly describes two groups of algorithms for solving CSP.

• Searching algorithm can be divided into two primary methods as follows.

1. Systematic search algorithm [38, 4, 28] explores the whole assignment space sys-

tematically. With this algorithm, a complete solution is guaranteed, if it exists. However,

the algorithm is inefficient especially with the variable or constraint increasing, such as with

the depth-first search algorithm in Figure 2.3. This algorithm always expands one of the

nodes at the deepest level of the tree by a special rule. Each node is an assignment. Only

when the search hits a dead end (a node is not goal and it could not be expanded) does the

search go back and expand the nodes at shallower level. The complexity of this algorithm is

0 (max ( I Di In ), where n is the number of variables.

2. Local search algorithm [38, 4, 29] extends a partial consistent assignment to a full one,

satisfying all the constraints. CSPs are known to be NP-hard in general [29]. Many efficient

CSP algorithms such as local search algorithms, have been developed to quickly solve com-

plex CSPs that have a large number of variables and domains [38]. Generally, the first partial

assignment of local search algorithms is obtained randomly. With a local search algorithm, a

complete solution is not guaranteed. However, it can quickly find a best solution that satis-

fies most of constraints. The min-conflicts-random-walk algorithm, an example algorithm, is

8


Domain of vC4: (0,0,0), (0,1,1), (1,0,1)

Constraints: NC\: ru in vCl and vC2, NC2'- r33 in vci, vC3, N C 3: r21 in vCl, vC4,

NC4: r33 in vCl, vC4, NC5: r31 in vC2, vC3 NC6: r22 in vC3, vC4, NC7: r 33 in vC3, vC4

Vc»Vci

NC4

NC6NCI NC7NC2

NCSV «

Figure 2.2: Dual encoding

The following briefly describes two groups of algorithms for solving CSP.

• Search ing a lg o rith m can be divided into two primary methods as follows.

1. S ystem atic search a lg o rith m [38, 4, 28] explores the whole assignment space sys

tematically. W ith this algorithm, a complete solution is guaranteed, if it exists. However,

the algorithm is inefficient especially with the variable or constraint increasing, such as with

the depth-first search algorithm in Figure 2.3. This algorithm always expands one of the

nodes at the deepest level of the tree by a special rule. Each node is an assignment. Only

when the search hits a dead end (a node is not goal and it could not be expanded) does the

search go back and expand the nodes at shallower level. The complexity of this algorithm is

0(max(\Di\n), where n is the number of variables.

2. Local search a lg o rith m [38, 4, 29] extends a partial consistent assignment to a full one,

satisfying all the constraints. CSPs are known to be NP-hard in general [29]. Many efficient

CSP algorithms such as local search algorithms, have been developed to quickly solve com

plex CSPs tha t have a large number of variables and domains [38]. Generally, the first partial

assignment of local search algorithms is obtained randomly. With a local search algorithm, a

complete solution is not guaranteed. However, it can quickly find a best solution tha t satis

fies most of constraints. The min-conflicts-random-walk algorithm, an example algorithm, is

8


Figure 2.3: Depth-first algorithm

shown in Table 2.1. An initial configuration is generated randomly. The algorithm randomly

chooses a conflicting variable that is involved in any unsatisfied constraint with probability

p. If p is in the special range, the algorithm picks a value that minimizes the number of

violated constraints. Otherwise, the algorithm picks a value randomly.

Table 2.1: Min-conflicts-random-walk algorithm

procedure min-conflict-random-walk(Max_Moves,p)

s <- random valuation of variables;

nb_moves <- 0; while eval(s) > 0 and nb_moves < Max_Moves do

if probability p verified then choose randomly a variable V in conflict; choose randomly a value v' for V;

else choose randomly a variable V in conflict;

choose a value v' that minimizes the number of conflicts for V;

endif

if v' <> current value of V then

assign v' to V; nb_moves <- nb_moves+1;

endif endwhile return s

end

• Consistency algorithm is invoked before searching algorithms for reduction of incon-

sistent values from the domains of variables [28, 29, 4, 38]. They are represented using the

9


Figure 2.3: Depth-first algorithm

shown in Table 2.1. An initial configuration is generated randomly. The algorithm randomly

chooses a conflicting variable that is involved in any unsatisfied constraint with probability

p. If p is in the special range, the algorithm picks a value that minimizes the number of

violated constraints. Otherwise, the algorithm picks a value randomly.

___________________ Table 2.1: Min-conflicts-random-walk algorithm___________________

procedure min-conflict-random-walk(Max_Moves,p) s <- random valuation of variables; nb_moves <- 0;w hile ev a l(s ) > 0 and nb_moves < Max_Moves do

i f p rob ab ility p v e r if ie d thenchoose randomly a variable V in c o n flic t;choose randomly a value v ’ for V;

e lsechoose randomly a variable V in c o n flic t;choose a value v ’ that minimizes the number

of c o n f lic ts for V;endifi f v' <> current value of V then

assign v ’ to V; nb_moves <- nb_moves+l;

endif endwhile return s

end

• C onsistency a lg o rith m is invoked before searching algorithms for reduction of incon

sistent values from the domains of variables [28, 29, 4, 38]. They are represented using the

9


notion of k-consistency. This kind of algorithm is used to reduce searching space.

Choosing the type of searching algorithm is based on the user's requirements. If a com-

plete solution is the most important to users, a systematic search algorithm is a good choice.

But if time is the most important factor to users, a local search algorithm is the best selection.

2.2 Introduction to temporal CSPs

Relation Symbol Inverse Meaning

X precedes Y P P- X Y

X equals Y E E X

Y

X meets Y M M- X Y

X overlaps Y 0 0- X Y

X during Y D D- X y

X starts Y S S- X y

X finishes Y F F- Y x

Figure 2.4: Allen logic relations

SOPO structure: [begintime, endtime, Duration, step]

Begintime

1 1 1 1

Endtime

1 1 1 1 1

Duration Step

lime line I I

Figure 2.5: Structure of SOPO

A TCSP is a special case of a binary CSP for which domains are infinite (time) and

constraints are allowed temporal relations [32, 33, 16]. In a TCSP, variables, called events,

represent temporal events, which are defined on domains of time space. Constraints are

disjunctions of Allen primitives [1]. As shown in Figure 2.4, there are thirteen logic Allen

relations. Domains are continuous time space. The domain of an event can be represented

by a finite set of intervals with constant duration. The Set of Possible Occurrences (SOPO)

10


notion of k-consistency. This kind of algorithm is used to reduce searching space.

Choosing the type of searching algorithm is based on the user’s requirements. If a com

plete solution is the most important to users, a systematic search algorithm is a good choice.

But if time is the most important factor to users, a local search algorithm is the best selection.

2.2 Introduction to temporal CSPs

Relation Symbol Inverse Meaning

X precedes Y P P-X Y

X equals Y E EXY

X meets Y M M- X v

X overlaps Y O o- X Y

X during Y D D- X Y

X starts Y S S- X Y

X finishes Y F F- Y X

Figure 2.4: Allen logic relations

SOPO structure: [begintime, endtime, Duration, step ]

Begintime Endtlme --------------------------------- Tim* line

h h H - f i 1 i | i Ir-frfr! i 1 1 i i •

4 S(ep

Figure 2.5: Structure of SOPO

A TCSP is a special case of a binary CSP for which domains are infinite (time) and

constraints are allowed temporal relations [32, 33, 16]. In a TCSP, variables, called events,

represent temporal events, which are defined on domains of time space. Constraints are

disjunctions of Allen primitives [1]. As shown in Figure 2.4, there are thirteen logic Allen

relations. Domains are continuous time space. The domain of an event can be represented

by a finite set of intervals with constant duration. The Set of Possible Occurrences (SOPO)

10


[32] is used to represent event domains that events can take. As shown in Figure 2.5, a SOPO

is represented by the four keywords [begintime, endtime, duration, step] where begintime and

endtime are, respectively, the start time and end time of events, duration is how long events

last (sometimes we call duration is interval), and step is the distance between two neighbor

intervals within the SOPO. An example of SOPO is shown below.

Example 2.3. Here, we represent a simple scheduling problem: "John is going to in-

terview Mike for ten minutes today. He has time from 3:00 to 3:30 this afternoon." So, we

can express the domain of the event John meeting Mike with SOPO structure. We assume

the step is five minutes. The domain is: [3:00, 3:30, 10, 5]. The values of the domain are

[3:00,3:10], [3:05, 3:15], [3:10, 3:20], [3:15, 3:25] and [3:20,3:30].

Example 2.4. We assume two events and present their relation here. The two events

are:v=[5:10, 6:00] and v'=[5:11, 6:30]. The begin time of v is earlier than the end of v',

the end time of v is later than the begin time of v', and the end time of v is earlier than the

end time of v'. So, the relation is v overlaps v'. We use logic Allen relations v 0 v' or v' 0 -

v to express this relation where 0 - is the reserve of 0 .

2.3 Introduction to distributed (temporal) CSPs

With the increasing of variables (events) and constraints, CSPs/TCSPs become more

complex. Users are confused with their OCL descriptions when they review them. For

example, if a CSP has 1000 constraints, the constraint graph is very big and complex. After

users describe or read 100 constraints, they are tired and cannot make any sense of the

problems. So, distributed CSP/TCSP is developed to solve these complex problems with

agent techniques. Users will easily understand and solve their CSPs/TCSPs.

A distributed CSP/TCSP is one in which variables and constraints are distributed among

multiple automated agents [44]. Each agent has some variables (events) and assigns a value

to variables (events) that satisfies inter-agent constraints. The assignment can be viewed as

achieving coherence or consistency among agents [9].

11


[32] is used to represent event domains tha t events can take. As shown in Figure 2.5, a SOPO

is represented by the four keywords [begintime, endtime, duration, step] where begintime and

endtime are, respectively, the start time and end time of events, duration is how long events

last (sometimes we call duration is interval), and step is the distance between two neighbor

intervals within the SOPO. An example of SOPO is shown below.

E xam ple 2.3. Here, we represent a simple scheduling problem: “John is going to in

terview Mike for ten minutes today. He has time from 3:00 to 3:30 this afternoon.” So, we

can express the domain of the event John meeting Mike with SOPO structure. We assume

the step is five minutes. The domain is: [3:00, 3:30, 10, 5], The values of the domain are

[3:00,3:10], [3:05, 3:15], [3:10, 3:20], [3:15, 3:25] and [3:20,3:30].

E xam ple 2.4. We assume two events and present their relation here. The two events

are:v—[5:10, 6:00] and v ’=[5:ll, 6:30]. The begin time of v is earlier than the end of v ’,

the end time of v is later than the begin time of v ’, and the end time of v is earlier than the

end time of v ’. So, the relation is v overlaps v ’. We use logic Allen relations v O v ’ or v ’ 0~

v to express this relation where 0 ~ is the reserve of O .

2.3 Introduction to distributed (temporal) CSPs

With the increasing of variables (events) and constraints, CSPs/TCSPs become more

complex. Users are confused with their OCL descriptions when they review them. For

example, if a CSP has 1000 constraints, the constraint graph is very big and complex. After

users describe or read 100 constraints, they are tired and cannot make any sense of the

problems. So, distributed CSP/TCSP is developed to solve these complex problems with

agent techniques. Users will easily understand and solve their CSPs/TCSPs.

A distributed CSP/TCSP is one in which variables and constraints are distributed among

multiple automated agents [44]. Each agent has some variables (events) and assigns a value

to variables (events) that satisfies inter-agent constraints. The assignment can be viewed as

achieving coherence or consistency among agents [9].

11


Within the agents of a distributed CSP/TCSP, we assume the following communication

model [43].

• An agent communicates by sending messages with other agents whose addresses are

known by it.

• The delay in delivering a message is finite in a random time.

• For the transmission between any pair of agents, messages are received in the order in

which they were sent.

We use a multi-agent truth maintenance system [24] to map any CSP/TCSP into dis-

tributed CSP/TCSP. In this system, there exist multiple agents, each of which has its own

truth maintenance system, such as in Figure 2.6. Each agent has some uncertain variables

(events) and each agent shares some variables (events) with other agents. Each agent must

consistently determine the label of these uncertain variables (events) according to the con-

straints among variables. Also, a shared variable (event) must have the same label. In this

thesis, the relations between agents are called "actions".

Figure 2.6: Multi-agent truth maintenance system

Although algorithms for solving distributed CSPs/TCSPs look similar to parallel/distributed

processing methods, the research motivations are fundamentally different [44]. The primary

goal in parallel/distributed processing is efficiency, but the main research issue in distributed

CSP/TCSP is an approach that solves a problem [44].

Example 2.5. We present here a simple scheduling problem: "John is going to inter-

view Mike for ten minutes today. He has time from 3:00 to 3:30 in this afternoon. Mike is

12


Within the agents of a distributed CSP/TCSP, we assume the following communication

model [43].

• An agent communicates by sending messages with other agents whose addresses are

known by it.

• The delay in delivering a message is finite in a random time.

• For the transmission between any pair of agents, messages are received in the order in

which they were sent.

We use a multi-agent tru th maintenance system [24] to map any CSP/TCSP into dis

tributed CSP/TCSP. In this system, there exist multiple agents, each of which has its own

tru th maintenance system, such as in Figure 2.6. Each agent has some uncertain variables

(events) and each agent shares some variables (events) with other agents. Each agent must

consistently determine the label of these uncertain variables (events) according to the con

straints among variables. Also, a shared variable (event) must have the same label. In this

thesis, the relations between agents are called “actions” .

Agent 1

Figure 2.6: Multi-agent tru th maintenance system

Although algorithms for solving distributed CSPs/TCSPs look similar to parallel/distributed

processing methods, the research motivations are fundamentally different [44]. The primary

goal in parallel/distributed processing is efficiency, but the main research issue in distributed

CSP/TCSP is an approach that solves a problem [44].

E xam ple 2.5. We present here a simple scheduling problem: “John is going to inter

view Mike for ten minutes today. He has time from 3:00 to 3:30 in this afternoon. Mike is

12


free from 2:00 to 3:15 in this afternoon."

If we use distributed TCSP techniques to solving this problem, John is an agent and

Mike is the other agent. The domain of agent John is: [3:00, 3:30, 10, 5]. The domain of

agent Mike is: [2:00, 3:15, 10, 5]. The shared events is "the interview." First, agent John

obtains an event value, and then sent this value to agent Mike and ask whether this value

is available. Agent John waits for the response from agent Mike. If the value is accepted

by agent Mike, he will send an "ok" message to agent John. Then, we obtain a solution.

However, if the value is not accepted by agent Mike, he will send a "no good" message to

agent John. Agent John will try other values and communicate with agent Mike until the

value satisfies both agents.

2.4 Constraint programming

We focus here on solving real-world CSP/TCSP applications. Constraint programming

(CP) represents one of the closest approaches to solving this kind of application [3]. We

briefly review some techniques of CP and discuss two ways to implement satisfaction and

optimization problems with constraint programming languages. We also introduce some

constraint class libraries and show the experiential comparison.

Constraint programming. With the increasing of intelligent software requirements, CP

[4] has attracted high attention from many areas because of its potential for solving hard

real-life problems such as intelligent games, market forecast, data mining, and so on.

CP is different from functional programming. CP [4] is a framework for solving constraint

satisfaction and optimization problems. The basic idea is to model a problem as a finite set

of variables with finite domains and a finite set of constraints restricting the possible com-

binations of the variables values. The goal is to obtain a set of values for the variables to

satisfy all the constraints. Users do not need to describe how to solve the problems. The

constraint programming languages have provide different solvers based on different search

algorithms. So, CP is the study of computational systems that are based on constraints [3].

13


free from 2:00 to 3:15 in this afternoon.”

If we use distributed TCSP techniques to solving this problem, John is an agent and

Mike is the other agent. The domain of agent John is: [3:00, 3:30, 10, 5]. The domain of

agent Mike is: [2:00, 3:15, 10, 5]. The shared events is “the interview.” First, agent John

obtains an event value, and then sent this value to agent Mike and ask whether this value

is available. Agent John waits for the response from agent Mike. If the value is accepted

by agent Mike, he will send an “ok” message to agent John. Then, we obtain a solution.

However, if the value is not accepted by agent Mike, he will send a “no good” message to

agent John. Agent John will try other values and communicate with agent Mike until the

value satisfies both agents.

2.4 Constraint programming

We focus here on solving real-world CSP/TCSP applications. Constraint programming

(CP) represents one of the closest approaches to solving this kind of application [3]. We

briefly review some techniques of CP and discuss two ways to implement satisfaction and

optimization problems with constraint programming languages. We also introduce some

constraint class libraries and show the experiential comparison.

C o n s tra in t p rog ram m ing . W ith the increasing of intelligent software requirements, CP

[4] has attracted high attention from many areas because of its potential for solving hard

real-life problems such as intelligent games, market forecast, data mining, and so on.

CP is different from functional programming. CP [4] is a framework for solving constraint

satisfaction and optimization problems. The basic idea is to model a problem as a finite set

of variables with finite domains and a finite set of constraints restricting the possible com

binations of the variables values. The goal is to obtain a set of values for the variables to

satisfy all the constraints. Users do not need to describe how to solve the problems. The

constraint programming languages have provide different solvers based on different search

algorithms. So, CP is the study of computational systems that are based on constraints [3].

13


X1 [1,2,3,4,5]

X1> X2

X2 [1,2,3,4,5] X3 [1,2,3,4,5]

Figure 2.7: CSP represented by graphic

Constraint programming languages. There are two basic ways to present constraints

with programming languages. One is using functional and logic languages such a Prolog

that already provide logical variables and implicit searches to describe relations of variables

and logical inference. The run time system searches through the database of facts and rules

to determine the answer. The alternative way is providing a class library (shown in Figure

2.8) that extends the language semantics by adding high-level object properties to the basic

programming language such as ILOG C++ version [37], Java Cream [14], and Choco [12].

Programming Host Language

Constraint Network

Solutions

Constraint Class Library Solver

Figure 2.8: Extending language semantics by class library

Whatever we choose to solve satisfaction and optimization problems with CP, there are

some essential functions that must be provided by the programming languages:

• Variables, domains, and constraints must be expressed by the language.

• The language must provide an interface to the solver, allowing the constraint network

to be passed to it.

• A solver, which solves combinatorial problems and gives an answer (showing the solu-

tions or no solutions), must be provided.

14


Figure 2.7: CSP represented by graphic

C o n s tra in t p ro g ram m in g languages. There are two basic ways to present constraints

with programming languages. One is using functional and logic languages such a Prolog

tha t already provide logical variables and implicit searches to describe relations of variables

and logical inference. The run time system searches through the database of facts and rules

to determine the answer. The alternative way is providing a class library (shown in Figure

2.8) that extends the language semantics by adding high-level object properties to the basic

programming language such as ILOG C + + version [37], Java Cream [14], and Choco [12],

C onstrain tNetwork

Solutions

Constraint Class Library Solver

Program m ing Host Language

Figure 2.8: Extending language semantics by class library

Whatever we choose to solve satisfaction and optimization problems with CP, there are

some essential functions tha t must be provided by the programming languages:

• Variables, domains, and constraints must be expressed by the language.

• The language must provide an interface to the solver, allowing the constraint network

to be passed to it.

• A solver, which solves combinatorial problems and gives an answer (showing the solu

tions or no solutions), must be provided.

14


If we just do a satisfaction and optimization problem application, the first one is a good

choice, but in this thesis, we focus on real life applications. Satisfaction and optimization

problems are just a part of the applications. Most developers use object oriented-object pro-

gramming languages to design and develop their whole applications. Many constraint class

libraries are open source and designed with C++ or Java languages. Thus, the constraint

class library is a good choice.

Comparison. Java Cream and Choco are mainly used as constraint class libraries. They

are written in Java. Java Cream was mainly developed by Naoyuki Tamura from Kobe

University in Japan. The key feature of Java Cream is that it provides various optimization

algorithms, such as Hill Climbing and Taboo Search. The latest version of Java Cream, 2.0,

was released on Jan 6, 2005.

Choco was developed by Francois Laburthe and Narendra Jussien. The latest version,

1.1.0.3, was released on May 23, 2006. Choco has many documents including an user guide,

API specifications, examples, and tutorials. The key feature of Choco is that it is based on

backtrackable structure search strategy. Both are open source, so users can download source

codes and extend the class library with their required algorithms.

Currently, neither library provides temporal CSP algorithms. We use Choco in this thesis

because it has two developers and timely upgrades. We can easily study and use it because

it has integrative documents.

2.5 Conclusion

We have described constraint-satisfaction and optimization problems. We have intro-

duced the ways of solving constraint-satisfaction and optimization problems with constraint

programming languages and compared some constraint class libraries. However, in a com-

plex and large project, the description of combinatorial problems directly with a constraint

class library is still difficult. In the following chapter, we introduce the modeling language

UML and agent UML, as well as a constraint description language, OCL. With these lan-

guages, any problem can be modeled with object-oriented and agent-oriented frameworks,

15


If we just do a satisfaction and optimization problem application, the first one is a good

choice, but in this thesis, we focus on real life applications. Satisfaction and optimization

problems are just a part of the applications. Most developers use object oriented-object pro

gramming languages to design and develop their whole applications. Many constraint class

libraries are open source and designed with C + + or Java languages. Thus, the constraint

class library is a good choice.

C om parison . Java Cream and Choco are mainly used as constraint class libraries. They

are written in Java. Java Cream was mainly developed by Naoyuki Tamura from Kobe

University in Japan. The key feature of Java Cream is tha t it provides various optimization

algorithms, such as Hill Climbing and Taboo Search. The latest version of Java Cream, 2.0,

was released on Jan 6, 2005.

Choco was developed by Francois Laburthe and Narendra Jussien. The latest version,

1.1.0.3, was released on May 23, 2006. Choco has many documents including an user guide,

API specifications, examples, and tutorials. The key feature of Choco is tha t it is based on

backtrackable structure search strategy. Both are open source, so users can download source

codes and extend the class library with their required algorithms.

Currently, neither library provides temporal CSP algorithms. We use Choco in this thesis

because it has two developers and timely upgrades. We can easily study and use it because

it has integrative documents.

2.5 Conclusion

We have described constraint-satisfaction and optimization problems. We have intro

duced the ways of solving constraint-satisfaction and optimization problems with constraint

programming languages and compared some constraint class libraries. However, in a com

plex and large project, the description of combinatorial problems directly with a constraint

class library is still difficult. In the following chapter, we introduce the modeling language

UML and agent UML, as well as a constraint description language, OCL. W ith these lan

guages, any problem can be modeled with object-oriented and agent-oriented frameworks,

15


which help users design and develop complex applications.

16


which help users design and develop complex applications.

16


3. AGENT AND OBJECT-ORIENTED

SPECIFICATIONS Object-oriented [34, 10] and agent-oriented [7] specifications are two important tech-

niques that analyze, design, and build complex software systems. UML (Unified Modeling

Language) [19] is a famous specification language used to describe object-oriented models.

Furthermore, agent-UML, an extension of UML, is used to describe agent-oriented models

[6]. In this chapter, these specification languages are introduced along with their definitions

and syntaxes. Moreover, OCL (Object Constraint Language) is also introduced to describe

complex constraints of classes and agents.

3.1 Introduction to UML

UML is a modeling language which uses (mainly graphical) notations to express designs

[19, 25, 21]. In the following, class diagrams and object diagrams are described.

Class diagram describes types (classes) of objects in a system with static relationships

existing among them. It also shows attributes and operations of classes. We show

three principal kinds of relationships as follows.

• Dependency means that the class at the source end of the relationship has some

sort of dependency on the class at the target (arrowhead) end of the relationship.

Given a dependency between two classes, one class depends on another but the

other class has no knowledge of the one. For example, Figure 3.1 indicates that

class A depends on class B in some way, but that class A does not contain an

instance of class B as part of its own state.

A

Figure 3.1: Dependency relationship of UML

17


3. AGENT AND OBJECT-ORIENTED

SPECIFICATIONSObject-oriented [34, 10] and agent-oriented [7] specifications are two important tech

niques tha t analyze, design, and build complex software systems. UML (Unified Modeling

Language) [19] is a famous specification language used to describe object-oriented models.

Furthermore, agent-UML, an extension of UML, is used to describe agent-oriented models

[6]. In this chapter, these specification languages are introduced along with their definitions

and syntaxes. Moreover, OCL (Object Constraint Language) is also introduced to describe

complex constraints of classes and agents.

3.1 Introduction to UML

UML is a modeling language which uses (mainly graphical) notations to express designs

[19, 25, 21]. In the following, class diagrams and object diagrams are described.

C lass d iag ram describes types (classes) of objects in a system with static relationships

existing among them. It also shows attributes and operations of classes. We show

three principal kinds of relationships as follows.

• Dependency means tha t the class at the source end of the relationship has some

sort of dependency on the class at the target (arrowhead) end of the relationship.

Given a dependency between two classes, one class depends on another but the

other class has no knowledge of the one. For example, Figure 3.1 indicates that

class A depends on class B in some way, but tha t class A does not contain an

instance of class B as part of its own state.

A B

.................

Figure 3.1: Dependency relationship of UML

17


• Generalization represents the inheritance concept in object-oriented techniques.

Within a specification model, generalization means that the interface of the sub-

type must include all elements from the interface of the supertype. The subtype's

interface is said to conform to the super-type's interface. For example, Figure 3.2

shows that class A2 inherits from class B2 because A2 is a specialization of B2.

A2 B2

Figure 3.2: Generalization relationship of UML

• Association is composed of two parts: an association object, and a collection

of association end objects. The association end is commonly termed as a role.

Roles are used to contain the attributes of the association's connection to the

associated classifiers. Association defines dependency, but this is a much stronger

dependency than that described above with the plain dependency relationship.

The arrowhead means that there is a one-way relationship. In Figure 3.3, class

Al is associated with class Bl. In other words, class Al uses and contains one

instance of class Bl, but B1 does not know about or contain any instances of class

Al.

Al BI

Figure 3.3: Association relationship of UML

Object diagram is a snapshot of the objects in a system at a point in time. Since it shows

instances rather than classes, an object diagram is often called an instance diagram.

For instance, This is very useful when the possible connections between objects are

complicated.

18


• Generalization represents the inheritance concept in object-oriented techniques.

W ithin a specification model, generalization means that the interface of the sub-

type must include all elements from the interface of the supertype. The subtype’s

interface is said to conform to the super-type’s interface. For example, Figure 3.2

shows tha t class A2 inherits from class B2 because A2 is a specialization of B2.

A2 1 B2

1---------------------^

Figure 3.2: Generalization relationship of UML

• Association is composed of two parts: an association object, and a collection

of association end objects. The association end is commonly termed as a role.

Roles are used to contain the attributes of the association’s connection to the

associated classifiers. Association defines dependency, but this is a much stronger

dependency than that described above with the plain dependency relationship.

The arrowhead means that there is a one-way relationship. In Figure 3.3, class

A1 is associated with class B l. In other words, class A l uses and contains one

instance of class B l, but B l does not know about or contain any instances of class

A l.

A1 B1

-----------------------^

Figure 3.3: Association relationship of UML

O b jec t d iag ram is a snapshot of the objects in a system at a point in time. Since it shows

instances rather than classes, an object diagram is often called an instance diagram.

For instance, This is very useful when the possible connections between objects are

complicated.

18


C-

S

Met

5 )

has

r--outat.zNAmr tiNuIu

-uccoulmui4sumlor Smog -cred,t1 0411 Double

Iteitittd0 4billFothitulth()

PerionalC..mri

Kr

Figure 3.4: Class diagram

Taylor. Par

address "1234 Toronto Street" name m -Taylor cnidi1Card "1234567890"

PA14+ Ice S

isClosad dmelteeisted.X4mamt6 number 2

-ir,prapubl fat!

daiRc4;t,..ed DAJe -,tPrapcd Boolean -n Wllbel . lincitur -prtaa Money -tat-1watt , Boolaun

+ealeulemIStrar) Money

orders' 1 J

p 24.95$ isC1osed tom cloueftecived.20/1m1006 number - I isPrepuirl Mid

Figure 3.5: Object diagram

Example 3.1. Figure 3.4 is a class diagram expressing this problem: "For a beer shop,

beers and pizzas are sold. There are two kinds of customers for the shop. One is a personal

customer. The other is a corporate customer. Any customer can have n orders." So, we

present four classes in this diagram. Class PersonalCustomer and class CorporateCustomer

herniate from class Customer. Class Order is an association end object of the class Customer.

Figure 3.5 is an object diagram generated by the example: "Taylor is a personal customer.

He ordered one pizza and one beer."

19


Monty )

►cdculawlVictO: Monty

arJ S.Mf.pSiring

Figure 3.4: Class diagram

Beer Order

Figure 3.5: Object diagram

E xam ple 3.1. Figure 3.4 is a class diagram expressing this problem: “For a beer shop,

beers and pizzas are sold. There are two kinds of customers for the shop. One is a personal

customer. The other is a corporate customer. Any customer can have n orders.” So, we

present four classes in this diagram. Class PersonalCustomer and class CorporateCustomer

herniate from class Customer. Class Order is an association end object of the class Customer.

Figure 3.5 is an object diagram generated by the example: “Taylor is a personal customer.

He ordered one pizza and one beer.”

19


3.2 Introduction to OCL

OCL is a subset of UML, mainly used for specifying constraints that can not be expressed

by diagrammatic notations [18]. As an expression language, OCL is not tied to specific plat-

forms or programming languages. It provides a textual description of constraint expressions

on attributes, methods, and classes. An OCL constraint is a set of rules that governs an

object [41]. Its evaluation always delivers a value. It does not change anything in the system

model [39].

The context of constraints is attributes, methods, classes, or other objects that are be-

ing constrained. These constraints may be noted within the UML notations or documented

separately [41, 40, 18]. Constraints provide additional information not provided by stan-

dard UML notations. This additional detail helps formalizing system requirements. In user

requirements, these constraints could be written in natural language. However, natural lan-

guage is an informal language that varies between modelers [17]. It is prone to ambiguity and

misinterpretation. OCL provides a textual description of constraints on attributes, methods,

and classes. Obviously, as a formal language for constraint notation, OCL reduces ambiguity

and increases precision of system descriptions [41, 13]. Now we will introduce OCL used in

this thesis.

1. OCL comments. These are written following two successive dashes.

-- comments

2. OCL keywords. Keywords in OCL are reserved words. The list of keywords is: self,

context, if, then, else, endif, inv, post, pre, let, in, and, or. Keyword "self" is used to

refer to the "context" instance. For instance, as a normal rule, an order's price must

be more than 0. So, we describe the rule as follows.

context Order inv:

self.price > 0

3. Basic values and types. OCL is a typed language, meaning that part of OCL

includes value types. Various operations can be performed on each value type as part

20


3.2 Introduction to OCL

OCL is a subset of UML, mainly used for specifying constraints tha t can not be expressed

by diagrammatic notations [18]. As an expression language, OCL is not tied to specific plat

forms or programming languages. It provides a textual description of constraint expressions

on attributes, methods, and classes. An OCL constraint is a set of rules that governs an

object [41]. Its evaluation always delivers a value. It does not change anything in the system

model [39].

The context of constraints is attributes, methods, classes, or other objects tha t are be

ing constrained. These constraints may be noted within the UML notations or documented

separately [41, 40, 18]. Constraints provide additional information not provided by stan

dard UML notations. This additional detail helps formalizing system requirements. In user

requirements, these constraints could be written in natural language. However, natural lan

guage is an informal language that varies between modelers [17]. It is prone to ambiguity and

misinterpretation. OCL provides a textual description of constraints on attributes, methods,

and classes. Obviously, as a formal language for constraint notation, OCL reduces ambiguity

and increases precision of system descriptions [41, 13]. Now we will introduce OCL used in

this thesis.

1. O CL com m ents. These are written following two successive dashes.

— comments

2. O CL keyw ords. Keywords in OCL are reserved words. The list of keywords is: self,

context, if, then, else, endif, inv, post, pre, let, in, and, or. Keyword “self” is used to

refer to the “co n tex t” instance. For instance, as a normal rule, an order’s price must

be more than 0. So, we describe the rule as follows.

context Order inv:

self.price > 0

3. B asic values an d types. OCL is a typed language, meaning that part of OCL

includes value types. Various operations can be performed on each value type as part

20


of evaluating an OCL expression. The basic predefined types and operations are shown

in Table 3.1.

Type Values Operations Boolean true, false and, or, xor, not, implies, if-then-else Integer 1, -5,2, +, -, *, /, abs() Real 1.5, -3.14, +, -, *, /, floor() String 'This is a string' concat(), size(),substring()

Table 3.1: Basic type, values, and operations

4. Types of constraints. There are three types of constraint expressions in OCL.

• Invariant expressions. An invariant is a constraint that states a condition that

must always be met by all instances of the class, type, or interface. An invariant

is described using an expression that evaluates to "true" if the invariant is met.

Invariants must be true all the time. The syntax is as follows.

context (typename: )TypeName inv

constraints

For example, as a normal order, the number of goods must be more than 0. So

we use a invariant expression to describe it. context Order inv:

se/fnumber > 0

• Pre- and postcondition expressions. A precondition to an operation is a restric-

tion that must be true at the moment that the operation is going to be executed.

A postcondition to an operation is a restriction that must be true at the moment

that the operation has just ended its execution. Below is the syntax.

context Typename::operationName(paraml:Typel,): ReturnType

pre (prename): paraml

post (postname): result=

The reserved word result denotes the result of the operation

For instance, if a cashier want to calculate a order's price, the order must be not

closed and the result must be more than 0. The constraint expressions in OCL is

21


of evaluating an OCL expression. The basic predefined types and operations are shown

in Table 3.1.

T y p e V alues O p era tio n sBoolean true, false and, or, xor, not, implies, if-then-elseInteger 1, -5,2, + , -, *, / , abs()Real 1.5, -3.14, + , -, *, / , floor()String ‘This is a string’ concatQ, size(),substring()

Table 3.1: Basic type, values, and operations

4. T ypes o f co n stra in ts . There are three types of constraint expressions in OCL.

• In v a rian t expressions. An invariant is a constraint that states a condition that

must always be met by all instances of the class, type, or interface. An invariant

is described using an expression tha t evaluates to “true” if the invariant is met.

Invariants must be true all the time. The syntax is as follows.

context (typename: )TypeName inv

constraints____________________________________

For example, as a normal order, the number of goods must be more than 0. So

we use a invariant expression to describe it. context Order inv:

self.number > 0

• P re - an d p o s tco n d itio n expressions. A precondition to an operation is a restric

tion tha t must be true at the moment that the operation is going to be executed.

A postcondition to an operation is a restriction that must be true at the moment

that the operation has just ended its execution. Below is the syntax.

context Typename::operationName(paraml:Typel,): ReturnType

pre (prename): paraml

post (postname): result=

The reserved word result denotes the result of the operation

For instance, if a cashier want to calculate a order’s price, the order must be not

closed and the result must be more than 0. The constraint expressions in OCL is

21


as follows.

context Order::calcuatePrice() : Money

pre: self isClosed = false

post: result > 0

5. Objects and properties. A property is one of attributes or association end objects.

The value of a property on an object that is defined in a class diagram is specified in

an OCL expression by a dot `.' followed by the name of the property.

6. Association end object and navigation. We navigate the association by using the

opposite association end objects: Object.associationEndName. The value of this ex-

pression is the set of objects on the other side of the associationEndName association.

If the multiplicity of the association-end has a maximum of one ("0..1", "1"), then the

value of this expression is an object. By default, navigation will result in a Set. A

property of the set is accessed by using an arrow `— >' followed by the name of the

property. For instance, according to the shop's rules, a personal customer could not

have more than thirty orders. The first order's price must be more than ten dollars.

So, we can describe the rules as follows:

context PersonalCustomer inv:

self.orders— >size() < 30

- orders[1] means the first order

se/f. orders [1] .price > 10

- we also can describe the first order's price must be

- more than 10 dollars like this:

context Order inv:

if (id == 1) then

se/f price > 10

endif

22


as follows.

context Order::calcuatePrice() : Money

pre: se//.isClosed = false

post: result > 0

5. Objects and properties. A property is one of attributes or association end objects.

The value of a property on an object tha t is defined in a class diagram is specified in

an OCL expression by a dot V followed by the name of the property.

6 . Association end object and navigation. We navigate the association by using the

opposite association end objects: Object.associationEndName. The value of this ex

pression is the set of objects on the other side of the associationEndName association.

If the multiplicity of the association-end has a maximum of one ( “0..1” , “1”), then the

value of this expression is an object. By default, navigation will result in a Set. A

property of the set is accessed by using an arrow > ’ followed by the name of the

property. For instance, according to the shop’s rules, a personal customer could not

have more than thirty orders. The first order’s price must be more than ten dollars.

So, we can describe the rules as follows:

context PersonalCustomer inv:

self.orders— >size() < 30

- orders [1] means the first order

se//.orders[l] .price > 10

- we also can describe the first order’s price must be

- more than 10 dollars like this:

context Order inv:

if (id = = 1) then

6e//.price > 10

endif

22


3.3 Introduction to agent-UML

In recent years, agents have become a powerful technique that can be applied to the

software engineering field. However, the research on agent-oriented software engineering had

been widely out of touch with the world of industrial software development [7, 42]. Successful

industrial deployment of agent techniques requires techniques that reduce the risk inherent

in any new technique [11]. UML is a suitable language for knowledge modeling in agent

systems and provides details of the techniques and extensions employed [19, 6]. Agent-UML

(AUML) has been proposed as a tool for modeling agents, modeling agent behaviors, and

details of agent designs and modeling ontologies in specific domains [6, 5, 8].

A class in the sense of object-oriented programming is a blueprint for objects. So, an

agent class has to be a blueprint for agents. However, agents and objects are completely

different paradigms [5, 8]. Figure 3.6 shows what should be specified in an agent class.

agent-class-name/ role-riamel, role-name2,

state-description

actions

methods

capabilities,service description, supported protocols

communicative acts (sending and receiving of communicative acts, trigger the corresponding behavior of the agent)

Figure 3.6: Agent class diagram

• Agent Class Descriptions and Roles. Agents perform various roles. For instance,

a job agent can act as an employer and an employee. In AUML, the general form that

describes agent roles is as follows.

instance-1 instance-n/role-1 role-m : agent class

23


3.3 Introduction to agent-UML

In recent years, agents have become a powerful technique tha t can be applied to the

software engineering field. However, the research on agent-oriented software engineering had

been widely out of touch with the world of industrial software development [7, 42], Successful

industrial deployment of agent techniques requires techniques that reduce the risk inherent

in any new technique [11]. UML is a suitable language for knowledge modeling in agent

systems and provides details of the techniques and extensions employed [19, 6]. Agent-UML

(AUML) has been proposed as a tool for modeling agents, modeling agent behaviors, and

details of agent designs and modeling ontologies in specific domains [6, 5, 8].

A class in the sense of object-oriented programming is a blueprint for objects. So, an

agent class has to be a blueprint for agents. However, agents and objects are completely

different paradigms [5, 8]. Figure 3.6 shows what should be specified in an agent class.

agent-class-namef role-namet, role-name2,...

state-description

actions

methods

capabilitles.service description, supported protocols

communicative acts(sending end receiving of communicative acts, trigger the corresponding behavior of the agent}

Figure 3.6: Agent class diagram

• A gent C lass D escrip tions an d Roles. Agents perform various roles. For instance,

a job agent can act as an employer and an employee. In AUML, the general form that

describes agent roles is as follows.

instance-1 ... instance-n/role-1 ... role-m : agent class

23


Example 3.2. We assume there is an agent class "University." There are some agent roles

such as teaching centers, research institutes, and employers. "UofR" and "UofT" are the

instances of the agent class University. At the same time, they are also teaching centers,

research institutes, and employers. So, they can be described as follows.

UofR,UofT/teaching center, research institute, employer : University

• State Descriptions. These are similar to attribute description in class diagrams.

• Actions. There are two kinds of actions for an agent: one is triggered by the agent

itself; another is triggered by other agents. The semantics of an action are defined by

pre-conditions, post-conditions, effects, and invariants.

• Methods. These are the same with operation descriptions in UML.

• Capabilities, service description and supported protocols. These can be de-

fined either in an informal way or using class diagrams.

• Communicative acts. Two parts are included in this section. One is sending and

receiving communicative acts. The received or sent communicative acts have priority

(The top-priority communicative act is processed first). Another is matching commu-

nicative acts. A received communicative act must be matched against the incoming

communicative acts of an agent to trigger the corresponding action of the agent.

The usual object-oriented techniques can be applied to agent techniques, supporting

efficient and structured program development, like inheritance, abstract agent types and

agent interfaces, and generic agent types [6, 5, 8]. Single, multi, and dynamic inheritance

can be applied for states, actions, methods, and message handling [6, 5]. Associations are

usable to describe, for example, agent "Institute" using the services of an agent "Employer"

to perform a task, with some cardinality and roles [8, 5]. An example is shown in Figure 3.7.

24


E xam ple 3.2. We assume there is an agent class “University.” There are some agent roles

such as teaching centers, research institutes, and employers. “UofR” and “UofT” are the

instances of the agent class University. At the same time, they are also teaching centers,

research institutes, and employers. So, they can be described as follows.

UofR,UofT/teaching center, research institute, employer : University

• S ta te D escrip tions. These are similar to attribute description in class diagrams.

• A ctions. There are two kinds of actions for an agent: one is triggered by the agent

itself; another is triggered by other agents. The semantics of an action are defined by

pre-conditions, post-conditions, effects, and invariants.

• M ethods. These are the same with operation descriptions in UML.

• C apab ilities , serv ice d escrip tio n an d su p p o rte d pro toco ls. These can be de

fined either in an informal way or using class diagrams.

• C om m unica tive acts. Two parts are included in this section. One is sending and

receiving communicative acts. The received or sent communicative acts have priority

(The top-priority communicative act is processed first). Another is matching commu

nicative acts. A received communicative act must be matched against the incoming

communicative acts of an agent to trigger the corresponding action of the agent.

The usual object-oriented techniques can be applied to agent techniques, supporting

efficient and structured program development, like inheritance, abstract agent types and

agent interfaces, and generic agent types [6, 5, 8]. Single, multi, and dynamic inheritance

can be applied for states, actions, methods, and message handling [6, 5]. Associations are

usable to describe, for example, agent “Institute” using the services of an agent “Employer”

to perform a task, with some cardinality and roles [8, 5]. An example is shown in Figure 3.7.

24


Figure 3.7: UML example with AUML

3.4 Examples


3.4.1.1 Functional requirements

The vertex colouring problem is used as an example in this thesis. The definition is

given as follows. G is an undirected graph. If G can be assigned one colour from a set of

k colours to each vertex such that no two adjacent vertices have the same colour, we say

G is (k)-colourable. If the graph G is k-colourable but not (k-1)-colourable, then G is a

k-chromatic graph and that its chromatic number x(G) is k. So, the chromatic number is

the minimum number k. In other words, a k-chromatic graph is a graph that needs at least

k colours, whereas a k-colourable graph is a graph that does not need more than k colours

[23].

In Figure 3.8, we show a 4-colouring of a graph. Colour 1 is blue, colour 2 is red, colour

3is yellow, and colour 4 is green. However, if we just have three colours, how can we assign

them to the vertices? Figure 3.9 is one possible solution. The functional requirements of the

problem are given below.

25


Ir tit ditp I n*pli*ef

•nam e StringUi>cfKjan Si’ii ̂

1 •employee

has

l.,n -cmpiov m

limployrr'Tciictiur, SmlY.

•nam e String

I'nve/vity1 taichingCcflior, RotcarctiCentcr

•ooursdbt

Figure 3.7: UML example with AUML

3.4 Examples



The vertex colouring problem is used as an example in this thesis. The definition is

given as follows. G is an undirected graph. If G can be assigned one colour from a set of

k colours to each vertex such that no two adjacent vertices have the same colour, we say

G is (fc)-colourable. If the graph G is Ar-colourable but not (k- 1 )-colourable, then G is a

fc-chromatic graph and that its chromatic number x( G) is k. So, the chromatic number is

the minimum number k. In other words, a /achromatic graph is a graph tha t needs at least

k colours, whereas a /c-colourable graph is a graph tha t does not need more than k colours

[23].

In Figure 3.8, we show a ^-colouring of a graph. Colour 1 is blue, colour 2 is red, colour

5 is yellow, and colour 4 is green. However, if we just have three colours, how can we assign

them to the vertices? Figure 3.9 is one possible solution. The functional requirements of the

problem are given below.

25


Figure 3.8: 4-colouring

2


• G is an undirected graph.

• There are 6 vertices {A, B, C, D, E, F} and 8 edges { AB, AC, AD, BC, BE, CD,

CE, CF }.

• Each vertex is assigned a colour number. For example, vertex A is assigned colour 1

and vertex C is assigned colour 3.

• An edge has two vertices.

• For each two vertices, if there is a common edge, they are assigned different colour

numbers. For example, A and B have a common edge AB, so A and B could not be

assigned the same colour. A is assigned colour 1 and B is assigned colour 2. A and F

do not have a common edge, so A and F can be assigned the same colour number.

• How do we use three colour numbers to assign the vertices of graph G?

3.4.1.2 Describing the example with CSP

Figure 3.8 can be described with six variables A to F and eight constraints Cl to C8.

Here, all the variables have the same domain, equal to red, blue, green. A detail of the CSP

specification is given in below.

26


Figure 3.8: ^-colouring

1


• G is an undirected graph.

• There are 6 vertices {A, B, C, D, E, F} and 8 edges { AB, AC, AD, BC, BE, CD,

CE, CF }.

• Each vertex is assigned a colour number. For example, vertex A is assigned colour 1

and vertex C is assigned colour 5.

• An edge has two vertices.

• For each two vertices, if there is a common edge, they are assigned different colour

numbers. For example, A and B have a common edge AB, so A and B could not be

assigned the same colour. A is assigned colour 1 and B is assigned colour 2. A and F

do not have a common edge, so A and F can be assigned the same colour number.

• How do we use three colour numbers to assign the vertices of graph G?

3.4.1.2 Describing the example with CSP

Figure 3.8 can be described with six variables A to F and eight constraints C\ to C&.

Here, all the variables have the same domain, equal to red, blue, green. A detail of the CSP

specification is given in below.

26


Variables: A, B, C, D, E, F

Domain: {red, blue, green}

Constraints: C1: A B; C2 : A # C; C3: B C; C4: A D; C5: B E; C6:

C E; C7: C D; C8: C F

We represent the CSP with an undirected graph in Figure 3.10

2

Figure 3.10: 3-colouring constraint graph

3.4.1.3 Describing the example with distributed CSP

We map Figure 3.8 into a distributed CSP through the multi-agent truth maintenance

system. The variables and constraints are distributed among three agents. As can be seen in

Figure 3.11, "Agentl" and "Agent2" share vertices B and C. "Agentl" and "Agent3" share

the vertex C. "Agent2" and "Agnet3" share the vertex C. The actions of this problem are:

vertex B has the same value between "Agentl" and "Agent2," and vertex C has the same

value among "Agent1," "Agent2," and "Agent3."

Agentl. Variables: A, B, C, D, Domain: {red, blue, green}, Constraints: C1:

A B; C2 : A C; C3: A D; C4: B C; C5: C D

Agent. Variables: B, C, E, Domain: {red, blue, green}, Constraints: C1: B

C; C2: B E; C3: CAE

Agent3. Variables: C, F, Domain: {red, blue, green}, Constraints: C1 : C F

27


Variables: A, B, C, D, E, F

Domain: {red, blue, green}

Constraints: Cx: A + B; C2 : A ± C\ C3: B ± C; C4: A ± D\ C5: B ± E; C6:

C ^ E - , C 7 : C ^ D; C8: C ± F

We represent the CSP with an undirected graph in Figure 3.10

1C2

03Ott

Figure 3.10: 5-colouring constraint graph

3.4.1.3 D escrib ing th e exam ple w ith d is tr ib u te d C SP

We map Figure 3.8 into a distributed CSP through the multi-agent tru th maintenance

system. The variables and constraints are distributed among three agents. As can be seen in

Figure 3.11, “Agentl” and “Agent2” share vertices B and C. “Agentl” and “Agent3” share

the vertex C. “Agent2” and “Agnet3” share the vertex C. The actions of this problem are:

vertex B has the same value between “Agentl” and “Agent2,” and vertex C has the same

value among “A gentl,” “Agent2,” and “Agent3.”

A g e n tl . Variables: A, B, C, D, Domain: {red, blue, green}, Constraints: Cx:

A ^ B ; C 2 : A ^ C ] C 3 : A ^ D - , Op B ± C\ C5: C + D

A gen2. Variables: B, C, E, Domain: {red, blue, green}, Constraints: C\: B ^

C; C2: B ^ E ; C 3 : C ^ E

A gent3. Variables: C, F, Domain: {red, blue, green}, Constraints: Cx : C ^ F

27


3 Agent3

2

Figure 3.11: Map colouring problem with distributed CSP



The following are the functional requirements of a TCSP problem. "Tom has class at

8:30 a.m. He can either breakfast at home (10 minutes) or buy food at store (5 minutes).

After breakfast he has a rest (5 minutes). Then he goes to school by bus (at least 45 minutes).

Today, Tom gets up between 7:05 a.m and 7:15 a.m. The question is: "can Tom arrive at

school in time for class?"

3.4.2.2 Describing the example with temporal CSP

In this TCSP example, there are five events: "let P0 be the event Tom gets up, P1 be the

event he has a breakfast at home, P2 be the event he takes food at store, P3 be the event

he has a rest, and P4 be the event he takes a bus." There are four constraints, which can be

represented by logic Allen relations. The TCSP constraint graph of the example is shown in

Figure 3.12. The description of the example with TCSP is as follows.

Variables: /3.9; Pi; P2 ; P3; P4

Domain: { 7:05a.m. to 8:30a.m. }

Constraints: C1: Po P P1; C2: Po P P2; C3: Pi P P3 or P2 P- P3; C4: P3 P P4;

28


Figure 3.11: Map colouring problem with distributed CSP



The following are the functional requirements of a TCSP problem. “Tom has class at

8:30 a.m. He can either breakfast at home (10 minutes) or buy food at store (5 minutes).

After breakfast he has a rest (5 minutes). Then he goes to school by bus (at least 45 minutes).

Today, Tom gets up between 7:05 a.m and 7:15 a.m. The question is: “can Tom arrive at

school in time for class?”

3.4.2.2 Describing the example with temporal CSP

In this TCSP example, there are five events: “let Po be the event Tom gets up, Pi be the

event he has a breakfast at home, Pz be the event he takes food at store, P3 be the event

he has a rest, and P4 be the event he takes a bus.” There are four constraints, which can be

represented by logic Allen relations. The TCSP constraint graph of the example is shown in

Figure 3.12. The description of the example with TCSP is as follows.

Variables: P0; Pi; P2; P3; Pi

Domain: { 7:05a.m. to 8:30a.m. }

Constraints: C\\ Po P Pi; Cz'- Po P P2; C3: Pi P P3 or P2 P- P3; C4: P3 P P4;

28


Getting up

Breakfast at store \

P Taking a bus

Breakfast at home

Having a rest

Figure 3.12: An example of temporal CSP

3.4.2.3 Describing the example with distributed temporal CSP

We describe the time scheduling problem with distributed TCSP. We describe this prob-

lem with two agents. From Figure 3.13, we can find "Agentl" and "Agent2" have one shared

event "having a rest."

Figure 3.13: Time scheduling problem with distributed TCSP

The distributed temporal CSP specification is shown here.

Agentl. Variables: Po; P2 ; P3, Domain: { 7:05a.m. to 8:30a.m.}, Con-

straints: C1: Po P Pi; C2: Po P P2 ; C3 : Pi P P3 or P2 P- P3

Agent2. Variables: P3 ; P4, Domain: { 7:05a.m. to 8:30a.m.}, Constraints:

P3 P P4

29


Breakfast at home

or

Breakfast at store

Taking a busHaving a rest

P

Figure 3.12: An example of temporal CSP

3.4.2.3 D escrib ing th e exam ple w ith d is tr ib u te d te m p o ra l C S P

We describe the time scheduling problem with distributed TCSP. We describe this prob

lem with two agents. From Figure 3.13, we can find “Agentl” and “Agent2” have one shared

event “having a rest.”

Agent 1

Breakfast a t home

or

Breakfast a t s to re

Having a rest

Taking a bus

% < —

Having a rest

Figure 3.13: Time scheduling problem with distributed TCSP

The distributed temporal CSP specification is shown here.

A g e n tl. Variables: P0; Pi; P2; P3, Domain: { 7:05a.m. to 8:30a.m.}, Con

straints: C\\ Po P Pi; C2: Po P P2; C3: Pi P P3 or P2 P- P3

A gent2. Variables: P3; P4, Domain: { 7:05a.m. to 8:30a.m.}, Constraints: Ci:

P3 P P t

29


3.5 Conclusion

We have introduced UML, agent-UML, and OCL through several examples. UML pro-

vides a good means for modeling CSP and TCSP applications. By the visual class diagrams

and corresponding OCL descriptions, understanding and solving CSPs and TCSPs will be-

come easier. However, OCL is not enough to describe the constraints of CSPs and TCSPs.

So, we are going to extend OCL in the next chapter and build two frameworks to describe

any CSP and TCSP application with UML and OCL extensions. These frameworks are an

interface between users and constraint class libraries, which we call (temporal) CSP solvers.

Users do not need to know how to use constraint class libraries when they describe their

problems. They just describe their CSPs and TCSPs and solution rules with the OCL ex-

tensions. The frameworks process the CSP and TCSP descriptions and generate codes with

the (temporal) CSP solver. Finally, constraint graphs and solutions are shown to users.

30


3.5 Conclusion

We have introduced UML, agent-UML, and OCL through several examples. UML pro

vides a good means for modeling CSP and TCSP applications. By the visual class diagrams

and corresponding OCL descriptions, understanding and solving CSPs and TCSPs will be

come easier. However, OCL is not enough to describe the constraints of CSPs and TCSPs.

So, we are going to extend OCL in the next chapter and build two frameworks to describe

any CSP and TCSP application with UML and OCL extensions. These frameworks are an

interface between users and constraint class libraries, which we call (temporal) CSP solvers.

Users do not need to know how to use constraint class libraries when they describe their

problems. They just describe their CSPs and TCSPs and solution rules with the OCL ex

tensions. The frameworks process the CSP and TCSP descriptions and generate codes with

the (temporal) CSP solver. Finally, constraint graphs and solutions are shown to users.

30


4. GENERIC CSP FRAMEWORKS WITH

UML AND OCL UML, a very expressive language, addresses all the views needed to develop software

systems. Even though it is expressive, UML is not difficult to understand and use. In

this chapter, we provide generic CSP and TCSP frameworks that can be used to describe

and solve any generic CSP and TCSP. The difference between CSP and TCSP is that CSP

manages discrete numbers and TCSP treats discrete time intervals. So, we discuss these two

frameworks separately. Furthermore, by extending OCL, we can use the CSP and TCSP

frameworks to describe the constraint details of CSPs and TCSPs and solution rules. In

addition, the CSP and TCSP templates are given to assist users in describing their CSP and

TCSP applications with the OCL extensions.

4.1 A generic CSP framework

We propose here a generic class diagram to describe any CSP. Users can use OCL to

specify the constraints of their problems and solution rules as well. The class diagram com-

piles the OCL description with a special constraint class library and automatically chooses

an algorithm according to the solution rules. Because values of CSP variables are discrete

numbers, we assume all the values of variables are natural numbers here.

4.1.1 Generic CSP class diagram

As shown in Figure 4.1, we use the UML class diagram to model any CSP constraint net-

work. The only relationships between classes are association, generalization and dependency.

We design this diagram a such way that it can be coupled with any existing CSP solver li-

brary, such as ILog, Java Cream, or Choco, in order to produce the solutions of a given CSP.

Therefore, this diagram can be enhanced anytime with new CSP techniques and solving

algorithms. We design any CSP solver library with the generic package CSP Solver that

contains four primary classes: IntVariable, IntDomain, IntConstraint, and NetworkBuffer.

31


4 GENERIC CSP FRAMEWORKS WITHUML AND OCL

UML, a very expressive language, addresses all the views needed to develop software

systems. Even though it is expressive, UML is not difficult to understand and use. In

this chapter, we provide generic CSP and TCSP frameworks that can be used to describe

and solve any generic CSP and TCSP. The difference between CSP and TCSP is that CSP

manages discrete numbers and TCSP treats discrete time intervals. So, we discuss these two

frameworks separately. Furthermore, by extending OCL, we can use the CSP and TCSP

frameworks to describe the constraint details of CSPs and TCSPs and solution rules. In

addition, the CSP and TCSP templates are given to assist users in describing their CSP and

TCSP applications with the OCL extensions.

4.1 A generic CSP framework

We propose here a generic class diagram to describe any CSP. Users can use OCL to

specify the constraints of their problems and solution rules as well. The class diagram com


an algorithm according to the solution rules. Because values of CSP variables are discrete

numbers, we assume all the values of variables are natural numbers here.

4.1.1 Generic CSP class diagram

As shown in Figure 4.1, we use the UML class diagram to model any CSP constraint net

work. The only relationships between classes are association, generalization and dependency.

We design this diagram a such way that it can be coupled with any existing CSP solver li

brary, such as ILog, Java Cream, or Choco, in order to produce the solutions of a given CSP.

Therefore, this diagram can be enhanced anytime with new CSP techniques and solving

algorithm s. We design any C SP solver lib rary w ith th e generic package C SP Solver th a t

contains four primary classes: IntVariable, IntDomain, IntConstraint, and NetworkBuffer.

31


CSP

-nameSting N

-conN : int 4imeLimilad:int

-sot titionl'ype : int

iineCSPO 0 +run0 ishnia6o1 once° 1

'CSPSoIv

NetWorkBuffer

-id; int -de.seription : Suing

+loCSPSolverCanstraint() 0

1.

-id • int -value : int

+toCSPitolverVarimble0 0

Figure 4.1: Generic CSP class diagram

v I

Domain

-id int -valueList List

+toCSPSolverDontain0 0

IntDornsin

CSP solver libraries use these classes to build CSP constraint networks. NetworkBuffer pro-

vides algorithm functions and is the handle of the solver. The other classes are summarized

below:

• Class CSP records CSP general information and user's solution rules. Its attributes in-

clude variable number, constraint number, time limited, and solution type. CSP::timeLimited

and CSP::solutionType controls the user's solution rules. Calling the operation

CSP::generateCSP 0, a constraint network will be generated based on the user's OCL

description.

• Class Variable inherits from CSPSolver::IntVariable. An instance of class Variable

records a variable information of OCL descriptions.

• Class Domain inherits from CSPSolver::IntDomain. Any variable object has a do-

main instance.

• Class Constraint inherits from CSPSolver::IntConstraint. Instances of class Con-

straint record constraint information of OCL descriptions. They are elements of con-

straint networks.

So, this class diagram presents a CSP object that describes a constraint network. A

constraint network consists of constraint objects. A constraint object includes some variable

objects. Each variable object has a domain object that restricts the value of the variable.

32


CSP

Hiaine: String -vai’Num: int -conNum: ml-timeLimited: im -*KjliitionType: int

►generateCSPO O +run()+s IkjwSoI ution()

h a shas

-variables

Constraint

-id : mt-description: String

+toCSPSolverConsmaint() O

Variable

-id : int -value: int

HotSPSoherVariableO 0

OT3SES"

has

-domain

Domain

-id int-valueList: List

HoCSPSolverDomainO O

li !>■ ii-NeiWodsBulTer JmConstraint tMVariable IntDomain

Figure 4.1: Generic CSP class diagram

CSP solver libraries use these classes to build CSP constraint networks. NetworkBuffer pro

vides algorithm functions and is the handle of the solver. The other classes are summarized

below:

• C lass C S P records CSP general information and user’s solution rules. Its attributes in

clude variable number, constraint number, time limited, and solution type. CSP::timeLimited

and CSP::solutionType controls the user’s solution rules. Calling the operation

CSP::generateCSP(), a constraint network will be generated based on the user’s OCL

description.

• C lass V ariab le inherits from CSPSolver::IntVariable. An instance of class Variable

records a variable information of OCL descriptions.

• C lass D om ain inherits from CSPSolver::IntDomain. Any variable object has a do

main instance.

• C lass C o n s tra in t inherits from CSPSolver::IntConstraint. Instances of class Con

straint record constraint information of OCL descriptions. They are elements of con

straint networks.

So, this class diagram presents a CSP object that describes a constraint network. A

constraint network consists of constraint objects. A constraint object includes some variable

objects. Each variable object has a domain object tha t restricts the value of the variable.

32


In chapter 2, we mention two kind of solutions: complete solution and best solution.

Here we give an example to explain when users will need the complete solution and when

users will need the best solution.

Example 4.1 We present an simple real world problem for complete solution and best

solution requirements: "A buyer need to buy some goods, which are in the different mar-

kets. He want to buy all the goods in a short time. So the buyer need a complete solution

to arrange his routine. However, if he wants to buy the most goods in 30 minutes, the buyer

needs a best solution to arrange his routine."

Basically, we have three kind of solution types in this thesis: one complete solution, all

complete solutions, and the best solution.

4.1.2 OCL extensions

In this thesis, to be able to describe a given CSP and its solution rules, we extend OCL

with new keywords. For CSP description, new keywords include the following.

• CSP expresses a CSP object.

• Name expresses name for a CSP, variable or constraint object.

• VarNum expresses variable number of a CSP.

• ConNum expresses constraint number of a CSP.

• Vars expresses the variable collection of a CSP. For instance, Vars[1] denotes the first

variable in the CSP specification, and so on.

• Value expresses the initial value of a variable.

• Domain express domain of a variable. We have two kind of domains in this thesis:

boundary and enumeration. For instance, Domain = [1,4] expresses the variable's

domain, an integer set from 1 to 4; Domain = {blue,green,yellow} denotes the variable's

domain, an enumerated type.

33


In chapter 2, we mention two kind of solutions: complete solution and best solution.

Here we give an example to explain when users will need the complete solution and when

users will need the best solution.

E xam ple 4.1 We present an simple real world problem for complete solution and best

solution requirements: “A buyer need to buy some goods, which are in the different mar

kets. He want to buy all the goods in a short time. So the buyer need a complete solution

to arrange his routine. However, if he wants to buy the most goods in 30 minutes, the buyer

needs a best solution to arrange his routine.”

Basically, we have three kind of solution types in this thesis: one complete solution, all

complete solutions, and the best solution.


In this thesis, to be able to describe a given CSP and its solution rules, we extend OCL

with new keywords. For CSP description, new keywords include the following.

• C SP expresses a CSP object.

• N am e expresses name for a CSP, variable or constraint object.

• V arN um expresses variable number of a CSP.

• C onN um expresses constraint number of a CSP.

• V ars expresses the variable collection of a CSP. For instance, Vars[l] denotes the first

variable in the CSP specification, and so on.

• V alue expresses the initial value of a variable.

• D om ain express domain of a variable. We have two kind of domains in this thesis:

boundary and enumeration. For instance, Domain = [1,4] expresses the variable’s

domain, an integer set from 1 to 4; Domain — {blue,green,yellow} denotes the variable’s

domain, an enumerated type.

33


• Cons expresses the constraint collection of a CSP. For example, Cons[1] denotes the

first constraint, and so on.

For solution rules, new keywords include the following.

• TimeLimited specifies iterate times for solving a CSP. Value 0 means no time limited.

• SolutionType specifies what kind of solution the user wants: AllSolutions means

all complete solutions, OneSolution one complete solution, FastSolution the best

solution in a specific time.

Currently, OCL uses invariant, precondition, and postcondition expressions to describe

constraints of object-oriented systems. These expressions are always associated with classes

or operations. In this thesis, we improve these expressions to be associated with special

objects represented by the new keywords. The new syntax of these expressions is defined

below.

• Invariant expressions. In OCL, invariants are associated with classes. But, in this

thesis, we use these expressions to denote a CSP and user rules. They are only asso-

ciated with objects CSP, Vars, and Cons. The syntax is as follows.

context (Object) inv: (expressions)

• Pre- and postcondition expressions. These are only associated with the object

Cons. Preconditions must be true when the constraint is going to be met; postcondi-

tions must be true after the constraint has just ended. The syntax is given below.

context (Constraint Object)

pre: (expressions)

post: (expressions)

4.1.3 Generic CSP template

Based on the extensions above, we present the CSP template containing three main parts,

including:

34


• Cons expresses the constraint collection of a CSP. For example, Cons[l] denotes the

first constraint, and so on.

For solution rules, new keywords include the following.

• T im eL im ited specifies iterate times for solving a CSP. Value 0 means no time limited.

• S o lu tionT ype specifies what kind of solution the user wants: A llSolu tions means

all complete solutions, O neSolu tion one complete solution, F astS o lu tion the best

solution in a specific time.

Currently, OCL uses invariant, precondition, and postcondition expressions to describe

constraints of object-oriented systems. These expressions are always associated with classes

or operations. In this thesis, we improve these expressions to be associated with special

objects represented by the new keywords. The new syntax of these expressions is defined

below.

• In v arian t expressions. In OCL, invariants are associated with classes. But, in this

thesis, we use these expressions to denote a CSP and user rules. They are only asso

ciated with objects C SP, V ars, an d Cons. The syntax is as follows.

c o n te x t (Object) inv: (expressions)

• P re - an d p o s tco n d itio n expressions. These are only associated with the object Cons. Preconditions must be true when the constraint is going to be met; postconditions must be true after the constraint has just ended. The syntax is given below.

c o n te x t (Constraint Object)

p re : (expressions)

p o st: (expressions)

4.1.3 Generic CSP tem plate

Based on the extensions above, we present the CSP template containing three main parts,

including:

34


• CSP and solution rules. Variable number, constraint number, default domain, and

solution rules are entered first.

• Variables and domains. We describe the information of a variable, Vars[i], 1 < i

< VarNum, including domain and value, which are first set to default values.

• Constraints. Each constraint is expressed with the object Cons[iJ, 1 < i < Con-

Num. The relations of constraints are any logical or mathematic relations. The

elements of constraints are variable objects, which are represented by the Vars key-

word.

The CSP template is illustrated in Table 4.1.

Table 4.1: CSP specification template

--CSP and Solution Rules context CSP inv: Name = --CSP name VarNum = --variable number ConNum = --constraint number TimeLimited = --time limited Solution Type = --solution type

--Variables and Domains context Vars[1] inv: Name =-- --variable/'s name Domain = --variable/'s domain Value = --variable/'s initial value

context Vars[2] inv: ...

--Constraints context Cons[1] inv: Name = --constraint/'s name --logical formulas of constraint/

context Cons[2] inv: ... ...

4.1.4 Examples of "map colouring problem" and "share apples"

We present two CSP examples here with CSP template.

Example 4.2. We present an intergrade OCL description in Section 3.4.1. The requirement

of the problem is: "the variable number is 6 and constraint number is 8. Users' rules are

35


• C S P an d so lu tion ru les. Variable number, constraint number, default domain, and


• V ariab les an d dom ains. We describe the information of a variable, Varsfi], 1 < i

< V arN um , including domain and value, which are first set to default values.

• C o n stra in ts . Each constraint is expressed with the object Cons[i], 1 < i < C on

N u m . The relations of constraints are any logical or mathematic relations. The

elements of constraints are variable objects, which are represented by the V ars key

word.

The CSP template is illustrated in Table 4.1.

____________________ Table 4.1: CSP specification template____________________

—CSP and Solution Rules context CSP inv:Name = —CSP name VarNum = —variable number ConNum = -constraint number TimeLimited = —time limited SolutionType = —solution type

—Variables and Domains context Vars[l] inv:Name = —■variable 1 ’s name Domain = —variable1’s domain Value = — variable! ’s initial value

context Vars[2] inv: . ..

—C onstraints context Cons[ 1] inv:Name — — constraint l ’s name -logical formulas of constraint!

context Cons[2] inv: ...

4.1.4 Examples of “map colouring problem” and “share apples”

We present two C SP exam ples here w ith C SP tem plate .

E xam ple 4.2. We present an intergrade OCL description in Section 3.4.1. The requirement of the problem is: “the variable number is 6 and constraint number is 8 . Users’ rules are

35


finding all complete solutions with no time limited." We use Vars[11 expresses vertex A,

Vars[2] expresses vertex B, Vars[3] expresses vertex C, Vars[4] expresses vertex D, Vars[6I

expresses vertex E, Vars[6] expresses vertex F. From Section 3.4.1 (map colouring), we know

all the variables have the same domain in this problem. They range from 1 to 6. The con-

straints are: Cons[1]: A B; Cons[2] : A C; Cons[3]: B C; Cons[4]: A D; Cons[5]:

B E; Cons[6]: C E; Cons[7]: C D; Cons[8]: C F. From the CSP template, we

generate the CSP specification below.

context CSP inv:

Name = "map colouring problem"--CSP name

VarNum = 6 --variable number

ConNum = 8 --constraint number

TimeLimited = 0 --no time limited

Solution Type = AllSolutions

context Vars[11 inv:

Name = "A" -- vertex A

Domain = {red, blue, green}

Value = "red" -- initial colouring of A is red

context Vars[2.1 inv:

Name = "B" -- vertex B


Value = "red" -- initial colouring of B is red

context Vars[3] inv:

Name = "C" -- vertex C


Value = "red" -- initial colouring of C is red

context Vars14 inv:

Name = "D" -- vertex D


Value = "red" -- initial colouring of D is red

36


finding all complete solutions with no time limited,” We use Vars[l] expresses vertex A, Vars[2j expresses vertex B , Vars[3] expresses vertex C, Vars[4] expresses vertex D, Vars[5] expresses vertex E, Vars[6] expresses vertex F. From Section 3.4.1 (map colouring), we know all the variables have the same domain in this problem. They range from 1 to 6 . The constraints are: Cons[ 1]: A B] Cons[2] : A ^ C \ Cons[3>}: B C; Cons[4]: A=£ D; Cons [5]: B / E\ C ons[6]: C ^ E\ Cons [7]: C / D\ Cons[8]: C / F. From the CSP template, we generate the CSP specification below.

context CSP inv:

Name = “map colouring problem”—CSP name

VarNum = 6 —variable number

ConNum = 8 —constraint number

TimeLimited — 0 —no time limited

SolutionType = AllSolutions

context Vars[l] inv:

Name = “A” — vertex A

Domain = (red, blue, green}

Value = “red” — initial colouring of A is red


Name = “B” — vertex B


Value = “red” — initial colouring of B is red


Name = “C” — vertex C


Value = “red” — initial colouring of C is red

context Vars[4j inv:

Name = “D” — vertex D


Value = “red” — initial colouring of D is red

36



Name = "E" -- vertex E


Value = "red" -- initial colouring of E is red


Name = "F" -- vertex F


Value = "red" -- initial colouring of F is red

context Cons[1] inv:

Name = "C1" <> B"

Vars[1] <> Vars[2]


Name = "C2" --"A <> C"

Vars[1] <> Vars[3]

context Cons [3] inv:

Name = "C3" —"A <> D"

Vars[1] <> Vars[4]


Name = "C4" --"B <> C"

Vars[2] <> Vars[3]


Name = "C5" --"B <> E"

Vars[2] <> Vars[5]


Name = "C6" --"C <> D"

Vars[3] <> Vars[4]


Name = "C7" --"C <> E"

Vars[3] <> Vars[5]


Name = "C8" --"A <> F"

Vars[3] <> Vars[6]

After calling CSP::generateCSP(), the object diagram (in Figure 4.2) is the initial state

in which only three variables and two constraints are shown. After calling CSP::run(), the

37



Name = “E” — vertex E


Value = “red” — initial colouring of E is red


Name — “F” - vertex F


Value = “red” -- initial colouring of F is red

context Cons[ 1] inv:

Name = “CV’ - “A <> B”

Ears[l] <> Vars [2]


Name = “C2” - “A <> C”

Vars [ 1] <> Ears [3]


Name = “C3” - “A <> D”

Ears[l] <> Ears [4]


Name = “C4” - “B <> C”

Ears [2] <> Ears [3]


Name = “C5” - “B <> E”



Name = “C6” ~ “C <> D”



Name = “C7” - “C <> E”

Ears [3] < > Ears [5]


Name = “C8” - “A <> F”


After calling CSP::generateCSP(), the object diagram (in Figure 4.2) is the initial state

in which only three variables and two constraints are shown. After calling CSP::run(), the


d2 tbnpdn

MIX CSP

0

name - "Map Cola* Problem" twaNtart 61 aohnionType .0%11801011W

USgEsitt.

Id* I desaiptioll..M>B"

ConOnant

id *2 **amnion* "Ac*(:"

B ;.Varielk

value 2 id * 2

A Vati

value* id

id*2 II, 24,4. 2.6)

value.G: Van

d•3

id • I valueLial • 11. 2. 3. 4. 0. 61

Id *3 valusUat• 11. 2. 3.4. 5,61

Figure 4.2: Constraint network of 3-colouring

total complete solutions are 12. One possible solution is A is blue, B is green, C is red, D is

green, E is blue, and F is blue.

Example 4.3. Let us consider another problem, which uses pre- and postcondition ex-

pressions: "There are three people Mike, Tom, and Jack, who have ten apples. Mike can eat

more than two apples, Tom and Jack more than six apples. Before Tom eats, Jack has to eat

two apples. After Jack is full, Tom can eat more than three apples." The CSP specification

is illustrated below.

context CSP inv:

Name = "Eating apples"

VarNum = 3

ConNum = 3

TimeLimited = 0

Solution Type = OneSolution


Name = "Mike"

Domain = [0,10]

Value = 0


Name = "Tom"

Domain = [0,10]

Value = 0

38


MaaColonwt C'SP

timeUmited » 0 var.Vumname - "Map Coloring Problem" couNurn ® 8solutionType * “AilSolution"

Ci ; Constraint

id «■ Idescription ** "A oB"

C2 .- CcMutrainl

id *2description «* "A<>C" hut

B ; Variable

•value ® 2 id *2A : Variable

value » I id* I

value *- 3 ui *.5

d2 ' Domain

id - 2valueList 11, 2, 3. 4. 5. 6 !

id* Ivaluel..tsl* {1, 2, 4. 5, 6)

ip . Domain

id «3vtdueList » ( I .2. 3. 4, 5, 6 |

Figure 4.2: Constraint network of 5-colouring

total complete solutions are 12. One possible solution is A is blue, B is green, C is red, D is

green, E is blue, and F is blue.

E xam ple 4.3. Let us consider another problem, which uses pre- and postcondition ex

pressions: “There are three people Mike, Tom, and Jack, who have ten apples. Mike can eat

more than two apples, Tom and Jack more than six apples. Before Tom eats, Jack has to eat

two apples. After Jack is full, Tom can eat more than three apples.” The CSP specification

is illustrated below.

context CSP inv:

Name = ’’Eating apples”

VarNum = 3

ConNum = 3

TimeLimited = 0

SolutionType = OneSolution

context Vars[l] inv:

Name = “Mike”

Domain = [0,10]

Value = 0

context Ears [2] inv:

Name = “Tom”

Domain = [0,10]

Ea/«e = 0

38


context Vars [3] inv:

Name = "Jack"

Domain = [0,10]

Value = 0


Name = "cl"

Vars[1] + Vars[2] + Vars[3] = 10


Name = "c2"

Vars[1] > 2

context Cons [3]

inv: Name = "c3"

pre: Vars[3] >= 2

inv: Vars[2] + Vars[3] > 6

post: Vars[2] > 3

There are only two solutions for this problem. One possible solution is that Mike eats

three apples, Tom four apples, and Jack three apples.

4.2 A generic temporal CSP framework

We propose here a generic class diagram to describe any TCSP. Users can use OCL to

specify the constraints of their problems and solution rules as well. The class diagram com-


an algorithm according to the solution rules. In the generic CSP class diagram, values of

variables must be held at a point in time. However, in the generic TCSP class diagram,

values of events may change from an earlier state to later state, while keeping the con-

straint satisfiable. That means values of events are time slices. The domain of events can

be presented by beginning time, end time, and step.

39


co n tex t Vars [3] inv:

Name = “Jack”

Domain = [0,10]

Value = 0

co n tex t Cons[ 1] inv:

Name = “c l”

Vars[l] + Vars [2] + Vars [3] = 10

co n tex t Cons[2] inv:

Name = “c2”

Vars[l] > 2

co n tex t Cons[3]

inv: Name = “c3”

pre: Vars[3] > = 2

inv: Vars[2] + Vars[3] > 6

post: Vars[2] > 3

There are only two solutions for this problem. One possible solution is tha t Mike eats

three apples, Tom four apples, and Jack three apples.

4.2 A generic temporal CSP framework

We propose here a generic class diagram to describe any TCSP. Users can use OCL to

specify the constraints of their problems and solution rules as well. The class diagram com


an algorithm according to the solution rules. In the generic CSP class diagram, values of

variables must be held at a point in time. However, in the generic TCSP class diagram,

values of events may change from an earlier state to later state, while keeping the con

straint satisfiable. That means values of events are time slices. The domain of events can

be presented by beginning time, end time, and step.

39


4.2.1 Generic TCSP class diagram

TCSP

-name: Suits .eventNum : hr -conNum : int •timel.imited : int •zolutionType int

+RenerateTCSP() 0 +run() mhoveSolutiaM) ;

4d : int •description

410T CSFSOIViNC0000a100 0

id int •valueEnd:•valucFronr: int -duration : int

MoTCSPSolverEvien10 0

Figure 4.3: Generic TCSP class diagram

-id: int -valueLita SOP()

No'TCSPSolverDomairt0

In Figure 4.3, the package TCSP Solver is a constraint solver class library that can solve

TCSPs. The generic TCSP framework wraps this class library. There are also four classes

to describe a generic TCSP:

• Class TCSP records TCSP general information and user's solution rules. Its at-

tributes include event number, constraint number, time limited, and solution type.

TCSP::timeLimited and TCSP::solutionType control the user's solution rules.

• Class Event records an event of a TCSP. There are three attributes to present a

value of a Event instance to record a time slice: Event::valueFrom, Event::valueEnd,

and Event::duration.

• Class Domain is recorded as shown in Figure 2.5.

• Class Constraint records the relations between Event objects.

This class diagram is similar to the generic CSP class diagram, but focusses on different

number spaces, which are discrete numbers and linear numbers. In the generic CSP class

diagram, the relations of two variable objects can be mathematical and logical. However, in

the generic TCSP class diagram, the relations of two event objects are logic Allen relations

[1].

40


4.2.1 Generic TCSP class diagram

TCSP

-n a m e ; String -e ven tN um : ini -co n N u tti: int • tim e lJm ited : int •solution T y p e ; int

+genarateTCSP() 0 •Hw() JfshowSduiionO }

has has has

I TCgPSolveT

1..* -constraints,................ IT — -events

1 -domain

Constraint Event D om ain

4 d : int•desc rip tion : String

• id : int•valueE nd : int -va tueFrom : in t •d u ra tio n : tn t

• i d : int-v a lu e l .is t : SOPO

4ioTC$P$oJverCon&lwtni() oi

_......

ttoTCSPSoiverD om ainO o

t+toTCSPSolvei'Eve«tO 0

TempNetWorkBufTer TempConstmm TempEvent Temp Domain

Figure 4.3: Generic TCSP class diagram

In Figure 4.3, the package TCSP Solver is a constraint solver class library tha t can solve

TCSPs. The generic TCSP framework wraps this class library. There are also four classes

to describe a generic TCSP:

• C lass T C S P records TCSP general information and user’s solution rules. Its at

tributes include event number, constraint number, time limited, and solution type.

TCSP::timeLimited and TCSP::solutionType control the user’s solution rules.

• C lass E v en t records an event of a TCSP. There are three attributes to present a

value of a Event instance to record a time slice: Event::valueFrom, Event: :valueEnd,

and Event::duration.

• C lass D om ain is recorded as shown in Figure 2.5.

• C lass C o n s tra in t records the relations between Event objects.

This class diagram is similar to the generic CSP class diagram, but focusses on different

number spaces, which are discrete numbers and linear numbers. In the generic CSP class

diagram , th e re la tions of two variable ob jects can be m athem atica l and logical. However, in

the generic TCSP class diagram, the relations of two event objects are logic Allen relations

[ ! ] •

40



Obviously, the OCL extensions for the generic CSP class diagram are appropriate to the

generic TCSP class diagram. However, some new keywords should be added to OCL.

• TCSP expresses a TCSP object.

• Events expresses the event object collection of a TCSP object.

• EventNum expresses event number of a TCSP object.

• BeginTime, EndTime, and Step. We use these three keywords to present the time

space for a TCSP object.

• Duration expresses the distance of time slice for event objects.

Based on these extensions and Figure 2.5, domains of events can be represented by the

following structure.

[BeginTime, EndTime, Duration, Step]

However, this structure can only be used in the TCSP framework. When users describe

their TCSPs with OCL extension, they will describe "[BeginTime, EndTime]," "Duration,"

and "Step" respectively.

We still use invariant, precondition, and postcondition expressions to describe constraints

of TCSPs. The syntax of these expressions look like the CSP description syntax, but the

associated keywords are different. The new syntax is defined below.

• Invariant expressions are used to denote a TCSP and user rules. They are only

associated with objects TCSP, Events, Cons. The syntax is as follows.


• Pre- and postcondition expressions are only associated with object Cons. Pre-

conditions must be true when the constraint is going to be met; postconditions must

41



Obviously, the OCL extensions for the generic CSP class diagram are appropriate to the

generic TCSP class diagram. However, some new keywords should be added to OCL.

• T C S P expresses a TCSP object.

• E ven ts expresses the event object collection of a TCSP object.

• E v en tN u m expresses event number of a TCSP object.

• B eg inT im e, E n d T im e, an d S tep . We use these three keywords to present the time

space for a TCSP object.

• D u ra tio n expresses the distance of time slice for event objects.

Based on these extensions and Figure 2.5, domains of events can be represented by the

following structure.

[B eginT im e, E ndT im e, D uration , Step]

However, this structure can only be used in the TCSP framework. When users describe

their TCSPs with OCL extension, they will describe “[BeginTime, EndTime],” “Duration,”

and “Step” respectively.

We still use invariant, precondition, and postcondition expressions to describe constraints

of TCSPs. The syntax of these expressions look like the CSP description syntax, but the

associated keywords are different. The new syntax is defined below.

• In v arian t expressions are used to denote a TCSP and user rules. They are only

associated with objects T C S P , E ven ts, Cons. The syntax is as follows.

con text (Object) inv: (expressions)

• P re - an d p o stco n d itio n expressions are only associated with object Cons. Preconditions must be true when the constraint is going to be met; postconditions must

41


be true after the constraint has just ended. The syntax is given below.


pre: (expressions)

post: (expressions)

4.2.3 Generic TCSP template

Based on the extensions above, we present the TCSP template still containing three main

parts, including

• TCSP and solution rules. Event number, constraint number, default domain, and


• Events and domains. We describe the information of an event, Eventsg 1 < i <

EventNum, including name, domain, duration, step, and initial value.

• Constraints. Each constraint is expressed with the object Cons fij, 1 < i < Con-

Num. The relations of constraints are Allen relations. The elements of constraints

are event objects, which are represented by the Event keyword.

The TCSP template is illustrated in Table 4.2.

42


be true after the constraint has just ended. The syntax is given below.


pre: (expressions)

post: (expressions)

4.2.3 Generic TCSP tem plate

Based on the extensions above, we present the TCSP template still containing three main

parts, including

• T C S P an d so lu tion rules. Event number, constraint number, default domain, and


• E ven ts an d dom ains. We describe the information of an event, E vents[i], 1 < i <

E v e n tN u m , including name, domain, duration, step, and initial value.

• C o n stra in ts . Each constraint is expressed with the object Cons[i], 1 < i < C on-

N u m . The relations of constraints are Allen relations. The elements of constraints

are event objects, which are represented by the E ven t keyword.

The TCSP template is illustrated in Table 4.2.

42


Table 4.2: TCSP specification template

--TCSP and Solution Rules context TCSP inv: Name = --TCSP name EventNum = --event number ConNum, = --constraint number TimeLimited = --time limited Solution Type = --solution type

--Time Points and Domains context Events[1] inv: Name = --Event/'s name Domain = --Event/'s domain Duration = --Event i 's during time Step = --Domain's step Value = --Event/'s initial value

context Events[2] inv: ... ...

--Constraints context Cons[1] inv: Name = --constraint/'s name --Allen relation formulas of constraint/

context Cons[2] inv: ... ...

4.2.4 A time scheduling problem example

Example 4.4. In the following, we give an intergrade TCSP description as described in

Section 3.4.2. The requirement of the problem is: "there are five events which are "getting

up," "breakfast at home," "breakfast from store," "having a rest" and "taking bus. The

relationship between any two adjacent events is "precede." The TCSP specification is given

below.

43


Table 4.2: TCSP specification template

—TCSP and Solution Rules context TCSP inv:Name = —TCSP name EventNum = —event number ConNum = —constraint number TimeLimited = —time limited SolutionType = —solution type

—Time Points and Domains context Events[l] inv:Name = —Event./ ’s name Domain = —Event 1 ’s domain Duration = —Event/’s during time Step = —Domain’s step Value = —Event 1 ’s initial value

context Events[2] inv: . ..

—Constraints context Cons[ 1] inv:Name = —constraint/’s name —Allen relation formulas of constraint/

context Cons[2] inv: . ..

4.2.4 A tim e scheduling problem example

E xam ple 4.4. In the following, we give an intergrade TCSP description as described in

Section 3.4.2. The requirement of the problem is: “there are five events which are “getting

up,” “breakfast at home,” “breakfast from store,” “having a rest” and “taking bus. The

relationship between any two adjacent events is “precede.” The TCSP specification is given

below.

43


context TCSP inv:

Name = "time scheduling problem"; -- example's name

EventNum = 5; -- events number

ConNum = 4; -- constraint number

TimeLimited = 0; -- no time limited

Solution Type = OneSolution; -- a complete solution

context Events[1] inv:

Name = "getting up"; -- name of event 1

Domain = [0, 85]; -- event's domain

Duration = 10; -- duration of the event 1

Step = 1; -- step of two durations

Value = [0, 10]; -- value of event 1


Name = "breakfast at home"; -- name of event 2



Step = 1; -- step of the event 2



Name = "breakfast from store"; -- name of event 3


Duration = 5; -- Duration of the event 3



context Events/.4J inv:

Name = "having a rest"; -- name of event 4





44


con tex t TCSP inv:

Name = “time scheduling problem” ; — example’s name

EventNum = 5; — events number

ConNum = 4; — constraint number

TimeLimited = 0; — no time limited

SolutionType = OneSolution; — a complete solution

con tex t Events[l] inv:

Name = “getting up” ; — name of event 1

Domain = [0, 85]; — event’s domain

Duration = 10; — duration of the event 1

Step = 1; — step of two durations

Value = [0, 10]; — value of event 1

con text Events[2] inv:

Name = “breakfast a t home” ; — name of event 2

Domain — [0, 85]; -- event’s domain


Step = 1; — step of the event 2

Value ~ [0, 10]; — value of event 2

con tex t Events[3] inv:

Name — “breakfast from store” ; — name of event 3

Domain = [0, 85]; — event’s domain

Duration = 5; — Duration of the event 3



con tex t Events[4] inv:

Name = “having a rest” ; — name of event 4

Domain = [0, 85]; -- event’s domain




44



Name = "taking bus"; -- name of event 5


Duration = 45; -- durationof the event 5




-- after getting up, Tom has a breakfast at home

Events[1] P Events[2];


-- after getting up, Tom has a breakfast from store

Events[1] S Events[3];


-- have a rest after breakfast

(Events[2] P Events[4]) or (Events[3] P Events[4]);


-- taking bus after have a rest

Events [4] P Events[5];

TinreSchedule TESP

uama - 'time initedulintt" coriNtrin - 4 solutionTypo a AllSolution aventNumM S

meLinuted

description vatis(il P Vint ts(2)" id. I

Ektunglin EOM%

valueEnd 10 o 1

Duration .10 valuaFrom • 0

BI"AtI Event

volueEnd *21 id 32 duration 10 valuefrom I I

idt• I valueLin t• (0. as, 1)

id -2 valueList ,ttt (0. 85, I)

Figure 4.4: Constraint network of the time scheduling problem

After calling TCSP::generateTCSPO, the constraint network of Figure 4.4 is the static

view of the framework. We just present two event instances and their relations. After calling

TCSP::run(), a complete solution is obtained. In this case, one possible solution is: Events[1]

= [0, 10], Events[2] = [11, 21], Events[3] = [22, 27], Events[4] = [28, 33] and Events[5] =

[34, 79].

45


co n te x t Events[5] inv:

Name = “talcing bus” ; — name of event 5

Domain = [0, 85]; -- event’s domain

Duration = 45; — durationof the event 5



co n te x t Cons{\] inv:

— after getting up, Tom has a breakfast a t home

Events[ 1] P Events[2];

c o n te x t Cons[2] inv:

— after getting up, Tom has a breakfast from store

Events[ 1] S Events[3];

co n te x t Cons[3] inv:

- have a rest after breakfast

(Events[2] P Events[4]) or (Events[3] P Events[4]);

c o n te x t Cons[4] inv:

— taking bus after have a rest


TnneSchedule ; TCSP

name * “time scheduling" cotiNwn * 4sohrtuwType * AllSolution eveniNum * 5 ttmcUmited - 0

- - - - - - - - - - - - - A H j - - - - - - - - - - - - - - - - “

C l : Constraint

description ® "h'venlsf 1 j P f ventsf2|" id “ 1

Figure 4.4: Constraint network of the time scheduling problem

After calling TCSP::generateTCSP(), the constraint network of Figure 4.4 is the static

view of the framework. We just present two event instances and their relations. After calling

TCSP::run(), a complete solution is obtained. In this case, one possible solution is: Events[l]

= [0, 10], Events[2] = [11, 21], Events[3] = [22, 27], Events[4] = [28, 33] and Events[5] =

[34, 79].

45

CtounpUp ; Eveni ' Domain

valueEttd * 10 has id •« 1id * 1 vahicUsi - (0 ,85, I)duration « 10vaJucFrom « 0

BFAtllomc : Event; Domain

vaiueEnd •* 21 id * 2dum ion ■' 10 v’almsFrotn ® 11

has id - 2valueLtst - (0 ,85 ,1 )


4.3 Conclusion

The generic CSP and TCSP frameworks along with the OCL extensions are expressive

enough to specify any real-world CSP and TCSP applications. However, these frameworks

are unable to help users describing and constructing more complex CSPs and TCSPs because

of the increasing variables (events) and constraints. Distributed (temporal) CSP uses agent

techniques to describe and solve complex (temporal) CSPs. In the next chapter, we build

generic distributed CSP and TCSP frameworks. Users can transform and represent any

(temporal) CSP to distributed (temporal) CSP with the new frameworks and new OCL

extensions.

46


4.3 Conclusion

The generic CSP and TCSP frameworks along with the OCL extensions are expressive

enough to specify any real-world CSP and TCSP applications. However, these frameworks

are unable to help users describing and constructing more complex CSPs and TCSPs because

of the increasing variables (events) and constraints. Distributed (temporal) CSP uses agent

techniques to describe and solve complex (temporal) CSPs. In the next chapter, we build

generic distributed CSP and TCSP frameworks. Users can transform and represent any

(temporal) CSP to distributed (temporal) CSP with the new frameworks and new OCL

extensions.

46


5. GENERIC DISTRIBUTED CSP

FRAMEWORKS WITH AGENT-UML AND

OCL Agent-UML (AUML) extends the UML class diagrams to represent the structural re-

lationships among agents, and between agents and classes. As mentioned before, we can

map any CSP/TCSP into distributed CSP/TCSP through a multi-agent truth maintenance

system [24]. In this chapter, we provide generic distributed CSP and TCSP frameworks that

can be used to describe and solve any generic CSP/TCSP with distributed (temporal) CSP

techniques. End-users still use the extended OCL to describe the details of agents, con-

straints among agents, and solution rules as well. Furthermore, a distributed CSP/TCSP

template is given to assist users describing their CSP/TCSP applications with distributed

techniques and the OCL extensions.

5.1 Generic distributed (temporal) CSP agent class diagram

Any CSP/TCSP can be considered as a distributed CSP/TCSP. In distributed CSPs/TCSPs,

variables/events and constraints are distributed among agents. In an agent, variables/events

are the core, and constraints are the relationships of the variables/events. These agents

include all the constraints of CSPs/TCSPs and they share some variables/events. The goal

is for each agent to obtain a complete solution with the shared variables/events having the

same values.

Figure 5.1 is the generic distributed (temporal) CSP agent class diagram. DCP is an

agent class that represents a generic distributed CSP/TCSP and controls the collaboration

of DCPAgent objects. The role of agent DCPAgent is a generic distributed CSP/TCSP

agent. Because each agent has some variables/events and their corresponding constraints,

DCPAgent extend generic CSP/TCSP class diagrams. Thus, we can use the generic class

diagrams to describe these variables and the inter-constraints. The attributes of the class

diagrams are the agent state descriptions. The operations of the class diagrams are the agent

methods. Furthermore, we still need to describe actions, capabilities, and communicative

47


5 GENERIC DISTRIBUTED CSP

FRAMEWORKS WITH AGENT-UML AND

OCLAgent-UML (AUML) extends the UML class diagrams to represent the structural re

lationships among agents, and between agents and classes. As mentioned before, we can

map any CSP/TCSP into distributed CSP/TCSP through a multi-agent tru th maintenance

system [24]. In this chapter, we provide generic distributed CSP and TCSP frameworks that

can be used to describe and solve any generic CSP/TCSP with distributed (temporal) CSP

techniques. End-users still use the extended OCL to describe the details of agents, con

straints among agents, and solution rules as well. Furthermore, a distributed CSP/TCSP

template is given to assist users describing their CSP/TCSP applications with distributed

techniques and the OCL extensions.

5.1 Generic distributed (temporal) CSP agent class diagram

Any CSP/TCSP can be considered as a distributed CSP/TCSP. In distributed CSPs/TCSPs,

variables/events and constraints are distributed among agents. In an agent, variables/events

are the core, and constraints are the relationships of the variables/events. These agents

include all the constraints of CSPs/TCSPs and they share some variables/events. The goal

is for each agent to obtain a complete solution with the shared variables/events having the

same values.

Figure 5.1 is the generic distributed (temporal) CSP agent class diagram. DCP is an

agent class tha t represents a generic distributed CSP/TCSP and controls the collaboration

of DCPAgent objects. The role of agent DCPAgent is a generic distributed CSP/TCSP

agent. Because each agent has some variables/events and their corresponding constraints,

DCPAgent extend generic CSP/TCSP class diagrams. Thus, we can use the generic class

diagrams to describe these variables and the inter-constraints. The attributes of the class

diagrams are the agent state descriptions. The operations of the class diagrams are the agent

methods. Furthermore, we still need to describe actions, capabilities, and communicative

47


DCP

-sone Siring •agentNum Integer -timeLionited Intern -solutionType tragior

+poor DCPO

+ma()

DCPAgent Oen** DCSPIDTCSP Apem

4bune -weight Integer -vanNitin Integer •enasNont Weser

• aCIUXILISt

-rtienetateComitneitiGn0130

-recoivelitift -sendBuff

+secs,

Figure 5.1: Generic agent class diagram

Generic CSP/TCSP

Class Diagram

acts that record the relations among agents. So, the functions of the class and agent class

in Figure 5.1 are

• Class DCP records distributed CSP/TCSP general information and the user's solu-

tion rules. Its attributes include name, agent number, time limited, and solution type.

DCP::timeLimited and DCP::solutionType control the user's solution rules.

• Agent class DCPAgent records all information of the generic CSP/TCSP class

diagrams. Furthermore, agent weight, which decides which agent is more important,

actionList, which records the transaction between the agent and other agents, and

receiveBuff and sendBuff, which record the capabilities and communicative methods,

are defined in the agent class.

If a problem is a distributed CSP, the constraints of agents and constraints of variables

are mathematical and logical formulas. However, if the problem is a distributed TCSP, the

relations of agents and the relations of events are logic Allen relations.

5.2 OCL extensions

For describing distributed CSPs/TCSPs, the OCL extensions for the generic CSP/TCSP

class diagrams are not enough. Some new keywords should be added to OCL as follows.

• DCP expresses a distributed CSP/TCSP object.

• Agents expresses the agent object collection of a DCP object.

48


•nam e: String -agentNum: Integer -tiroelJm ited; Integer -sotuiionTypeInteger

D C PG e n eric C S P /T C S P

C la ss D iagram

+<kntmteComirfti»it<jT»pti()-*nm0

DCPAgent / Generic EX’SP/DTCSP Agent

Figure 5.1: Generic agent class diagram

acts that record the relations among agents. So, the functions of the class and agent class

in Figure 5.1 are

• C lass D C P records distributed CSP/TCSP general information and the user’s solu

tion rules. Its attributes include name, agent number, time limited, and solution type.

DCP::timeLimited and DCP::solutionType control the user’s solution rules.

• A gen t class D C P A gen t records all information of the generic CSP/TCSP class

diagrams. Furthermore, agent weight, which decides which agent is more important,

actionList, which records the transaction between the agent and other agents, and

receiveBuff and sendBuff, which record the capabilities and communicative methods,

are defined in the agent class.

If a problem is a distributed CSP, the constraints of agents and constraints of variables

are mathematical and logical formulas. However, if the problem is a distributed TCSP, the

relations of agents and the relations of events are logic Allen relations.

5.2 OCL extensions

For describing distributed CSPs/TCSPs, the OCL extensions for the generic CSP/TCSP

class diagrams are not enough. Some new keywords should be added to OCL as follows.

• D C P expresses a distributed CSP/TCSP object.

• A gen ts expresses the agent object collection of a DCP object.

48


• Actions expresses the action collection of a DCP object.

• AgentNum expresses agent number of a DCP object.

• ActionNum expresses action number of a DCP object.

• Weight expresses the weight value of an agent.

We still use invariant, precondition, and postcondition expressions to describe actions

and constraints of distributed CSPs/TCSPs. The syntax of these expressions look like

CSP/TCSP description syntax, but the associated keywords are different. The new syn-

tax is defined below.

• Invariant expressions. We use these expressions to denote a distributed CSP/TCSP

and user rules. They are only associated with objects DCP, Vars, Events, Cons,

and Actions. The syntax is as follows.


• Pre- and postcondition expressions. They are only associated with object Cons.

Preconditions must be true when the constraint is going to be met; postconditions

must be true after the constraint has just ended. The syntax is given below.


pre: (expressions)

post: (expressions)

5.3 Generic distributed CSP and TCSP templates

Based on the extensions above, we present the distributed CSP/TCSP templates still

containing three main parts, including:

• DCP and solution rules. We describe distributed CSP/TCSP general information

and user's solution rules here. They include agent number, agent action number, time

limited, and solution type.

49


• A ctions expresses the action collection of a DCP object.

• A g en tN u m expresses agent number of a DCP object.

• A c tio n N u m expresses action number of a DCP object.

• W eight expresses the weight value of an agent.

We still use invariant, precondition, and postcondition expressions to describe actions

and constraints of distributed CSPs/TCSPs. The syntax of these expressions look like

CSP/TCSP description syntax, but the associated keywords are different. The new syn

tax is defined below.

• In v arian t expressions. We use these expressions to denote a distributed CSP/TCSP

and user rules. They are only associated with objects D C P, V ars, E ven ts, Cons,

an d A ctions. The syntax is as follows.

con text (Object) inv: (expressions)

• P re - a n d p o s tco n d itio n expressions. They are only associated with object Cons. Preconditions must be true when the constraint is going to be met; postconditions must be true after the constraint has just ended. The syntax is given below.

con text (Constraint Object)

pre: (expressions)

post: (expressions)

5.3 Generic distributed CSP and TCSP tem plates

Based on the extensions above, we present the distributed CSP/TCSP templates still

containing three main parts, including:

• D C P an d so lu tion ru les. We describe distributed CSP/TCSP general information

and user’s solution rules here. They include agent number, agent action number, time

limited, and solution type.

49


• Agent description. We need to describe each agent here. For each agent, we describe

it as with generic CSP/TCSP class diagrams. The differences are that the agent weight

and the agents do not have the own user's solution rules. Agents will use the DCP

user's solution rules.

• Agent actions. We describe all the relationships between the agents.

The distributed CSP template is illustrated in Table 5.1.

Table 5.1: Distributed CSP specification template

--Distributed CSP and Solution Rules context DCP inv: Name = --problem name AgentNum = --Agent number ActionNum = --Action Number TimeLimited = --time limited SolutionType = --solution type

--Agents context Agents[1] inv: Name = --Agent/ 's name Weight = --Agent/ 's Weight VarNum = --variable number ConNum = --constraint number

--Agent's Variables and Domains context Agents11J.Vars[1.1 inv: Name = --variable1's name Domain = --variable/'s domain Value = --variable/'s initial value

context Agents[1].Vars[2] inv: ...

--Constraints context Agents9J.Cons[1] inv: Name = --constraint i 's name --logical formulas of constraint/

context Agents[1].Cons[2] inv: ...

context Agents[2] inv: ... --Agent actions context Actions[1] inv: -- action 1 of the problem

--equal equation of action 1 of agent 1 context Actions[2] inv: -- action 2 of the problem ...

The distributed TCSP template is illustrated in Table 5.2.

50


• A gent descrip tion . We need to describe each agent here. For each agent, we describe

it as with generic CSP/TCSP class diagrams. The differences are that the agent weight

and the agents do not have the own user’s solution rules. Agents will use the DCP

user’s solution rules.

• A gent actions. We describe all the relationships between the agents.

The distributed CSP template is illustrated in Table 5.1.

______________ Table 5.1: Distributed CSP specification template_______________

-D istributed CSP and Solution Rules context DCP inv:Name = —problem name AgentNum — -Agent number ActionNum = —Action Number TimeLimited = -tim e limited SolutionType = —solution type

-A gentscontext Agents[l] inv:Name = —Agents’s name Weight — —Agents's Weight VarNum = -variable number ConNum = —constraint number

—Agent’s Variables and Domains context Agents[l].Vars[l] inv:Name = —■variable 1 ’s name Domain = —variableS’s domain Value = —variable 1 ’s initial value

context Agents[l].Vars[2] inv: . ..

—Constraintscontext Agents[l].Cons[ 1] inv:Name = —constraints’s name -logical formulas of constraints

context Agents[l].Cons[2] inv: . ..

context Agents[2] inv:

—Agent actionscontext Actions/1] inv: — action 1 of the problem

—equal equation of action S of agent S context Actions[2] inv: — action 2 of the problem

The distributed TCSP template is illustrated in Table 5.2.

50


Table 5.2: Distributed TCSP specification template

--Distributed TCSP and Solution Rules context DCP inv: Name = --problem name AgentNum = --Agent number ActionNum = --Action Number TimeLimited = --time limited Solution Type = --solution type

--Agents context Agents[1] inv: Name = --Agent/ 's name Weight = --Agent/'s Weight EventNum = --event number ConNum = --constraint number

--Time Points and Domains context Agent[1].Events[1] inv: Name = --Event 1 's name Domain = --Event/'s domain Duration = --Event/'s during time Step = --Domain's step Value = --Event i 's initial value

context Agent[11.EventsM inv:

--Constraints context Agenti1J.Cons[1] inv: Name = --constraint/'s name --Allen relation formulas of constraint/

context Agent[1].Cons[2] inv:


--Agent actions context Actions[1] inv: -- action 1 of the problem

--logic Allen relation formulas 1 context Actions/2J inv: -- action 2 of the problem

51


Table 5.2: Distributed TCSP specification template

—Distributed TCSP and Solution Rules context DCP inv:Name = —problem name AgentNum = -Agent number ActionNum = -Action Number TimeLimited, = —time limited SolutionType = —solution type

—Agentscontext Agents[l] inv:Name = — Agent 1’s name Weight = —Agentl ’s Weight EventNum = —event number ConNum = —constraint number

—Time Points and Domains context Agent[lJ.Events[l] inv:Name = —Eventl’s name Domain = —Eventl’s domain Duration = —Eventl’s during time Step = —Domain’s step Value = —Eventl’s initial value

context Agent[lj.Events[2] inv: ...

—Constraintscontext Agent[l].Cons[ 1] inv:Name = —constraint Ts name -Allen relation formulas of constraint!

context Agent[l].Cons[2] inv: . ..


—Agent actionscontext Actions[l] inv: — action 1 of the problem

-logic Allen relation formulas 1 context Actions[2] inv: — action 2 of the problem

51


5.4 Examples

In this section, we also apply the examples "map colouring problem" and "time schedul-

ing problem" given in Chapter 3 on the distributed CSP/TCSP framework. We describe

these problems with the distributed CSP/TCSP templates and the resulting descriptions are

provided in the following subsection.


In the following, we give an intergrade CSP description for Figure 3.11. So we have three

agents and four agent actions between agents. The distributed CSP specification is given

below.

context DCP inv:

-- give the name of DCP

Name = "map colouring problem"

-- 3 agents

AgentNum = 3;

-- 4 agent actions

ActionNum = 4;

-- describing time limited here.

TimeLimited = 0;

-- describing what kind of solutions users want

SolutionType = OneSolution;

-- describe agent 1

context Agents[1]

-- give the name of Agent

Name = "a part of the graph"

Weight = 1; the agent's weight

-- 4 vertices

VarNum = 4;

-- 5 edges

ConNum = 5; -- the agent do not has own user's solution rules, so we do not need

-- describe it here. It will use the DCP solution rules.

describe vertices, domains and initial values here

context Agents[1].Vars[1] inv:

Name = Vertex A;

Domain = {red, blue, green};

Value = red; -- colour number of vertex A

52


5.4 Examples

In this section, we also apply the examples “map colouring problem” and “time schedul

ing problem” given in Chapter 3 on the distributed CSP/TCSP framework. We describe

these problems with the distributed CSP/TCSP templates and the resulting descriptions are

provided in the following subsection.


In the following, we give an intergrade CSP description for Figure 3.11. So we have three

agents and four agent actions between agents. The distributed CSP specification is given

below.

context DCP inv:— give the name of DCPName = "map colouring problem"— 3 agents AgentNum = 3;— 4 agent actions ActionNum = 4;— describ ing time lim ited here.TimeLimited = 0;— describ ing what kind of so lu tion s users want SolutionType = OneSolution;

— describe agent 1 context Agents[1]

— give the name of Agent Name = "a part of the graph"Weight = 1; the agent's weight— 4 v e r tic e s VarNum = 4;— 5 edges ConNum = 5;— the agent do not has own u ser 's so lu tion ru le s , so we do not need— describe i t here. I t w il l use the DCP so lu tion ru les.

— describe v e r t ic e s , domains and in i t i a l values here context Agents[1 ] .Vars[1] inv:

Name = Vertex A;Domain = {red, b lue, green};Value = red; — colour number of vertex A

52


context Agents[1].Vars[2] inv: Name = Vertex B;

Domain = {red, blue, green}; Value = red; -- colour number of vertex B


Name = Vertex C;


Value = red; -- colour number of vertex C


Name = Vertex D;


Value = red; -- colour number of vertex D

-- describe inter-constraints here

context Agents[1].Cons[1] inv:

-- There is an edge between vertices A and B

Vars[1] <> Vars[2];


-- There is an edge between vertices A and C

Vars [1] <> Vars[3];


-- There is an edge between vertices A and D Vars[1] <> Vars[4];


-- There is an edge between vertices B and C

Vars [2] <> Vars[3]; context Agents[1].Cons[5] inv:

-- There is an edge between vertices C and D


-- agent 1 description end

-- describe agent 2 context Agents[2]




-- 3 vertices

VarNum = 3;

-- 3 edges

ConNum = 3;

-- the agent do not has own user's solution rules, so we do not need

-- describe it here. It will use the DCP solution rules. describe vertices, domains and initial values here


Name = Vertex B; Domain = {red, blue, green};

53


context Agents[1 ] .Vars[2] inv:Name = Vertex B;Domain = {red, b lue, green};Value = red; — colour number of vertex B

context Agents[1 ] .Vars[3] inv:Name = Vertex C;Domain = {red, b lue, green};Value = red; — colour number of vertex C

context Agents[1 ] .Vars[4] inv:Name = Vertex D;Domain = {red, b lue, green};Value = red; — colour number of vertex D

— describe in ter -co n stra in ts here context Agents[ 1 ] .Cons[1] inv:

— There i s an edge between v e r tic e s A and B V ars[l] <> Vars [2];

context Agents[1 ] .Cons[2] inv:— There i s an edge between v e r t ic e s A and C Vars[1] <> Vars[3];

context Agents [ 1 ] .Cons [3] in v :— There i s an edge between v e r tic e s A and D Vars [1] <> Vars [4] ;

context Agents[ 1 ] .Cons[4] in v :— There i s an edge between v e r tic e s B and C Vars[2] <> Vars[3];

context Agents[1 ] .Cons[5] inv:— There i s an edge between v e r tic e s C and D Vars[3] <> Vars[4];

— agent 1 d escrip tion end


— give the name of Agent Name = "a part of the graph"Weight = 2; the agent's weight— 3 v e r tic e s VarNum = 3;— 3 edges ConNum = 3;— the agent do not has own u ser’s so lu tion ru le s , so we do not need— describe i t here. I t w il l use the DCP so lu tion ru les.


Name = Vertex B;Domain = {red, b lue, green};

53


Value = red; -- colour number of vertex B


Name = Vertex C;




Name = Vertex E;


Value = red; -- colour number of vertex E

describe inter-constraints here


-- There is an edge between vertices B and C

Vars[1] <> Vars[2];


-- There is an edge between vertices B and E



-- There is an edge between vertices C and E



-- describe agent 3

context Agents[3]




-- 2 vertices

VarNum = 2;

-- 1 edges

ConNum = 1;



describe vertices, domains and initial values here


Name = Vertex C; Domain = {red, blue, green};



Name = Vertex F;


Value = red; -- colour number of vertex F -- describe inter-constraints here


-- There is an edge between vertices C and F

Vars[1] <> Vars[2];

54


Value = red; — colour number of vertex B context Agents[2 ] .Vars[2] inv:

Name = Vertex C;Domain = {red, b lue, green};Value = red; — colour number of vertex C

context Agents[2 ] .Vars[3] inv:Name = Vertex E;Domain = {red, b lue, green};Value = red; — colour number of vertex E

— describe in ter -co n stra in ts here context Agents[ 2 ] .Cons[1] in v :

— There i s an edge between v e r tic e s B and C V ars[l] <> Vars [2];

context Agents[ 2 ] .Cons[2] in v :— There i s an edge between v e r tic e s B and E Vars[1] <> Vars[3];

context Agents[ 2 ] .Cons[3] inv:— There i s an edge between v e r tic e s C and E Vars[2] <> Vars[3];



— give the name of Agent Name = "a part of the graph"Weight = 3; the agent's weight— 2 v e r tic e s VarNum = 2;— 1 edges ConNum = 1;— the agent do not has own u ser’s so lu tion r u le s , so we do not need— describe i t here. I t w il l use the DCP so lu tion ru le s .


Name = Vertex C;Domain = {red, b lue, green};Value = red; — colour number of vertex C

context Agents[ 3 ] .Vars[2] inv:Name = Vertex F;Domain = {red, b lue, green};Value = red; — colour number of vertex F

— describe in ter -co n stra in ts here context Agents[3 ] .Cons[1] inv:

— There i s an edge between v e r tic e s C and F V ars[l] <> Vars [2];

54



-- describe agent constraints here

context Actions[1] inv:

-- agent 1 and agent 2 share the vertex B.

Agents[1].Vars[2] = Agents[2].Vars[1]



Agents[1].Vars[3] = Agents[2].Vars[2]



Agents[1].Vars[3] = Agents[2].Vars[1] context Actions[4] inv:


Agents[1].Vars[2] = Agents[2].Vars[1] -- agent constraint description end


In the following, we give an intergrade TCSP description for Figure 3.13. So we have

two agents and only one agent action between agents. The distributed TCSP specification

is given below.

context DCP inv:

-- give the name of DCP

Name = "time scheduling problem"

-- 2 agents

AgentNum = 2;

-- 1 agent actions

ActionNum = 1;

-- describing time limited here.

TimeLimited = 0;

-- describing what kind of solutions users want

SolutionType = OneSolution;

-- describe agent 1

context Agents[1]


Name = "a part of the graph" Weight = 1; the agent's weight -- 4 events EventNum = 4;

-- 3 constraint ConNum = 3;

55



— describe agent constrain ts here context A ction s[1] inv:

— agent 1 and agent 2 share the vertex B.Agents[1 ] .Vars[2] = Agents[2 ] .Vars[1]

context Actions [2] inv:— agent 1 and agent 2 share the vertex B.A gents[1 ] .Vars[3] = Agents[2 ] .Vars[2]

context A ction s[3] inv:— agent 1 and agent 3 share the vertex B.Agents[1 ] .Vars[3] = Agents[ 2 ] .Vars[1]

context A ction s[4] inv:— agent 1 and agent 2 share the vertex B.Agents[1 ] .Vars[2] = Agents[2 ] .Vars[1]

— agent constrain t d escrip tion end


In the following, we give an intergrade TCSP description for Figure 3.13. So we have

two agents and only one agent action between agents. The distributed TCSP specification

is given below.

context DCP inv:— give the name of DCPName = "time scheduling problem"— 2 agents AgentNum = 2;— 1 agent actions ActionNum = 1;— describ ing time lim ited here.TimeLimited = 0;— describ ing what kind of so lu tion s users want SolutionType = OneSolution;


— give the name of Agent Name = "a part of the graph"W eig h t = 1; t h e a g e n t ’ s w e ig h t— 4 events EventNum = 4;— 3 constraint ConNum = 3;

55




-- describe vertices, domains and initial values here

context Agents[1].Events[1] inv:

Name = getting up;

Duration = 10; -- during time

Domain = [0,85]; -- domain of event 1

Step = 1;

Value = [0, 10]; context Agents[1].Events[2] inv:

Name = breakfast at home;



Step = 1;

Value = [0, 10];

context Agents[1].Events[3] inv:

Name = breakfast at store;



Step = 1;

Value = [0, 5]; context Agents[1].Events[4] inv:

Name = having a rest;



Step = 1;

Value = [0, 5]; describe inter-constraints here




Events [1] P Events[3];


Events [2] P Events [4] or Event [3] P Event[4];


-- describe agent 2

context Agents[2]



Weight = 2; the agent's weight -- 2 events

EventNum = 2;

-- 3 constraint ConNum = 1;

56


— the agent do not has own u ser’s so lu tion ru le s , so we do not need— describe i t here. I t w il l use the DCP so lu tion ru les.

— describe v e r t ic e s , domains and in i t i a l values here context A gents[1 ] .E vents[1] inv:

Name = g e ttin g up;Duration = 10; — during time Domain = [0 ,85]; — domain of event 1 Step = 1;Value = [0, 10];

context Agents[1 ] .E vents[2] inv:Name = breakfast at home;Duration = 10; — during time Domain = [0 ,85]; — domain of event 2 Step = 1;Value = [0, 10];

context Agents[1 ] .E vents[3] inv:Name = breakfast at store;Duration = 5 ; — during time Domain = [0 ,85]; — domain of event 3 Step = 1;Value = [0, 5];

context Agents[ 1 ] .Events[4] inv:Name = having a rest;Duration = 5 ; — during time Domain = [0 ,85]; — domain of event 4 Step = 1;Value = [0, 5];

— describe in ter-co n stra in ts here context Agents[1 ] .Cons[1] inv:

Events [1] P Events[2]; context Agents[1 ] .Cons[2] inv:

Events[1] P Events[3]; context Agents[1 ] .Cons[3] inv:

Events[2] P Events[4] or Event[3] P Event[4];— agent 1 d escrip tion end


— give the name of Agent Name = "a part of the graph"Weight = 2; the agent’s weight— 2 events EventNum = 2;— 3 constraint ConNum = 1;

56


context Agents [2] . Events [1] inv:

Name = having a rest;


Domain = [0 , 85] ; -- domain of event 1

Step = 1;

Value = [0 , 5] ;

context Agents [2] . Events [2] inv:

Name = taking a bus;


Domain = [0 , 85] ; -- domain of event 2

Step = 1;

Value = [0, 45] ; describe inter-constraints here

context Agents [2] . Cons [1] inv:

Events [1] P Events [2] ;


-- describe agent constraints here

context Actions [1] inv:

Agents [1] . Events [4] E Agents [2] . Events [1]

-- agent actions description end

5.5 Conclusion

In this chapter, the generic distributed CSP and TCSP frameworks are given in which

the OCL extensions and generic distributed CSP and TCSP templates are specified. CSP

and TCSP examples are illustrated based on the proposed templates. In the next chapter, an

assistance tool based on the generic CSP and TCSP class diagrams is given to demonstrate

the effectiveness of our combinatorial problem descriptions.

57


context A gents[2 ] .E vents[1] inv:Name = having a rest;Duration = 5 ; — during time Domain = [0 ,85]; — domain of event 1 Step = 1;Value = [0, 5];

context Agents[2 ] .E vents[2] inv:Name = taking a bus;Duration = 4 5 ; — during time Domain = [0 ,85]; — domain of event 2 Step = 1;Value = [0, 45];

— describe in ter -co n stra in ts here context Agents[2 ] .Cons[1] inv:

Events[1] P Events[2];— agent 2 d escrip tion end

— describe agent constra in ts here context A ctions[1] inv:

A gents[1 ] .E vents[4] E Agents[2 ] .E vents[1]— agent actions descrip tion end

5.5 Conclusion

In this chapter, the generic distributed CSP and TCSP frameworks are given in which

the OCL extensions and generic distributed CSP and TCSP templates are specified. CSP

and TCSP examples are illustrated based on the proposed templates. In the next chapter, an

assistance tool based on the generic CSP and TCSP class diagrams is given to demonstrate

the effectiveness of our combinatorial problem descriptions.

57


6. IMPLEMENTATION AND

EXPERIMENTATION In this chapter, we propose a novel UML-based solver tool that assists users in describing

their combinatorial problems and generating constraint graphs and solutions as well. End-

users can use constraint graphs that are generated by our tool to validate the correctness

of their CSP/TCSP descriptions, according to the requirements. Finally, the tool maps

the CSP/TCSP description into constraint networks through the generic CSP and TCSP

frameworks. We design these frameworks in a way that can be coupled with any existing CSP

solver library, such as ILOG, Choco, or Java Cream. Through CSP and TCSP descriptions,

the tool calls the solver libraries to solve the problems and shows solutions to the users

automatically.

6.1 UML-based solver

Figure 6.1 is an assistant tool for CSP/TCSP specification, constraint graph, and solution

generation. Eclipse 3.12 is used as an implementation environment for its support for Java

SDK 1.5. Our tool has been fully implemented with a total of 3200 lines of pure Java

code. Several open source Java class libraries have been used, such as L2FProd.com to

implement the CSP/TCSP description interface, VGJ (a free Java graph-editor library) that

we have extended to draw the constraint and solution graphs, as well as Choco (a constraint

class library) that we have extended to solve TCSPs. The functionalities of the tool are

summarized below.

• Assisting the end-users in constructing their CSP/TCSP specifications. The assistance

consists in checking the correctness of the entered values and the consistency of the

whole CSP/TCSP specification.

• Automatically generating the constraint graph to visualize the current problem.

• Automatically choosing the appropriate solving algorithm (from the constraint class

library) depending on the solution rules.

58


6 IMPLEMENTATION AND EXPERIMENTATION

In this chapter, we propose a novel UML-based solver tool that assists users in describing

their combinatorial problems and generating constraint graphs and solutions as well. End-

users can use constraint graphs that are generated by our tool to validate the correctness

of their CSP/TCSP descriptions, according to the requirements. Finally, the tool maps

the CSP/TCSP description into constraint networks through the generic CSP and TCSP

frameworks. We design these frameworks in a way tha t can be coupled with any existing CSP

solver library, such as ILOG, Choco, or Java Cream. Through CSP and TCSP descriptions,

the tool calls the solver libraries to solve the problems and shows solutions to the users

automatically.

6.1 UML-based solver

Figure 6.1 is an assistant tool for CSP/TCSP specification, constraint graph, and solution

generation. Eclipse 3.12 is used as an implementation environment for its support for Java

SDK 1.5. Our tool has been fully implemented with a total of 3200 lines of pure Java

code. Several open source Java class libraries have been used, such as L2FProd.com to

implement the CSP/TCSP description interface, VGJ (a free Java graph-editor library) that

we have extended to draw the constraint and solution graphs, as well as Choco (a constraint

class library) tha t we have extended to solve TCSPs. The functionalities of the tool are

summarized below.

• Assisting the end-users in constructing their CSP/TCSP specifications. The assistance

consists in checking the correctness of the entered values and the consistency of the

whole CSP/TCSP specification.

• Automatically generating the constraint graph to visualize the current problem.

• Automatically choosing the appropriate solving algorithm (from the constraint class

library) depending on the solution rules.

58


CSP/TCSP Specification

/ MAL bane / 4 CSPTTCSP CSP/TCSP

Solver Class Library Diagram

Generate

Constraint Graph

Figure 6.1: UML-based solver for CSP and TCSP

silos ceestaint DWI 4, CV 3CSP Now WWI Oman

Constraint Network

Figure 6.2: GUI of the UML-based solver

• Automatically generating the solution graphs and solution text.

As shown in Figure 6.2, the assistant tool includes primary five areas. The toolbar area

includes shortcuts of all operations and options such as problem types (CSP or TCSP).

CSP/TCSP specification area provides CSP/TCSP templates to assist users in describing

their combinatorial problems based on the OCL extensions presented in Chapter 4. The

constraint graph area shows constraint graphs according to the user's CSP/TCSP descrip-

tion. Moreover, the solution graph area shows visual solutions by constraint graphs after

obtaining and choosing solutions. The corresponding text solutions are shown in the solution

text area. The UML class diagram of the UML-based solver is shown in Figure 6.3

59


CSP/TCSPSolverLibrary

<— cat

OCL based CSP/TCSP Template

GenerateGenerate

Constraint Graph Solution (Text Mode)

Figure 6.1: UML-based solver for CSP and TCSP

■=' UMi. b.i-.tii (Temporal) CSI* Solver

! jMiwT) Fopflfl] f S aw j. jj /o c C D e S ^ ' lm ]. - C on tfrM S ra jif t! , i | ' Rim j-. Q Show Cotatr^ntD ataH # CSP Q T C SP j~j snow P e ta l Itanam

CSP D e s c r ip t i o n

i VwtaMB Number jo O m t i m Number jo

Domain j ] :______I 2J

LZZZZ Oanarato catS pecm ca tton

C onstraint Network

frrjr& 'A S S . I I I I H I I 'I I— IlM lliu

L

Figure 6.2: GUI of the UML-based solver

• Automatically generating the solution graphs and solution text.

As shown in Figure 6.2, the assistant tool includes primary five areas. The toolbar area

includes shortcuts of all operations and options such as problem types (CSP or TCSP).

CSP/TCSP specification area provides CSP/TCSP templates to assist users in describing

their combinatorial problems based on the OCL extensions presented in Chapter 4. The

constraint graph area shows constraint graphs according to the user’s CSP/TCSP descrip

tion. Moreover, the solution graph area shows visual solutions by constraint graphs after

obtaining and choosing solutions. The corresponding text solutions are shown in the solution

text area. The UML class diagram of the UML-based solver is shown in Figure 6.3

59


friadgeid

irsuliTau

Figure 6.3: Class diagram of the UML-based solver

6.2 Examples

UML-based solver gives users the opportunity to use a GUI to specify CSPs/TCSPs

and obtain solutions automatically. Java and Choco are used in this tool. When specifying

combinatorial problems with the UML-based Solver, several specific steps should be followed,

as shown below.

• Choosing the combinatorial problem type, CSP or TCSP, is the first step. This option

is shown in toolbar area in Figure 6.4.

File wda lOpon Sar ! bd... ihnimOlon Comb wit GieP.4.1 how ConAmint Mall C.O. CSP

(#) CSP TCSP

TCSP 1 Slow Dahl Doman

Figure 6.4: Combinatorial problem type options of the UML-based solver

• Users specify a variable (event) number, constraint number, and default domain, and

then click the "Generate CSP/TCSP Specification" button. CSP/TCSP specifications

60


f De4ciipiiniiPBiitfl I rTixiitJai CoiuiKUMOapfcl'aiel ( oni nainittaph Pand JTttlFMld

-dascriptionPanel 1 -toolBar I -comtramrtiraph I -nssultGrapb 1 -itaullTcxt 1

includes

. __ ,

MamWindaw has 1 1 FBDeiC j has 1 n Constraint

•pbDesc { j -consirajniv -

C hoco (C onstraint cl as* library)

U o iiu in '

u_p!____ • has

TCSPCongtramt

CSPConniaini

Vaniblo

Figure 6.3: Class diagram of the UML-based solver

6.2 Examples

UML-based solver gives users the opportunity to use a GUI to specify CSPs/TCSPs

and obtain solutions automatically. Java and Choco are used in this tool. When specifying

combinatorial problems with the UML-based Solver, several specific steps should be followed,

as shown below.

• Choosing the combinatorial problem type, CSP or TCSP, is the first step. This option

is shown in toolbar area in Figure 6.4.

H e HalofNeaiK] )-4' S w » f 4| :[iPtuiii'I,. , 'Q Show Cacwln^nt Patau (<yCSP TCSI^ U Show Oetal .

§: CSP O TCSP

Figure 6.4: Combinatorial problem type options of the UML-based solver

Users specify a variable (event) number, constraint number, and default domain, and

then click the “Generate CSP/TCSP Specification” button. CSP/TCSP specifications

60


are generated automatically based on the CSP/TCSP template presented in Chapter

4. Afterwards, users need fill in CSP/TCSP information and solution rules.

• After users click the "Constraint Graph" button, the constraint graph appears in Figure

6.5.

At

NIII Hole

:Nee Peen: S

,r,11)(SP

6!ep

Constraint Graph

: onsilraintDetail *CUP U TCSP al Damen

Connitra,nt r:etworh

Constraint Graph Area

Figure 6.5: Constraint graph area of the UML-based solver

• After users check the correctness of their CSP/TCSP specifications and constraint

graphs, the "Run" button is called. The UML-based solver analyzes CSP/TCSP spec-

ifications and the corresponding algorithms are chosen, Choco codes are generated,

and solutions are obtained. All the solutions are visualized textually and graphically.

ONIL harpti ffeopprdll CSP rue Ilelp

iinprii :Pune i Save Slaw C

Solution Text Area

CSP 0 TCSP Shoe Deese Denteln

Solution Graph Area

Figure 6.6: Solution areas of the UML-based solver

61


are generated automatically based on the CSP/TCSP template presented in Chapter

4. Afterwards, users need fill in CSP/TCSP information and solution rules.

• After users click the “Constraint Graph” button, the constraint graph appears in Figure

6.5.

Hla Help ......; N e w | O p e n p S a w i H i O C t D a e c f l p t l o n i < C o n s t r a W < * « £ { » > i R " " i • j S h o w C o n s t r a i n t D e t a i l s j f e C S P O T C S P [ j S h o w B e t a l D w n a * '

rconsfraiht Graph IL

Constraint Network

Constraint Graph Area

19

Figure 6.5: Constraint graph area of the UML-based solver

• After users check the correctness of their CSP/TCSP specifications and constraint

graphs, the “Run” button is called. The UML-based solver analyzes CSP/TCSP spec

ifications and the corresponding algorithms are chosen, Choco codes are generated,

and solutions are obtained. All the solutions are visualized textually and graphically.

? UML t.rtsiti ftmjN.m!) O P S-Hwr I- . ! 1*1 I*r u e H 8 l p ,H e w f o p o n j . : s a v o i j i < O C L t t t s e r l p t l o n ] . C n n t i r a t o t G r a p h | i i Q R u n ) i 1 s t i n w C o n s t r a i n t D e t a i l d f c C S P O T C S P D S h o w D o t a l D o m a i n

[ Run 1 LSolution Graph Area _j

•j ■ j - ■ • _______- - J! Ptuvloiis ~j j Nfflrt

I

Solution Text Area

Figure 6.6: Solution areas of the UML-based solver

61



Example 6.1. We describe and solve the 3-map colouring problem introduced in Section

3.4.1 with the UML-based Solver. Following the steps above, the CSP option is chosen first.

After filling in the CSP description, according the Example 4.2, the constraint graph and

the twelve solutions are guaranteed. The Choco code generated by the tool is in Table 6.1

and the result is shown in Figure 6.7.

62



E xam ple 6.1. We describe and solve the 3-map colouring problem introduced in Section

3.4.1 with the UML-based Solver. Following the steps above, the CSP option is chosen first.

After filling in the CSP description, according the Example 4.2, the constraint graph and

the twelve solutions are guaranteed. The Choco code generated by the tool is in Table 6.1

and the result is shown in Figure 6.7.

62


Table 6.1: Choco code of 3-colouring

Problem pb = new Problem();

IntDomainVarp intVar = new IntDomainVar[6];

int[] d = {1,2,3};

// 1 = red, 2 = green, 3 = blue

//construct constraint network by Choco

//generate variables

intVar[0] = pb.makeEnumIntVar("A", d);

intVar[1] = pb.makeEnumIntVar("B", d);

intVar[2] = pb.makeEnumIntVar("C", d);

intVar[3] = pb.makeEnumIntVar("D", d);

intVar[4] = pb.makeEnumIntVar("E", d);

intVar[5] = pb.makeEnumIntVar("F", d);

//generate constraint

pb.post(pb.neq(intVar[0],intVar[1]));


pb.post(pb.neq(intVar[0],intVar[3])); pb.post(pb.neq(intVar[1],intVar[2])); pb.post(pb.neq(intVar[1],intVar[4]));


pb.post(pb.neq(intVar[2],intVar[4])); pb.post(pb.neq(intVar[2],intVar[5]));

//generate solver

solver = pb.getSolver();

//obtain all solutions

pb.solveAll();

//m-Nbsolutions is the number of solutions

m_NbSolutions = solver.getSearchSolver().solutions.size();

63


Table 6.1: Choco code of 3-colouring

Problem pb = new ProblemO;IntDomainVar[] intVar = new IntDomainVar[6]; in t[] d = {1 ,2 ,3 };/ / 1 = red, 2 = green, 3 = blue

//co n stru c t constraint network by Choco //gen era te variab les intV ar[0] = pb.makeEnumIntVar("A", d ) ; intV ar[1] = pb.makeEnumlntVarC'B", d ) ; intV ar[2] = pb.makeEnumlntVarO'C", d ) ; intV ar[3] = pb.makeEnumlntVarC'D", d ) ; intV ar[4] = pb.makeEnumlntVarC'E", d ) ; intV ar[5] = pb.makeEnumlntVarC'F", d ) ;

//gen era te constraint pb.post(pb.neq(intV ar[ 0 ] , intV ar[1 ])); pb.post(pb.neq(intV ar[ 0 ] , intVar[2 ])); pb.post(pb.neq(intV ar[ 0 ] , intV ar[3 ])); pb.post(pb.neq(intV ar[ 1 ] , intV ar[2 ])); pb.post(pb.neq(intV ar[ 1 ] , intV ar[4 ])); pb.post(pb .neq(intV ar[2], intV ar[3 ])); pb.post(pb.neq(intV ar[ 2 ] , intVar[4 ])); pb.post(pb.neq(intV ar[ 2 ] , intV ar[5 ]));

//gen era te so lver so lver = pb.getSolverO ;

//o b ta in a l l so lu tion s p b .so lv e A llO ;

//m -Nbsolutions i s the number of so lu tion s m_NbSolutions = so lv e r .getSeaxchSolver( ) . so lu tio n s . s i z e ();

63


bas,-,d (Temporal) CSP Soler

Fie Help

rN—e—Ou Olson 1 Sere i1 • OCL Doserbalon ; Constraint al*

CSP Description

Variable Number 6 I Cello id Humber

Domain {red, blue,greern I Left to MO

c contextVarsill iiir Name= A Dornnin = (red, blue, green) Value =: red

contexlVars[211nv: Name= Domain = (red. blue, green)

11 Value = red

9 contextVars[31 Name=

-1 Domain= (red, blue, green) : Value= red

- context Vars141inv:

4 Name= Domain= (red, blue, green)

I! value= red cordextVarslq inn:

Name= Domain= (red, blue, green;

red

f Show Constraint Dated re; CSP TOW :Show Detail Domain

(red, blue, green)

, 27 0z 36

X

(red, bl

green

Solution(s) 1/12 : Venally. green Vars[2]= blue Vamp] - red Vars[4]. blue Vars151= green Vars[6] = green

(red, blue, green)

blue

(red, blue, green)

(red, blue, green)

green

green

1.11T115c-

Fig

ure

6.7:

3-c

olou

ring

pro

blem

scr

een

shot

U M L - b a s e d / T e m p o r a l ) C 5 P S o l d e rFile Help

rw ewl Open ; T sa w l j | OCL DescripHotT l Constraint Graph l i | Ren M Show Constraint DetaS • CSP C TCSP Q Show Detai Domain

CSP Description

I Constraint Number 1

Domain [{red, blue,green) iLert to Right

Gpnenrtfe CSP Specification . |

&B®o context CSP inv:Name = Map Coloring Problem "1

.3 \ l ,r> ■1j

iSo!utionType = AliSolutfons|Tlrneljinitecl = 0I f contextVars[1)inv: a»Name = ADomain = {red, blue, green)Value = redf context Vars[2) inv:Name = B

s Domain = {red. blue, green} _lvalue = redf contextVars[3) Inv:Name = CDomain = {red. blue, green} :

:Vaiue = red |f context¥arsl4}mv: ■Name = D ;

lo o m am s {red, blue, green}Value = red? contextVars[5) irtv:Name = E !D om ains {red, blue, green} iVaiue = red *

Constraint Network

{red, b lue , g reen )

{red,{red. b lue, g reen )

A b lue , g reen}

{red. b lu e , g reen}

E

g re e n

Previous

Ow80>o>i- toCQ

bO

.5*n

o01CO

I>CO

oiH3.SP

CO

Solution(s) 1/12 : Vars[1]= green Vars[2]= blue Vars[3] = red Vars[4]= blue Vars[5]= green Vars[8]* green

Rep

rodu

ced

with

pe

rmis

sion

of

the

copy

right

ow

ner.

Furth

er

repr

oduc

tion

proh

ibite

d w

ithou

t pe

rmis

sion

.


Example 6.2. We describe and solve the time scheduling problem introduced in Section

3.4.2 with the UML-based Solver. Following the steps above, the TCSP option is chosen

first. After filling in the TCSP description, according to the Example 4.4, the constraint

graph and a complete solution are guaranteed. A possible result is shown in Figure 6.8.

65



E xam ple 6.2. We describe and solve the time scheduling problem introduced in Section

3.4.2 with the UML-based Solver. Following the steps above, the TCSP option is chosen

first. After filling in the TCSP description, according to the Example 4.4, the constraint

graph and a complete solution are guaranteed. A possible result is shown in Figure 6.8.

65


- 1.1t1,i• based !Temporal] CS? Seiner

File Help

New Open. -•• 11 ! OCL Description rConstraint Graphi 1Vertex Consistent • 11 Share Constraint Detail 0 CSP 7CSP 0Show Detail Domain

Variable Number

mime I[:05.10.11

TCSP Description

;Lett to Riot*

Generate TCSP SPersT

corttexITCSE irH Name now

SolutionType = OneSolution TmeLimiteci= '0 O context Erents[1] inv.

Name = PO Domain = 10; 851

II Step= ,1 Duration= 10

iValue= [0,10] 19 context Events[2] inv: Name= P1 Domain= [0, 85]

I Step= i i Duration= 10

Value= [0, 101 o context Everite[311m,

• Name= P2 , Domain= a 85]

'f Step= 1 II Duration= 6 I Value = 051 1 p context Events[4] irm

Name=

[0.85,10,1]

[0,101

Result 1 : Vars[1] = [0,10] V pi- ttimi v raj. sj Varela] e [17,221 Vara [5] a [23,613]

Constraint Network

[0,85,10,1i

[0,85,5,1] 10,85,45,1]

[17,22] 123,681

Rep

rodu

ced

with

per

mis

sion

of t

he c

opyr

ight

ow

ner.

F

urt

her

repr

oduc

tion

proh

ibite

d w

ithout

perm

issi

on.

Figu

re 6

.8:

Tim

e sc

hedu

ling

prob

lem

scr

een

shot

Rep

rodu

ced

with

per

mis

sion

of t

he c

opyr

ight

ow

ner.

Fur

ther

rep

rodu

ctio

n pr

ohib

ited

with

out p

erm

issi

on.

6.2.3 N-queens problem

Example 6.3. Another example is the N-queens problem. Given any integer N, the problem

is to place N queens on N distinct squares in an N x N chess board, satisfying the constraints

that no two queens should threaten each other (that is, no two queens can be placed on the

same row, same column, and same diagonal). The OCL specification of N-queens is shown

in Table 6.2.

Table 6.2: N-queens OCL specification

context CSP inv: Name = "N-queens problem" VarNum = N ConNum = 3 TimeLimited = 0 Solution Type = AllSolutions

context Vars[] inv: Name = "queen 1" Domain = [1, N] Value = 1

context Vars[] inv: Name = "queen 2" Domain = [1, N] Value = 1

.... context Vars[N] inv:

Name = "queen n" Domain = [1, N] Value = 1

context Cons [1] inv: Name = "cl" Vars -4 forall(Vars[i],VarsUJI i <> j imples Vars[i] <> Vars[j])

context Cons[2] inv: Name = "c2" Vars--4orall( Vars[i],Vars Di' i <> j imples Vars[i] - Vars[j] <> i - j)

context Cons [3] inv: Name = "c3" Vars—>forall( Vars[i],Vars[j]l i <> j imples Vars[i] - Vars[j] <> j - i)

Here, we assume N is 4, and we use the UML-based solver to solve this CSP problem.

There are a total of two solutions for the 4-queens problem, and one possible solution is

shown in Figure 6.9.

67


6.2.3 N-queens problem

E xam ple 6.3. Another example is the N-queens problem. Given any integer N, the problem

is to place N queens on N distinct squares in an N xN chess board, satisfying the constraints

tha t no two queens should threaten each other (that is, no two queens can be placed on the

same row, same column, and same diagonal). The OCL specification of N-queens is shown

in Table 6.2.

____________________Table 6.2: N-queens OCL specification____________________

context CSP inv:Name = ” N-queens problem”VarNum — N ConNum = 3 TimeLimited = 0 SolutionType = AllSolutions

context Vars[l] inv:Name = “queen 1”Domain = [1, N]Value = 1

context Vars[2] inv:Name = “queen 2”Domain = [1, N]Value = 1

context Vars[N] inv:Name = “queen n”Domain = [1, N]Value = 1

context Cons[ 1] inv:Name = “c l”Vara—>forall( Vars[i], Varsjj]| i <> j imples Vars[i] <> Vars[j])

context Cons [2] inv:Name = “c2”Kars -s-forall ( Vars[i], Vars[j] j i <> j imples Vars[i] - Vars[j] <> i - j)

context Cons[3] inv:Name = “c3”Vars ̂ for all ( Vars [i], Vars [j] | i <> j imples Vars [i] - Vars[j] <> j - i)

Here, we assume N is 4, and we use the UML-based solver to solve this CSP problem.

There are a total of two solutions for the 4-queens problem, and one possible solution is

shown in Figure 6.9.

67


-based(Temporal} CSP Sta(ke,

File Help

Nev., r Mao sPve OCL Desertinion Constraint Graph Run ❑ Snow Csnstraint Detain CSP C TCSP snow Detail Domain

Variable Nunber

CSP Description

14

Domain .41

Constraint I.

[Left to Paprit

Generate CSP. Specification

; I I context CSP Name= .1-aoaenx n 'Intern

I SolutioraYpe= NISolutions TirneLimiteil = 0

contextVars[t] inn/ Name= nt

:Domain = [1,4] Value= 1

contextVars[2j bur :1•Flame = 11 Domain= I,,41 1 Value =

context Varsplinv: Name = n3 Domain = 11,41 Value = 1

contextVars[a] irrr Name = 04 Domain =

1 Value xx U1 1 conisOConsitiiiii.

'Name= Consul= Vacs-, f,

;q context Conspl inv: rv.traN,Jarsfill i >j imples

Constraint Network

[1 Al 11 .4)

-. 1111 04 1000.... 21

11.41 11,41

X 3 1

511 .7 4 41 110)523

Prevstin, Next

seiution(s) : Vars[1] = 3 [2] = 1 V [3]. 4 Vars[4] = 2

Fig

ure

6.9

: 4-

quee

ns

scre

en s

hot

Rep

rodu

ced

with

per

mis

sion

of t

he c

opyr

ight

ow

ner.

F

urth

er re

prod

uctio

n pr

ohib

ited

with

out

perm

issi

on.

Figu

re 6

.9:

4-qu

eens

scr

een

shot

68

Rep

rodu

ced

with

per

mis

sion

of t

he c

opyr

ight

ow

ner.

Fur

ther

rep

rodu

ctio

n pr

ohib

ited

with

out

perm

issi

on.

6.2.4 Benchmark

Table 6.3 reports the time taken by solving some combinatorial problems. The problems

have the different variable numbers and different constraint numbers. The goals are obtain

a complete solution. Through the results in table 6.3, we find that it takes some time when

the tool analyzes user's descriptions. But with the variables and constraints increasing, the

performance in the analyzing time is very good. The variety of the analyzing time is tiny.

Example Constraint Variable Code Generation Solution Map Coloring Problem 6 8 312ms 12ms Time Scheduling Problem 5 4 328ms 15ms 4-Queens 4 8 317ms 32ms 8-Queens 8 16 320 62ms 32-Queens 32 64 338ms 22156ms Map Coloring Problem 100 400 337 16

Table 6.3: Time taken for solving combinatorial problems

6.3 Conclusion

In this chapter, we have presented an assistant tool UML-based solver for describing and

solving any CSP and TCSP. We have extended OCL to be able to express the very complex

CSP applications. Currently we have improved the tool to describe and solve temporal

CSPs in which domains are time space described by the SOPO structure and constraints

are allowed Allen logic relations. The map colouring problem, time scheduling problem and

N-queens problem are used as case studies, in order to demonstrate how CSPs and TCSPs

are described and solved using the UML-based solver.

69


6.2.4 Benchmark

Table 6.3 reports the time taken by solving some combinatorial problems. The problems

have the different variable numbers and different constraint numbers. The goals are obtain

a complete solution. Through the results in table 6.3, we find that it takes some time when

the tool analyzes user’s descriptions. But with the variables and constraints increasing, the

performance in the analyzing time is very good. The variety of the analyzing time is tiny.

Example Constraint Variable Code Generation SolutionMap Coloring Problem 6 8 312ms 12msTime Scheduling Problem 5 4 328ms 15ms4-Queens 4 8 317ms 32ms8-Queens 8 16 320 62ms32-Queens 32 64 338ms 22156msMap Coloring Problem 100 400 337 16

Table 6.3: Time taken for solving combinatorial problems

6.3 Conclusion

In this chapter, we have presented an assistant tool UML-based solver for describing and

solving any CSP and TCSP. We have extended OCL to be able to express the very complex

CSP applications. Currently we have improved the tool to describe and solve temporal

CSPs in which domains are time space described by the SOPO structure and constraints

are allowed Allen logic relations. The map colouring problem, time scheduling problem and

N-queens problem are used as case studies, in order to demonstrate how CSPs and TCSPs

are described and solved using the UML-based solver.

69


7. CONCLUSIONS AND PROSPECTS This chapter reviews the objectives of this thesis, lists the results that we have successfully

obtained, and makes few plans for future work.

7.1 Contribution

In this work, we focus on describing and solving real-world combinatorial problems.

End-users are developers who lack operational research and AI foundations and solving al-

gorithms, and have to design, model and solve combinatorial problems. One way is to use

formal languages to describe these problems and then to generate the solutions. However,

there are several challenges in applying these methods. First, the chosen formal language

should be widely popular and known by most developers. Second, models and solutions

should use flexibility and maintainability development techniques. Thus, users can simply

extend and enhance them. Finally, users do not have to know (temporal) CSP solving

techniques and programming languages. The solutions are generated by the descriptions

automatically. This thesis addresses these issues by choosing a specification language, de-

veloping (temporal) CSP descriptions, and automatically generating solutions from these

descriptions. The contributions of this thesis are summarized below.

• Provide a systematic development methodology for CSP/TCSP descriptions in an

object-oriented way. UML is a popular object-oriented design and development lan-

guage. OCL, a part of UML, describes constraints of UML models. So, in this work, we

have developed a generic CSP/TCSP framework with UML and OCL. This framework

helps users to analyze and model their CSPs/TCSPs, and then helps users to describe

their CSPs/TCSPs with OCL.

• Minimize OCL constraint expressions and extend OCL keywords for CSP/TCSP speci-

fications. It is not meaningful if an OCL description does not depend on an UML model.

In this thesis, CSP/TCSP descriptions depend on the generic CSP/TCSP framework.

By using the OCL extensions to represent variables, domains, constraints, and solution

rules and binding OCL constraint expressions with these keywords, CSP/TCSP can

be described clearly and understood easily.

70


7 CONCLUSIONS AND PROSPECTSThis chapter reviews the objectives of this thesis, lists the results tha t we have successfully-

obtained, and makes few plans for future work.

7.1 Contribution

In this work, we focus on describing and solving real-world combinatorial problems.

End-users are developers who lack operational research and AI foundations and solving al

gorithms, and have to design, model and solve combinatorial problems. One way is to use

formal languages to describe these problems and then to generate the solutions. However,

there are several challenges in applying these methods. First, the chosen formal language

should be widely popular and known by most developers. Second, models and solutions

should use flexibility and maintainability development techniques. Thus, users can simply

extend and enhance them. Finally, users do not have to know (temporal) CSP solving

techniques and programming languages. The solutions are generated by the descriptions

automatically. This thesis addresses these issues by choosing a specification language, de

veloping (temporal) CSP descriptions, and automatically generating solutions from these

descriptions. The contributions of this thesis are summarized below.

• Provide a systematic development methodology for CSP/TCSP descriptions in an

object-oriented way. UML is a popular object-oriented design and development lan

guage. OCL, a part of UML, describes constraints of UML models. So, in this work, we

have developed a generic CSP/TCSP framework with UML and OCL. This framework

helps users to analyze and model their CSPs/TCSPs, and then helps users to describe

their CSPs/TCSPs with OCL.

• Minimize OCL constraint expressions and extend OCL keywords for CSP/TCSP speci

fications. It is not meaningful if an OCL description does not depend on an UML model.

In this thesis, CSP/TCSP descriptions depend on the generic CSP/TCSP framework.

By using the OCL extensions to represent variables, domains, constraints, and solution

rules and binding OCL constraint expressions with these keywords, CSP/TCSP can

be described clearly and understood easily.

70


• Provide a CSP/TCSP template to facilitate the transformation of CSP/TCSP require-

ments into a CSP/TCSP, comprising algorithms, a list of variables with corresponding

domains, and initial values and n-ary constraints between variables.

• Obtain solutions from CSP/TCSP descriptions automatically. By analyzing solution

rules, algorithms are chosen automatically. Then, the generic CSP/TCSP model trans-

forms CSP/TCSP descriptions using constraint class libraries. Finally, solutions are

given to users.

• Implement a novel GUI-based tool to assist users describing CSPs/TCSPs and obtain-

ing solutions. By choosing options and filling in some basic information, CSP/TCSP

descriptions according to the CSP and TCSP templates are generated automatically.

Visual and text solutions are shown to users.

7.2 Future work

In this work, we have provided two frameworks and OCL templates to describe and solve

combinatorial problems. We have also implemented a novel tool that assists the description

and solving of CSP/TCSP based on the generic CSP/TCSP framework. The following lists

the features that will make the tool more powerful and flexible.

• Extending the solution rule keywords. The solution rules can be described by key-

words "TimeLimited" and "SolutionType." Some features of solution rules are not

considered in this work, but it is really important in real-world applications, such as in

determining which constraints are more important, and the value order of a variable's

domains. So, incorporating these features and providing more preferences will improve

the applicability of the tool.

• Extending the OCL functions. Through these extensions, users can describe their prob-

lems more conveniently. For example, we can use the extending function "Vars— >A11Diff0"

to represent that all the variables have different values.

• Extending the algorithms of constraint class libraries. With the different solution rules,

the tool should solve problems with different algorithms. However, Choco just provides

71


• Provide a CSP/TCSP template to facilitate the transformation of CSP/TCSP require

ments into a CSP/TCSP, comprising algorithms, a list of variables with corresponding

domains, and initial values and n-ary constraints between variables.

• Obtain solutions from CSP/TCSP descriptions automatically. By analyzing solution

rules, algorithms are chosen automatically. Then, the generic CSP/TCSP model trans

forms CSP/TCSP descriptions using constraint class libraries. Finally, solutions are

given to users.

• Implement a novel GUI-based tool to assist users describing CSPs/TCSPs and obtain

ing solutions. By choosing options and filling in some basic information, CSP/TCSP

descriptions according to the CSP and TCSP templates are generated automatically.

Visual and text solutions are shown to users.

7.2 Future work

In this work, we have provided two frameworks and OCL templates to describe and solve

combinatorial problems. We have also implemented a novel tool tha t assists the description

and solving of CSP/TCSP based on the generic CSP/TCSP framework. The following lists

the features that will make the tool more powerful and flexible.

• Extending the solution rule keywords. The solution rules can be described by key

words “TimeLimited” and “SolutionType.” Some features of solution rules are not

considered in this work, but it is really important in real-world applications, such as in

determining which constraints are more important, and the value order of a variable’s

domains. So, incorporating these features and providing more preferences will improve

the applicability of the tool.

• Extending the OCL functions. Through these extensions, users can describe their prob

lems more conveniently. For example, we can use the extending function “Vars— >AllDiff()”

to represent that all the variables have different values.

• Extending the algorithms of constraint class libraries. With the different solution rules,

the tool should solve problems with different algorithms. However, Choco just provides

71


some basic algorithms and does not support temporal CSP algorithms. The generated

Choco code from OCL descriptions is not optimum and not complete. Hence, we will

provide more and powerful algorithms in the future, such as approximation techniques,

which are very fast to obtain good solutions.

• Developing an AUML-based tool to describe and solve CSP/TCSP with distributed

CSP/TCSP techniques. In this thesis, we provide a generic distributed CSP/TCSP

framework and OCL extensions to describe complex CSPs/TCSPs, but we do not

implement the code to support them. In the future, the supporting tool will be devel-

oped and a friendly graphical user interface can be provided for specifying distributed

CSPs/TCSPs. In addition, constraint graphs and solutions are still shown in this tool.

However, users have many choices to show constraint graphs and solutions, such as

showing appointed agents, simply agent constraint graphs with no agent details and

so on.

72


some basic algorithms and does not support temporal CSP algorithms. The generated

Choco code from OCL descriptions is not optimum and not complete. Hence, we will

provide more and powerful algorithms in the future, such as approximation techniques,

which are very fast to obtain good solutions.

• Developing an AUML-based tool to describe and solve CSP/TCSP with distributed

CSP/TCSP techniques. In this thesis, we provide a generic distributed CSP/TCSP

framework and OCL extensions to describe complex CSPs/TCSPs, but we do not

implement the code to support them. In the future, the supporting tool will be devel

oped and a friendly graphical user interface can be provided for specifying distributed

CSPs/TCSPs. In addition, constraint graphs and solutions are still shown in this tool.

However, users have many choices to show constraint graphs and solutions, such as

showing appointed agents, simply agent constraint graphs with no agent details and

so on.

72


Bibliography

[1] J. F. Allen. Towards a general theory of action and time. Artif. Intell., 23(2):123-154,

1984.

[2] F. Bacchus and P. van Beek. On the conversion between non-binary constraint

satisfaction problems. In AAAI '98/IAAI '98: Proceedings of the fifteenth

national/tenth conference on Artificial intelligence/Innovative applications of artificial

intelligence, pages 311-318, Menlo Park, CA, USA, 1998. American Association for

Artificial Intelligence.

[3] R. Bartk. Constraint programming: What is behind? In Proceedings of CPDC99

Workshop, pages 7-15, 69-74, 1999.

[4] R. Bartk. Constraint-based scheduling: An introduction for newcomers. In Intelligent

Manufacturing Systems, pages 69-74. IFAC Publications, Elsevier Science, 2003.

[5] B. Bauer. Uml classes diagrams and agent-based systems. In AGENTS '01:

Proceedings of the fifth international conference on Autonomous agents, pages

104-105, New York, NY, USA, 2001. ACM Press.

[6] B. Bauer, J. P. Muller, and J. Odell. An extension of uml by protocols for multiagent

interaction. In ICMAS '00: Proceedings of the Fourth International Conference on

MultiAgent Systems (ICMAS-2000), page 207, Washington, DC, USA, 2000. IEEE

Computer Society.

[7] B. Bauer, J. P. Muller, and J. Odell. Agent uml: A formalism for specifying

multiagent interaction. pages 91-103, 2001.

[8] C. Bernon, M. Cossentino, and J. Pay. Agent-oriented software engineering. Knowl.

Eng. Rev., 20(2):99-116, 2005.

73


Bibliography

[1] J. F. Allen. Towards a general theory of action and time. Artif. Intell., 23(2):123-154,

1984.

[2] F. Bacchus and P. van Beek. On the conversion between non-binary constraint

satisfaction problems. In A A A I ’98/IA A I ’98: Proceedings of the fifteenth

national/tenth conference on Artificial intelligence/innovative applications o f artificial

intelligence, pages 311-318, Menlo Park, CA, USA, 1998. American Association for

Artificial Intelligence.

[3] R. Bartk. Constraint programming: W hat is behind? In Proceedings of CPDC99

Workshop, pages 7-15, 69-74, 1999.

[4] R. Bartk. Constraint-based scheduling: An introduction for newcomers. In Intelligent

Manufacturing Systems, pages 69-74. IFAC Publications, Elsevier Science, 2003.

[5] B. Bauer. Uml classes diagrams and agent-based systems. In AG ENTS ’01:

Proceedings of the fifth international conference on Autonomous agents, pages


[6] B. Bauer, J. P. Muller, and J. Odell. An extension of uml by protocols for multiagent

interaction. In ICM AS ’00: Proceedings of the Fourth International Conference on

MultiAgent Systems (ICMAS-2000), page 207, Washington, DC, USA, 2000. IEEE

Computer Society.

[7] B. Bauer, J. P. Muller, and J. Odell. Agent uml: A formalism for specifying

multiagent interaction, pages 91-103, 2001.

[8] C. Bernon, M. Cossentino, and J. Pav. Agent-oriented software engineering. Knouil.

Eng. Rev., 20(2):99-116, 2005.

73


[9] C. Bessi, A. Maestre, and P. Meseguer. Distributed dynamic backtracking. In CP '01:

Proceedings of the 7th International Conference on Principles and Practice of

Constraint Programming, page 772, London, UK, 2001. Springer-Verlag.

[10] E. J. Braude. Software engineering: An object-oriented perpective. page pp21, 2000.

[11] P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia, and J. Mylopoulos. Tropos: An

agent-oriented software development methodology. Autonomous Agents and

Multi-Agent Systems, 8(3):203-236, 2004.

[12] Choco. Java constraint class library, http://choco.sourceforge.net/.

[13] H. W. Chun. A methodology for object-oriented constraint programming. In APSEC

'97 and ICSC '97, pages 116-122, 1997.

[14] Java Cream. Java constraint class library, http://bach.istc.kobe-u.ac.jp/cream/.

[15] R. Dechter. Constraint Processing. Morgan Kaufmann, 2003.

[16] R. Dechter, I. Meiri, and J. Pearl. Temporal constraint networks. 1991.

[17] H. Ehrig, F. Orejas, and J. Padberg. Relevance, integration and classification of

specification formalisms and formal specification techniques. Proc. FORMS'99, 1999.

[18] S. Flake. Towards the completion of the formal semantics of ocl 2.0. In ACSC '04:

Proceedings of the 27th Australasian conference on Computer science, pages 73-82,

Darlinghurst, Australia, Australia, 2004. Australian Computer Society, Inc.

[19] M. Fowler. Uml distilled: A brief guide to the standard object modeling language. 3,

2003.

[20] E. C. Freuder. In pursuit of the holy grail. Constraints, 2(1):57-61, 1997.

[21] M. Glinz. Problems and deficiencies of uml as a requirements specification language. In

IWSSD '00: Proceedings of the 10th International Workshop on Software Specification

and Design, page 11, Washington, DC, USA, 2000. IEEE Computer Society.

74


[9] C. Bessi, A. Maestre, and P. Meseguer. Distributed dynamic backtracking. In CP ’01:

Proceedings of the 7th International Conference on Principles and Practice of

Constraint Programming, page 772, London, UK, 2001. Springer-Verlag.

[10] E. J. Braude. Software engineering: An object-oriented perpective. page pp21, 2000.

[11] P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia, and J. Mylopoulos. Tropos: An

agent-oriented software development methodology. Autonomous Agents and

Multi-Agent Systems, 8(3):203-236, 2004.

[12] Choco. Java constraint class library, http://choco.sourceforge.net/.

[13] H. W. Chun. A methodology for object-oriented constraint programming. In APSEC

’97 and ICSC ’97, pages 116-122, 1997.

[14] Java Cream. Java constraint class library, http://bach.istc.kobe-u.ac.jp/cream /.

[15] R. Dechter. Constraint Processing. Morgan Kaufmann, 2003.

[16] R. Dechter, I. Meiri, and J. Pearl. Temporal constraint networks. 1991.

[17] H. Ehrig, F. Orejas, and J. Padberg. Relevance, integration and classification of

specification formalisms and formal specification techniques. Proc. FORM S’99, 1999.

[18] S. Flake. Towards the completion of the formal semantics of ocl 2.0. In ACSC ’04:

Proceedings of the 27th Australasian conference on Computer science, pages 73-82,

Darlinghurst, Australia, Australia, 2004. Australian Computer Society, Inc.

[19] M. Fowler. Uml distilled: A brief guide to the standard object modeling language. 3,

2003.

[20] E. C. Freuder. In pursuit of the holy grail. Constraints, 2(1):57—61, 1997.

[21] M. Glinz. Problems and deficiencies of uml as a requirements specification language. In

IWSSD ’00: Proceedings of the 10th International Workshop on Software Specification

and Design, page 11, Washington, DC, USA, 2000. IEEE Computer Society.

74


http://choco.sourceforge.net/

http://bach.istc.kobe-u.ac.jp/cream/

[22] P Van Hentenryck. Constraint Satisfaction in Logic Programming. The MIT Press,

1989.

[23] http://www.math.gatech.edu/ trotter/Section6 Coloring.htm. 2003.

[24] M.N. Huhns and D.M. Bridgeland. Multiagent truth maintenance. In IEEE Trans.

Sys., Man, and Cybernetics, pages 21(6):1437— 1445, 1991.

[25] D. J, A. Schleicher, and B. Westfechtel. Using urn! for software process modeling. In

ESEC/FSE-7: Proceedings of the 7th European software engineering conference held

jointly with the 7th ACM SIGSOFT international symposium on Foundations of

software engineering, pages 91-108, London, UK, 1999. Springer-Verlag.

[26] N. Klarlund, J. Koistinen, and M. I. Schwartzbach. Formal design constraints. In

OOPSLA '96: Proceedings of the 11th ACM SIGPLAN conference on Object-oriented

programming, systems, languages, and applications, pages 370-383, New York, NY,

USA, 1996. ACM Press.

[27] V. Kumar. Algorithms for constraint-satisfication problems: A survey. 1992.

[28] A. K. Mackworth. Consistency in networks of relations. Technical report, Vancouver,

BC, Canada, Canada, 1975.

[29] A. K. Mackworth and E. C. Freuder. The complexity of some polynomial network

consistency algorithms for constraint satisfaction problems. Artif. Intell., 25(1):65-74,

1985.

[30] S. Meyers, C. K. Duby, and S. P. Reiss. Constraining the structure and style of

object-oriented programs. Technical report, Providence, RI, USA, 1993.

[31] Z. Michalewicz and D. B. Fogel. How to Solve It: Modern Heuristics. Springer-Verlag,

2000.

[32] M. Mouhoub. Reasoning with numeric and symbolic time information. Artif. Intell.

Rev., 21(1):25-56, 2004.

75


[22] P Van Hentenryck. Constraint Satisfaction in Logic Programming. The MIT Press,

1989.

[23] http://www.m ath.gatech.edu/ trotter/Section6 Coloring.htm. 2003.

[24] M.N. Huhns and D.M. Bridgeland. Multiagent tru th maintenance. In IEEE Trans.

Sys., Man, and Cybernetics, pages 21 (6) :1437— 1445, 1991.

[25] D. J, A. Schleicher, and B. Westfechtel. Using uml for software process modeling. In

ESEC/FSE-7: Proceedings o f the 7th European software engineering conference held

jointly with the 7th ACM SIGSOFT international symposium on Foundations of

software engineering, pages 91-108, London, UK, 1999. Springer-Verlag.

[26] N. Klarlund, J. Koistinen, and M. I. Schwartzbach. Formal design constraints. In

OOPSLA ’96: Proceedings o f the 11th ACM SIG PLAN conference on Object-oriented

programming, systems, languages, and applications, pages 370-383, New York, NY,

USA, 1996. ACM Press.

[27] V. Kumar. Algorithms for constraint-satisfication problems: A survey. 1992.

[28] A. K. Mackworth. Consistency in networks of relations. Technical report, Vancouver,

BC, Canada, Canada, 1975.

[29] A. K. Mackworth and E. C. Freuder. The complexity of some polynomial network

consistency algorithms for constraint satisfaction problems. Artif. Intell., 25(1):65—74,

1985.

[30] S. Meyers, C. K. Duby, and S. P. Reiss. Constraining the structure and style of

object-oriented programs. Technical report, Providence, RI, USA, 1993.

[31] Z. Michalewicz and D. B. Fogel. How to Solve It: Modem Heuristics. Springer-Verlag,

2000 .

[32] M. Mouhoub. Reasoning with numeric and symbolic time information. Artif. Intell.

Rev., 21 (1):25—56, 2004.

75


http://www.math.gatech.edu/

[33] J. F. Rit. Propagating temporal constraints for scheduling. In Proceedings of

AAAi-86, pages 383-388. Morgan Kaufmann.

[34] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and A. W. Lorensen.

Object-oriented modeling and design. 1991.

[35] S. Russell and P. Norvig. Artificial intelligence: A modern approach. 2, 2005.

[36] E. Schwalb and L. Vila. Temporal constraints: A survey. Constraints, 3(2-3):129-149,

1998.

[37] ILog Solver. http://www.ilog.com/products/solver/.

[38] E.P.K. Tsang. Foundations of Constraint Satisfaction. Academic Press, London, 1995.

[39] T. M. van Engers, R. Gerrits, M. Boekenoogen, E. Glasse, and P. Kordelaar. Power:

using uml/ocl for modeling legislation - an application report. In ICAIL '01:

Proceedings of the 8th international conference on Artificial intelligence and law, pages


[40] B. Verheecke and R. V. D. Straeten. Specifying and implementing the operational use

of constraints in object-oriented applications. In CRPIT '02: Proceedings of the

Fortieth International Conference on Tools Pacific, pages 23-32, Darlinghurst,

Australia, Australia, 2002. Australian Computer Society, Inc.

[41] J. Warmer and A. Kleppe. The object constraint language. 2, 2003.

[42] G. Wei. Agent orientation in software engineering. Knowl. Eng. Rev., 16(4):349-373,

2001.

[43] M. Yokoo. Distributed constraint satisfaction problems: Founations of cooperation in

multi-agent systems. 2000.

[44] M. Yokoo and K. Hirayama. Algorithms for distributed constraint satisfaction: A

review. Autonomous Agents and Multi-Agent Systems, 3(2):185-207, 2000.

76


[33] J. F. Rit. Propagating temporal constraints for scheduling. In Proceedings of

AAAi-86, pages 383-388. Morgan Kaufmann.

[34] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and A. W. Lorensen.

Object-oriented modeling and design. 1991.

[35] S. Russell and P. Norvig. Artificial intelligence: A modern approach. 2, 2005.

[36] E. Schwalb and L. Vila. Temporal constraints: A survey. Constraints, 3(2-3): 129-149,

1998.

[37] ILog Solver, http://www.ilog.com/products/solver/.

[38] E.P.K. Tsang. Foundations of Constraint Satisfaction. Academic Press, London, 1995.

[39] T. M. van Engers, R. Gerrits, M. Boekenoogen, E. Glasse, and P. Kordelaar. Power:

using uml/ocl for modeling legislation - an application report. In ICAIL ’01:

Proceedings of the 8 th international conference on Artificial intelligence and law, pages


[40] B. Verheecke and R. V. D. Straeten. Specifying and implementing the operational use

of constraints in object-oriented applications. In CRPIT ’02: Proceedings of the

Fortieth International Conference on Tools Pacific, pages 23-32, Darlinghurst,

Australia, Australia, 2002. Australian Computer Society, Inc.

[41] J. Warmer and A. Kleppe. The object constraint language. 2, 2003.

[42] G. Wei. Agent orientation in software engineering. Knowl. Eng. Rev., 16(4):349-373,

2001 .

[43] M. Yokoo. Distributed constraint satisfaction problems: Founations of cooperation in

multi-agent systems. 2000.

[44] M. Yokoo and K. Hirayama. Algorithms for distributed constraint satisfaction: A

review. Autonomous Agents and Multi-Agent Systems, 3(2):185-207, 2000.

76


http://www.ilog.com/products/solver/

[45] W. Zhang and L. Wittenburg. Distributed breakout revisited. In Eighteenth national

conference on Artificial intelligence, pages 352-357, Menlo Park, CA, USA, 2002.

American Association for Artificial Intelligence.

77


[45] W. Zhang and L. Wittenburg. Distributed breakout revisited. In Eighteenth national

conference on Artificial intelligence, pages 352-357, Menlo Park, CA, USA, 2002.

American Association for Artificial Intelligence.

77


a uml-based solver tool for combinatorial problems

Documents