Δ Ι Π Λ Ω Μ ΑΤ Ι Κ Η Ε Ρ Γ Α Σ Ι Α

Transcript

1 Α Ρ Ι Σ Τ Ο Τ Ε Λ Ε Ι Ο Π Α Ν Ε Π Ι Σ Τ Η Μ Ι Ο Θ Ε Σ Σ Α Λ Ο Ν Ι Κ Η Σ ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΠΡΟΓΡΑΜΜΑ ΜΕΤΑΠΤΥΧΙΑΚΩΝ ΣΠΟΥΔΩΝ Δ Ι Π Λ Ω Μ ΑΤ Ι Κ Η Ε Ρ Γ Α Σ Ι Α ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ DEVELOPING A SYSTEM FOR VALIDATING PLANNING PROBLEMS VIA WEB SERVICES ΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ ΕΠΙΒΛΕΠΩΝ ΚΑΘΗΓΗΤΗΣ: ΔΗΜΗΤΡΙΟΣ ΒΡΑΚΑΣ, ΛΕΚΤΟΡΑΣ ΘΕΣΣΑΛΟΝΙΚΗ 2015

2

3 Π Ε Ρ Ι Λ Η Ψ Η Αντικείμενο της παρούσας εργασίας είναι η ανάπτυξη ενός συστήματος για τον έλεγχο επιλυσιμότητας προβλημάτων σχεδιασμού με την χρήση υπηρεσιών ιστού. Καθώς έχουν δημιουργηθεί και εκτενώς εξεταστεί διάφορα εργαλεία για την συγγραφή προβλημάτων σχεδιασμού γίνεται φανερό ότι εργαλεία που βοηθούν στον έλεγχο και την εύρεση λογικών σφαλμάτων των παραγόμενων προβλημάτων αποτελούν ένα ξεχωριστό πεδίο έρευνας στη περιοχή αυτή. Πιο συγκεκριμένα, με τις υπηρεσίες ιστού που δημιουργήσαμε καταφέραμε αρχικά να ανακαλύψουμε αν κάποιο πρόβλημα σχεδιασμού είναι επιλύσιμο και ως δεύτερο βήμα έγινε προσπάθεια να δώσουμε στο χρήστη την αιτία ή τις αιτίες που το πρόβλημα δεν είναι επιλύσιμο. Επιπρόσθετα, έγινε η σύνδεση του εργαλείου μας με το πρόγραμμα Vleppo που είναι ένα γραφικό περιβάλλον σχεδιασμού. Τέλος, πιστοποιήσαμε τα αποτελέσματα της ευχρηστίας του προγράμματος βάση πραγματικού προβλήματος που κλήθηκαν να λύσουν φοιτητές στα πλαίσια του μαθήματος της Τεχνητής Νοημοσύνης.

4

5 A B S T R A C T The main objective of this thesis is the development of a system that solves planning problems through the aid of a stand-alone web service. Since most planning-related tools are also well-tested, this is an indication that tools that focus on easing the process of writing and debugging planning problems are becoming another field of interest. To be more precise, through our web services we managed to determine if a planning problem is solvable and later present to the user of the service the cause (or causes) of the logical problem. Moreover, the service provides information to the already-existing graphical tool Vleppo. Finally, we validated our claims of ease of use against the results of survey that was conducted with the help of undergraduate students in the context of the Artifical Intelligence.

6

7 ΕΥΧΑΡΙΣΤΙΕΣ Ε Υ Χ Α Ρ Ι Σ Τ Ι Ε Σ Η εκπόνηση της εργασίας έγινε στο Εργαστήριο Λογικού Προγραμματισμού και Ευφυών Συστημάτων (LPIS group) του Τμήματος Πληροφορικής του Αριστοτέλειου Πανεπιστημίου Θεσσαλονίκης. Στην πραγματοποίηση αυτής της εργασίας συνέβαλλαν ορισμένοι άνθρωποι τους οποίους θα ήθελα να ευχαριστήσω. Αρχικά θα ήθελα να ευχαριστήσω τον κύριο Δημήτριο Βράκα, Λέκτορα του τμήματος Πληροφορικής του ΑΠΘ για την ανάθεση της εργασίας, τις συμβουλές, τις καθοδηγήσεις και την ευκαιρία που μου προσέφερε να ασχοληθώ με το συγκεκριμένο θέμα. Ακόμη αισθάνομαι την ανάγκη να ευχαριστήσω τον κ. Ιωάννη Βλαχάβα, διευθυντή του εργαστηρίου, για την παροχή του απαραίτητου εργαστηριακού εξοπλισμού αλλά και τα υπόλοιπα μέλη της ομάδας LPIS, για τη δημιουργία ευχάριστου και δημιουργικού κλίματος εργασίας μέσα στο εργαστήριο. Επίσης, θα ήθελα να ευχαριστήσω τον μεταπτυχιακό φοιτητή του τμήματος και φίλο Δημήτριο Γιουρούκη για τη συμβολή του στην εργασία, μέσα από την άψογη συνεργασία μας. Τέλος θα ήθελα να ευχαριστήσω τους γονείς μου για τη συνεχή στήριξη και την συμπαράσταση που μου προσφέρουν. 27/2/2015 Μωυσής Συμεωνίδης ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ VII

8

9 ΠΕΡΙΕΧΟΜΕΝΑ Π Ε Ρ Ι Ε Χ Ο Μ Ε Ν Α 1 ΕΙΣΑΓΩΓΉ ΣΧΕΔΙΑΣΜΟΣ ΕΝΕΡΓΕΙΩΝ ΚΑΙ ΥΠΗΡΕΣΙΕΣ ΙΣΤΟΥ ΣΧΕΔΙΑΣΜΟΣ ΕΝΕΡΓΕΙΩΝ ΑΥΤΟΜΑΤΟΠΟΙΗΜΈΝΟΣ ΣΧΕΔΙΑΣΜΌΣ ΙΣΤΟΡΙΚΉ ΑΝΑΔΡΟΜΉ ΕΠΊΛΥΣΗΣ ΠΡΟΒΛΗΜΆΤΩΝ ΣΧΕΔΙΑΣΜΟΎ ΤΟ ΜΟΝΤΈΛΟ STRIPS Η ΓΛΏΣΣΑ PDDL ΓΡΆΦΟΙ ΣΧΕΔΙΑΣΜΟΎ ΚΑΙ ΤΟ ΣΎΣΤΗΜΑ GRAPHPLAN ΥΠΗΡΕΣΙΕΣ ΙΣΤΟΥ - WEB SERVICES ΕΡΓΑΛΕΙΑ ΚΑΙ ΒΙΒΛΙΟΘΗΚΕΣ ΥΛΟΠΟΙΗΣΗΣ ΒΙΒΛΙΟΘΗΚΗ GSON ΠΑΡΆΔΕΙΓΜΑ ΜΕΤΑΤΡΟΠΉΣ ΑΠΌ ΑΝΤΙΚΕΊΜΕΝΟ JAVA ΣΕ JSON ΠΑΡΆΔΕΙΓΜΑ ΜΕΤΑΤΡΟΠΉΣ ΑΠΌ JSON ΣΕ ΑΝΤΙΚΕΊΜΕΝΟ JAVA ΒΙΒΛΙΟΘΗΚΗ PDDL4J ΥΛΟΠΟΙΗΣΗ ΤΟΥ WEB SERVICE ΥΠΗΡΕΣΙΑ ΕΥΡΕΣΗΣ ΔΥΝΑΜΙΚΩΝ ΚΑΙ ΣΤΑΤΙΚΩΝ ΓΕΓΟΝΟΤΩΝ ΑΛΓΟΡΙΘΜΟΣ ΕΥΡΕΣΗΣ ΔΥΝΑΜΙΚΩΝ ΚΑΙ ΣΤΑΤΙΚΩΝ ΓΕΓΟΝΟΤΩΝ ΥΛΟΠΟΙΗΣΗ ΑΛΓΟΡΙΘΜΟΥ JSON ΑΝΑΠΑΡΑΣΤΑΣΗ ΕΥΡΕΣΗ ΕΠΙΛΥΣΙΜΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΑΛΓΟΡΙΘΜΟΣ ΕΥΡΕΣΗΣ ΕΠΙΛΥΣΙΜΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΥΛΟΠΟΙΗΣΗ ΑΛΓΟΡΙΘΜΟΥ JSON ΑΝΑΠΑΡΑΣΤΑΣΗ ΑΞΙΟΛΟΓΗΣΗ ΑΠΟΤΕΛΕΣΜΑΤΩΝ ΣΥΝΔΕΣΗ ΜΕ ΤΟ VLEPPO ΠΑΡΑΔΕΙΓΜΑ ΕΡΓΑΣΙΑΣ ΣΤΑ ΠΛΑΙΣΙΑ ΤΟΥ ΜΑΘΗΜΑΤΟΣ ΤΕΧΝΗΤΗΣ ΝΟΗΜΟΣΥΝΗΣ ΠΕΡΙΓΡΑΦΉ ΠΡΟΒΛΉΜΑΤΟΣ ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ IX

10 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣ ΛΑΝΘΑΣΜΈΝΗ ΕΠΊΛΥΣΗ ΤΟΥ ΠΡΟΒΛΉΜΑΤΟΣ ΣΥΜΠΕΡΑΣΜΑΤΑ ΒΙΒΛΙΟΓΡΑΦΙΑ X ΥΠΗΡΕΣΙΕΣ ΙΣΤΟΥ ΣΕ ΠΕΡΙΒΑΛΛΟΝΤΑ ΔΙΑΧΥΤΗΣ ΝΟΗΜΟΣΥΝΗΣ

11 ΛΙΣΤΑ ΣΧΗΜΑΤΩΝ Λ Ι Σ Τ Α Σ Χ Η Μ Α Τ Ω Ν ΕΙΚΟΝΑ 1 ΙΣΤΟΡΙΚΗ ΠΕΡΙΟΔΟΙ ΜΕΘΟΔΩΝ ΕΠΙΛΥΣΗΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΕΙΚΟΝΑ 2 ΠΑΡΑΔΕΙΓΜΑ ΣΧΕΔΙΑΣΜΟΥ ΣΤΟ ΧΩΡΟ ΤΩΝ ΚΑΤΑΣΤΑΣΕΩΝ ΕΙΚΟΝΑ 3 ΠΑΡΑΔΕΙΓΜΑ ΤΟΥ ΚΟΣΜΟΥ ΤΩΝ ΚΥΒΩΝ ΕΙΚΟΝΑ 4 ΠΑΡΑΔΕΙΓΜΑ ΠΕΔΙΟΥ ΕΙΚΟΝΑ 5 ΠΑΡΑΔΕΙΓΜΑ ΠΡΟΒΛΗΜΑΤΟΣ ΕΙΚΟΝΑ 6 ΠΑΡΑΔΕΙΓΜΑ ΠΛΑΝΟΥ ΕΙΚΟΝΑ 7 ΠΑΡΑΔΕΙΓΜΑ ΓΡΑΦΟΥ ΣΧΕΔΙΑΣΜΟΥ ΕΙΚΟΝΑ 8 ΑΡΧΙΚΗ ΚΑΙ ΤΕΛΙΚΗ ΚΑΤΑΣΤΑΣΗ ΠΡΟΒΛΗΜΑΤΟΣ ΕΙΚΟΝΑ 9 ΠΑΡΑΔΕΙΓΜΑ ΓΡΑΦΟΥ ΣΧΕΔΙΑΣΜΟΥ ΤΟΥ GRAPHPLAN ΕΙΚΟΝΑ 10 ΠΑΡΑΔΕΙΓΜΑ ΕΥΡΕΣΗΣ ΠΛΑΝΟΥ ΕΚΤΕΛΕΣΗΣ ΣΤΟ GRAPHPLAN ΕΙΚΟΝΑ 11 ΤΥΠΟΙ ΑΜΟΙΒΑΙΩΝ ΑΠΟΚΛΕΙΣΜΩΝ ΕΝΕΡΓΕΙΩΝ ΕΙΚΟΝΑ 12 ΨΕΥΔΟΚΩΔΙΚΑΣ ΤΟΥ ΑΛΓΟΡΙΘΜΟΥ GRAPHPLAN ΕΙΚΟΝΑ 13 ΠΑΡΑΔΕΙΓΜΑ ΕΝΕΡΓΕΙΩΝ ΕΙΚΟΝΑ 14 ΠΑΡΑΔΕΙΓΜΑ ΕΠΙΚΟΙΝΩΝΙΑΣ ΥΠΗΡΕΣΙΑΣ ΙΣΤΟΥ ΜΕ ΤΟΝ ΠΕΛΑΤΗ ΤΗΣ ΥΠΗΡΕΣΙΑΣ ΕΙΚΟΝΑ 15 ΠΡΩΤΟΚΟΛΛΟ SOAP ΕΙΚΟΝΑ 16 ΠΑΡΑΔΕΙΓΜΑ RESTFUL ΥΠΗΡΕΣΙΑΣ ΙΣΤΟΥ ΕΙΚΟΝΑ 17 ΥΠΗΡΕΣΙΟΣΤΡΑΦΗΣ ΑΡΧΙΤΕΚΤΟΝΙΚΗ ΕΙΚΟΝΑ 18 ΚΛΑΣΗ DATAOBJECT ΓΙΑ ΤΟ ΠΑΡΑΔΕΙΓΜΑ ΧΡΗΣΗΣ ΤΗΣ ΒΙΒΛΙΟΘΗΚΗΣ GSON ΕΙΚΟΝΑ 19 ΠΑΡΑΔΕΙΓΜΑ ΚΩΔΙΚΑ ΓΙΑ ΠΑΡΑΓΩΓΗ JSON ΑΡΧΕΙΟΥ ΕΙΚΟΝΑ 20 ΠΑΡΑΔΕΙΓΜΑ ΚΩΔΙΚΑ ΓΙΑ ΔΗΜΙΟΥΡΓΙΑ ΑΝΤΙΚΕΙΜΕΝΟΥ ΑΠΟ JSON ΑΡΧΕΙΟΥ ΕΙΚΟΝΑ 21 ΠΑΡΑΔΕΙΓΜΑ ΧΡΗΣΗΣ ΤΗΣ ΒΙΒΛΙΟΘΗΚΗΣ PDDL4J ΕΙΚΟΝΑ 22 ΠΑΡΑΔΕΙΓΜΑ ΚΩΔΙΚΑ PHP ΤΗΣ ΒΙΒΛΙΟΘΗΚΗΣ WSDLCREATOR ΕΙΚΟΝΑ 23 ΠΑΡΑΔΕΙΓΜΑ ΣΤΑΤΙΚΩΝ ΚΑΙ ΔΥΝΑΜΙΚΩΝ ΓΕΓΟΝΟΤΩΝ ΕΙΚΟΝΑ 24 ΚΩΔΙΚΑΣ ΕΥΡΕΣΗΣ ΔΥΝΑΜΙΚΩΝ ΚΑΙ ΣΤΑΤΙΚΩΝ ΓΕΓΟΝΟΤΩΝ ΕΙΚΟΝΑ 25 ΜΕΤΑΒΛΗΤΕΣ ΤΗΣ ΚΛΑΣΗΣ RESPONSEFACTS ΕΙΚΟΝΑ 26 ΠΑΡΑΔΕΙΓΜΑ ΑΡΧΕΙΟΥ JSON ΕΙΚΟΝΑ 27 ΚΩΔΙΚΑΣ ΓΙΑ ΤΗΝ ΜΕΤΑΤΡΟΠΗ ΤΟΥ ΑΝΤΙΚΕΙΜΕΝΟΥ ΣΕ JSON ΜΟΡΦΗ ΕΙΚΌΝΑ 28 ΑΣΥΝΕΠΉ ΑΠΟΤΕΛΈΣΜΑΤΑ ΕΙΚΌΝΑ 29 ΠΑΡΕΜΒΟΛΉ ΕΙΚΟΝΑ 30 ΑΝΤΑΓΩΝΙΣΤΙΚΕΣ ΠΡΟΫΠΟΘΕΣΕΙΣ ΕΙΚΟΝΑ 31 ΚΩΔΙΚΑΣ ΕΠΕΚΤΑΣΗΣ ΤΟΥ ΓΡΑΦΟΥ ΣΧΕΔΙΑΣΜΟΥ ΕΙΚΟΝΑ 32 ΚΩΔΙΚΑΣ ΓΙΑ ΕΥΡΕΣΗ ΣΤΟΧΩΝ ΠΟΥ ΔΕΝ ΕΠΙΤΥΓΧΑΝΟΝΤΑΙ ΑΠΟ ΚΑΜΙΑ ΕΝΕΡΓΕΙΑ ΕΙΚΟΝΑ 33 ΚΩΔΙΚΑΣ ΓΙΑ ΕΥΡΕΣΗ ΕΝΕΡΓΕΙΩΝ ΠΟΥ ΕΠΙΤΥΓΧΑΝΟΥΝ ΚΑΠΟΙΟ ΣΤΟΧΟ ΕΙΚΟΝΑ 34 ΚΩΔΙΚΑΣ ΓΙΑ ΕΥΡΕΣΗ ΕΝΕΡΓΕΙΩΝ (TEMPLATES) ΠΟΥ ΕΠΙΤΥΓΧΑΝΟΥΝ ΚΑΠΟΙΟ ΣΤΟΧΟ ΕΙΚΟΝΑ 35 ΚΩΔΙΚΑΣ ΓΙΑ ΕΥΡΕΣΗ ΑΜΟΙΒΑΙΩΣ ΑΠΟΚΛΕΙΟΜΕΝΟΥΣ ΣΤΟΧΟΥΣ ΕΙΚΟΝΑ 36 ΚΩΔΙΚΑΣ ΓΙΑ ΕΥΡΕΣΗ ΤΩΝ ΑΙΤΙΩΝ ΤΩΝ ΑΜΟΙΒΑΙΩΝ ΑΠΟΚΛΕΙΟΜΕΝΩΝ ΕΙΚΟΝΑ 37 ΜΕΤΑΒΛΗΤΕΣ ΤΗΣ ΚΛΑΣΗΣ RESPONSEVALIDATE ΕΙΚΟΝΑ 38 ΤΜΗΜΑ JSON ΑΡΧΕΙΟΥ ΓΙΑ ΜΗ ΕΠΙΤΕΥΞΙΜΟΥΣ ΣΤΟΧΟΥΣ ΕΙΚΟΝΑ 39 ΤΜΗΜΑ ΑΡΧΕΙΟΥ JSON ΓΙΑ ΑΜΟΙΒΑΙΩΣ ΑΠΟΚΛΕΙΟΜΕΝΟΥΣ ΣΤΟΧΟΥΣ ΕΙΚΟΝΑ 40 ΠΑΡΑΔΕΙΓΜΑ ΠΡΟΒΛΗΜΑΤΟΣ ΚΥΒΩΝ ΕΙΚΟΝΑ 41 ΜΕΝΟΥ ΤΟΥ VLEPPO ΕΙΚΟΝΑ 42 ΠΑΡΑΔΕΙΓΜΑ ΣΧΕΔΙΑΣΜΟΥ ΣΤΟ ΓΡΑΦΙΚΟ ΕΡΓΑΛΕΙΟ VLEPPO ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ XI

12 ΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ ΕΙΚΟΝΑ 43 ΠΛΑΙΣΙΟ ΔΙΑΛΟΓΟΥ ΓΙΑ ΣΤΑΤΙΚΑ ΚΑΙ ΔΥΝΑΜΙΚΑ ΓΕΓΟΝΟΤΑ ΕΙΚΟΝΑ 44 ΠΛΑΙΣΙΟ ΔΙΑΛΟΓΟΥ ΓΙΑ ΕΠΙΤΕΥΞΙΜΟΥΣ ΚΑΙ ΜΗ ΕΠΙΤΕΥΞΙΜΟΥΣ ΣΤΟΧΟΥΣ ΕΙΚΟΝΑ 45 ΓΡΑΦΙΚΗ ΔΙΕΠΑΦΗ ΓΙΑ ΑΝΑΤΡΟΦΟΔΟΤΗΣΗ ΕΙΚΟΝΑ 46 ΓΡΑΦΙΚΗ ΔΙΕΠΑΦΗ ΓΙΑ ΑΜΟΙΒΑΙΩΣ ΑΠΟΚΛΕΙΩΜΕΝΟΥΣ ΣΤΟΧΟΥΣ ΕΙΚΟΝΑ 47 ΓΡΑΦΙΚΗ ΑΝΑΠΑΡΑΣΤΑΣΗ ΤΗΣ ΕΡΓΑΣΙΑΣ ΕΙΚΟΝΑ 48 ΛΑΝΘΑΣΜΕΝΗ ΕΠΙΛΥΣΗ ΠΡΟΒΛΗΜΑΤΟΣ ΕΙΚΟΝΑ 49 ΛΑΝΘΑΣΜΕΝΟ ΠΕΔΙΟ ΤΟΥ ΠΡΟΒΛΗΜΑΤΟΣ ΣΕ PDDL ΕΙΚΟΝΑ 50 ΛΑΝΘΑΣΜΕΝΟ ΠΡΟΒΛΗΜΑ ΣΕ PDDL ΕΙΚΟΝΑ 51 ΕΜΦΑΝΙΣΗ ΣΤΑΤΙΚΩΝ ΚΑΙ ΔΥΝΑΜΙΚΩΝ ΓΕΓΟΝΟΤΩΝ ΕΙΚΟΝΑ 52 ΠΑΡΑΘΥΡΟ ΓΙΑ VALIDATE ΕΙΚΌΝΑ 53 ΣΤΟΧΟΣ (HASLETTER MAILBOX1 LETTER1) ΕΙΚΟΝΑ 54 ΑΝΑΤΡΟΦΟΔΟΤΗΣΗ ΣΥΣΤΗΜΑΤΟΣ ΕΙΚΟΝΑ 55 ΑΝΑΤΡΟΦΟΔΟΤΗΣΗ ΜΕΤΑ ΑΠΟ ΚΑΠΟΙΑ ΒΗΜΑΤΑ XII ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

13 Κ Ε Φ Α Λ Α Ι Ο 1 : Ε Ι Σ Α Γ Ω Γ Η

14

15 ΚΕΦΑΛΑΙΟ 1: ΕΙΣΑΓΩΓΗ 1 ΕΙΣΑΓΩΓΉ Αντικείμενο της παρούσας εργασίας είναι η διερεύνηση και ανάπτυξη ενός συστήματος για τον έλεγχο εγκυρότητας προβλημάτων σχεδιασμού μέσω υπηρεσιών ιστού. Αρχικά γίνεται μια επισκόπηση της περιοχής του σχεδιασμού ενεργειών. Επιλέχθηκε η δημιουργία υπηρεσιών ιστού για την υλοποίηση του συστήματος, καθώς είναι μία αναπτυσσόμενη περιοχή της επιστήμης υπολογιστών και παρέχει την δυνατότητα χρησιμοποίησης του συστήματος απομακρυσμένα. Στη συνέχεια παρουσιάζονται πρωτόκολλα, εργαλεία και βιβλιοθήκες που χρησιμοποιήθηκαν για την υλοποίηση. Επιπρόσθετα, παρουσιάζεται η λογική της υλοποίησης των υπηρεσιών ιστού καθώς και τα δεδομένα που αποστέλλονται. Τέλος, παρουσιάζεται η σύνδεση με το εργαλείο σχεδιασμού ενεργειών Vleppo και παραδείγματα ευχρηστίας του συστήματος. Αναλυτικά, η εργασία δομείται σε κεφάλαια ως εξής: Στο Κεφάλαιο 2 γίνεται μια επισκόπηση της περιοχής του Σχεδιασμού Ενεργειών και των Υπηρεσιών Ιστού που αποτελούν το υπόβαθρο της εργασίας. Στο Κεφάλαιο 3, παρουσιάζονται τα εργαλεία και οι βιβλιοθήκες που βασίστηκε το σύστημά μας για την υλοποίηση μας. Στο Κεφάλαιο 4, παρουσιάζεται η πρώτη υπηρεσία ιστού δηλαδή ο αλγόριθμος υλοποίησης, κάποια κομμάτια κώδικα και η αναπαράσταση των δεδομένων. Στο Κεφάλαιο 5, παρουσιάζεται η δεύτερη υπηρεσία ιστού, ο αλγόριθμος υλοποίησης, κάποια κομμάτια κώδικα και η αναπαράσταση των δεδομένων. Στο Κεφάλαιο 6, παρουσιάζεται η σύνδεση με το γραφικό εργαλείο Vleppo και αξιολόγηση αποτελεσματικότητας επίλυσης προβλημάτων με την χρήση του. Στο Κεφάλαιο 7, παρουσιάζονται τα συμπεράσματα των αποτελεσμάτων μας και οι μελλοντικές επεκτάσεις. Στο Παράρτημα I παρουσιάζεται αλφαβητικά η βιβλιογραφία που αναφέρεται στην εργασία. ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 15

16

17 Κ Ε Φ Α Λ Α Ι Ο 2 : Σ Χ Ε Δ Ι Α Σ Μ Ό Σ Ε Ν Ε Ρ Γ Ε Ι Ώ Ν Κ Α Ι Υ Π Η Ρ Ε Σ Ι Ε Σ Ι Σ Τ Ο Υ

18

19 2 ΣΧΕΔΙΑΣΜΟΣ ΕΝΕΡΓΕΙΩΝ ΚΑΙ ΥΠΗΡΕΣΙΕΣ ΙΣΤΟΥ Στο κεφάλαιο αυτό γίνεται μια επισκόπηση των επιστημονικών περιοχών που σχετίζονται με την εργασία. Παράλληλα αποσαφηνίζονται οι κύριοι όροι του θέματος, Σχεδιασμός Ενεργειών και Υπηρεσίες Ιστού (Web Services). 2.1 ΣΧΕΔΙΑΣΜΟΣ ΕΝΕΡΓΕΙΩΝ Αυτοματοποιημένος Σχεδιασμός Μια βασική δυνατότητα οποιασδήποτε οντότητας που επιδεικνύει νοημοσύνη είναι η επίλυση προβλημάτων. Με τον όρο επίλυση προβλημάτων θα μπορούσε να οριστεί μία διαδικασία επιλογής και οργάνωσης ενεργειών με απώτερο σκοπό την επίτευξη ενός στόχου. Η αυτοματοποιημένη επίλυση προβλημάτων είναι ένα από τα βασικότερα αντικείμενα ενασχόλησης του τομέα της τεχνητής νοημοσύνης. Ως αυτοματοποιημένος σχεδιασμός (automated planning) και προγραμματισμός ορίζεται ο κλάδος της τεχνητής νοημοσύνης, που ασχολείται με τη διαδικασία εύρεσης μιας ακολουθίας ενεργειών (actions) οι οποίες όταν εκτελεστούν από κάποιο ευφυή και αυτόνομο πράκτορα (agent) ή ρομπότ, οδηγούν στην επίτευξη κάποιων στόχων (goals). Ένα πρόβλημα σχεδιασμού ενεργειών (planning problems) ορίζεται από μια αρχική κατάσταση (I), ένα σύνολο στόχων (G) και τις ενέργειες που μπορεί να εκτελέσει ο πράκτορας που καλείται να λύσει το πρόβλημα. Για την επίλυση προβλημάτων σχεδιασμού ενεργειών επιδιώκεται η εύρεση μιας ακολουθίας ενεργειών (πλάνο), μέσω κάποιας διαδικασίας, ώστε αν ο πράκτορας εκτελέσει αυτές τις ενέργειες να βρεθεί από την αρχική κατάσταση (I) σε μία τελική κατάσταση υποσύνολο των στόχων (G). Τα προγράμματα που καλούνται να λύσουν προβλήματα σχεδιασμού ονομάζονται σχεδιαστές (planners). Έχοντας ένα εύρος ενεργειών γίνεται αντιληπτό ότι υπάρχουν και μια πληθώρα προβλημάτων σχεδιασμού. Μερικά παραδείγματα είναι Σχεδιασμός Κίνησης και Μονοπατιού (Motion and Path Planning), Σχεδιασμός Αντίληψης (Perception Planning), Σχεδιασμός Καθοδήγησης (Navigation Planning), Σχεδιασμός Χειρισμού (Manipulation Planning), Σχεδιασμός Επικοινωνίας (Communication Planning), κτλ. Η αρχική προσέγγιση των προβλημάτων σχεδιασμού βασιζόταν στην ξεχωριστή αναπαράσταση του προβλήματος και των τεχνικών επίλυσης ανάλογα με το πεδίο (domain-specific approach). Ωστόσο, έχοντας μια τέτοια πληθώρα προβλημάτων έγινε γρήγορα σαφές ότι θα έπρεπε η περιγραφή του προβλήματος να γίνει με τέτοιο τρόπο ώστε να είναι ανεξάρτητη του πεδίου. Έτσι πλέον όταν αναφερόμαστε σε αυτοματοποιημένο σχεδιασμό (automated planning) μιλάμε για επίλυση προβλημάτων ανεξάρτητα του πεδίου (domain-independent). Για την επίλυση ενός προβλήματος, ένας ανεξάρτητα του πεδίου ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 21

20 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ σχεδιαστής (domain-independent planner) έχει ως είσοδο μία περιγραφή του προβλήματος (problem) καθώς και μια περιγραφή του πεδίου (domain). Ιστορική Αναδρομή Επίλυσης Προβλημάτων Σχεδιασμού Οι μέθοδοι επίλυσης προβλημάτων σχεδιασμού χωρίζονται σε δύο κατηγορίες,όπου αντιπροσωπεύουν και δύο χρονικά ξεχωριστές περιόδους (όπως εμφανίζεται στο σχήμα (Εικόνα 1)): α)στις κλασικές μεθόδους, που εμφανίστηκαν στις πρώτες δεκαετίες της ερευνάς στη περιοχή και βελτιώθηκαν στη δεκαετία του 80 και β) στις νεοκλασικές προσεγγίσεις, που αναπτύχθηκαν κυρίως στη δεκαετία του 90. ΚΛΑΣΙΚΗ ΝΕΟΚΛΑΣΙΚΗ ΑΥΤΟΜΑΤΕΣ ΕΥΡΙΣΤΙΚΕΣ ΜΟΝΤΕΛΑ ΙΕΡΑΡΧΙΚΟΣ ΣΧΕΔΙΑΣΜΟΣ ΑΝΑΖΗΤΗΣΗ ΣΤΟ ΧΩΡΟ ΠΛΑΝΩΝ ΑΝΑΛΥΣΗ ΓΡΑΦΩΝ ΠΕΡΙΟΡΙΣΜΟΙ ΑΝΑΖΗΤΗΣΗ ΣΤΟ ΧΩΡΟ ΚΑΤΑΣΤΑΣΕΩΝ ΙΚΑΝΟΠΟΙΗΣΗΣ Εικόνα 1 Ιστορική Περίοδοι Μεθόδων Επίλυσης Προβλημάτων Σχεδιασμού Στις κλασικές τεχνικές κατατάσσονται ο σχεδιασμός στο χώρο καταστάσεων (State Space Planning), ο σχεδιασμός στο χώρο πλάνων (Plan Space Planning) καθώς και ο ιεραρχικός σχεδιασμός (Hierarchical Planning). Οι νεοκλασικές μέθοδοι περιλαμβάνουν τους γράφου σχεδιασμού (Planning Graphs), την ικανοποίηση προτασιακών τύπων (Propositional Satisfiability), την ικανοποίηση περιορισμών (Constraint Satisfaction), τον έλεγχο μοντέλων (model checking) και την Αυτοματοποιημένη Κατασκευή Ευριστικών Συναρτήσεων (Automatic Heuristic Construction). Κλασικές Μέθοδοι Οι πρώτες μέθοδοι επίλυσης προβλημάτων βασίζονταν στο σχεδιασμό στο χώρο των καταστάσεων. Σε αυτό το σημείο θα πρέπει να οριστεί τι είναι χώρος καταστάσεων και χώρος αναζήτησης. Ως χώρο καταστάσεων ορίζουμε ένα σύνολο έγκυρών καταστάσεων του κόσμου του προβλήματος και ως χώρο αναζήτησης είναι το σύνολο των καταστάσεων που μπορούν να προκύψουν εφαρμόζοντας ένα πλήθος ενεργειών στην αρχική κατάσταση. Εφαρμόζοντας, λοιπόν, κλασικές τεχνικές τεχνητής νοημοσύνης κάνουμε μία εξερεύνηση στο χώρο αναζήτησης μέχρι να βρούμε μία αποδεκτή λύση του προβλήματος. Η αναζήτηση μπορεί να γίνει είτε εφαρμόζοντας ενέργειες στην αρχική κατάσταση μέχρι να βρούμε την λύση και ονομάζεται ορθή φορά αναζήτησης (Forward), είτε εφαρμόζοντας ανάστροφα τις ενέργειες από τους στόχους μέχρι την αρχική κατάσταση,αυτός ο τρόπος ονομάζεται ανάστροφη φορά αναζήτησης (Backward). Για τον περιορισμό του χώρου αναζήτησης συνήθως χρησιμοποιούνται ευριστικές συναρτήσεις. Τέλος, αξίζει να σημειωθεί ότι τα περισσότερα καθώς και τα πιο γνωστά συστήματα(πχ GPS, QA3, STRIPS) του χώρου των καταστάσεων χρησιμοποιούν την ανάστροφη φορά αναζήτησης. Λεπτομέρειες (Korf, 1998) (Zhang, 1999) 20 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

21 Αρχική Κατάσταση Τελική Κατάσταση A B B A B A Εικόνα 2 Παράδειγμα Σχεδιασμού στο Χώρο των Καταστάσεων Ο σχεδιασμός στο χώρο των πλάνων αποτελεί μια διαφορετική οπτική των προβλημάτων σχεδιασμού. Σύμφωνα με την προσέγγιση αυτή, ο χώρος αναζήτησης πλέον αποτελείται από πλανά. Η αναζήτηση βασίζεται σε ήδη γνωστούς αλγορίθμους αναζήτησης ωστόσο το μέτωπο αναζήτησης ξεκινά ως ένα κενό πλάνο που αλλάζει συνεχώς μέχρι να δημιουργηθεί ένα πλάνο που να μπορεί να εφαρμοστεί (applicability) και όταν εφαρμοστεί στην αρχική κατάσταση να έχουμε φτάσει σε μια κατάσταση που περιέχονται οι στόχοι. Ο σχεδιασμός στο χώρο των πλάνων δίνει δυνατότητες κατασκευής μερικώς-διατεταγμένων πλάνων (Partial Order Plans), επιτρέποντας έτσι την κατασκευή μη-γραμμικών πλάνων, και βασίζεται στην αρχή της ελάχιστης δέσμευσης(least commitment principle) δηλαδή ο καθορισμός της θέσης των ενεργειών αναβάλλεται όσο το δυνατό περισσότερο. Πρέπει να επισημάνουμε ότι ο σχεδιασμός στο χώρο των πλάνων μείωσε σημαντικά το χρόνο αναζήτησης στα προβλήματα σχεδιασμού. Ο πρώτος σχεδιαστής αυτής της κατηγορίας ήταν ο Noah (Sacerdoti, The nonlinear nature of plans, 1975), ενώ ακολούθησαν πολλοί άλλοι, από τους οποίους ξεχώρισαν οι SNLP (McAllester, 1991)και UCPOP (Penberthy, 1992). Μια ειδική περίπτωση σχεδιαστών είναι η σχεδιαστές που χρησιμοποιούν το ιεραρχικό μοντέλο επίλυσης προβλημάτων σχεδιασμού. Η βασική αρχή αυτού του μοντέλου είναι ότι ο χρήστης πρέπει να δηλώσει διαφορετικά επίπεδα «αφαίρεσης» (abstraction) στη περιγράφει του προβλήματος και ο σχεδιαστής καλείτε να λύσει το πρόβλημα από το πιο υψηλό επίπεδο και να προχωρήσει σε χαμηλότερα επίπεδα προσθέτοντας λεπτομέρειες στο πλάνο. Έτσι όταν ο σχεδιαστής φτάσει στο τελικό επίπεδο έχει δημιουργήσει ένα εκτελέσιμο πλάνο. Αυτή η τεχνική επιτυγχάνει σημαντική μείωση του χρόνου εκτέλεσης αλλά προϋποθέτει γνώση του πεδίου. Για την επίλυση στο κάθε επίπεδο μπορούν να χρησιμοποιηθούν οι μέθοδοι που αναφέραμε παραπάνω. Δηλαδή ιεραρχικές μέθοδοι με αναζήτηση στο χώρο των καταστάσεων (πχ ABSTRIPS (Sacerdoti, Planning in a hierarchy of abstractioin spaces, 1974) )και στο χώρο των πλάνων (πχ ABTWEAK (Yang, 1990)) Νεοκλασικές Μέθοδοι Όπως παρουσιάζεται και στο σχήμα (Εικόνα 1) οι κλασικές μέθοδοι επικράτησαν μέχρι τις αρχές της δεκαετίας του 90. Σε εκείνο το σημείο υπήρξε μια νέα θεώρηση στο τρόπο προσέγγισης του προβλήματος. Αν και πολλές μελέτες ακόμα και σήμερα βασίζονται στις κλασικές μεθόδους, ο κύριος όγκος των ερευνών στράφηκε σε αναζήτηση νέων τεχνικών που θα μπορούσαν να έχουν αποτελέσματα στο κομμάτι του σχεδιασμού εισάγοντας όμως και νέα ζητήματα όπως ο χρόνος, οι πόροι που χρειάζονται, η αβεβαιότητα κτλ. ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 21

22 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Μια ριζοσπαστική προσέγγιση αυτής της περιόδου αποτέλεσε ο Γράφος Σχεδιασμού που πρωτοπαρουσιάστηκε στο σύστημα Graphplan (Blum, 1995). Η τεχνική αυτή βασίζεται στη κατασκευή ενός γράφου από την περιγραφή του προβλήματος. Αυτός ο γράφος έχει ουσιαστικά όλη την πληροφορία που χρειάζεται ο σχεδιαστής για να λύσει το πρόβλημα. Μετά την κατασκευή του γράφου, εκτελείται μια ειδική μορφή αναζήτησης για εύρεση πλάνων (γραμμικών και μη) σε πολύ μικρό χρονικό διάστημα. Από την δημιουργία του Graphplan, και έκτοτε, πολλά συστήματα ακολούθησαν αυτή τη μεθοδολογία όπως οι IPP (Koehler, 1997), STAN (Fox & Long, 1999) και Hybrid STAN (Fox & Long, 2001). Σημ. Η μεθοδολογία του Graphplan θα αναλυθεί εκτενέστερα σε επόμενο κεφάλαιο αφού αποτελεί βασικό κομμάτι της εργασίας. Η ιδέα μετατροπής του προβλήματος σχεδιασμού σε πρόβλημα Ικανοποίησης Προτασιακής Λογικής αποτέλεσε μια ακόμα τάση της νεοκλασικής περιόδου. Έτσι έχουν σχεδιαστεί πολλά συστήματα που μετατρέπουν ένα πρόβλημα σχεδιασμού σε πρόβλημα ικανοποίησης προτασιακής λογικής και στη συνέχεια προσπαθούν να λύσουν το νέο πρόβλημα ικανοποιησιμότητας των προτάσεων. Τα προβλήματα αυτά αποτελούνται από λογικές προτάσεις που είτε αληθεύουν είτε όχι και σχέσεις μεταξύ τους. Λύση σε τέτοια προβλήματα είναι η εύρεση της αλήθειας ώστε να ικανοποιούνται όλες οι σχέσεις. Παραδείγματα τέτοιων συστημάτων είναι ο SATPLAN (Kautz & Selman, Planning as satisfiability, 1992) (Kautz & Selman, 1996) και ο BLACKBOX (Kautz & Selman, 1998) Δυο ακόμα προσεγγίσεις για την επίλυση προβλημάτων σχεδιασμού είναι η χρησιμοποίηση της αναπαράστασης των προβλημάτων με Μοντέλα Ελέγχου και Μακροβιανές Διαδικασίες Απόφασης. Ο στόχος των δύο τεχνικών είναι η λύση προβλημάτων που εμπεριέχουν ένα μέρος αβεβαιότητας. Η αβεβαιότητα σε προβλήματα σχεδιασμού, πρακτικών προβλημάτων, είναι πολλές φόρες ένας υπαρκτός παράγοντας. Έτσι πολλοί ερευνητές ασχολήθηκαν με τέτοια προβλήματα και υπάρχουν και παραδείγματα τέτοιων συστημάτων όπως αναφέρονται στα (Howe, Dahlman, Hasen, vonmayrhauser, & Scheetz, 1999) (Boutilier, Reiter, & Price, 2001) (Feng & Hansen, 2001) (Jensen, Veloso, & Bowling, 2001) (Cimatti, Giunchiglia, & Traverso, 1997), (Giunchiglia & Traverso, 1999). Το κυρίαρχο χαρακτηριστικό αυτών των προσεγγίσεων είναι ο μετασχηματισμός των προβλημάτων σχεδιασμού σε προβλήματα άλλων περιοχών που μπορούν να χειριστούν την αβεβαιότητα. Τέλος, στις νεοκλασικές προσεγγίσεις, θα πρέπει να αναφέρουμε και την τεχνική της αυτόματης εξαγωγής Ευριστικών Μεθόδων από την δομή του εκάστοτε προβλήματος. Τα συστήματα αυτής της περιοχής στοχεύει στην αύξηση της αποδοτικότητας της αναζήτησης. Ο σχεδιαστής UNPOP (McDermott, 1996) ήταν το πρώτο σύστημα αυτής της περιοχής και βασίστηκε στη τεχνική ανάλυσης των μέσων και των σκοπών για την ανάλυση του προβλήματος και την κατασκευή μιας ευριστικής συνάρτησης. Μετά η ευριστική συνάρτηση χρησιμοποιείται από κάποιον κλασικό αλγόριθμο αναζήτησης στο χώρο των καταστάσεων. Μετά τον UNPOP πολλοί σχεδιαστές βασίστηκαν στο παράδειγμα του, τέτοιοι σχεδιαστές ήταν οι ASP/HSP (Bonet, Loerincs, & Geffner, 1998), (Bonet & Geffner, 1999),GRT (Refanidis & Vlahavas, 1999) (Refanidis & Vlahavas, 2001), FF (Hoffmann, 2000), (Hoffmann & Nebel, 2001)] και AltAlt (Nguyen, Kamphambati, & Nigenda, 2000). 22 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

23 Το Μοντέλο STRIPS Η μέθοδος STRIPS αναπτύχθηκε για το ρομπότ Shakey από την ανάγκη για δημιουργία ενός γενικού αλγορίθμου που σχεδιάζει ενέργειες για την επίτευξη στόχων. Το σύστημα STRIPS, αν και θεωρήθηκε γρήγορα ξεπερασμένο, χρησιμοποίησε μια γλώσσα περιγραφής προβλημάτων σχεδιασμού που έκτοτε χρησιμοποιήθηκε από τα περισσότερα συστήματα σχεδιασμού μέχρι και τα πλέον σύγχρονα. Το μοντέλο STRIPS κάνει κάποιες παραδοχές για τον κόσμο του προβλήματος. Ο κόσμος είναι προκαθορισμένος και στατικός. Δηλαδή, οι ενέργειες του πράκτορα έχουν προβλεπόμενα αποτελέσματα και είναι οι μόνες που μπορούν να επιφέρουν αλλαγές στον κόσμο του προβλήματος. Επίσης, ο κόσμος είναι κλειστός δηλαδή τα αντικείμενα που υπάρχουν στην αρχική κατάσταση είναι τα μόνα που μπορούν να υπάρχουν σε οποιαδήποτε κατάσταση του προβλήματος. Ακόμα, ο πράκτορας έχει πλήρη γνώση του κόσμου του προβλήματος που τον αφορά και τέλος οι ενέργειες που εκτελεί είναι αδιαίρετες. A B Γ Εικόνα 3 Παράδειγμα του Κόσμου των Κύβων Μια κατάσταση στην κωδικοποίηση του STRIPS αναπαρίσταται ως ένα σύνολο γεγονότων. Για παράδειγμα στο σχήμα (Εικόνα 3) η κατάσταση S είναι: S={ontable(A), clear(a), ontable(γ), on(β,γ), clear(b)} Για ένα πρόβλημα κατά STRIPS η αρχική κατάσταση περιγράφεται πλήρως ενώ οι στόχοι είναι μια απλή σύζευξη γεγονότων. Για παράδειγμα, οι στόχοι για ένα πρόβλημα με τρεις κύβους (Α,Β,Γ) θα μπορούσαν να είναι: G={on(Β,Γ),clear(Β)} Τέλος μια ενέργεια στο STRIPS περιγράφεται με τρεις λίστες: Τη λίστα προϋποθέσεων (precondition list), που περιέχει τα γεγονότα που πρέπει να ισχύουν σε κάποια κατάσταση για να εφαρμοστεί η ενέργεια. Τη λίστα προσθήκης (add list), περιέχει τα γεγονότα που θα προστεθούν στην καινούρια κατάσταση. Τη λίστα διαγραφής (delete list), περιέχει τα γεγονότα που διαγράφονται εφαρμόζοντας την ενέργεια. Για παράδειγμα στο πρόβλημα των κύβων η ενέργεια move(a,b,γ) θα περιγραφόταν με τις παρακάτω λίστες Λίστα Προϋποθέσεων={on(A,B), clear(a), clear(γ)} Λίστα Προσθήκης={on(Α,Γ), clear(b)} Λίστα Διαγραφής={on(A,B), clear(γ)} ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 23

24 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Η γλώσσα PDDL Όπως αναφέρθηκε και παραπάνω, για να περιγράφει ένα πρόβλημα σχεδιασμού χρειάζεται η τυπική περιγραφή του προβλήματος καθώς και του πεδίου. Για να επιτευχθεί αυτή η τυποποίηση, λοιπόν, δημιουργήθηκε η γλώσσα PDDL (Planning Domain Definition Language) από τον Drew McDermott και την ομάδα του το 1988/2000. Η Γλώσσα PDDL βασίστηκε στο μοντέλο strips. Για να οριστεί ένα πρόβλημα στην PDDL πρέπει να οριστούν δύο μέρη του: το πεδίο (domain) και το πρόβλημα (problem). Η περιγραφή του πεδίου περιέχει όλες τις απαραίτητες πληροφορίες για την αναπαράσταση του όπως κλάσεις και ενέργειες, ενώ η περιγραφή του προβλήματος έχει την περιγραφή της αρχικής κατάστασης καθώς και την περιγραφή των στόχων. Το πεδίο και το πρόβλημα αποτελούν στη πράξη δύο ξεχωριστά αρχεία που τα δημιουργεί ο εκάστοτε χρήστης και δηλώνει, με τυποποιημένο τρόπο, ότι αναφέραμε παραπάνω. Εικόνα 4 Παράδειγμα Πεδίου Στην παραπάνω εικόνα (Εικόνα 4 Παράδειγμα Πεδίου) παρουσιάζουμε την περιγραφή ενός πεδίου της οικογένειας του Gripper. Στα προβλήματα αυτά υπάρχει ένα ή περισσότερα ρομπότ με ένα συγκεκριμένο αριθμό βραχιόνων πάνω στο κάθε ρομπότ, τα οποία μπορούν να μετακινούνται σε διάφορα δωμάτια με σκοπό να μεταφέρουν αντικείμενα από το ένα δωμάτιο στο άλλο. Σε αυτό το παράδειγμα του πεδίου ορίζουμε τις οντότητες δωμάτιο (room), μπάλα (ball) και βραχίονας (gripper) και τέσσερις σχέσεις που συνδέουν αυτές τις οντότητες. Η σχέση at-robby δηλώνει ότι το ρομπότ βρίσκεται σε ένα δωμάτιο, η σχέση at δηλώνει ότι η μπάλα βρίσκεται σε ένα δωμάτιο, η σχέση free δηλώνει ότι ο βραχίονας είναι ελεύθερος και η σχέση carry δηλώνει ότι ο βραχίονας κουβαλάει μία μπάλα. Ακόμα ορίζονται οι τρεις ενέργειες του πεδίου. Η πρώτη ενέργεια move το ρομπότ βρίσκεται σε 24 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

25 ένα δωμάτιο και στο τέλος της βρίσκεται σε ένα νέο δωμάτιο. Η επόμενη ενέργεια pick με την οποία το ρομπότ σηκώνει μία μπάλα. Προϋποθέσεις είναι ο βραχίονας να είναι ελεύθερος, η μπάλα να βρίσκεται στο δωμάτιο και όχι σε κάποιον βραχίονα και η μπάλα να είναι στο ίδιο δωμάτιο με το ρομπότ. Τα αποτελέσματα της ενέργειας είναι ότι η μπάλα βρίσκεται πλέον στον βραχίονα και όχι στο δωμάτιο και ο βραχίονας δεν είναι πλέον ελεύθερος. Τέλος, η ενέργεια drop δηλώνει την περίπτωση που το ρομπότ αφήνει μία μπάλα σε ένα δωμάτιο. Οι προϋποθέσεις είναι το ρομπότ να κρατάει την μπάλα και να βρίσκεται σε ένα δωμάτιο και τα αποτελέσματα είναι η μπάλα να μην βρίσκεται πλέον στον βραχίονα αλλά στο δωμάτιο που αναφέρθηκε στις προϋποθέσεις και ο βραχίονας είναι ελεύθερος. Εικόνα 5 Παράδειγμα Προβλήματος Στην (Εικόνα 5) εμφανίζεται ένα πρόβλημα του πεδίου gripper. Αρχικά ορίζονται τα αντικείμενα του προβλήματος δηλαδή 2 δωμάτια, 2 μπάλες και 2 βραχίονες. Έπειτα δηλώνονται τα γεγονότα που περιέχονται στην αρχική κατάσταση, δηλαδή ότι το ρομπότ βρίσκεται στο δωμάτιο Α, όπως και οι δύο μπάλες και οι βραχίονές του είναι ελεύθεροι. Τέλος ορίζονται οι στόχοι του προβλήματος που είναι δύο μπάλες να βρίσκονται στο δωμάτιο Β. Εικόνα 6 Παράδειγμα Πλάνου ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 25

26 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Μετά την εκτέλεση ενός σχεδιαστή ενεργειών (planner), παραδείγματος χάριν ο LPG-td (Local search for Planning Graphs) (Gerevini, Saetti, & Serina, 2004), και δίνοντας του ως είσοδο τα προηγούμενα αρχεία πεδίου και προβλήματος, προκύπτει ένα νέο αρχείο στο οποίο βρίσκεται το πλάνο που επιλύει το πρόβλημα. Στην εικόνα (Εικόνα 6) φαίνεται το πλάνο του παραπάνω προβλήματος εκφρασμένο σε PDDL+. Η γλώσσα PDDL+, είναι μία επέκταση της PDDL έτσι ώστε να μπορεί να περιγράφει και την χρονική διάρκεια της κάθε ενέργειας. Ο αριθμός μπροστά από κάθε ενέργεια δηλώνει την χρονική στιγμή στην οποία θα εκτελεστεί η κάθε ενέργεια και ο τελευταίος αριθμός μετά από κάθε ενέργεια αναφέρεται στην χρονική διάρκεια που θα έχει αυτή. Σε αυτό το παράδειγμα κάθε ενέργεια διαρκεί μία χρονική στιγμή και όλες εκτελούνται σειριακά. Εδώ πρέπει να αναφερθεί ότι οι ενέργειες που μπορούν να εκτελεστούν παράλληλα, έχουν τον ίδιο αριθμό στην θέση της χρονικής στιγμής. Στην λύση που προτείνεται, το ρομπότ θα πρέπει να σηκώσει την μπάλα 1 με τον αριστερό βραχίονα, να μεταφερθεί στο δωμάτιο Β και να την αφήσει, στην συνέχεια να μεταφερθεί πάλι στο δωμάτιο Α, να σηκώσει την μπάλα 2, να μεταφερθεί στο δωμάτιο Β και να αφήσει εκεί και την μπάλα 2. Γράφοι Σχεδιασμού και το Σύστημα Graphplan Η Ανάλυση Γράφων Σχεδιασμού είναι μια από τις σημαντικότερες τεχνικές σχεδιασμού της νεοκλασικής περιόδου. Ο σχεδιαστής, σύμφωνα με την τεχνική αυτή, κατασκευάζει πρώτα μια δομή που ονομάζεται γράφος σχεδιασμού (planning graph) και παρουσιάζει το πρόβλημα έτσι ώστε να μπορούν να ανακαλυφθούν χρήσιμα συμπεράσματα που περιορίζουν το εύρος αναζήτησης. Η γράφοι σχεδιασμού εμφανίστηκαν πρώτη φορά στο Graphplan (Blum, 1995) και έκανε σημαντικά ευκολότερη και γρηγορότερη την αναζήτηση λύσης στα προβλήματα σχεδιασμού. B C A Move(B,C,table) B C A Move(A,table,B) A B C Move(B,C,A) C B A Εικόνα 7 Παράδειγμα Γράφου Σχεδιασμού Η ανάλυση των γράφων σχεδιασμού μπορεί να εφαρμοστεί σε προβλήματα ορισμένα στο μοντέλο STRIPS. Ο γράφος σχεδιασμού είναι ένας πολυεπίπεδος, κατευθυνόμενος γράφος που αποτελείται από δύο ειδών κόμβους και τριών ειδών ακμές. Τα επίπεδα του γράφου είναι είτε προτασιακά (proposition levels) είτε επίπεδα ενεργειών ( action levels ) και εναλλάσσονται μεταξύ τους. Το πρώτο επίπεδο περιέχει έναν κόμβο για κάθε γεγονός της αρχικής 26 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

27 κατάστασης και, φυσικά, ανήκει στα προτασιακά επίπεδα. Το δεύτερο επίπεδο, είναι ουσιαστικά, το πρώτο επίπεδο ενεργειών, και περιέχει όλες τις ενέργειες που μπορούν να εφαρμοστούν στην αρχική κατάσταση, καθώς και τις ενέργειες no-op που περνάν τα γεγονότα του προηγούμενου επιπέδου στο επόμενο επίπεδο. Το τρίτο επίπεδο περιέχει τους κόμβους του πρώτου επιπέδου (που πέρασαν με τις no-op ενέργειες) καθώς και γεγονότα που προστέθηκαν από τις ενέργειες του δευτέρου επιπέδου. Τα επόμενα επίπεδα σχηματίζονται με τον ίδιο ακριβώς τρόπο. Οι ακμές του γράφου αναπαριστούν τις σχέσεις μεταξύ ενεργειών και των προτάσεων. Οι ενέργειες στο επίπεδο i συνδέονται με τις προϋποθέσεις τους στο επίπεδο i-1 (επίπεδο προτάσεων i), μέσω ακμών προϋποθέσεων (precondition-edges). Ακόμα συνδέονται με τα αποτελέσματα στο επίπεδο i+1 (προτασιακό επίπεδο i+1), με ακμές προσθήκης (add-edges) και διαγραφείς (delete-edges). Οι συνδέσεις σε ένα γράφο σχεδιασμού είναι πολύ χαλαρές,πολύ πιο χαλαρές σε σχέση με αυτές των έγκυρων πλάνων. Οι ενέργειες τοποθετούνται σε ένα επίπεδο αν οι προϋποθέσεις τους ικανοποιούνται στο προηγούμενο επίπεδο, ακόμα και αν δύο ενέργειες δεν μπορούν στην πραγματικότητα να συνυπάρξουν μεταξύ τους. Ακόμα, ένα γεγονός μπορεί να υπάρξει σε ένα προτασιακό επίπεδο αν, απλά, κάποια ενέργεια του προηγούμενου επιπέδου το προσθέτει, έστω και αν κάποια άλλη ενέργεια το διαγράφει. Επίσης, αν σκεφτεί κάποιος ότι επιτρέπονται και οι μηδενικοί τελεστές (no-op) είναι φανερό ότι κάποιο προτασιακό επίπεδο είναι υπερσύνολο των προηγούμενων προτασιακών επιπέδων. Όπως προαναφέραμε, οι απαιτήσεις τέτοιων γράφων είναι αρκετά χαλαρές αυτό έχει ως αποτέλεσμα την εύκολη κατασκευή τους. Αρχική Κατάσταση: On(A,B) ontable(b) Clear(A) A B Τελική Κατάσταση: On(B,Α) A B Εικόνα 8 Αρχική και Τελική Κατάσταση Προβλήματος Το σχήμα (Εικόνα 8) παρουσιάζεται ένα παράδειγμα του προβλήματος των κύβων. Στο παρακάτω σχήμα (Εικόνα 9) δείχνει το γράφο σχεδιασμού που θα δημιουργούσε ο Graphplan για αυτό το πρόβλημα. Οι μπλε γραμμές στο σχήμα συνδέουν τις ενέργειες με τις προϋποθέσεις τους. Τα πράσινα και πορτοκαλί βέλη συνδέουν τις ενέργειες με τα αποτελέσματα τους, θετικά και αρνητικά αντίστοιχα. Ο γράφος, στο συγκεκριμένο παράδειγμα, έχει επεκταθεί μέχρι το 3ο επίπεδο, αφού η λύση μπορεί να εξαχθεί σε αυτό το επίπεδο. Η λύση αυτή παρουσιάζεται στο σχήμα (Εικόνα 10) που είναι υπογράφος του παραδείγματος. ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 27

28 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Προτασιακό Επίπεδο 1 Επίπεδο Ενεργειών 1 Προτασιακό Επίπεδο 2 Επίπεδο Ενεργειών 2 Προτασιακό Επίπεδο 3 movefromtable(b,a) ontable(b) clear(a) on(a,b) NO-OP NO-OP movefromtable(a,b) NO-OP ontable(b) clear(a) clear(b) ontable(a) NO-OP NO-OP movetotable(a,b) NO-OP NO-OP on(b,a) ontable(b) clear(a) clear(b) ontable(a) on(a,b) movefromtable(a,b) on(a,b) NO-OP Εικόνα 9 Παράδειγμα Γράφου Σχεδιασμού του Graphplan Αρχική Κατάσταση Επίπεδο Ενεργειών 1 Κατάσταση 1 Επίπεδο Ενεργειών 2 Στόχοι movefromtable(b,a) ontable(b) on(b,a) ontable(b) clear(a) NO-OP NO-OP movefromtable(a,b) clear(a) clear(b) on(a,b) Εικόνα 10 Παράδειγμα Εύρεσης Πλάνου Εκτέλεσης στο Graphplan Σχέσεις αποκλεισμού μεταξύ κόμβων γράφου σχεδιασμού Η ανάλυση γράφων και η εύρεση πλάνου σε αυτούς βασίζεται σε μεγάλο βαθμό στην εύρεση σχέσεων αμοιβαίου αποκλεισμού (mutual exclusions ή mutexes) μεταξύ των κόμβων. Η διαδικασία εύρεσης αμοιβαίων αποκλεισμών έχει ως αποτέλεσμα τον περιορισμό της αναζήτησης για έγκυρα πλάνα σε ένα γράφο σχεδιασμού. Οι αμοιβαίοι αποκλεισμοί αναφέρονται είτε σε ενέργειες είτε σε γεγονότα. Δύο ενέργειες είναι αμοιβαίως αποκλειόμενες, σε κάποιο επίπεδο, αν κανένα έγκυρο πλάνο δεν θα μπορούσε να τις εκτελέσει και δύο γεγονότα,ομοίως, είναι αμοιβαίως αποκλειόμενα αν κανένα έγκυρο πλάνο δεν θα μπορούσε να τα χρησιμοποιήσει ταυτόχρονα. 28 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

29 Όσον αφορά τον Graphplan οι αμοιβαίοι αποκλεισμοί εντοπίζονται, καταχωρούνται και διαδίδονται μέσα στο γράφο. Ο Graphplan βασίζεται σε κάποιους απλούς κανόνες την εύρεση των αμοιβαίων αποκλεισμών. Πιο συγκεκριμένα: Οι λόγοι για τους οποίους δύο ενέργειες είναι αμοιβαίως αποκλειόμενες είναι: Ασυνεπή Αποτελέσματα (Inconsistent effects): Η μία διαγράφει ένα αποτέλεσμα της άλλης Παρεμβολή (Interference): Η μία διαγράφει μια προϋπόθεση της άλλης Ανταγωνιστικές Προϋποθέσεις (Competing needs): Έχουν προϋποθέσεις που είναι αμοιβαίως αποκλειόμενες Και δύο γεγονότα στο επίπεδο είναι αμοιβαίως αποκλειόμενα: Ασυνεπής Υποστήριξη (Inconsistent support): Το ένα είναι η άρνηση του άλλου ή όλοι οι τρόποι επίτευξης τους είναι αμοιβαία αποκλειόμενοι Παρακάτω εμφανίζονται οι περιπτώσεις των αμοιβαίων αποκλεισμών που λαμβάνει υπόψη του ο Graphplan. Ασυνεπή Αποτελέσματα Παρεμβολή Ανταγωνιστικές Προϋποθέσεις Εικόνα 11 Τύποι Αμοιβαίων Αποκλεισμών Ενεργειών Πρέπει να σημειωθεί ότι ο Graphplan δεν μπορεί να βρει όλους τους τύπους αμοιβαίων αποκλεισμών που μπορεί να υπάρχουν. Συγκεκριμένα μπορεί να ανακαλύψει μόνο τους αποκλεισμούς μεταξύ ενεργειών ενός επιπέδου. Αλγόριθμος του Graphplan Μια απλή περιγραφή του αλγορίθμου επίλυσης που χρησιμοποιεί ο σχεδιαστής του Graphplan θα μπορούσε να ήταν η εξής: Αρχικά εισάγει στο πρώτο προτασιακό επίπεδο όλα τα γεγονότα της αρχικής κατάστασης, έπειτα, επεκτείνει επαναληπτικά τα επόμενα επίπεδα του γράφου μέχρι είτε να βρεθεί λύση, είτε να αποδειχθεί η μη δυνατότητα λύσης. Παρακάτω παρουσιάζεται ο ψευδοκώδικας του αλγορίθμου (Εικόνα 12) καθώς και μία αναλυτική περιγραφή του. ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 29

30 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Εικόνα 12 Ψευδοκώδικας του αλγορίθμου Graphplan Αρχικά, όπως αναφέρθηκε και παραπάνω, ο αλγόριθμος εισάγει την αρχική κατάσταση στο πρώτο προτασιακό επίπεδο. Έπειτα εφαρμόζει τις ενέργειες (και τις no-op) στο επίπεδο και κατασκευάζει το επόμενο προτασιακό επίπεδο. Στη συνέχεια βρίσκει τους αμοιβαίους αποκλεισμούς και τους αποθηκεύει. Η διαδικασία επαναλαμβάνεται μέχρι να βρεθεί ένα προτασιακό επίπεδο που να είναι υπερσύνολο των στόχων και οι στόχοι να μην είναι αμοιβαίως αποκλειόμενοι σε αυτό το επίπεδο. Μιλώντας τυπικά το να έχει ένα προτασιακό επίπεδο τους στόχους είναι αναγκαία αλλά όχι ικανή συνθήκη για την επίλυση του προβλήματος. Σε αυτό το σημείο ο αλγόριθμος εκτελεί μια ανάστροφη διάσχιση του γράφου για την εύρεση λύσης. Αν μετά την ανάστροφη διάσχιση του γράφου δεν βρεθεί λύση τότε εφαρμόζονται οι διαδικασίες που αναφέρθηκαν παραπάνω για επέκταση του γράφου κατά ένα προτασιακό επίπεδο και εύρεση λύσης. Η διαδικασία θα σταματήσει εάν βρεθεί λύση ή αν στο τελευταίο προτασιακό επίπεδο δεν μπορεί να βρεθεί σύνολο ενεργειών το οποίο πετυχαίνει νέους στόχους χωρίς αμοιβαίους αποκλεισμούς (level-off). Έτσι ο Graphplan έχει την δυνατότητα να σταματήσει την λειτουργία του όταν διαγνώσει μη επιλυσιμότητα του προβλήματος. Από την περιγραφή του αλγορίθμου, γίνεται εύκολα αντιληπτό ότι, αν κάποιο πρόβλημα έχει λύση τότε η λύση που θα δώσει ο αλγόριθμος θα έχει το μικρότερο δυνατό σύνολο ενεργειών. Τέλος, θα πρέπει να αναφέρουμε, ότι ο Graphplan, αν σε κάποιο επίπεδο αποτύχει, κρατά ένα σύνολο υποστόχων που μπορούν να επιτευχθούν, έτσι αν συναντήσει ξανά αυτούς τους υποστόχους στην διαδικασία επίλυσης να μπορεί να αποφανθεί αμέσως για αυτούς. Παραδείγματος χάριν, στο γράφο του σχήματος (Εικόνα 9) η διαδικασία έχει ως εξής: Το Προτασιακό Επίπεδο 3 είναι το τελευταίο επίπεδο του γράφου άρα αν υπάρχει λύση θα αποτελείται από δύο βήματα. Ο μοναδικός στόχος του προβλήματος είναι ο on (B,A), πού φαίνεται στο σχήμα (Εικόνα 10). Σε αυτό το σχήμα (Εικόνα 10) εμφανίζεται και το ελάχιστο σύνολο ενεργειών 2 ου επιπέδου (Επίπεδο Ενεργειών 2). Το νέο υποσύνολο στόχων του προβλήματος (Κατάσταση 1) θα γίνουν τώρα οι προϋποθέσεις των ενεργειών του επιπέδου (Κατάσταση 2). Το νέο υποσύνολο στόχων μπορεί να επιτευχθεί με ένα σύνολο ενεργειών οι οποίες δεν έχουν αμοιβαίους αποκλεισμούς. Πιο συγκεκριμένα: 30 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

31 1ο βήμα NO-OP 2ο βήμα movefromtable(b,a) NO-OP movefromtable(a,b) Εικόνα 13 Παράδειγμα Ενεργειών Την τεχνική σχεδιασμού που εισήγαγε ο Graphplan ακολούθησαν και επέκτειναν και άλλα συστήματα κυρίως στο κομμάτι της αναζήτησης λύσης του γράφου. Τέτοια συστήματα σχεδιασμού είναι οι SGP[weld, anderson and Smith 1988], IPP[koehler 1998], STAN [Long and Fox 1998], Hybrid STAN [Fox and Long 2001], SATPLAN[Kautz and Selman 199six], BLACKBOX[kautz and Selman 1998] και FF[Hoffmann and Nebel 2001]. 2.2 ΥΠΗΡΕΣΙΕΣ ΙΣΤΟΥ - WEB SERVICES Μια υπηρεσία ιστού είναι μια διεπαφή η οποία περιγράφει μια συλλογή από διαδικασίες (συναρτήσεις) που είναι προσβάσιμες μέσω δικτύου (ή του διαδικτύου) χρησιμοποιώντας ένα τυποποιημένο πρωτόκολλο επικοινωνίας. Επίσης, μια υπηρεσία ιστού δεν φανερώνει λεπτομέρειες για της υλοποίησης της και έτσι επιτρέπει την χρησιμοποίησή της ανεξαρτήτως της πλατφόρμας υλοποίησης (είτε λογιστικού είτε υλικού) και ανεξαρτήτως της γλώσσας υλοποίησης. Αυτό δίνει την δυνατότητα να κληθεί και να χρησιμοποιηθεί από οποιαδήποτε μηχανή έχει πρόσβαση στο δίκτυο λειτουργίας τους. Με τα σημερινά δεδομένα το δίκτυο λειτουργίας μιας τέτοιας εφαρμογής είναι ουσιαστικά το Διαδίκτυο. H επιτυχία των υπηρεσιών ιστού έγκειται στα κοινά βιομηχανικά πρότυπα και τεχνολογίες που χρησιμοποιούν για την λειτουργία τους, όπως είναι η γλώσσα σήμανσης XML και το πρωτόκολλο HTTP. Έτσι για να επιτευχθεί η διαλειτουργικότητα των υπηρεσιών ιστού δημιουργήθηκε και μια γλώσσα περιγραφής υπηρεσιών ιστού, η γλώσσα WSDL (Web Service Description Language), η οποία ορίζει τα μηνύματα που πρέπει να ανταλλάξει κάποιο μηχάνημα ώστε να επικοινωνήσει με μία συγκεκριμένη υπηρεσία ιστού. Πιο συγκεκριμένα, ένα client πρόγραμμα μπορεί να συνδεθεί σε μία υπηρεσία ιστού και να διαβάσει το WSDL αρχείο της υπηρεσίας ώστε να προσδιορίσει ποιες συναρτήσεις (λειτουργίες) είναι διαθέσιμες από την υπηρεσία. ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 31

32 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Web Service REQUEST WSDL SEND WSDL Client Application Εικόνα 14 Παράδειγμα Επικοινωνίας Υπηρεσίας Ιστού με τον Πελάτη της Υπηρεσίας Οι υπηρεσίες ιστού χωρίζονται σε δύο κατηγορίες, αυτές που χρησιμοποιούν το πρωτόκολλο SOAP (Simple Object Access protocol) και στις RESTful. Το πρωτόκολλο SOAP βασίζεται στην γλώσσα σήμανσης XML για να ορίσει ένα επεκτάσιμο πλαίσιο μηνυμάτων (το οποίο παρέχει τη δομή του μηνύματος). Το μήνυμα μπορεί να μεταφέρεται πάνω από διάφορα πρωτόκολλα, συνήθως, μεταφέρεται πάνω από το HTTP. Web Service Client Application WSDL Interface WSDL Interface SOAP SOAP Transfer Protocol SOAP HTTP HEADER SOAP TCP/IP protocol stack HTTP HEADER SOAP Εικόνα 15 Πρωτόκολλο SOAP Το πρότυπο REST (Represent state transfer) περιγράφει μια σειρά από αρχιτεκτονικές αρχές με τις οποίες τα δεδομένα μπορούν να μεταδοθούν σε μια τυποποιημένη διεπαφή όπως το HTTP, περιορίζοντας τις διεπαφές σε ένα σύνολο σαφώς ορισμένων ενεργειών (όπως η GET, POST, PUT, DELETE του HTTP). Client Application Method Protocol Host name Path to a resource Query String GET HTTP Status:200 (OK) Response headers Request representation Server Web Service Εικόνα 16 Παράδειγμα RESTful Υπηρεσίας Ιστού 32 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

33 Η διαλειτουργικότητα των υπηρεσιών ιστού άνοιξε νέους δρόμους στο σχεδιασμό συστημάτων λογισμικού. Η νέα τάση που γεννήθηκε ονομάζεται Υπηρεσιοστραφής Αρχιτεκτονική (Service Oriented Architecture) και είναι μια εξέλιξη των κατανεμημένων συστημάτων πληροφορικής, για την παροχή υπηρεσιών προς χρήστες ή άλλες υπηρεσίες στο διαδίκτυο, χρησιμοποιώντας τυποποιημένες περιγραφές (wsdl) για την δημοσίευση και την αναζήτηση υπηρεσιών. Client Application Service Client UDDI Service Broker Find Service Description Web Service Service Provider Εικόνα 17 Υπηρεσιοστραφής Αρχιτεκτονική Στη παραπάνω εικόνα (Εικόνα 17) φαίνεται η αρχιτεκτονική λειτουργίας του συστήματος. Ο πάροχος (provider) μίας υπηρεσίας «δημοσιεύει» την υπηρεσία σε ένα μητρώο (registry/repository) υπηρεσιών που του παρέχει ένας διαπραγματευτής υπηρεσιών (Service Broker). Η υπηρεσία καταχωρείται σε έναν πίνακα καταχωρίσεων UDDI. Ο πελάτης (Service Client) στέλνει ένα αίτημα στο κατάλογο με τα κριτήρια που επιθυμεί και ο κατάλογος στέλνει τις WSDL περιγραφές στον ενδιαφερόμενο πελάτη. O πελάτης μπορεί να επιλέξει χειροκίνητα, αν μιλάμε για φυσικό πρόσωπο, ή αυτόματα, αν αναφερόμαστε σε κάποιον πράκτορα λογισμικού, μία από τις περιγραφές. Ακολούθως μπορεί να επικοινωνήσει με τον πάροχο (Service Provider) της υπηρεσίας με μηνύματα SOAP. Η παραπάνω διαδικασία δίνει την δυνατότητα συνδυάζοντας διαφορετικές υπηρεσίες ιστού να προκύψει μία πληθώρα νέων εφαρμογών που εκτελούν λειτουργίες για τις οποίες οι αρχικές υπηρεσίες δεν είχαν καν σχεδιαστεί. Με αυτόν τον τρόπο η κατασκευή νέων εφαρμογών και η προσθήκη λειτουργικότητας σε αυτές γίνεται μία πολύ εύκολη διαδικασία καθώς δεν απαιτείται η εξ ολοκλήρου δημιουργία τους από την αρχή αλλά απλά ο εντοπισμός των επιθυμητών υπηρεσιών και ο κατάλληλος συνδυασμός τους. Αξίζει να αναφερθεί ότι τα τελευταία χρόνια η αρχιτεκτονική SOA επιλέγεται όλο και περισσότερο από τις εταιρείες. Έτσι πλέον τα δεδομένα είναι προσβάσιμα ως Υπηρεσίες (Data as a Service), το ίδιο και το λογισμικό (Software as a Service) αλλά και ολόκληρες πλατφόρμες (Platform as a Service). ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 33

34 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Κ Ε Φ Α Λ Α Ι Ο 3 : Ε Ρ Γ Α Λ Ι Α Κ Α Ι Β Ι Β Λ Ι Ο Θ Η Κ Ε Σ Υ Λ Ο Π Ο Ι Η Σ Η Σ 34 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

35 3 ΕΡΓΑΛΕΙΑ ΚΑΙ ΒΙΒΛΙΟΘΗΚΕΣ ΥΛΟΠΟΙΗΣΗΣ Σε αυτό το κεφάλαιο θα αναφερθούμε στα εργαλεία, τις βιβλιοθήκες και τις υλοποιήσεις που χρησιμοποιήσαμε για να υλοποιήσουμε τις μεθόδους μας. Η γλώσσα υλοποίησης είναι η JAVA για τις μεθόδους και την γλώσσα PHP για την υλοποίηση της υπηρεσίας ιστού. Ουσιαστικά, υλοποιήσαμε τις μεθόδους μας σε java και έχοντας το εκτελέσιμο αρχείο (jar), το καλούμε μέσω της PHP με κατάλληλες παραμέτρους. 3.1 ΒΙΒΛΙΟΘΗΚΗ GSON Gson είναι μια Java βιβλιοθήκη που παρέχει την δυνατότητα αναπαράστασης δεδομένων σε μορφή JSON αρχείων. Η JSON αναπαράσταση (JavaScript Object Notation) είναι πρότυπο αναπαράστασης δεδομένων. Είναι εύκολο και για τον άνθρωπο αλλά και για τον υπολογιστή να διαβάσουν και να δημιουργήσουν JSON αρχεία. Θα πρέπει να σημειωθεί ότι το πρότυπο είναι ανεξάρτητο της γλώσσας υλοποίησης. Έτσι γίνεται κατανοητό ότι ένα αρχείο μπορεί να διαβαστεί από οποιαδήποτε πρόγραμμα σε όποια γλώσσα προγραμματισμού και αν έχει γραφεί. Δύο είναι οι βασικές δομές που μπορεί να αναπαρασταθούν σε ένα JSON αρχείο 1) Μία λίστα της μορφής <όνομα, τιμή> και 2) Μία λίστα τιμών. Στη δική μας υλοποίηση, τα αποτελέσματα των μεθόδων μας αναπαρίστανται με αρχεία JSON. Η βιβλιοθήκη (Gson) αυτό το πετυχαίνει με την μετατροπή αντικειμένων JAVA σε αναπαράσταση JSON. Επίσης, μπορεί να μετατρέψει ένα JSON αρχείο σε ανάλογο JAVA αντικείμενο. Η Gson μπορεί να δουλέψει με οποιαδήποτε JAVA αντικείμενα συμπεριλαμβανομένων των ήδη υπαρχόντων αντικειμένων της JAVA ακόμα και αν δεν παρουσιάζεται ο κώδικάς τους. Παρακάτω παρουσιάζονται παραδείγματα για τον τρόπο λειτουργίας της βιβλιοθήκης. Παράδειγμα μετατροπής από αντικείμενο JAVA σε JSON Η παρακάτω κλάση (DataObject) περιέχει τρείς μεταβλητές την μεταβλητές data1, data2 και list. ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 35

36 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Εικόνα 18 Κλάση DataObject για το παράδειγμα χρήσης της βιβλιοθήκης GSON Το παρακάτω κομμάτι κώδικα όταν εκτελεστεί θα παραχθεί ένα αντικείμενο json και θα εμφανιστεί. Αυτό που θα εμφανίσει είναι το εξής: Εικόνα 19 Παράδειγμα κώδικα για παραγωγή JSON αρχείου 36 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

37 Έτσι παράγεται το αρχείο JSON. Παράδειγμα μετατροπής από JSON σε αντικείμενο JAVA Η ακριβώς αντίθετη διαδικασία μπορεί να εκτελεστεί όσων αφορά την μετατροπή ενός JSON σε αντικείμενο JAVA. Έτσι το επόμενο κομμάτι κώδικα παρουσιάζει αυτή την διαδικασία που θα μπορούσε να ακολουθηθεί στο αντικείμενο της κλάσης DataObject. Εικόνα 20 Παράδειγμα κώδικα για δημιουργία αντικειμένου από JSON αρχείου Τέλος το αποτέλεσμα του παραπάνω τμήματος κώδικα είναι να εμφανίσει: 3.2 ΒΙΒΛΙΟΘΗΚΗ PDDL4J Η PDDL4J είναι μια βιβλιοθήκη ανοιχτού κώδικα ( licence CECILL ). Στόχος της βιβλιοθήκης είναι να διευκολύνει την δημιουργία σχεδιαστών βασισμένων στη PDDL (Planning Description Language). Η βιβλιοθήκη περιέχει ένα parser της τελευταίας έκδοσης της PDDL 3.0 και όλες της κλάσεις που χρειάζονται για να διαχειριστούμε τα περιεχόμενα της. Καθώς η PDDL έχει γίνει ένα de facto πρότυπο γλώσσας για την περιγραφή του σχεδιασμού πεδίων όχι μόνο για διαγωνισμούς, αλλά ευρύτερα, καθώς προσφέρει τη δυνατότητα να ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 37

38 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ υπάρξει μια εμπειρική αξιολόγηση συστημάτων σχεδιασμού. Είναι φυσικό, η ανάδυση μιας πρότυπης γλώσσας θα έχει επιπτώσεις σε ολόκληρο τον τομέα. Η βιβλιοθήκη pddl4j μπορεί να χρησιμοποιηθεί ως ένα αρχείο jar, ονομάζεται "pddl4j.jar", έτσι το εισάγουμε στο " lib " κατάλογο της java εφαρμογής και έχουμε όλες τις δυνατότητες που μας δίνει η βιβλιοθήκη. Με χρήση της βιβλιοθήκης τα αρχεία του πεδίου και του προβλήματος διαβάζονται με αποτέλεσμα να είναι διαθέσιμη όλη η πληροφορία που χρειάζεται ο αλγόριθμος για την λειτουργία του αποθηκευμένη πλέον σε ένα αντικείμενο. Επίσης σε αυτό το σημείο, πρέπει να αναφέρουμε ότι μαζί με την βιβλιοθήκη χρησιμοποιήθηκε η υλοποίηση του graphplan (JavaGP). Η υλοποίηση του Graphplan χρησιμοποιήθηκε από την παρούσα εργασία ως ο βασικός κώδικας της υλοποίησης. Ουσιαστικά, βασιζόμενοι σε αυτή την υλοποίηση μπορέσαμε να λάβουμε όλες τις απαραίτητες πληροφορίες που χρειάζεται η υλοποίηση του validator μας. Παρακάτω είναι ένα παράδειγμα χρήσης της βιβλιοθήκης για την ανάγνωση ενός αρχείου πεδίου και ενός προβλήματος. Εικόνα 21 Παράδειγμα χρήσης της βιβλιοθήκης PDDL4J Επίσης, πρέπει να σημειωθεί ότι υπάρχει ένα ακόμα παράδειγμα υλοποίησης του graphplan ως ένα παράδειγμα χρήσης της βιβλιοθήκης, από τον δημιουργό της βιβλιοθήκης. 38 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

39 3.3 ΥΛΟΠΟΙΗΣΗ ΤΟΥ WEB SERVICE Για την δημιουργία της διαδικτυακής υπηρεσίας (web service), χρησιμοποιήθηκε η γλώσσα προγραμματισμού PHP. Η επιλογή αυτή έγινε με σκοπό τη γρήγορη ανάπτυξη και τη σωστή αρχιτεκτονική υλοποίηση του συνολικού συστήματος. Η υλοποίηση αποτελεί έναν συνδυασμό ενσωματωμένων και εξωτερικών βιβλιοθηκών της γλώσσας. Οι εξωτερικές βιβλιοθήκες επιλέχθηκαν με βασικό κριτήριο την μικρότερη εξάρτηση από τις βιβλιοθήκες και τη μεταφερσιμότητα και επεκτασιμότητα του συστήματος. Το σύστημα ακολουθεί την βασική αρχιτεκτονική του πελάτη-εξυπηρετητή (serverclient). Αρχικά, ο πελάτης συνδέεται στον εξυπηρετητή και αυτός επιστρέφει μια λίστα με τις διαθέσιμες λειτουργίες στον πελάτη. Για την επικοινωνία πελατών με τον εξυπηρετητή και την αυτόματη ανακάλυψη των λειτουργιών του εξυπηρετητή από τον πελάτη χρησιμοποιείται το πρωτόκολλο SOAP σε συνδυασμό με μηνύματα WSDL. Η PHP παρέχει έτοιμη λειτουργικότητα που διευκολύνει την δημιουργία εξυπηρετητή που υπακούει στο SOAP. Η γλώσσα όμως δεν διαθέτει λειτουργείες για την αυτόματη δημιουργία και αποστολή WSDL περιγραφών. Για αυτό το σκοπό χρησιμοποιείται η εξωτερική βιβλιοθήκη WSDLCreator ( Πιο συγκεκριμένα, εάν κάποιος πελάτης ζητήσει μέσω HTTP αιτήματος GET την παράμετρο wsdl στο βασικό URI της ηλεκτρονικής υπηρεσίας, τότε ο εξυπηρετητής δημιουργεί, με τη βοήθεια της εξωτερικής βιβλιοθήκης, την περιγραφή των λειτουργιών που προσφέρονται από την υπηρεσία. Αναλυτικότερα, αν η βασική υπηρεσία βρισκότανε στο URI τότε η κλήση στο θα μας επέστρεφε το WSDL μήνυμα με τις υπάρχουσες λειτουργίες της υπηρεσίας. Η εξωτερική βιβλιοθήκη δημιουργεί αυτόματα τις περιγραφές WSDL με το να διαπερνά εξωτερικά αρχεία τα οποία δηλώνουν κλάσεις της γλώσσας PHP. Εάν το εξωτερικό αρχείο περιέχει λεπτομερείς τεκμηριώσεις των διάφορων μεθόδων και αυτές οι τεκμηριώσεις είναι γραμμένες με το πρότυπο PHPDoc τότε το wsdl-creator μπορεί να δημιουργήσει ένα σωστά δομημένο WSDL. H διαχείριση των εξωτερικών βιβλιοθηκών γίνεται μέσω του προγράμματος Composer, κάτι το οποίο συμβάλλει στην μεταφερσιμότητα του συνόλου του κώδικα του συστήματος. Από τα παραπάνω μπορεί κανείς εύκολα να συμπεράνει ότι η βασική λειτουργικότητα της υπηρεσίας συγκεντρώνεται σε αυτό το εξωτερικό αρχείο. Στη περίπτωσή μας, το αρχείο Library.php περιέχει τις μεθόδους rungraphplan, ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 39

40 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ runvalidate και factdefinition. Σε κάθε μία από αυτές, ο χρήστης περνάει σαν όρισμα 2 αρχεία τα οποία αντιστοιχούν στο πεδίο και τη περιγραφή του προβλήματος δοσμένα σε PDDL μορφή. Στη συνέχεια τα αποθηκεύει σε προσωρινά αρχεία τα οποία ισχύουν μόνο για την διάρκεια του session μεταξύ πελάτηεξυπηρετητή, καλεί την υλοποίηση του Graphplan με όρισμα τα προσωρινά αρχεία, ελέγχει για λάθη κατά την διάρκεια της εκτέλεσής του και επιστρέφει το κατάλληλο αποτέλεσμα στον πελάτη. Εικόνα 22 Παράδειγμα κώδικα PHP της βιβλιοθήκης WSDLCreator 40 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

41 Κ Ε Φ Α Λ Α Ι Ο 4 : Υ Π Η Ρ Ε Σ Ι Α Ε Υ Ρ Ε Σ Η Σ ΔΥ Ν Α Μ Ι Κ Ω Ν Κ Α Ι Σ ΤΑΤ Ι Κ Ω Ν Γ Ε Γ Ο Ν Ο Τ Ω Ν ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 41

42 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ 4 ΥΠΗΡΕΣΙΑ ΕΥΡΕΣΗΣ ΔΥΝΑΜΙΚΩΝ ΚΑΙ ΣΤΑΤΙΚΩΝ ΓΕΓΟΝΟΤΩΝ Η εύρεση στατικών και δυναμικών γεγονότων κατά τον σχεδιασμό προβλημάτων αποτελεί σημαντική πληροφορία για τον χρήστη. Πολλές φορές, ιδίως στα γραφικά σχεδιαστικά περιβάλλοντα, ο χρήστης κατά τον σχεδιασμό κάποιων ενέργειων μπορεί να παραλήψει είτε να έχει κάποιο γεγονός στη λίστα προσθήκης είτε να έχει κάποιο γεγονός αμετάβλητο ενώ θα ήθελε να διαγράφεται από κάποια ενέργεια. Για τους λόγους, υλοποιήσαμε μία υπηρεσία ιστού στην οποία εισάγονται ένα πεδίο και ένα πρόβλημα και έχει ως έξοδο μια λίστα στατικών και μια λίστα δυναμικών γεγονότων. 4.1 ΑΛΓΟΡΙΘΜΟΣ ΕΥΡΕΣΗΣ ΔΥΝΑΜΙΚΩΝ ΚΑΙ ΣΤΑΤΙΚΩΝ ΓΕΓΟΝΟΤΩΝ Αρχικά θα πρέπει να γίνει σαφές τι είναι στατικό και τι δυναμικό γεγονός σε ένα πρόβλημα σχεδιασμού. Στατικό Γεγονός είναι ένα γεγονός που δεν μπορεί να διαγραφεί από καμία ενέργεια και πιο τυπικά: ένα γεγονός f είναι στατικό για ένα πρόβλημα p αν το f είναι μέρος τις αρχικής κατάστασης του p και καμία ενέργεια δεν μπορεί να το διαγράψει. Δυναμικό Γεγονός είναι ένα γεγονός που μπορεί να διαγραφεί από κάποια ενέργεια του πεδίου. Ουσιαστικά είναι το ακριβώς αντίθετο του στατικού γεγονότος. Παρακάτω παρουσιάζεται το πεδίο του gripper, σε αυτό το πεδίο για παράδειγμα τα γεγονότα room, ball, gripper είναι στατικά αφού δεν αφαιρούνται από καμία ενέργεια ενώ τα γεγονότα at-robby, at, free, carry είναι δυναμικά αφού μπορούν να διαγραφούν από κάποια-κάποιες ενέργεια. Στο παρακάτω παράδειγμα (Εικόνα 23 Παράδειγμα Στατικών και Δυναμικών Γεγονότων) τα κίτρινα βέλη συνδέουν τα αποτελέσματα (λίστες διαγραφής) των ενεργειών με τα δυναμικά γεγονότα. 42 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

43 Στατικά Γεγονότα Δυναμικά Γεγονότα Εικόνα 23 Παράδειγμα Στατικών και Δυναμικών Γεγονότων Όπως αναφέρθηκε και πρωτύτερα, η εύρεση στατικών και δυναμικών γεγονότων κατά τον σχεδιασμό προβλημάτων είναι μια χρήσιμη πληροφορία για τον χρήστη κυρίως όταν αναφερόμαστε σε γραφικά σχεδιαστικά περιβάλλοντα, ο χρήστης μπορεί, κατά τον σχεδιασμό των ενέργειων του πεδίου, να συμπεριλάβει κάποιο γεγονός στη λίστα διαγραφής ή να έχει κάποιο γεγονός στατικό ενώ θα ήθελε να διαγράφεται από κάποια ενέργεια. Η λειτουργία της υπηρεσίας είναι εξαιρετικά απλή, αρχικά βρίσκουμε το σύνολο όλων των εκτελέσιμων ενεργειών. Έχοντας, λοιπόν, όλες τις εκτελέσιμες ενέργειες για κάθε ενέργεια βρίσκουμε το σύνολο των γεγονότων που υπάρχουν στη λίστα διαγραφής και το αφαιρούμε από το σύνολο των γεγονότων-σχέσεων. Εκτελώντας την παραπάνω διαδικασία για κάθε ενέργεια, αφαιρώντας δηλαδή συνέχεια από το σύνολο, που αρχικά είχε τις αρχικές σχέσεις, την λίστα διαγραφής της εκάστοτε ενέργειας στο τέλος θα έχουν μείνει στο σύνολο μόνο τα στατικά γεγονότα (δηλαδή τα γεγονότα που δεν διαγράφονται από καμία ενέργεια). Γίνεται εύκολα σαφές ότι έχοντας τα στατικά γεγονότα μπορούμε απλώς αφαιρώντας τα από τα αρχικά γεγονότα να βρούμε τα μη στατικά γεγονότα. Έτσι η υπηρεσία ιστού μας στέλνει δύο λίστες του τύπου {Στατικά_Γεγονότα :[ ΣτατικόΓεγονός_1, ΣτατικόΓεγονός _2., ΣτατικόΓεγονός_κ], Δυναμικά_Γεγονότα :[ΔυναμικόΓεγονός_1, ΔυναμικόΓεγονός_2., ΔυναμικόΓεγονός_λ]} 4.2 ΥΛΟΠΟΙΗΣΗ ΑΛΓΟΡΙΘΜΟΥ Όπως αναφέρθηκε και παραπάνω, για την υλοποίηση χρησιμοποιήθηκε η βιβλιοθήκη pddl4j. Έτσι, αρχικά εισάγουμε τα αρχεία του domain και του problem και τα προσπελαύνουμε με την διαδικασία parse. ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 43

44 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Μετά συνδέουμε τα αρχεία με την διαδικασία link και αφού έχουμε αρχικοποιήσει τις μεταβλητές μας εκτελούμε την μέθοδο μας factsdefinition. Αρχικά, αποθηκεύουμε σε μια λίστα από γεγονότα τα αρχικά γεγονότα-σχέσης. Μετά από την λίστα των σχέσεων αφαιρούμε τις σχέσεις που βρίσκονται στη λίστα προσθήκης και την λίστα διαγραφής κάθε δυνατής ενέργειας, έτσι ότι μείνει στη λίστα είναι ουσιαστικά τα στατικά γεγονότα. Τέλος, από τις αρχικές σχέσεις αφαιρούμε τα στατικά γεγονότα και ότι μας μείνει είναι τα δυναμικά γεγονότα. Εικόνα 24 Κώδικας Εύρεσης Δυναμικών και Στατικών Γεγονότων 4.3 JSON ΑΝΑΠΑΡΑΣΤΑΣΗ Για την αναπαράσταση των δεδομένων χρησιμοποιούμε, όπως προείπαμε, json αρχεία με την βοήθεια της βιβλιοθήκης GSON. Όλα τα δεδομένα που χρειάζεται να αποσταλούν αποθηκεύονται σε ένα αντικείμενο της κλάσης ResponseFacts.java που δημιουργήσαμε και περιέχει της παρακάτω μεταβλητές. 44 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

45 Εικόνα 25 Μεταβλητές της Κλάσης ResponseFacts Στη μεταβλητή parsermessage αποθηκεύεται το μήνυμα του parser κατά την εκτέλεσή του. Στη μεταβλητή staticfacts αποθηκεύονται τα στατικά γεγονότα του προβλήματος. Και τέλος, στη μεταβλητή dynamicfacts αποθηκεύονται τα δυναμικά γεγονότα του προβλήματος. { "parsermessage": "Parser warning at line 1, column 18 file (800554ee3f3b3563e pddl) : problem \ "defaultproblem\" must be defined in a file \ "defaultproblem.pddl\".\r\nparser warning at line 1, column 17 file ( ee3f3b pddl) : Domain \ "defaultdomain\" should be defined in a file \ "defaultdomain.pddl\".\r\n\nparsing domain \ "defaultdomain\" done successfully...parsing problem \ "defaultproblem\" done successfully...\n\r\npreprocessing...\n\r\n", Μήνυμα Parser "staticfacts": [ "class1 ", "class2" Στατικά Γεγονότα ], "dynamicfacts": [ "relation1", "relation3" Δυναμικά Γεγονότα ] } Εικόνα 26 Παράδειγμα αρχείου JSON Παραπάνω (Εικόνα 26) παρουσιάζεται ένα παράδειγμα ενός json αρχείου της μεθόδου μας. Το αρχείο αυτό παράχθηκε με την βοήθεια της βιβλιοθήκης gson. Τέλος, παρουσιάζεται ο κώδικας για την μετατροπή του αντικειμένου σε JSON μορφή (Εικόνα 27). Εικόνα 27 Κώδικας για την Μετατροπή του Αντικειμένου σε JSON μορφή ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 45

46 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Κ Ε Φ Α Λ Α Ι Ο 5 : Ε Υ Ρ Ε Σ Η Ε Π Ι ΛΥ Σ Ι Μ Ο Τ Η ΤΑ Σ Π Ρ Ο Β Λ Η Μ ΑΤ Ω Ν Σ Χ Ε Δ Ι Α Σ Μ Ο Υ 46 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

47 5 ΕΥΡΕΣΗ ΕΠΙΛΥΣΙΜΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ Στη περιοχή του σχεδιασμού ενεργειών έχουν αναπτυχθεί διάφορα εργαλεία είτε για την συγγραφή, είτε αυτοματοποιημένη δημιουργία προβλημάτων και πεδίων σχεδιασμού μέσα από γραφικά περιβάλλοντα. Ένα ανοιχτό όμως πεδίο έρευνας, που με αυτό ασχολείται η παρούσα εργασία, είναι η επικύρωση της επιλυσιμότητας των στόχων ενός προβλήματος. Πιο συγκεκριμένα, έγινε προσπάθεια, αρχικά, να δημιουργηθεί μια μέθοδος η οποία θα είχε ως είσοδο ένα πεδίο και κάποιους στόχους και ως έξοδο θα μας επέστρεφε ποιοι στόχοι μπορούν να επιτευχθούν και ποιοι όχι. Επίσης σε επόμενο στάδιο, πετύχαμε εκτός από αυτό να ανακαλύπτουμε τις αιτίες της μη επίτευξης των στόχων αυτών. Όπως μπορεί να γίνει εύκολα σαφές, μια τέτοια μέθοδος θα μπορούσε να είναι βοηθητική σε εργαλεία σχεδιασμού πεδίων και στόχων. Έχοντας λοιπόν αυτή την πληροφορία, δηλαδή ποιοι στόχοι δεν μπορούν να επιτευχθούν και γιατί, ο χρήστης θα μπορούσε ευκολότερα να διορθώσει τυχών λάθη που θα είχε στο σχεδιασμό. 5.1 ΑΛΓΟΡΙΘΜΟΣ ΕΥΡΕΣΗΣ ΕΠΙΛΥΣΙΜΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ Η μέθοδός μας είναι βασισμένη στην διαδικασία που χρησιμοποιούν οι γράφοι σχεδιασμού για την εύρεση λύσης και πιο συγκεκριμένα ο Graphplan. Όπως αναφέρθηκε και σε προηγούμενο κεφάλαιο, ο Graphplan σταματάει εάν βρεθεί λύση ή αν στο τελευταίο προτασιακό επίπεδο (level-off) δεν μπορεί να βρεθεί σύνολο ενεργειών το οποίο πετυχαίνει νέους στόχους χωρίς αμοιβαίους αποκλεισμούς. Όμως θα πρέπει να γίνει σαφές ότι κατά την δημιουργία του γράφου σχεδιασμού κάποιο προτασιακό επίπεδο είναι υπερσύνολο των προηγούμενων προτασιακών επιπέδων. Επίσης ένα άλλο σημείο που λάβαμε υπόψιν μας είναι ότι η κατασκευή του γράφου ώστε να φτάσει στο level-off είναι πιο εύκοληγρήγορη από την κατασκευή του σταδιακά και την αναζήτηση λύσης σε κάθε επίπεδο. Έχοντας πάρει υπόψιν μας όλα αυτά η διαδικασία μας αφήνει τον γράφου το Graphplan να φτάσει σε level-off και ελέγχει κάποιες περιπτώσεις στα τελευταία επίπεδα του γράφου, συγκεκριμένα στα δύο τελευταία επίπεδα γεγονότων και στο τελευταίο επίπεδο ενεργειών, καθώς και στο σύνολο των ενεργειών. ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 47

48 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Η πιο απλή περίπτωση που εξετάστηκε είναι η περίπτωση για έναν στόχο να μην υπάρχει ενέργεια που να τον πετυχαίνει. Αυτό το πετύχαμε αναζητώντας στο σύνολο ενεργειών αν υπάρχει μία ενέργεια που να έχει ως θετικό αποτέλεσμα (positive effect) το στόχο που εξετάζουμε και φυσικά ο στόχος να μην υπάρχει στην αρχική κατάσταση. Έτσι, για κάθε στόχο ελέγχουμε, με την παραπάνω διαδικασία, αν δεν υπάρχει καμία ενέργεια να τον πετύχει. Η δεύτερη περίπτωση που εξετάσαμε είναι αν κάποιος στόχος εμπλέκεται σε κάποιον αμοιβαίο αποκλεισμό με κάποιον άλλο στόχο. Γνωρίζοντας ότι ο Graphplan κρατάει κατά την εκτέλεση του μία λίστα με όλους τους αμοιβαίους αποκλεισμούς ήταν εύκολο να βρούμε ποιοι από τους στόχους είναι αμοιβαίως αποκλεισμένοι. Επίσης, βασισμένοι στο γεγονός ότι οι αμοιβαίοι αποκλεισμοί καθώς και τα γεγονότα σε κάποιο επίπεδο του γράφου είναι υπερσύνολο όλων των προηγούμενων επιπέδων, γίνεται ξεκάθαρο ότι θα έπρεπε απλά να ελεγχθεί μόνο το τελευταίο επίπεδο (level-off). Έχοντας, λοιπόν, τις απαραίτητες πληροφορίες για τους αμοιβαίως αποκλεισμένους στόχους σκεφτήκαμε ότι θα ήταν ακόμα πιο ξεκάθαρο για τον χρήστη αν γνώριζε και την αιτία του αμοιβαίου αποκλεισμού. Οι λόγοι για τους οποίους δύο ενέργειες είναι αμοιβαίως αποκλειόμενες είναι: 1) Ασυνεπή Αποτελέσματα (Inconsistent effects),δηλαδή η μία διαγράφει ένα αποτέλεσμα της άλλης Προτασιακό Επίπεδο (Level-off)-1 Επίπεδο Ενεργειών Προτασιακό Επίπεδο Level-off Εικόνα 28 Ασυνεπή Αποτελέσματα 2) Παρεμβολή (Interference), η μία διαγράφει μια προϋπόθεση της άλλης Προτασιακό Επίπεδο (Level-off)-1 Επίπεδο Ενεργειών Προτασιακό Επίπεδο Level-off Εικόνα 29 Παρεμβολή 48 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

49 3) Ανταγωνιστικές Προϋποθέσεις (Competing needs), δηλαδή έχουν προϋποθέσεις που είναι αμοιβαίως αποκλειόμενες. Προτασιακό Επίπεδο (Level-off)-1 Επίπεδο Ενεργειών Προτασιακό Επίπεδο Level-off Εικόνα 30 Ανταγωνιστικές Προϋποθέσεις Έτσι με τις πληροφορίες για τις ενέργειες που εμπλέκονται στους αμοιβαίους αποκλεισμούς καθώς και τις λίστες προσθήκης, διαγραφής και προϋποθέσεων μπορούμε να ελέγξουμε τι είδους αμοιβαίου αποκλεισμού έχουμε. Για τα ασυνεπή αποτελέσματα, δύο ενεργειών, ελέγχεται η τομή της λίστας προσθήκης της μίας με την λίστα διαγραφής της άλλης αν το αποτέλεσμα είναι διάφορο του κενού συνόλου τότε έχουμε ασυνεπή αποτελέσματα. Για την παρεμβολή, ελέγχεται η τομή της λίστας διαγραφής της μίας ενέργειας με την λίστα προϋποθέσεων της άλλης αν είναι διάφορη του κενού συνόλου τότε έχουμε παρεμβολή. Τέλος για τις ανταγωνιστικές προϋποθέσεις ελέγχεται το σύνολο αμοιβαίων αποκλειόμενων του προηγούμενου επιπέδου. Έτσι για κάθε ζεύγος αμοιβαίως αποκλειόμενων στόχων ουσιαστικά έχουμε μία λίστα αποτελούμενης από τέσσερα στοιχεία της μορφής (στόχος_1, στόχος_2, ενέργεια_1, ενέργεια_2, τύπος αποκλεισμού). Ακόμα, δύο στόχοι μπορεί να είναι αμοιβαίως αποκλειόμενοι για παραπάνω από μία αιτία έτσι οι αμοιβαίοι αποκλεισμοί είναι μία λίστα. Πρέπει να σημειώσουμε επίσης ότι μια ενέργεια μπορεί να είναι και no-op ενέργεια δηλαδή ουσιαστικά ένα γεγονός μπορεί να είναι αμοιβαίως αποκλειόμενο με μία ενέργεια. Τελευταία περίπτωση που εξετάζουμε είναι αν κάποιος στόχος ενώ δυνητικά μπορεί να επιτευχθεί με κάποια ενέργεια, δεν υπάρχει στο τελευταίο επίπεδο (level-off). Αυτό μπορεί να συμβεί αν η ενέργεια δεν υπάρχει στο τελευταίο επίπεδο ενεργειών και κατ επέκταση κάποια από τις προϋποθέσεις της ενέργειας δεν βρίσκεται στο (level-off)-1 επίπεδο. Σε αυτή την περίπτωση, για να γίνει πιο κατανοητό στο χρήστη το πρόβλημα που υπάρχει, εκτός από το προβληματικό στόχο αναφέρουμε μια λίστα από πιθανές ενέργειες που μπορούν να τον πετύχουν καθώς και τις προϋποθέσεις κάθε ενέργειας, δηλαδή για κάθε στόχο έχουμε δεδομένα της μορφής {Στόχος,[ {ενέργεια_1,[προϋποθέσεις_1]} {ενέργεια_2,[προϋποθέσεις_2]}.. {ενέργεια_ν,[προϋποθέσεις_ν]}]}. Με αυτόν τον τρόπο, ο χρήστης του προγράμματος θα μπορούσε να ανατροφοδοτήσει την μέθοδο με τις προϋποθέσεις κάποιας ενέργειας (δηλαδή κάποιας ενέργειας που περίμενε ο χρήστης ότι θα μπορούσε να εκτελεστεί) ώστε να εκτελεστεί ξανά η μέθοδος και να επιστρέψει στο χρήστη ποια προϋπόθεση δεν επιτεύχθηκε και γιατί. ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 49

50 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ 5.2 ΥΛΟΠΟΙΗΣΗ ΑΛΓΟΡΙΘΜΟΥ Όπως και στην εύρεση Δυναμικών και Στατικών Γεγονότων, έτσι και σε αυτή την υλοποίηση χρησιμοποιήθηκε η βιβλιοθήκη pddl4j και βασίστηκε και σε ένα παράδειγμα υλοποίησης του graphplan ( Αφού εισάγουμε τα αρχεία και κάνουμε την αρχικοποίηση, όπως περιγράφηκε στο κεφάλαιο 4.2, επεκτείνουμε τον γράφο του Graphplan μέχρι να φτάσει στο level-off σημείο του. Εικόνα 31 Κώδικας Επέκτασης του Γράφου Σχεδιασμού Όπως αναφέραμε και στον αλγόριθμο, αυτό γίνεται αρκετά γρήγορα γιατί δεν ψάχνουμε λύση απλά επεκτείνουμε τον γράφο. Χρησιμοποιώντας, σε αυτό το σημείο τη μέθοδο goalspossible, που είναι ήδη υλοποιημένες στο παράδειγμα του graphplan, βρίσκουμε αν στο επίπεδο του level-off επιτυγχάνονται οι στόχοι και αν δεν υπάρχουν αμοιβαίως αποκλειόμενοι στόχοι. Στην περίπτωση που οι στόχοι δεν είναι πιθανοί στο τελευταίο επίπεδο καλούμε τρεις μεθόδους. Για την εύρεση των μη επιτεύξιμων στόχων εκτελούμε τις μεθόδους nooperatorgoals και nonachivablegoals. Με τη μέθοδο nooperatorgoals, ελέγχουμε αν υπάρχουν στόχοι που δεν μπορούν να επιτευχθούν από καμία ενέργεια. Αυτό το κάνουμε με την βοήθεια της κλάσης OperatorFactory (ήδη υλοποιημένη κλάση) και την συνάρτηση getcausingoperatorstemplates που επιστρέφει μια λίστα από templates ενεργειών που εν δυνάμει θα μπορούσαν να πετύχουν τον στόχο. Αν η λίστα είναι άδεια τότε προσθέτουμε τον στόχο στους στόχους που δεν έχει δημιουργηθεί ενέργεια να τους πετυχαίνει. 50 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

51 Εικόνα 32 Κώδικας για Εύρεση Στόχων που δεν Επιτυγχάνονται από καμία Ενέργεια Μετά ψάχνουμε τους στόχους που υπάρχει ενέργεια που τους πετυχαίνει αλλά δεν μπορεί να εκτελεστεί. Αυτό το πετυχαίνουμε όπως στο προηγούμενο βήμα απλά τώρα κρατάμε και μία λίστα από τις ενέργειες που πετυχαίνουν το στόχο. Αυτό μπορεί να βοηθήσει το χρήστη σε μια επόμενη διαδικασία να κάνει ανατροφοδότηση στο σύστημά μας. Για την δημιουργία των ενεργειών χρησιμοποιούμε την συνάρτηση getallpossibleinstantiations όπου υπάρχει υλοποιημένη στο κώδικα της υλοποίησης και παίρνει ως είσοδο ένα επίπεδο γράφου και τις ενέργειες (templates) και να τις εφαρμόσει. Έτσι αυτό που έπρεπε να κάνουμε είναι να δημιουργήσουμε ένα επίπεδο γεγονότων. Αυτό το πετύχαμε με την συνάρτηση getoperatorprecontitionlayer, όπου έχει ως είσοδο μια ενέργεια, τα αρχικά δεδομένα καθώς και στατικά και δυναμικά γεγονότα, τα οποία τα βρίσκουμε όπως έχουμε πει παραπάνω. Αυτό που κάνει η συνάρτηση, είναι να βρει από τις προϋποθέσεις ποιες είναι στατικές και ποιες δυναμικές καθώς και να γίνει αντικατάσταση από την αρχική κατάσταση του προβλήματος αυτών των προϋποθέσεων. Έτσι δημιουργούμε το επίπεδο των γεγονότων στο οποίο θα εφαρμοστεί η ενέργεια. ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 51

52 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Εικόνα 33 Κώδικας για Εύρεση Ενεργειών που Επιτυγχάνουν Κάποιο Στόχο Για όσες ενέργειες δεν υπάρχει δυνατότητα να εφαρμοστούν (γιατί δεν υπάρχουν στατικές προϋποθέσεις στην αρχική κατάσταση ή κάποια δυναμική ενέργεια έχει σχεδιαστεί ως στατική λάθος) στέλνουμε μόνο το όνομα της ενέργειας με κενή την λίστα των προϋποθέσεων. Εικόνα 34 Κώδικας για Εύρεση Ενεργειών (templates) που Επιτυγχάνουν κάποιο Στόχο Αφού έχουμε βρει τους στόχους που δεν πετυχαίνονται πρέπει να βρούμε τώρα τους αμοιβαίως αποκλυόμενους στόχους. Αρχικά για κάθε στόχο παίρνουμε το σετ των αμοιβαίως αποκλυόμενων γεγονότων στο επίπεδο του level-off. Αυτό πετυχαίνεται με την συνάρτηση getresponsemutexes. Εικόνα 35 Κώδικας για Εύρεση Αμοιβαίως Αποκλειόμενους Στόχους Μετά βρίσκουμε τις ενέργειες που πετυχαίνουν τον ένα στόχο και τις ενέργειες που πετυχαίνουν τον δεύτερο στόχο. Το επόμενο μας βήμα είναι να βρούμε την αιτία του 52 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

53 αμοιβαίου αποκλεισμού για κάθε ζεύγος ενεργειών. Έτσι προσπελαύνουμε τις δύο λίστες με τις ενέργειες και έχουμε ξεχωριστό έλεγχο για την κάθε δυνατή περίπτωση αποκλεισμού ενεργειών. Παρακάτω (Εικόνα 36) εμφανίζουμε των κώδικα των ελέγχων για τις περιπτώσεις αυτές. Εικόνα 36 Κώδικας για Εύρεση των Αιτίων των Αμοιβαίων Αποκλειόμενων Πρέπει να σημειώσουμε ότι για τις ανταγωνιστικές προϋποθέσεις αποστέλλουμε και την λίστα με τις αμοιβαίως αποκλειώμενες προϋποθέσεις των ενεργειών από το level-off επιπέδου ώστε ο χρήστης τις υπηρεσίας να μπορεί να έχει μια πλήρη εποπτεία του σφάλματος. Επίσης σε κάθε περίπτωση οι ενέργειες στέλνονται αυτούσιες, δηλαδή μαζί με το όνομα τους στέλνουμε και τις λίστες των προϋποθέσεων, προσθήκης και διαγραφής. ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 53

54 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ 5.1 JSON ΑΝΑΠΑΡΑΣΤΑΣΗ Για την αναπαράσταση των δεδομένων χρησιμοποιούμε, όπως προείπαμε, json αρχεία με την βοήθεια της βιβλιοθήκης GSON. Όλα τα στοιχεία που πρέπει να αποσταλούν αποθηκεύονται σε ένα αντικείμενο της κλάσης ResponseValidate.java και περιέχει τις παρακάτω μεταβλητές. Εικόνα 37 Μεταβλητές της Κλάσης ResponseValidate Στη μεταβλητή parsermessage αποθηκεύεται το μήνυμα του parser κατά την εκτέλεσή του. Η μεταβλητή result επιστρέφει Right αν το πρόβλημα είναι επιλύσιμο ή Wrong αν δεν είναι επιλύσιμο. Στη μεταβλητή noopergoals περιέχονται οι στόχοι που δεν υπάρχει ενέργεια να τους πετυχαίνει. Στη μεταβλητή nonachievablegoals επιστρέφονται οι στόχοι που δεν πετυχαίνονται αν και υπάρχουν ενέργειες να τους πετύχουν, επίσης κάθε στόχος συνοδεύεται από την λίστα των ενεργειών που τον πετυχαίνουν. Η μεταβλητή mutexedgoals περιέχει μια λίστα από αμοιβαίους αποκλεισμούς του προβλήματος. Οι αμοιβαίοι αποκλεισμοί αναπαρίστανται με τη δομή Mutex που έχει τους δύο στόχους, τις δύο ενέργειες που τους πετυχαίνουν και τον λόγο του αμοιβαίου αποκλεισμού. Τέλος, στην μεταβλητή achievablegoals επιστρέφονται οι στόχοι που πετυχαίνονται. "nonachievablegoals": { }, "(relation4 class2obj)": [ ] { } "operation": "(operator1 class1obj class2obj)", "Precontitions": [ ], "(class1 class1obj)", "(class2 class2obj)", "(relation1 class1obj)", "(relation3 class2obj)" Προϋποθέσεις της Ενέργειας Όνομα Ενέργειας Εικόνα 38 Τμήμα JSON Αρχείου για μη Επιτεύξιμους Στόχους Στο παραπάνω τμήμα (Εικόνα 38) εμφανίζεται ένας στόχος που δεν πετυχαίνεται ενώ υπάρχει ενέργεια να τον πετύχει. Δηλαδή δεν μπορεί να εκτελεστεί η ενέργεια που θα μπορούσε να πετύχει τον στόχο. Μαζί με την ενέργεια αποστέλλονται και οι προϋποθέσεις της. 54 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

55 { "mutexedgoals": [ ] } "goal1": "(relation2 class1obj)", "goal2": "(relation4 class2obj)", "reason": "Competing needs", "action1": { }, "operation": "(noop-relation2 class1obj)", "Precontitions": [ ], "(relation2 class1obj)" "negeffects": [ ], "poseffects": [ ] "(relation2 class1obj)" "action2": { }, "operation": "(noop-relation4 class2obj)", "posprecontitions": [ ], "(relation4 class2obj)" "negeffects": [ ], "poseffects": [ ] "(relation4 class2obj)" "usefulfacts": [ ] "(relation2 class1obj)", "(relation4 class2obj)" Στόχος 1 Στόχος 2 Όνομα Ενέργειας Αιτία Ενέργεια 1 Προϋποθέσεις Αρνητικά Αποτελέσματα Θετικά Αποτελέσματα Ενέργεια 2 Βοηθητική Λίστα με Αμοιβαίους αποκλεισμούς σε προηγούμενο επίπεδο Εικόνα 39 Τμήμα Αρχείου JSON για Αμοιβαίως Αποκλειόμενους Στόχους Σε αυτό το τμήμα του JSON αρχείου (Εικόνα 39) παρουσιάζεται η αναπαράσταση ενός αμοιβαίου αποκλεισμού. Όπως προείπαμε, υπάρχουν τα ονόματα των δύο αμοιβαίως αποκλειόμενων στόχων, τον λόγο του αποκλείσμου, τις δύο ενέργειες που τους πετυχαίνουν, μαζί φυσικά με τις προϋποθέσεις και τα αποτελέσματα τους και, τέλος, μια λίστα βοηθητική λίστα. Η βοηθητική λίστα περιέχει τα αμοιβαίως αποκλειόμενα γεγονότα των προϋποθέσεων των ενεργειών, μόνο στη περίπτωση των ανταγωνιστικών προϋποθέσεων. ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 55

56 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Κ Ε Φ Α Λ Α Ι Ο 6 : Α Ξ Ι Ο Λ Ο Γ Ι Σ Η Α Π Ο Τ Ε Λ Ε Σ Μ ΑΤ Ω Ν 56 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

57 6 ΑΞΙΟΛΟΓΗΣΗ ΑΠΟΤΕΛΕΣΜΑΤΩΝ Σε αυτό το κεφάλαιο παρουσιάζεται η σύνδεση των υπηρεσιών ιστού με το πρόγραμμα γραφικού σχεδιασμού για προβλήματα σχεδιασμού Vleppo (Hatzi, Vrakas, Bassiliades, Anagnostopoulos, & Vlahavas, 2007), καθώς, και ανάλυση κάποιων λανθασμένων προβλημάτων σχεδιασμού, που αναπτύχθηκαν από φοιτητές στα πλαίσια του μαθήματος της τεχνητής νοημοσύνης. Τον τρόπο σύνδεσης καθώς και την ανάπτυξη του γραφικού περιβάλλοντος παρουσιάζει η πτυχιακή εργασία. 6.1 ΣΥΝΔΕΣΗ ΜΕ ΤΟ VLEPPO Παρακάτω, παρουσιάζουμε κάποια παραδείγματα σχεδίασης γνωστών πεδίων. Πιο συγκεκριμένα, εστιάζουμε στο πεδίο των κύβων. Όπως βλέπουμε, ο κύβος έχει τρεις σχέσεις την isfree, που δείχνει αν κάποιος κύβος δεν έχει άλλον κύβο πάνω του, την ontable, που αναφέρεται στο αν ο κύβος είναι πάνω στο τραπέζι, και τέλος, την on, που συσχετίζει δύο κύβους και δείχνει αν ο ένας κύβος βρίσκεται πάνω από τον άλλο. Στο επόμενο σχήμα (Εικόνα 40 Παράδειγμα Προβλήματος Κύβων) παρουσιάζεται η επιθυμητή αρχική και η επιθυμητή τελική κατάσταση για το χρήστη. A C B C A B Αρχική Τελική Εικόνα 40 Παράδειγμα Προβλήματος Κύβων Το στοιχείο tools είναι το μενού που μπορεί ο χρήστης να επιλέξει είτε για να βρει τα δυναμικά και στατικά γεγονότα (Facts Definition) είτε για την εξακρίβωση της επιλυσιμότητας του προβλήματος (Validate) όπως εμφανίζεται στο σχήμα(εικόνα 41). Εικόνα 41 Μενού του Vleppo ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 57

58 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Το εσκεμμένο λάθος σε αυτό το πρόβλημα (Εικόνα 42) είναι ότι σε όλους τους τελεστές έχουμε στη λίστα διαγραφής τη σχέση isfree. Αυτό είναι ένα αρκετά συχνό λάθος που μπορεί να συμβεί σε αυτό το σχεδιαστικό πρόγραμμα. Εικόνα 42 Παράδειγμα Σχεδιασμού στο Γραφικό Εργαλείο Vleppo Κατά την εκτέλεση της υπηρεσίας ιστού για την εύρεση στατικών και δυναμικών γεγονότων, του προβλήματος που περιγράψαμε παραπάνω, εμφανίζεται το παρακάτω παράδειγμα (Εικόνα 43). Έτσι τα δυναμικά γεγονότα του προβλήματος είναι οι σχέσεις ontable, isfree, και την on και τα στατικά είναι η σχέση cube. Εικόνα 43 Πλαίσιο Διαλόγου για Στατικά και Δυναμικά Γεγονότα Κατά την εκτέλεση της υπηρεσίας ιστού για την εύρεση της επιλυσιμότητας του προβλήματος, για αυτό το λανθασμένο πεδίο, εμφανίζεται η παρακάτω φόρμα (Εικόνα 44) η οποία έχει μία λίστα στόχων που μπορούν να επιτευχθούν, στη περίπτωσή μας το ontable 58 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

59 C, και μία λίστα στόχων που δεν μπορούν να επιτευχθούν, στη περίπτωσή μας το στόχο on B A. Εικόνα 44 Πλαίσιο Διαλόγου για Επιτεύξιμους και Μη Επιτεύξιμους Στόχους Επιλέγοντας το στόχο και τις λεπτομέρειες του εμφανίζεται το παρακάτω γραφικό (Εικόνα 45) για στόχους που δεν μπορούν να επιτευχθούν. Για κάθε στόχο μπορούμε να επιλέξουμε μια ενέργεια που μπορεί να τον πετύχει και να εμφανιστούν οι προϋποθέσεις τις ενέργειας με τον ίδιο τρόπο, δηλαδή με κόκκινους κύκλους οι προϋποθέσεις που δεν επιτυγχάνονται και με πράσινο αυτές που επιτυγχάνονται. Όταν δεν υπάρχει ενέργεια που να πετυχαίνει ένα στόχο εμφανίζεται ανάλογο μήνυμα, όπως φαίνεται στη παρακάτω εικόνα. Εικόνα 45 Γραφική Διεπαφή για Ανατροφοδότηση ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 59

60 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Ακόμα, η εύρεση σφαλμάτων μπορεί να ανακαλύψει και σφάλματα που οφείλονται σε αμοιβαίους αποκλεισμούς. Για παράδειγμα, στο παραπάνω πρόβλημα αλλάζοντας τους επιθυμητούς στόχους θα μπορούσαμε να έχουμε τον στόχο (on C B) και τον (on B A). Στο γραφικό περιβάλλον όμως εύκολα κάποιος μπορεί να κάνει λάθος και να ζητήσει ως επιθυμητή κατάσταση την κατάσταση (on C B) και (on C A). Εικόνα 46 Γραφική Διεπαφή για Αμοιβαίως Αποκλειώμενους Στόχους Επιλέγοντας, λοιπόν, ένα στόχο εμφανίζεται η παραπάνω καρτέλα (Εικόνα 46) όπου ο χρήστης μπορεί να επιλέξει τους στόχους που τον ενδιαφέρουν, καθώς, και ποια ενέργεια θα πετυχαίνει το εκάστοτε στόχο. Αφού γίνει αυτή η επιλογή στο δεξί κομμάτι του παραθύρου εμφανίζονται οι προϋποθέσεις των ενεργειών, τα θετικά και τα αρνητικά αποτελέσματα και, τέλος, η αιτία του αμοιβαίου αποκλεισμού. Για παράδειγμα, στο σχήμα (Εικόνα 46) έχουμε τις ενέργειες (movefromtable C A) και (movefromtable C B) που έχουν ως λόγο αμοιβαίου αποκλεισμού την παρεμβολή (interference) αφού η μία έχει ως προϋπόθεση το (ontable C) ενώ η άλλη το έχει στη λίστα διαγραφής της. 60 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

61 6.2 ΠΑΡΑΔΕΙΓΜΑ ΕΡΓΑΣΙΑΣ ΣΤΑ ΠΛΑΙΣΙΑ ΤΟΥ ΜΑΘΗΜΑΤΟΣ ΤΕΧΝΗΤΗΣ ΝΟΗΜΟΣΥΝΗΣ Στα πλαίσια του μαθήματος Τεχνητής Νοημοσύνης του τμήματος Πληροφορικής του Αριστοτελείου Πανεπιστημίου Θεσσαλονίκης ανατέθηκε μια εργασία σχεδιασμού ενεργειών σε ομάδα προπτυχιακών φοιτητών. Τυχαία, αποφασίσαμε να ελέγξουμε μια από τις λανθασμένες απόπειρες των φοιτητών και να δοκιμάσουμε αν θα μπορούσαμε να βρούμε το λάθος που έκανε ο φοιτητής. Παρακάτω, παρουσιάζεται η εκφώνηση της εργασίας. Περιγραφή προβλήματος Έστω το πρόβλημα του ταχυδρόμου που περιγράφεται παρακάτω: Υπάρχει μια πόλη στην οποία εργάζονται κάποιοι ταχυδρόμοι. Η δουλειά των ταχυδρόμων είναι να μαζέψουν τα γράμματα από τα σπίτια της πόλης και να τα τοποθετήσουν στα ειδικά ταχυδρομικά κουτιά. Η πόλη αποτελείται από ένα σύνολο σημείων τα οποία συνδέονται μεταξύ τους με δρόμους, τους οποίους μπορεί κάποιος να περπατήσει. Σε κάθε σημείο μπορεί να υπάρχει ταχυδρομικό κουτί ή/και σπίτι. Οι ταχυδρόμοι μπορούν να περπατήσουν μέσω των δρόμων και να περάσουν από όσα σπίτια έχουν γράμματα να τα συλλέξουν και να τα τοποθετήσουν σε κάποιο από τα ταχυδρομικά κουτιά. Επίσης στην πόλη λειτουργεί μετρό σε μορφή δακτυλίου το οποίο μπορούν να χρησιμοποιήσουν οι ταχυδρόμοι για τη μετακίνηση τους. Το μετρό ακολουθεί ένα συγκεκριμένο δρομολόγιο μια φοράς και σε ορισμένα από τα σημεία από τα οποία περνάει υπάρχει στάση επιβίβασης/αποβίβασης. Για να μετακινηθεί επομένως κάποιος ταχυδρόμος από ένα σημείο σε ένα άλλο θα πρέπει είτε να υπάρχει δρόμος (αν η μετακίνηση γίνει με τα πόδια) ή τα δύο σημεία να αποτελούν στάσεις του μετρό και φυσικά η κατεύθυνση της μετακίνησης να είναι ίδια με αυτή του μετρό. Σημείωση: Στην παραπάνω οικογένεια προβλημάτων θεωρούμε ότι μπορούν να υπάρχουν παραπάνω του ενός σπίτια, γράμματα, ταχυδρόμοι και ταχυδρομικά κουτιά. Επίσης ο κάθε ταχυδρόμος μπορεί να κουβαλά στην τσάντα του πολλά γράμματα ταυτόχρονα και κάθε γράμμα θεωρείται ότι παραδόθηκε αν τοποθετηθεί σε οποιοδήποτε από τα ταχυδρομικά κουτιά της πόλης. Στο πρόβλημα του παρακάτω σχήματος υπάρχουν 14 σημεία στη πόλη, ένας ταχυδρόμος (14), 3 σπίτια (4,11,13), 2 γράμματα(4,11), 2 ταχυδρομικά κουτιά (5,10). Οι συνεχόμενες γραμμές αντιστοιχούν σε δρόμους τους οποίους μπορεί ο ταχυδρόμος να περπατήσει, οι διακεκομμένες αντιστοιχούν σε διαδρομές του μετρό, ενώ τα σημεία που παρουσιάζονται με διπλή έλλειψη αντιστοιχούν σε στάσεις του μετρό. ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 61

62 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Εικόνα 47 Γραφική Αναπαράσταση της Εργασίας Λανθασμένη Επίλυση του Προβλήματος Όπως αναφέραμε και στην εισαγωγή του κεφαλαίου, θα εξετάσουμε την εσφαλμένη λύση για το παραπάνω πρόβλημα που έδωσε κάποιος φοιτητής. Στην παρακάτω εικόνα (Εικόνα 48) λοιπόν παρουσιάζεται το πεδίο και το πρόβλημα όπως έχει σχεδιαστεί από τον φοιτητή. Εικόνα 48 Λανθασμένη Επίλυση Προβλήματος Παρακάτω εμφανίζονται επίσης και τα αρχεία PDDL (Εικόνα 49) και (Εικόνα 50) που εξάγει το Vleppo για το παραπάνω πρόβλημα. 62 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

63 (define (domain defaultdomain) (:requirements :strips) (:predicates (Mailman?x) (Point?x) (Mailbox?x) (Letter?x) (House?x) (at?mailman1?point2) (at3?house1?point2) (belongs?house1?letter2) (holds?mailman1?letter2) (at2?mailbox1?point2) (hasstation?point1) (hasletter?mailbox1?letter2) (isroadconnected?point1?point2) (issubwayconnected?point1?point2) ) (:action Move_Subway :parameters (?M?X?Y ) :precondition (and (Mailman?M) (Point?X) (Point?Y) (at?m?x) (hasstation?x) (issubwayconnected?x?y)) :effect (and (at?m?y) (hasstation?y) (not (at?m?x)) (not (hasstation?x))) )(:action Drop_Letter :parameters (?MailmanObj?LetterObj?MailboxObj?PointObj ) :precondition (and (Mailman?MailmanObj) (Letter?LetterObj) (Mailbox?MailboxObj) (Point?PointObj) (at?mailmanobj?pointobj) (at2?mailboxobj?pointobj) (holds?mailmanobj?letterobj)) :effect (and (hasletter?mailboxobj?letterobj) (not (holds?mailmanobj?letterobj))) )(:action Move_Feet :parameters (?M?X?Y ) :precondition (and (Mailman?M) (Point?X) (Point?Y) (at?m?x) (isroadconnected?x?y)) :effect (and (at?m?y) (not (at?m?x))) )(:action Pick_Letter :parameters (?MailmanObj?LetterObj?HouseObj?PointObj ) :precondition (and (Mailman?MailmanObj) (Letter?LetterObj) (House?HouseObj) (Point?PointObj) (at?mailmanobj?pointobj) (belongs?houseobj?letterobj) (at3?houseobj?pointobj)) :effect (and (holds?mailmanobj?letterobj) (not (belongs?houseobj?letterobj))) ) ) Εικόνα 49 Λανθασμένο Πεδίο του Προβλήματος σε PDDL ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 63

64 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ (define (problem defaultproblem) (:domain defaultdomain) (:objects Mailman1 Letter1 Letter2 House1 House2 House3 Mailbox1 Mailbox2 Point1 Point2 Point3 Point4 Point5 Point6 Point7 Point8 Point9 Point10 Point11 Point12 Point13 Point14 ) (:init (Mailman Mailman1) (Letter Letter1) (Letter Letter2) (House House1) (House House2) (House House3) (Mailbox Mailbox1) (Mailbox Mailbox2) (Point Point1) (Point Point2) (Point Point3) (Point Point4) (Point Point5) (Point Point6) (Point Point7) (Point Point8) (Point Point9) (Point Point10) (Point Point11) (Point Point12) (Point Point13) (Point Point14) (at Mailman1 Point14) (at2 Mailbox1 Point5) (at2 Mailbox2 Point10) (at3 House1 Point4) (at3 House2 Point11) (at3 House3 Point13) (belongs House1 Letter1) (belongs House2 Letter2) (hasstation Point2) (hasstation Point3) (hasstation Point6) (hasstation Point7) (hasstation Point8) (isroadconnected Point1 Point2) (isroadconnected Point2 Point11) (isroadconnected Point11 Point9) (isroadconnected Point11 Point6) (isroadconnected Point9 Point10) (isroadconnected Point10 Point8) (isroadconnected Point8 Point13) (isroadconnected Point13 Point14) (isroadconnected Point12 Point8) (isroadconnected Point5 Point12) (isroadconnected Point4 Point5) (isroadconnected Point3 Point4) (issubwayconnected Point2 Point3) (issubwayconnected Point3 Point5) (issubwayconnected Point5 Point7) (issubwayconnected Point7 Point8) (issubwayconnected Point8 Point6) (issubwayconnected Point6 Point2) ) (:goal (and (hasletter Mailbox1 Letter1) (hasletter Mailbox2 Letter2) ) ) ) Εικόνα 50 Λανθασμένο Πρόβλημα σε PDDL 64 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ

65 Αρχικά εκτελούμε την διαδικασία εύρεσης στατικών και δυναμικών γεγονότων για να ελέγξουμε αν είναι όντως ορισμένα σωστά. Εκτελώντας την διαδικασία εύρεσης στατικών και δυναμικών γεγονότων, λοιπόν, εμφανίζεται η παρακάτω φόρμα (Εικόνα 51). Εύκολα καταλαβαίνουμε ότι κάποια ενέργεια έχει οριστεί λάθος αφού η σχέση hasstation ανήκει λανθασμένα στα δυναμικά γεγονότα (η σχέση hasstation αναφέρεται στο αν κάποιο σημείο του χάρτη έχει σταθμό του μετρό). Αυτό συμβαίνει γιατί, ο φοιτητής του παραδείγματός μας, ξέχασε να προσθέσει στη σχέση Move_Subway το hasstation(x). Εικόνα 51 Εμφάνιση Στατικών και Δυναμικών Γεγονότων Μετά από αυτό το σφάλμα, εκτελούμε την διαδικασία Validate. Μετά την εκτέλεση, εμφανίζεται η φόρμα (Εικόνα 52). Σε αυτή τη φόρμα, εμφανίζονται και οι δύο στόχοι να είναι μη επιτεύξιμοι. Επόμενο βήμα είναι να πατήσουμε την επιλογή see more για να εμφανιστούν περισσότερες λεπτομέρειες. Εικόνα 52 Παράθυρο για Validate ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ 65

66 ΣΤΑΥΡΟΠΟΥΛΟΣ ΘΑΝΟΣΣΥΜΕΩΝΙΔΗΣ ΜΩΥΣΗΣ Έτσι, επιλέγουμε τον πρώτο στόχο και επιλέγουμε το see more. Εμφανίζεται, λοιπόν, το παρακάτω σχήμα (Εικόνα 53) που δείχνει τον στόχο και κλικάροντας πάνω στο κόκκινο κύκλο εμφανίζεται ένα μενού με τις ενέργειες που θα μπορούσαν να πετύχουν το στόχο. Έτσι επιλέγουμε την μοναδική ενέργεια που θα μπορούσε να πετύχει το στόχο δηλαδή drop_letter(mailman1,letter1,mailbox1,point5). Επιλέγοντας, λοιπόν, την ενέργεια γίνεται ανατροφοδότηση της υπηρεσίας με της προϋποθέσεις της ενέργειας και εμφανίζεται το σχήμα (Εικόνα 54). Με πράσινο χρώμα είναι οι προϋποθέσεις που μπορούν να επιτευχθούν και με κόκκινο οι προϋποθέσεις που δεν μπορούν να επιτευχθούν. Με τον ίδιο τρόπο κλικάρουμε σε ένα κόκκινο κύκλο και εμφανίζεται το σύνολο των ενεργειών που θα μπορούσε να πετύχει την προϋπόθεση της ενέργειας. Εικόνα 53 Στόχος (hasletter mailbox1 letter1) Εικόνα 54 Ανατροφοδότηση Συστήματος Εικόνα 55 Ανατροφοδότηση μετά από κάποια βήματα Εκτελώντας την ίδια διαδικασία βλέπουμε ότι υπάρχει πρόβλημα στην μετακίνηση του mailman μέσα στο χάρτη. Έτσι γίνεται εύκολα κατανοητό ότι είτε υπάρχει κάποιο πρόβλημα στις ενέργειες move_feet ή move_subway είτε να έχει γίνει κάποιο λάθος στο σχεδιασμό του χάρτη. Ελέγχοντας τον χάρτη βλέπουμε ότι οι πόλεις είναι συνδεδεμένες μόνο προς μία κατεύθυνση. Δηλαδή, έστω δύο πόλεις Α και Β για να συνδεθούν οι δύο πόλεις πρέπει ή η σχέση isroadconnected(a,b) να έχει και μία σχέση isroadconnected(b,a) ή θα πρέπει να υπάρχουν δύο ενέργειες move_feet που να λαμβάνουν υπόψιν και τις δύο περιπτώσεις. 66 ΑΝΑΠΤΥΞΗ ΣΥΣΤΗΜΑΤΟΣ ΓΙΑ ΤΟΝ ΈΛΕΓΧΟ ΕΓΚΥΡΟΤΗΤΑΣ ΠΡΟΒΛΗΜΑΤΩΝ ΣΧΕΔΙΑΣΜΟΥ ΜΕΣΩ ΥΠΗΡΕΣΙΩΝ ΙΣΤΟΥ