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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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.
UNIVERSITY OF REGINA
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
UNIVERSITY OF REGINA
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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.
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
which help users design and develop complex applications.
16
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
which help users design and develop complex applications.
16
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Figure 3.7: UML example with AUML
3.4 Examples
3.4.1 Map colouring problem
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
3.4.1 Map colouring problem
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 (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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Figure 3.8: 4-colouring
2
Figure 3.9: 3-colouring
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Figure 3.8: ^-colouring
1
Figure 3.9: 5-colouring
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
3 Agent3
2
Figure 3.11: Map colouring problem with distributed CSP
3.4.2 Time scheduling problem
3.4.2.1 Functional requirements
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Figure 3.11: Map colouring problem with distributed CSP
3.4.2 Time scheduling problem
3.4.2.1 Functional requirements
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
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
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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.
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.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• C S P an d so lu tion ru les. Variable number, constraint number, default domain, and
solution rules are entered first.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Domain = {red, blue, green}
Value = "red" -- initial colouring of B is red
context Vars[3] inv:
Name = "C" -- vertex C
Domain = {red, blue, green}
Value = "red" -- initial colouring of C is red
context Vars14 inv:
Name = "D" -- vertex D
Domain = {red, blue, green}
Value = "red" -- initial colouring of D is red
36
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
context Vars[2] inv:
Name = “B” — vertex B
Domain = {red, blue, green}
Value = “red” — initial colouring of B is red
context Vars[3] inv:
Name = “C” — vertex C
Domain = {red, blue, green}
Value = “red” — initial colouring of C is red
context Vars[4j inv:
Name = “D” — vertex D
Domain = {red, blue, green}
Value = “red” — initial colouring of D is red
36
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
context Vars[5] inv:
Name = "E" -- vertex E
Domain = {red, blue, green}
Value = "red" -- initial colouring of E is red
context Vars[6] inv:
Name = "F" -- vertex F
Domain = {red, blue, green}
Value = "red" -- initial colouring of F is red
context Cons[1] inv:
Name = "C1" <> B"
Vars[1] <> Vars[2]
context Cons[2] inv:
Name = "C2" --"A <> C"
Vars[1] <> Vars[3]
context Cons [3] inv:
Name = "C3" —"A <> D"
Vars[1] <> Vars[4]
context Cons[4] inv:
Name = "C4" --"B <> C"
Vars[2] <> Vars[3]
context Cons[5] inv:
Name = "C5" --"B <> E"
Vars[2] <> Vars[5]
context Cons [6] inv:
Name = "C6" --"C <> D"
Vars[3] <> Vars[4]
context Cons [7] inv:
Name = "C7" --"C <> E"
Vars[3] <> Vars[5]
context Cons[8] inv:
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
context Vars[5] inv:
Name = “E” — vertex E
Domain = {red, blue, green}
Value = “red” — initial colouring of E is red
context Vars[6] inv:
Name — “F” - vertex F
Domain = {red, blue, green}
Value = “red” -- initial colouring of F is red
context Cons[ 1] inv:
Name = “CV’ - “A <> B”
Ears[l] <> Vars [2]
context Cons[2] inv:
Name = “C2” - “A <> C”
Vars [ 1] <> Ears [3]
context Cons[3] inv:
Name = “C3” - “A <> D”
Ears[l] <> Ears [4]
context Cons[4] inv:
Name = “C4” - “B <> C”
Ears [2] <> Ears [3]
context Cons[5] inv:
Name = “C5” - “B <> E”
Ears [2] <> Ears [5]
context Cons[6] inv:
Name = “C6” ~ “C <> D”
Ears [3] <> Ears [4]
context Cons[7] inv:
Name = “C7” - “C <> E”
Ears [3] < > Ears [5]
context Cons[8] inv:
Name = “C8” - “A <> F”
Ears [3] <> Ears [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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
context Vars[1] inv:
Name = "Mike"
Domain = [0,10]
Value = 0
context Vars[2] inv:
Name = "Tom"
Domain = [0,10]
Value = 0
38
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
context Vars [3] inv:
Name = "Jack"
Domain = [0,10]
Value = 0
context Cons[1] inv:
Name = "cl"
Vars[1] + Vars[2] + Vars[3] = 10
context Cons[2] inv:
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-
piles the OCL description with a special constraint class library and automatically chooses
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
piles the OCL description with a special constraint class library and automatically chooses
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
4.2.2 OCL extensions
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.
context (Object) inv: (expressions)
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
4.2.2 OCL extensions
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
be true after the constraint has just ended. The syntax is given below.
context (Constraint Object)
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
solution rules are entered first.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
be true after the constraint has just ended. The syntax is given below.
context (Constraint Object)
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
solution rules are entered first.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
context Events[2] inv:
Name = "breakfast at home"; -- name of event 2
Domain = [0, 85]; -- event's domain
Duration = 10; -- duration of the event 2
Step = 1; -- step of the event 2
Value = [0, 10]; -- value of event 2
context Events[3] inv:
Name = "breakfast from store"; -- name of event 3
Domain = [0, 85]; -- event's domain
Duration = 5; -- Duration of the event 3
Step = 1; -- step of the event 3
Value = [0, 5]; -- value of event 3
context Events/.4J inv:
Name = "having a rest"; -- name of event 4
Domain = [0, 85]; -- event's domain
Duration = 5; -- duration of the event 4
Step = 1; -- step of the event 4
Value = [0, 5]; -- value of event 4
44
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Duration = 10; — duration of the event 2
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
Step = 1; -- step of the event 3
Value = [0, 5]; — value of event 3
con tex t Events[4] inv:
Name = “having a rest” ; — name of event 4
Domain = [0, 85]; -- event’s domain
Duration = 5; — duration of the event 4
Step = 1; — step of the event 4
Value = [0, 5]; — value of event 4
44
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
context Events[5] inv:
Name = "taking bus"; -- name of event 5
Domain = [0, 85]; -- event's domain
Duration = 45; -- durationof the event 5
Step = 1; -- step of the event 4
Value = [0, 45]; -- value of event 5
context Cons[1] inv:
-- after getting up, Tom has a breakfast at home
Events[1] P Events[2];
context Cons[2] inv:
-- after getting up, Tom has a breakfast from store
Events[1] S Events[3];
context Cons[3] inv:
-- have a rest after breakfast
(Events[2] P Events[4]) or (Events[3] P Events[4]);
context Cons [4] inv:
-- 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Step = 1; — step of the event 4
Value = [0, 45]; — value of 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
Events[4] P Events[5];
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 )
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
•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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• 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.
context (Object) inv: (expressions)
• 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.
context (Constraint Object)
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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:
context Agents[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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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: . ..
context Agents[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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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.
5.4.1 Map colouring problem
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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.
5.4.1 Map colouring problem
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
context Agents[1].Vars[2] inv: Name = Vertex B;
Domain = {red, blue, green}; Value = red; -- colour number of vertex B
context Agents[1].Vars[3] inv:
Name = Vertex C;
Domain = {red, blue, green};
Value = red; -- colour number of vertex C
context Agents[1].Vars[4] inv:
Name = Vertex D;
Domain = {red, blue, green};
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];
context Agents[1].Cons[2] inv:
-- There is an edge between vertices A and C
Vars [1] <> Vars[3];
context Agents[1].Cons[3] inv:
-- There is an edge between vertices A and D Vars[1] <> Vars[4];
context Agents[1].Cons[4] inv:
-- 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
Vars [3] <> Vars[4];
-- agent 1 description end
-- describe agent 2 context Agents[2]
-- give the name of Agent
Name = "a part of the graph"
Weight = 2; the agent's weight
-- 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
context Agents[2].Vars[1] inv:
Name = Vertex B; Domain = {red, blue, green};
53
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
— describe agent 2 context Agents[2]
— 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.
— describe v e r t ic e s , domains and in i t i a l values here context Agents[2 ] .Vars[1] inv:
Name = Vertex B;Domain = {red, b lue, green};
53
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Value = red; -- colour number of vertex B
context Agents[2].Vars[2] inv:
Name = Vertex C;
Domain = {red, blue, green};
Value = red; -- colour number of vertex C
context Agents[2].Vars[3] inv:
Name = Vertex E;
Domain = {red, blue, green};
Value = red; -- colour number of vertex E
describe inter-constraints here
context Agents[2].Cons[1] inv:
-- There is an edge between vertices B and C
Vars[1] <> Vars[2];
context Agents[2].Cons[2] inv:
-- There is an edge between vertices B and E
Vars [1] <> Vars[3];
context Agents[2].Cons[3] inv:
-- There is an edge between vertices C and E
Vars [2] <> Vars[3];
-- agent 2 description end
-- describe agent 3
context Agents[3]
-- give the name of Agent
Name = "a part of the graph"
Weight = 3; the agent's weight
-- 2 vertices
VarNum = 2;
-- 1 edges
ConNum = 1;
-- 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[3].Vars[1] inv:
Name = Vertex C; Domain = {red, blue, green};
Value = red; -- colour number of vertex C
context Agents[3].Vars[2] inv:
Name = Vertex F;
Domain = {red, blue, green};
Value = red; -- colour number of vertex F -- describe inter-constraints here
context Agents[3].Cons[1] inv:
-- There is an edge between vertices C and F
Vars[1] <> Vars[2];
54
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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];
— agent 2 d escrip tion end
— describe agent 3 context Agents[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 .
— describe v e r t ic e s , domains and in i t i a l values here context Agents[3 ] .Vars[1] inv:
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
-- agent 3 description end
-- 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]
context Actions[2] inv:
-- agent 1 and agent 2 share the vertex B.
Agents[1].Vars[3] = Agents[2].Vars[2]
context Actions[3] inv:
-- agent 1 and agent 3 share the vertex B.
Agents[1].Vars[3] = Agents[2].Vars[1] context Actions[4] inv:
-- agent 1 and agent 2 share the vertex B.
Agents[1].Vars[2] = Agents[2].Vars[1] -- agent constraint description end
5.4.2 Time scheduling problem
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]
-- give the name of Agent
Name = "a part of the graph" Weight = 1; the agent's weight -- 4 events EventNum = 4;
-- 3 constraint ConNum = 3;
55
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
— agent 3 d escrip tion end
— 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
5.4.2 Time scheduling problem
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;
— describe agent 1 context Agents[1]
— 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
-- 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].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;
Duration = 10; -- during time
Domain = [0,85]; -- domain of event 2
Step = 1;
Value = [0, 10];
context Agents[1].Events[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 inter-constraints 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 description end
-- describe agent 2
context Agents[2]
-- 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
— 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
— describe agent 2 context Agents[2]
— 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
context Agents [2] . Events [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] . Events [2] inv:
Name = taking a bus;
Duration = 45; -- during time
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] ;
-- agent 2 description end
-- 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
6.2.1 Map colouring problem
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
6.2.1 Map colouring problem
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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[2]));
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[3]));
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
.
6.2.2 Time scheduling problem
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
6.2.2 Time scheduling problem
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
- 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
-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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
• 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
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
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 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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[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
157-167, New York, NY, USA, 2001. ACM Press.
[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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[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
157-167, New York, NY, USA, 2001. ACM Press.
[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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
[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
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
Top Related