Βελτίωση της πλατφόρµας ανάπτυξης συστηµάτων πολλών πρακτόρων Agent Factory

Transcript

1 ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΜΗΧΑΝΙΚΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ ΗΛΕΚΤΡΟΝΙΚΗΣ ΚΑΙ ΥΠΟΛΟΓΙΣΤΩΝ Βελτίωση της πλατφόρµας ανάπτυξης συστηµάτων πολλών πρακτόρων Agent Factory ιπλωµατική Εργασία Νικολαΐδου Παρασκευή ΑΕΜ : 4620 υπό την επίβλεψη Περικλή Α. Μήτκα αναπληρωτή καθηγητή Θεσσαλονίκη 2004

2 2 Αφιερώνεται στον αδερφό µου Γιάννη

3 3

4 4 Ευχαριστίες Πρώτα απ όλα, θα ήθελα να ευχαριστήσω τον υπεύθυνο καθηγητή κ. Περικλή Μήτκα, για την εµπιστοσύνη που µου έδειξε µε την ανάθεση της εργασίας αυτής και για την ευκαιρία που µου έδωσε ν ασχοληθώ µε ένα τόσο ενδιαφέρον θέµα. Επίσης, θα ήθελα να ευχαριστήσω το Γιάννη Αθανασιάδη και όλους τους άλλους διδακτορικούς φοιτητές και µέλη του εργαστηρίου για την συνεργασία τους, την υποµονή τους και τη βοήθειά τους κατά την πορεία της διπλωµατικής.

5 5

6 6 Περιεχόµενα Ευχαριστίες... 4 Περιεχόµενα... 6 Λίστα σχηµάτων... 8 Λίστα πινάκων... 9 Λίστα συντοµεύσεων Λίστα ξένων όρων Πρόλογος Κεφάλαιο 1. Εισαγωγή Τι είναι agent; Η πλατφόρµα λογισµικού Agent Academy Το Agent Factory Σκοπός της διπλωµατικής Μεθοδολογία της διπλωµατικής Περιεχόµενα της διπλωµατικής...20 Κεφάλαιο 2. Η λειτουργία του Agent Factory Εισαγωγή Υποσυστήµατα ODT BTDT ATDT SDT Κεφάλαιο 3. Περιγραφή του προβλήµατος Ορισµός του προβλήµατος Ανάλυση απαιτήσεων Γενική περιγραφή του AF Απαιτήσεις εσωτερικής σχεδίασης Απαιτήσεις εξωτερικών διεπαφών Μη λειτουργικές απαιτήσεις Αξιολογήσεις Παρατηρήσεις Ανάλυση προβληµάτων του Agent Factory...41

7 Προβλήµατα λειτουργικότητας Προβλήµατα διεπαφής χρήστη Κεφάλαιο 4. Μεθοδολογία προσέγγισης Κατευθυντήριες γραµµές στην αντιµετώπιση του προβλήµατος Προδιαγραφές Αρχιτεκτονική σχεδίαση Λειτουργίες του Agent Factory ιαγράµµατα UML Εργαλεία που χρησιµοποιήθηκαν...54 Κεφάλαιο 5. Αναλυτική περιγραφή προβληµάτων και λύσεων Περιγραφή προβληµάτων Περιγραφή λύσεων...58 Κεφάλαιο 6. Επικύρωση καλής λειτουργίας του AF Πλάνο ελέγχου Καθορισµός µηχανής (machine configuration) Υποθέσεις του τεστ οκιµές Έλεγχοι που έγιναν οκιµές λειτουργίας οκιµές επίδοσης οκιµές πίεσης οκιµές δοµής Αποτελέσµατα Κεφάλαιο 7. Συµπεράσµατα Μελλοντική εργασία Συµπεράσµατα Προτάσεις για µελλοντική επέκταση Βιβλιογραφία Παράρτηµα A. Αρχεία βοήθειας A.1 Το κείµενο βοήθειας του αρχικού παραθύρου A.2 Το κείµενο βοήθειας του ODT A.3 Το κείµενο βοήθειας του BTDT A.4 Το αρχείο βοήθειας του ATDT A.5 Το αρχείο βοήθειας του SDT Παράρτηµα B. Πηγαίος κώδικας Παράρτηµα C. Κατανάλωση πόρων συστήµατος

8 8 Λίστα σχηµάτων Σχήµα 1-1 Το λειτουργικό διάγραµµα του Agent Academy...16 Σχήµα 2-1 Στιγµιότυπο κεντρικής οθόνης του Agent Academy...23 Σχήµα 2-2 Στιγµιότυπο οθόνης του ODT...24 Σχήµα 2-3 Στιγµιότυπο οθόνης του BTDT...25 Σχήµα 2-4 Το Mapping Tool...26 Σχήµα 2-5 Στιγµιότυπο οθόνης του ATDT...27 Σχήµα 2-6 Στιγµιότυπο οθόνης του SDT...28 Σχήµα 4-1 Επικοινωνία µεταξύ των τµηµάτων του AF...45 Σχήµα 4-2 Επικοινωνία AF µε AUR και ATM...46 Σχήµα 4-3 Use Case διάγραµµα...48 Σχήµα 4-4 Use Case State διάγραµµα...49 Σχήµα 4-5 Το πακέτο org.agentacademy.modules.af...49 Σχήµα 4-6 ιάγραµµα καταστάσεων για το φόρτωµα οντολογίας...50 Σχήµα 4-7 ιάγραµµα κλάσεων για το φόρτωµα οντολογίας...50 Σχήµα 4-8 ιάγραµµα καταστάσεων για τη δηµιουργία νέας συµπεριφοράς...51 Σχήµα 4-9 ιάγραµµα κλάσεων για τη δηµιουργία νέας συµπεριφοράς...51 Σχήµα 4-10 ιάγραµµα καταστάσεων για τη δηµιουργία τύπου πράκτορα...52 Σχήµα 4-11 ιάγραµµα κλάσεων για τη δηµιουργία τύπου πράκτορα...52 Σχήµα 4-12 ιάγραµµα καταστάσεων για τη δηµιουργία σεναρίου και στιγµιότυπων..53 Σχήµα 6-1 Η αρχιτεκτονική του O 3 RTAA...88

9 9 Λίστα πινάκων Πίνακας 3-1 Αποτελέσµατα δοκιµών της πρώτης έκδοσης του AF 40 Πίνακας 5-1 Προβλήµατα του συστήµατος 57 Πίνακας 5-2 Σύνοψη προβληµάτων συστήµατος 58 Πίνακας 6-1 Πλάνο δοκιµών 71 Πίνακας 6-2 Αποτελέσµατα δοκιµών λειτουργίας 94 Πίνακας 6-3 Αποτελέσµατα δοκιµών επίδοσης 96 Πίνακας 6-4 Αποτελέσµατα δοκιµών πίεσης 99

10 10 Λίστα συντοµεύσεων AA AF ant ATDT ATM AUR BTDT DM FIPA JADE JESS ODT PADT PMML SDT UA UML XML ΑΑ ΑΠ ΟΑΕ ΠΠΣ Agent Academy Agent Factory Another Neat Tool Agent Type Design Tool Agent Training Module Agent Use Repository Behaviour Type Design Tool Data Miner Foundation for Intelligent Physical Agents Java Agent Development Framework Java Expert System Shell Ontology Design Tool Physical Asset Design Tool Predictive Model Markup Language Scenario Design Tool Untrained Agent Unified Modelling Language Extensible Markup Language Αναµενόµενο αποτέλεσµα Απαιτήσεις που δοκιµάζονται Ορισµός αποσαφήνιση εισόδων Πολυπρακτορικό σύστηµα

11 11 Λίστα ξένων όρων agent compile data mining knowledge base overwrite panel peer-to-peer platform-independency proxy remote procedure call semantics meaning software agent tab πράκτορας συµβολοµετάφραση εξόρυξη δεδοµένων γνωσιακή βάση επανεγγραφή ταµπλό οµότιµος ανεξαρτησία από την πλατφόρµα ενδιάµεσος αποµακρυσµένη κλήση διαδικασίας σηµασιολογική έννοια πράκτορας λογισµικού καρτέλα

12 12 Πρόλογος Η διπλωµατική εργασία αποτελεί το επιστέγασµα της προπτυχιακής ακαδηµαϊκής σταδιοδροµίας κάθε φοιτητή, ο οποίος καλείται να συνεισφέρει προσωπικά στην επιστήµη και να χρησιµοποιήσει τις γνώσεις που αποκόµισε κατά τη διάρκεια των σπουδών του στο Πολυτεχνείο. Το θέµα που επιλέχθηκε στην παρούσα εργασία αφορά τη βελτίωση µιας ήδη υπάρχουσας πλατφόρµας, η οποία καθοδηγεί το χρήστη κατά τη σχεδίαση και εκπαίδευση συστηµάτων ευφυών πρακτόρων. Στη σηµερινή κοινωνία, η τεχνολογία των ευφυών πρακτόρων αρχίζει να βγαίνει από τα ερευνητικά εργαστήρια και να χρησιµοποιείται από τις επιχειρήσεις, ως απάντηση σε ένα γρήγορα µεταβαλλόµενο κόσµο. Μέσω αυτής της τεχνολογίας, γίνεται προσπάθεια να δοθεί λύση σε ένα µείζον πρόβληµα του σύγχρονου ανθρώπου, δηλαδή τον καταιγισµό πληροφοριών και την έλλειψη πραγµατικής γνώσης. Η παρούσα διπλωµατική εργασία είναι µια, ελάχιστη έστω, συµβολή στην προσπάθεια επίλυσης αυτού του ζητήµατος. Πιο αναλυτικά, η εργασία αυτή ασχολείται µε το Agent Academy, µια πλατφόρµα λογισµικού, η οποία καθοδηγεί το χρήστη στο σχεδιασµό συστηµάτων πολλών πρακτόρων και, κατόπιν, στην εκπαίδευση αυτών των πρακτόρων. Βέβαια, η ίδια η πλατφόρµα λειτουργεί µε τη βοήθεια πρακτόρων, κάτι που έχει ως αποτέλεσµα την αποδοτικότερη λειτουργία της, αλλά και τη φιλικότερη αλληλεπίδραση µε το χρήστη. Συγκεκριµένα, το τµήµα του Agent Academy όπου εστιάζεται η διπλωµατική είναι το Agent Factory, που αναλαµβάνει τη δηµιουργία ενός νέου πράκτορα, έτοιµου για εκπαίδευση. Μια αρχική δυσχέρεια ήταν η εξοικείωση µε τις εξειδικευµένες γνώσεις και τις τεχνολογίες που απαιτούνται γι αυτόν το σκοπό. Παρόλ αυτά, το µεγαλύτερο βαθµό δυσκολίας τον εισήγαγε ακριβώς το γεγονός ότι πρόκειται για τη βελτίωση ενός τµήµατος ενός ήδη υπάρχοντος συστήµατος, κάτι που περιορίζει σηµαντικά τα περιθώρια κίνησης, όσον αφορά τα εργαλεία ανάπτυξης και την εσωτερική δοµή του συστήµατος.

13 13 Κεφάλαιο 1. Εισαγωγή 1.1 Τι είναι agent; Με την έννοια «πράκτορας λογισµικού» (software agent) ή απλώς «πράκτορας» (agent) εννοούµε µια οντότητα λογισµικού που εκτελεί µια συγκεκριµένη εργασία, συνήθως στο ιαδίκτυο, σύµφωνα µε τις απαιτήσεις του χρήστη [1-3]. Για να κατανοήσουµε τη διαφορά ενός πράκτορα από τα άλλα προγράµµατα, πρέπει να εξετάσουµε κάποια βασικά χαρακτηριστικά του. Έτσι, οι πράκτορες είναι αυτόνοµοι, αυτενεργοί και κοινωνικοί [4]: Αυτόνοµοι: οι πράκτορες έχουν ένα βαθµό ελέγχου των πράξεών τους, κατέχουν τη δική τους ακολουθία ελέγχου και, κάτω από ορισµένες προϋποθέσεις, είναι ικανοί και να παίρνουν αποφάσεις. Αυτενεργοί: οι πράκτορες δεν αντιδρούν απλώς σε εξωτερικά γεγονότα (λ.χ. αποµακρυσµένη κλήση διαδικασίας remote procedure call). Παρουσιάζουν και συµπεριφορά οδηγούµενη από στόχους και, αν κρίνεται σκόπιµο, είναι ικανοί να λάβουν πρωτοβουλία. Κοινωνικοί: οι πράκτορες είναι ικανοί (και χρειάζεται) να αλληλεπιδρούν µε άλλους πράκτορες, για να εκτελούν τα καθήκοντά τους και να επιτυγχάνουν το συνολικό στόχο του συστήµατος. Τα συστήµατα που βασίζονται σε πράκτορες είναι από τη φύση τους οµότιµα (peer-to-peer): κάθε πράκτορας είναι ένα µέλος που ενδεχοµένως να χρειαστεί να ξεκινήσει µια επικοινωνία µε οποιονδήποτε άλλον πράκτορα, ενώ είναι και ικανός να παρέχει δυνατότητες στους υπόλοιπους πράκτορες. Ο ρόλος

14 14 της επικοινωνίας είναι πολύ σηµαντικός σε ένα σύστηµα βασισµένο σε πράκτορες. Το µοντέλο ενός τέτοιου συστήµατος βασίζεται σε τρία βασικά χαρακτηριστικά: 1. Οι πράκτορες είναι ενεργές οντότητες, µπορούν να πουν «όχι» και είναι χαλαρά συνδεδεµένοι. Αυτό το σύνολο αλληλοσυσχετισµένων ιδιοτήτων είναι η βάση για την επιλογή της ασύγχρονης και βασισµένης σε µηνύµατα επικοινωνίας αντί για την αποµακρυσµένη κλήση διαδικασίας (remote procedure call): ένας πράκτορας που επιθυµεί να επικοινωνήσει πρέπει απλώς να στείλει ένα µήνυµα σε ένα συγκεκριµένο προορισµό. Πράγµατι, αυτή η µορφή επικοινωνίας επιτρέπει στον παραλήπτη να επιλέξει ποια µηνύµατα να εξυπηρετήσει και ποια να απορρίψει, καθώς επίσης και ποια µηνύµατα να εξυπηρετήσει πρώτα και ποια αργότερα. Επίσης, επιτρέπει στον αποστολέα να ελέγξει τη ροή της εκτέλεσής του, αντί να διακόπτεται µέχρι ο παραλήπτης να διαβάσει και να εξυπηρετήσει το µήνυµα. Τέλος, αφαιρεί κάθε χρονική εξάρτηση ανάµεσα στον αποστολέα και τον παραλήπτη. Ο παραλήπτης µπορεί να µην είναι διαθέσιµος τη στιγµή που ο αποστολέας στέλνει το µήνυµα, ή να µην υπάρχει καν εκείνη τη στιγµή ή, ακόµα, να µην είναι καν γνωστός στον αποστολέα. Τότε, ο πράκτορας αποστολέας καθορίζει τους πράκτορες παραλήπτες µε βάση την πρόθεσή του (λ.χ. να πάρουν το µήνυµα όλοι οι πράκτορες που ενδιαφέρονται για «ποδόσφαιρο») ή κατευθύνει την επικοινωνία µέσω ενδιάµεσου (proxy), (λ.χ. δηµοσιοποίησε αυτό το µήνυµα σε όλους τους πράκτορες στην περιοχή Χ). 2. Οι πράκτορες εκτελούν ενέργειες και η επικοινωνία είναι απλώς µια µορφή ενέργειας. Με το να ορίζεται η επικοινωνία ως µια µορφή ενέργειας, ένας πράκτορας µπορεί, για παράδειγµα, να επεξεργάζεται λογικά ένα σχέδιο που περικλείει τόσο φυσικές ενέργειες («στρίψε αριστερά») όσο και ενέργειες επικοινωνίας («ζήτα ν ανοίξουν την πόρτα»). Για να προγραµµατίζονται οι επικοινωνίες, πρέπει να είναι σαφώς ορισµένες οι επιδράσεις και οι προϋποθέσεις κάθε δυνατής επικοινωνίας.

15 15 3. Η επικοινωνία µεταφέρει µια σηµασιολογική έννοια (semantics meaning). Όταν ένας πράκτορας είναι ο αποδέκτης µιας ενέργειας επικοινωνίας (δηλ. λαµβάνει ένα µήνυµα), πρέπει να είναι ικανός να καταλάβει τη σηµασία αυτής της ενέργειας και, συγκεκριµένα, γιατί έγινε αυτή η ενέργεια (την πρόθεση του αποστολέα του µηνύµατος). Με τον όρο «πολυπρακτορικό σύστηµα» (ΠΠΣ) εννοούµε ένα σύστηµα, στο οποίο πολλοί πράκτορες επικοινωνούν µεταξύ τους. Η επικοινωνία αυτή µπορεί να είναι είτε συνεταιρική είτε ιδιοτελής. ηλαδή, οι πράκτορες µπορεί να µοιράζονται έναν κοινό στόχο (π.χ. αποικία µυρµηγκιών) ή να επιδιώκει ο καθένας το δικό του συµφέρον (π.χ. στην ελεύθερη αγορά). Τα χαρακτηριστικά των ΠΠΣ [25] είναι: 1) Ο κάθε πράκτορας έχει ελλιπή πληροφόρηση ή ικανότητες για την επίλυση του προβλήµατος και, κατά συνέπεια, έχει περιορισµένη αντίληψη 2) εν υπάρχει σφαιρικός έλεγχος του συστήµατος 3) Τα δεδοµένα είναι αποκεντρωµένα 4) Οι υπολογισµοί είναι ασύγχρονοι 1.2 Η πλατφόρµα λογισµικού Agent Academy Η βαρύνουσα σηµασία της επικοινωνίας µεταξύ των πρακτόρων καθιστά απαραίτητο ένα εργαλείο που θα επιτρέπει στο σχεδιαστή ενός ΠΠΣ να εξασφαλίζει τη δυνατότητα επικοινωνίας τους µε βάση ένα κοινό πρωτόκολλο. Επίσης, αυτοί οι πράκτορες θα πρέπει να βασίζονται σε κάποια πρότυπα [7,8], για να µπορούν να επικοινωνούν µε άλλους οµοειδείς τους, που δεν ανήκουν απαραίτητα στο ίδιο σύστηµα. Αυτήν την ανάγκη έρχεται να καλύψει το Agent Academy. Το Agent Academy (AA) λειτουργεί ως µια πλατφόρµα ανάπτυξης ΠΠΣ η οποία επιτρέπει τη δηµιουργία και την εκπαίδευση νέων πρακτόρων και, προαιρετικά, την επανεκπαίδευσή τους. Με τον όρο «εκπαίδευση» περιγράφεται η διαδικασία ενσωµάτωσης λογικών µοντέλων (π.χ. δένδρο λήψης αποφάσεων) στους νέους πράκτορες. Η πλατφόρµα επιτρέπει τη

16 16 δηµιουργία αυτών των λογικών µοντέλων εφαρµόζοντας τεχνικές εξόρυξης δεδοµένων σε ιστορικά δεδοµένα χρήσης της εφαρµογής για την οποία σχεδιάζεται το συγκεκριµένο ΠΠΣ. Το AA αποτελεί ένα ολοκληρωµένο εργαλείο ανάπτυξης λογισµικού, που συνίσταται από τέσσερα βασικά υποσυστήµατα. Αυτά είναι: το Agent Factory (AF), το Agent Use Repository (AUR), το Data Miner (DM) και το Agent Training Module (ATM). Το Σχήµα 1-1 παρουσιάζει το ΑΑ και τα υποσυστήµατά του, καθώς και τις αλληλεπιδράσεις µεταξύ τους, µε τη µορφή του λειτουργικού διαγράµµατος του AA [10]. Σχήµα 1-1 Το λειτουργικό διάγραµµα του Agent Academy Το Agent Academy δέχεται είσοδο από τους χρήστες του, οι οποίοι α) θέτουν ένα αίτηµα για έναν καινούριο πράκτορα, µε βάση ένα σύνολο λειτουργικών απαιτήσεων και β) δηµιουργούν µια συγκεκριµένη οντολογία [18], την οποία µοιράζονται όλοι οι πράκτορες στην επικοινωνία τους. Η απαίτηση αυτή υλοποιείται εν µέρει από το Agent Factory (AF), ένα υποσύστηµα υπεύθυνο για τη δηµιουργία νέων πρακτόρων, σύµφωνα µε τις απαιτήσεις του χρήστη. Κάθε νεοδηµιούργητος πράκτορας παίζει το ρόλο ενός ανεκπαίδευτου πράκτορα (Untrained Agent - UA), που είναι ικανός να εκτελεί βασικές λειτουργίες και έχει έναν ελάχιστο βαθµό γνώσης για το περιβάλλον του. Αυτός ο πράκτορας εισέρχεται στο Agent Training Module (ATM). Εκεί εξοπλίζεται µε ικανότητες λήψης αποφάσεων και επιτυγχάνει υψηλότερο βαθµό αντίληψης για µια συγκεκριµένη αρχή, που σχηµατίζεται µε βάση τις οντολογίες. Το ATM λαµβάνει είσοδο από το τµήµα εξόρυξης δεδοµένων, Data Miner (DM), η

17 17 λειτουργία του οποίου είναι να εξάγει γνώση εφαρµόζοντας, όπως υποδηλώνει το όνοµά του, τεχνικές εξόρυξης δεδοµένων (data mining) σε ένα σχετικά µεγάλο σύνολο δεδοµένων. Όλα τα δεδοµένα που χρησιµοποιούνται στις τεχνικές εξόρυξης δεδοµένων αποθηκεύονται σε µια βάση, της οποίας η δηµιουργία και συντήρηση επαφίεται στο Agent Use Repository (AUR). Αυτό το στοιχείο παρέχει επίσης τη διεπαφή λογισµικού για τη συλλογή δεδοµένων που αφορούν τους πράκτορες. Στα στοιχεία του AUR εκτελεί ο DM όλες τις κατάλληλες µεθόδους, για να εξαγάγει ένα συγκεκριµένο µοτίβο συµπεριφοράς (π.χ. µε τη µορφή ενός δέντρου αποφάσεων) και να εκπαιδεύσει τον UA. Αφού ολοκληρωθεί η διαδικασία της εκπαίδευσης, το AA αποδίδει έναν ευφυή (εκπαιδευµένο) πράκτορα στο χρήστη που τον ζήτησε. Στη συνέχεια, οι πράκτορες του AA µπορούν να αναφέρουν τις ενέργειές τους στο AUR, απ όπου το AA µπορεί συνεχώς να ανανεώνει τη γνωσιακή βάση του (knowledge base), συνεισφέροντας σε µια διαδικασία λεπτοµερούς ρύθµισης της γνώσης που εξάγεται. 1.3 Το Agent Factory Ο ρόλος του τµήµατος Agent Factory (AF), όπως προαναφέρθηκε, είναι η δηµιουργία νέων ανεκπαίδευτων πρακτόρων. Το Agent Factory ενσωµατώνει τις απαιτούµενες λειτουργίες για το σχεδιασµό και την αρχικοποίηση πρακτόρων βασισµένων στις απαιτήσεις του χρήστη και τους προετοιµάζει για τη διαδικασία εκπαίδευσης. Επιπρόσθετα, το Agent Factory παρέχει µια βιβλιοθήκη µε έτοιµα µοντέλα πρακτόρων γενικής χρήσης. Η βιβλιοθήκη αυτή είναι δυναµική, άρα µπορεί να προσαρµόζει τα περιεχόµενά της ανάλογα µε την κάθε εφαρµογή. Οι λειτουργικές προδιαγραφές αυτών των γενικής χρήσης πρακτόρων προκύπτουν από τις απαιτήσεις της ίδιας της εφαρµογής και των χρηστών της. Το AF χειρίζεται τα αιτήµατα των χρηστών και δηµιουργεί, µε έναν ηµιαυτόµατο τρόπο, τον κατάλληλο τύπο πράκτορα µε το βασικό κώδικα αυτού. Αυτοί οι πράκτορες διαθέτουν έναν ελάχιστο βαθµό ευφυΐας και είναι σε θέση να εκπαιδευτούν περαιτέρω µε χρήση του τµήµατος Agent Training Module του

18 18 Agent Academy. Παράλληλα, το Agent Factory διασφαλίζει την επικοινωνία ανάµεσα στο Agent Academy και την ήδη υπάρχουσα πλατφόρµα JADE [4-6], δρώντας σαν ενδιάµεσο στοιχείο. Η διεπαφή χρήστη του Agent Factory διευκολύνει τους χρήστες να παρέχουν στο σύστηµα τις απαραίτητες πληροφορίες για τη δηµιουργία του κατάλληλου τύπου πράκτορα, καθώς και τυχόν προτιµήσεις σε ιδιαιτερότητες που βοηθούν στη δηµιουργία ενός πράκτορα κατάλληλου για τις ανάγκες τους. 1.4 Σκοπός της διπλωµατικής Στόχος της παρούσας διπλωµατικής εργασίας είναι ο επανασχεδιασµός του AF σύµφωνα µε αναθεωρηµένες απαιτήσεις και, στη συνέχεια, η αναθεώρηση και βελτίωση του υπάρχοντος κώδικα, έτσι ώστε ν ανταποκρίνεται στις απαιτήσεις αυτές, χωρίς όµως να διαταραχθεί η συνεργασία του AF µε τα υπόλοιπα τµήµατα του AA. Συγκεκριµένα, οι πράκτορες που δηµιουργεί το AF πρέπει να είναι σε θέση να εκπαιδευτούν στο ATM, χρησιµοποιώντας τα δεδοµένα του Data Miner. Επιµέρους στόχοι της εργασίας αυτής είναι: Η ανάλυση των κάθε είδους απαιτήσεων που υπάρχουν από το Agent Factory. Η καταγραφή των υπαρχόντων προβληµάτων, µε χρήση παλιότερων αξιολογήσεων αλλά και προσωπικών παρατηρήσεων από τη χρήση του προγράµµατος. Η συγγραφή των προδιαγραφών, σύµφωνα µε τις οποίες θα πρέπει να λειτουργεί το Agent Factory. Η τροποποίηση του κώδικα, ώστε να ανταποκρίνεται στις νέες προδιαγραφές. Η συγγραφή του κειµένου βοήθειας [23], στο οποίο θα ανατρέχει ο χρήστης κατά τη χρήση του προγράµµατος. Ο έλεγχος της καλής λειτουργίας του προγράµµατος. Η αξιολόγηση του αναθεωρηµένου Agent Factory

19 Μεθοδολογία της διπλωµατικής Γενικότερα, στα πλαίσια της παρούσας διπλωµατικής εργασίας έγιναν οι απαραίτητες διορθώσεις και βελτιώσεις στο AF. Το AF δεν είναι αυτόνοµο, αλλά αποτελεί µέρος του AA, το οποίο µε τη σειρά του συνεργάζεται µε µια σειρά άλλων λογισµικών, όπως JADE [4-6], JESS [17] κτλ. Κατά συνέπεια, η επικοινωνία µε τα περιβάλλοντα αυτά παίζει ουσιαστικό ρόλο στη λειτουργία του AF. Όµως, η διεπαφή µεταξύ του AF και των άλλων τµηµάτων του AA υπήρχε ήδη, µε τη µορφή του πράκτορα AF. Για το λόγο αυτό, κρίθηκε σκόπιµη µια προσεκτική µεθοδολογία προσέγγισης του προβλήµατος, για να µη διαταραχθεί αυτή η επικοινωνία. Από την πλευρά του τελικού χρήστη, η χρήση του AF δεν απαιτεί κάποια ιδιαίτερη εξοικείωση µε το περιβάλλον του συστήµατος. Παρόλ αυτά, είναι επιθυµητές κάποιες βασικές γνώσεις προγραµµατισµού και αλγορίθµων, για να µπορέσει ο χρήστης να καθορίσει µε µεγαλύτερη ευκολία τον αλγόριθµο της συµπεριφοράς του πράκτορα. Από τεχνικής άποψης, η πλατφόρµα είναι γραµµένη σε γλώσσα Java [21], ενώ οι πράκτορες που παράγονται είναι πράκτορες JADE συµβατοί µε τα πρότυπα που ορίζονται από τη FIPA [7,8]. Βασικά πλεονεκτήµατά της είναι η ανεξαρτησία από την πλατφόρµα (platform independency), η ευκολία στη χρήση και η δυνατότητα συνεργασίας από πολλούς σταθµούς εργασίας, µε ένα µικρό αντίτιµο στην ταχύτητα λόγω της γλώσσας Java. Έτσι, ήταν απαραίτητος ένας αρχικός προσδιορισµός των απαιτήσεων του προγράµµατος. Έγινε προσπάθεια, ώστε αυτές οι απαιτήσεις να γραφτούν από την οπτική γωνία ενός µέσου χρήστη, που έχει εµπειρία στον προγραµµατισµό αλλά όχι ιδιαίτερη εξοικείωση µε το ΑΑ / AF. Καθώς το υπάρχον πρόγραµµα παρείχε ήδη ένα βαθµό λειτουργικότητας, θεωρήθηκε ότι ήταν καλύτερο να βελτιωθεί ο υπάρχων κώδικας παρά να συγγραφεί από την αρχή. Έτσι, µετά τη συγγραφή των απαιτήσεων ακολούθησε η εκσφαλµάτωση του συστήµατος, µε σκοπό να καταγραφούν επακριβώς οι ατέλειες του συστήµατος. Ακολούθησε αντιπαραβολή των απαιτήσεων µε τα αποτελέσµατα της εκσφαλµάτωσης, απ

20 20 όπου προέκυψαν µε λεπτοµέρεια τα σηµεία που χρήζουν βελτίωσης. Μετά την καταγραφή αυτή, έγιναν προσεκτικά οι απαραίτητες διορθώσεις στον κώδικα. Τέλος, έγιναν οι απαραίτητες δοκιµές, ώστε να πιστοποιηθεί η καλή λειτουργία του συστήµατος. 1.6 Περιεχόµενα της διπλωµατικής Το δεύτερο κεφάλαιο περιγράφει αναλυτικά τη δηµιουργία του Agent Factory. Αρχικά, γίνεται µια σύντοµη περιγραφή της λειτουργίας του. Στη συνέχεια, εξηγούνται τα βήµατα που απαιτείται να ακολουθήσει ο χρήστης, για τη δηµιουργία και την εκτέλεση ενός σεναρίου. Το κεφάλαιο κλείνει µε µια σύντοµη επεξήγηση της λειτουργίας του κάθε υποσυστήµατος, µε τη βοήθεια στιγµιότυπων οθόνης. Το τρίτο κεφάλαιο ασχολείται µε την περιγραφή του προβλήµατος της διπλωµατικής. Συγκεκριµένα, αναλύονται οι απαιτήσεις λογισµικού, όπως προκύπτουν από το αρχικό σχέδιο του AA, αλλά και τις απαραίτητες αναθεωρήσεις. Στη συνέχεια, συνοψίζονται οι αξιολογήσεις που έχουν ήδη γίνει στην πλατφόρµα. Κατόπιν, γίνεται αντιπαραβολή των απαιτήσεων µε τις αξιολογήσεις, µε σκοπό να εντοπιστούν οι ελλείψεις του συστήµατος. Τέλος, κατηγοριοποιούνται και αναλύονται τα προβλήµατα του συστήµατος, µε βάση τις παραπάνω παρατηρήσεις, αλλά και συµπεράσµατα από προσωπική χρήση του AF. Το τέταρτο κεφάλαιο αναπτύσσει τη µεθοδολογία προσέγγισης του προβλήµατος µε το οποίο ασχολείται η διπλωµατική. Αρχικά, επεξηγούνται οι κατευθυντήριες γραµµές που ακολουθήθηκαν κατά την αντιµετώπιση του προβλήµατος. Έπειτα, αναλύονται οι προδιαγραφές του συστήµατος και παρατίθενται τα σχέδια UML [19]. Τέλος, αναλύονται τα εργαλεία που χρησιµοποιήθηκαν κατά την ανάπτυξη του συστήµατος. Στο πέµπτο κεφάλαιο περιγράφονται µε αναλυτικό τρόπο, τόσο τα προβλήµατα που εντοπίστηκαν, όσο και ο τρόπος µε τον οποίο λύθηκαν. Σε κάθε πρόβληµα, αναφέρεται η κατηγορία του και το τµήµα του Agent Factory στο οποίο εντοπίστηκε. Ύστερα, περιγράφεται αναλυτικά το πρόβληµα, καθώς

21 21 και ο τρόπος επίλυσής του, µε παραδείγµατα από τον κώδικα, όπου αυτό κρίνεται αναγκαίο. Το έκτο κεφάλαιο έχει ως αντικείµενο την επικύρωση της καλής λειτουργίας του AF. Αρχικά, περιγράφεται το πλάνο ελέγχου του AF, µε αναλυτική περιγραφή των δοκιµών που προγραµµατίστηκε να γίνουν, καθώς και τη βαρύτητα της καθεµίας. Στη συνέχεια, δίνονται τα αποτελέσµατα των ελέγχων που έγιναν, βαθµολογηµένα σύµφωνα µε τις απαιτήσεις του πλάνου. Τέλος, αναλύονται τα συµπεράσµατα που βγαίνουν από τις δοκιµές, µαζί µε µια γενική αξιολόγηση του συστήµατος. Το έβδοµο κεφάλαιο αναλύει τα συµπεράσµατα που βγαίνουν σε όλα τα επίπεδα της εργασίας και περιγράφει κάποιες προτεινόµενες βελτιώσεις προσδιορίζοντας τον τρόπο που αυτές θα µπορούσαν να αποτελέσουν επεκτάσεις της εφαρµογής που αναπτύχθηκε. Η διπλωµατική εργασία κλείνει µε τη βιβλιογραφία και τα παραρτήµατα, που περιλαµβάνουν τα αρχεία βοήθειας του προγράµµατος, αναφορά στον πηγαίο κώδικα και τους πίνακες µε την κατανάλωση πόρων του συστήµατος.

22 22 Κεφάλαιο 2. Η λειτουργία του Agent Factory 2.1 Εισαγωγή Το AF βοηθά το χρήστη στο σχεδιασµό νέων ανεκπαίδευτων πρακτόρων, οι οποίοι συµµετέχουν σε πολυπρακτορικά συστήµατα. Οι πράκτορες αυτοί δηµιουργούνται µε βάση τις προδιαγραφές που δίνει ο χρήστης στο σύστηµα, διαθέτουν έναν ελάχιστο βαθµό ευφυΐας και, µετά τη δηµιουργία τους, είναι έτοιµοι να εκπαιδευτούν στο ΑΤΜ. Τα απαραίτητα βήµατα για τη δηµιουργία και την εκτέλεση των πρακτόρων είναι: 1) Φόρτωµα των απαραίτητων οντολογιών. Μια οντολογία αναπαριστά το µοντέλο ενός συγκεκριµένου γνωστικού πεδίου τις έννοιες και τις ιδιότητές τους, καθώς και τις σχέσεις µεταξύ των εννοιών. Έτσι, οι οντολογίες καθορίζουν τον τρόπο µε τον οποίο οι πράκτορες «βλέπουν» τον υπόλοιπο κόσµο. 2) Σχεδιασµός των συµπεριφορών των πρακτόρων. Οι συµπεριφορές αυτές καθορίζουν τον αλγόριθµο, τον οποίο θα ακολουθούν οι πράκτορες κατά την εκτέλεσή τους. εν είναι απαραίτητο να υπάρχει ακριβώς µία συµπεριφορά για κάθε πράκτορα οι συµπεριφορές υπάρχουν ως πρότυπα, και µπορούν να λάβουν διαφορετικές αρχικές τιµές για κάθε πράκτορα που θα τις ακολουθεί.

23 23 3) ηµιουργία τύπων πρακτόρων και συσχέτισή τους µε µία ή περισσότερες συµπεριφορές. Οι τύποι πρακτόρων υπάρχουν και πάλι ως πρότυπα χωρίς αρχικές συνθήκες. 4) ηµιουργία και εκτέλεση των στιγµιότυπων των πρακτόρων. Σε αυτό το στάδιο, δηµιουργείται ένα «σενάριο», στο οποίο φαίνονται όλοι οι πράκτορες που θα συµµετέχουν στο υπό σχεδίαση ΠΠΣ, καθώς και ο τύπος του καθένα. Στη συνέχεια, δίνονται αρχικές τιµές σε κάθε πράκτορα. Ακολουθεί η εκτέλεση του σεναρίου, µε όλους τους πράκτορες που συµµετέχουν σ αυτό. 2.2 Υποσυστήµατα Το AF αποτελείται από τέσσερα υποσυστήµατα: 1) ODT (Ontology Design Tool), στο οποίο σχεδιάζονται και φορτώνονται οι οντολογίες. 2) BTDT (Behavior Type Design Tool), όπου ο χρήστης σχεδιάζει τις συµπεριφορές των πρακτόρων. 3) ATDT (Agent Type Design Tool), όπου συσχετίζονται οι τύποι πρακτόρων µε τις συµπεριφορές. 4) SDT (Scenario Design Tool), όπου δηµιουργείται και εκτελείται το σενάριο του ΠΠΣ. Στο σχήµα 2-1 φαίνεται το κεντρικό παράθυρο του ΑΑ. Τα τέσσερα υποσυστήµατα του AF ενεργοποιούνται από τα τέσσερα πρώτα κουµπιά του παραθύρου. Τα υπόλοιπα τέσσερα αφορούν το PADT (Physical Asset Design Tool), που δείχνει τα assets του συστήµατος, έναν οδηγό για τη δηµιουργία ενός νέου ΠΠΣ, καθώς και τα υποσυστήµατα ATM και DM του ΑΑ. Σχήµα 2-1 Στιγµιότυπο κεντρικής οθόνης του Agent Academy Ακολουθεί µια σύντοµη περιγραφή του κάθε υποσυστήµατος.

24 ODT Το ODT είναι το υποσύστηµα που είναι υπεύθυνο για το φόρτωµα των οντολογιών, ώστε να διαβάζονται από το σύστηµα. Οι οντολογίες σχεδιάζονται µε το Protégé [18], το οποίο καλείται από το περιβάλλον του ODT. Το Protégé σχεδιάζει τις οντολογίες µε τη µορφή κλάσεων, οι οποίες συµβολοµεταφράζονται (compile) από το ODT. Σχήµα 2-2 Στιγµιότυπο οθόνης του ODT Στο Σχήµα 2-2 φαίνεται το παράθυρο του ODT. Το πρώτο πεδίο χρησιµεύει στην εισαγωγή µιας αποθηκευµένης οντολογίας. Το δεύτερο πεδίο καλεί το Protégé, για να σχεδιάσει µια νέα οντολογία, και το τρίτο δείχνει µια λίστα µε τις ήδη φορτωµένες οντολογίες.

25 BTDT Σχήµα 2-3 Στιγµιότυπο οθόνης του BTDT Το BTDT είναι το υποσύστηµα που είναι υπεύθυνο για τη σχεδίαση του αλγόριθµου της συµπεριφοράς του κάθε πράκτορα. Όπως φαίνεται από το Σχήµα 2-3, ο αλγόριθµος αυτός οπτικοποιείται στο χρήστη µε τη µορφή ενός διαγράµµατος ροής, για διευκόλυνσή του. Για να σχεδιάσει την επιθυµητή συµπεριφορά, ο χρήστης προσθέτει blocks στο διάγραµµα, όπου κάθε block αντιστοιχεί σε µια ενέργεια του πράκτορα. Οι διαθέσιµοι τύποι blocks είναι οι εξής: Receive block : λήψη µηνύµατος από έναν άλλο πράκτορα Send block : αποστολή µηνύµατος σε έναν άλλο πράκτορα Activity block : εκτέλεση µιας συνάρτησης από εξωτερική κλάση Java Jess block : εκτέλεση κώδικα Jess [17] If block : διακλάδωση ανάλογα µε µια συνθήκη While block : για υλοποίηση βρόχων Statement block : για απλές πράξεις µεταξύ µεταβλητών

26 26 Οι µεταβλητές που χειρίζεται το σύστηµα είναι δύο ειδών: Assets, όταν ορίζονται και αρχικοποιούνται από το χρήστη Global variables, όταν αντιστοιχούν σε κάποια έξοδο block (π.χ. το περιεχόµενο ενός µηνύµατος) Τα assets ορίζονται από το PADT (Physical Asset Design Tool), όπου ορίζεται ο τύπος τους (ακέραιος, αριθµός κινητής υποδιαστολής, συµβολοσειρά ή λογική µεταβλητή), καθώς και αν η αρχική τιµή δίνεται από το χρήστη ή διαβάζεται από κάποιο αρχείο XML ή από µια βάση δεδοµένων. Επίσης, συχνά χρειάζεται να δοθεί η τιµή κάποιου asset ως όρισµα σε κάποια εξωτερική συνάρτηση. Αυτό συµβαίνει κατά την αποστολή µηνυµάτων, την εκτέλεση κλάσεων Java και την εκτέλεση κώδικα Jess. Αυτό γίνεται µε το Mapping Tool, που αντιστοιχίζει τα assets µε τα ορίσµατα των παραπάνω συναρτήσεων. Το Σχήµα 2-4 δείχνει το παράθυρο του Mapping Tool. Η αριστερή στήλη έχει µια λίστα µε τα assets και τις µεταβλητές του συστήµατος, ενώ η δεξιά δείχνει την οντολογία, µε τα στοιχεία της οποίας θα γίνει η αντιστοίχιση. Σχήµα 2-4 Το Mapping Tool

27 27 Όταν ο χρήστης σχεδιάσει την επιθυµητή συµπεριφορά, την αποθηκεύει στο AUR, ώστε να διαβάζεται στα επόµενα στάδια. Εναλλακτικά, µπορεί και να την αποθηκεύσει σε αρχείο ATDT Το ATDT είναι το υποσύστηµα που αναλαµβάνει τη δηµιουργία των τύπων των πρακτόρων και την αντιστοίχισή τους µε µία ή περισσότερες συµπεριφορές. Ένας τύπος πράκτορα είναι στην ουσία ένα πρότυπο πράκτορα, αντιστοιχισµένο µε µια ή περισσότερες συµπεριφορές. Μπορεί να σχεδιαστεί από την αρχή ή να προκύψει τροποποιώντας έναν υπάρχοντα τύπο πράκτορα. Το Σχήµα 2-5 δείχνει το παράθυρο του ATDT, στο οποίο περιέχεται µια καρτέλα µε έναν πράκτορα. Σχήµα 2-5 Στιγµιότυπο οθόνης του ATDT Όπως φαίνεται στο Σχήµα 2-5, κάθε τύπος πράκτορα σχεδιάζεται σε µια ξεχωριστή καρτέλα. Μετά τη σχεδίαση, ο χρήστης αποθηκεύει τους νεοδηµιουργηθέντες πράκτορες στο AUR SDT Το SDT αναλαµβάνει τη δηµιουργία ενός σεναρίου, στο οποίο συµµετέχουν ένας ή περισσότεροι πράκτορες. Οι πράκτορες αυτοί

28 28 δηµιουργούνται σύµφωνα µε τους τύπους πράκτορα που δηµιουργήθηκαν από το ATDT. Για να τρέξουν µε επιτυχία οι πράκτορες, πρέπει πρώτα να καθοριστούν ορισµένες αρχικές συνθήκες, δηλαδή οι αρχικές τιµές των µεταβλητών και οι αποστολείς και παραλήπτες των µηνυµάτων. Έτσι, ο χρήστης ακολουθεί µια διαδικασία εισαγωγής αυτών των αρχικών τιµών, καλώντας αρχικά το ATDT για κάθε πράκτορα και τέλος το BTDT για κάθε συµπεριφορά. Όταν τελειώσει αυτή η διαδικασία, το σενάριο αποθηκεύεται στο AUR και είναι έτοιµο να εκτελεστεί. Εναλλακτικά, το σενάριο µπορεί να αποθηκευτεί και σε αρχείο XML, για λόγους φορητότητας. Στο Σχήµα 2-6 φαίνεται το παράθυρο του SDT, µε ένα κενό σενάριο, κατά τη στιγµή της εισαγωγής ενός νέου πράκτορα. Σχήµα 2-6 Στιγµιότυπο οθόνης του SDT

29 29 Κεφάλαιο 3. Περιγραφή του προβλήµατος 3.1 Ορισµός του προβλήµατος Όπως αναφέρθηκε στο προηγούµενο κεφάλαιο, το Agent Factory είναι το τµήµα του Agent Academy που δηµιουργεί νέους ανεκπαίδευτους πράκτορες, και µάλιστα το τµήµα που έχει το µεγαλύτερο βαθµό αλληλεπίδρασης µε το χρήστη. Όπως προέκυψε από τις αξιολογήσεις που έγιναν στην προηγούµενη έκδοση του Agent Factory, η λειτουργία του δεν ήταν ικανοποιητική, δεν ήταν αρκετά φιλικό προς το χρήστη, ενώ παρουσίαζε και αρκετά σφάλµατα. Αυτό ακριβώς είναι και το πρόβληµα που αντιµετωπίστηκε στην παρούσα διπλωµατική, δηλαδή η εκσφαλµάτωση και βελτίωση του Agent Factory. Η βελτίωση αυτή έγινε σε τέσσερα στάδια. Το πρώτο στάδιο περιλαµβάνει τον καθορισµό των απαιτήσεων και των προδιαγραφών του συστήµατος, µε βάση και τα προηγούµενα παραδοτέα του Agent Academy [9,10]. Το δεύτερο εστιάζεται στην αξιοποίηση των περασµένων αξιολογήσεων, καθώς και προσωπική προσπάθεια στην εκσφαλµάτωση του συστήµατος. Το τρίτο αφορά τη βελτίωση του κώδικα. Τέλος, στο τέταρτο στάδιο έγιναν οι απαραίτητες δοκιµές για την πιστοποίηση της καλής λειτουργίας του Agent Factory.

30 Ανάλυση απαιτήσεων Γενική περιγραφή του AF Κύρια δοµικά στοιχεία του AF Το AF αποτελείται από τέσσερα δοµικά στοιχεία: 1. ODT (Ontology Design Tool): Σχεδιασµός νέας οντολογίας από το Protégé [18] ή εισαγωγή ήδη υπάρχουσας 2. BTDT (Behavior Type Design Tool): Σχεδιασµός της συµπεριφοράς του πράκτορα 3. ATDT (Agent Type Design Tool): Συσχέτιση πράκτορα µε συµπεριφορά 4. SDT (Scenario Design Tool): ηµιουργία στιγµιότυπου πράκτορα Κατηγορίες και χαρακτηριστικά χρηστών Οι κύριες οµάδες χρηστών του συστήµατος είναι οι ακόλουθες: α. Προγραµµατιστές εφαρµογών β. Ιδιοκτήτες εφαρµογών γ. Τελικοί χρήστες Οι διάφορες οµάδες χρηστών θα µπορούν να επιτελούν πληθώρα λειτουργιών για την ενηµέρωση τη δική τους και του συστήµατος. Πιο συγκεκριµένα, οι προγραµµατιστές είναι οι πραγµατικοί χρήστες του συστήµατος, που δηµιουργούν πράκτορες και εκτελούν εξόρυξη δεδοµένων. Οι ιδιοκτήτες είναι ουσιαστικά οι εταιρείες που έχουν µια υπάρχουσα εφαρµογή, η οποία µπορεί να βελτιωθεί µε την εισαγωγή ευφυών πρακτόρων, και επιλέγουν να χρησιµοποιήσουν το Agent Academy για την εκπαίδευσή τους. Πρέπει να προµηθεύουν τους προγραµµατιστές µε δεδοµένα εφαρµογών και απαιτήσεις. Οι τελικοί χρήστες είναι όσοι χρησιµοποιούν την τελική εφαρµογή και µέσω αυτής τους πράκτορες που αυτή εµπεριέχει. εν έχουν επίγνωση της ύπαρξης του Agent Academy και έτσι θεωρούνται έµµεσοι χρήστες του συστήµατος.

31 Περιβάλλον λειτουργίας Το Agent Factory δε λειτουργεί µεµονωµένα σε κάθε µηχάνηµα, αλλά θα παρέχει στους χρήστες του δυνατότητα επικοινωνίας µε µια κεντρική βάση δεδοµένων, µέσω τοπικού δικτύου ή διαδικτύου. Στόχος αυτής της επιλογής είναι η διευκόλυνση των άµεσων χρηστών του Agent Factory που συνεργάζονται για την ίδια εφαρµογή, ώστε να διαµοιράζονται τυχόν τύπους πρακτόρων που έχουν οι ίδιοι δηµιουργήσει. Σύµφωνα µε τα παραπάνω, είναι απαραίτητο, όπως και το υπόλοιπο τµήµα του Agent Academy άλλωστε, το Agent Factory να σχεδιαστεί σε περιβάλλον Java, ώστε να είναι ανεξάρτητο από το λειτουργικό σύστηµα του κάθε υπολογιστή. Εξάλλου, θα πρέπει να έχει δυνατότητα συνεργασίας µε εξωτερική βάση δεδοµένων, συγκεκριµένα µε την PostgreSQL που χρησιµοποιείται από το Agent Academy. Εξυπακούεται ότι δεν είναι απαραίτητο η βάση δεδοµένων να λειτουργεί στο ίδιο µηχάνηµα µε το Agent Factory, αλλά µπορεί να γίνει και δικτυακή σύνδεση, µέσω τοπικού δικτύου ή διαδικτύου Υποστήριξη χρηστών Η υποστήριξη χρηστών παρέχεται στην αγγλική γλώσσα, µέσω των εγχειριδίων του AA. Ένα µέρος των εγχειριδίων αυτών βρίσκεται σε µορφή pdf στον κατάλογο documentation του Agent Academy. Ένα άλλο µέρος τους είναι άµεσα προσβάσιµο από το µενού βοήθειας, κατά την εκτέλεση της εφαρµογής. Το µέρος αυτό δεν προϋπήρχε, αλλά γράφτηκε στα πλαίσια της παρούσας διπλωµατικής και βρίσκεται στο παράρτηµα Α.

32 Απαιτήσεις εσωτερικής σχεδίασης Οι απαιτήσεις αυτές γράφτηκαν από την αρχή, ανεξάρτητα από την υπάρχουσα υλοποίηση, για να ορίσουν το πλαίσιο στο οποίο πρέπει να κινείται το AF. Από την αντιπαραβολή των απαιτήσεων µε τα αποτελέσµατα των δοκιµών προέκυψαν οι διορθώσεις που έπρεπε να γίνουν ODT (Ontology Design Tool) Το ODT είναι ένα απλό κοµµάτι του AF, το οποίο επιτρέπει στο χρήστη να εισάγει τις επιθυµητές οντολογίες. Ακολουθίες εισόδου: Νέα οντολογία: Καλείται το Protégé για να σχεδιαστεί η νέα οντολογία. Το αποτέλεσµα αποθηκεύεται και φορτώνεται. Υπάρχουσα οντολογία: Ο χρήστης καλείται να επιλέξει το όνοµα της επιθυµητής οντολογίας. Ακολουθίες εξόδου: Προσθήκη στη λίστα AF_Ontologies: Η νέα οντότητα προσαρτάται στη λίστα AF_Ontologies. Ο χρήστης µπορεί να τη χρησιµοποιήσει κατόπιν στη σχεδίαση. Λειτουργικές απαιτήσεις: ΑΠ-1.1 Στο χρήστη θα πρέπει να εµφανίζεται λίστα µε τις οντολογίες που έχουν ήδη προστεθεί. Αιτιολ. : ιευκόλυνση του χρήστη στην επαλήθευση της δουλειάς του, ειδικά στην περίπτωση πολλών οντολογιών. ΑΠ-1.2 Ο χρήστης µπορεί να προχωρήσει στο επόµενο βήµα χωρίς να εισάγει οντολογία, αλλά µε σχετική προειδοποίηση. Αιτιολ. : Η οντολογία δεν είναι απαραίτητη, κυρίως για µικρές εφαρµογές, αλλά ο χρήστης πρέπει να γνωρίζει εκ των προτέρων ποιους περιορισµούς εισάγει αυτή η επιλογή. ΑΠ-1.3 Το σύστηµα παρέχει στο χρήστη τη δυνατότητα ενός προεπιλεγµένου καταλόγου για την αποθήκευση των οντολογιών. Αιτιολ. : ιευκόλυνση του χρήστη στην οργάνωση των οντολογιών. ΑΠ-1.4 Το σύστηµα παρέχει στο χρήστη τη δυνατότητα να διαγράψει µια φορτωµένη οντολογία, µόνο µετά από προειδοποιητικό µήνυµα. Αιτιολ. : Η διαγραφή µιας οντολογίας θα διαταράξει τη λειτουργία τυχόν πρακτόρων που τη χρησιµοποιούν. Ο χρήστης πρέπει να προειδοποιηθεί.

33 BTDT Το BTDT είναι ένα εργαλείο που διευκολύνει το χρήστη στο σχεδιασµό της επιθυµητής συµπεριφοράς του πράκτορα, µε φιλικό προς αυτόν τρόπο. Ο αλγόριθµος που καθορίζει τη συµπεριφορά του πράκτορα σχεδιάζεται από το χρήστη µε τη µορφή ενός διαγράµµατος ροής. Παράλληλα, ζητείται από το χρήστη η εισαγωγή των παραµέτρων που είναι απαραίτητες για τον πλήρη καθορισµό της συµπεριφοράς για παράδειγµα, σε µια διακλάδωση IF, πρέπει να καθορίζεται πλήρως το κριτήριο σύµφωνα µε το οποίο θα ληφθεί η απόφαση. Ακολουθίες εισόδου: Αλγόριθµος συµπεριφοράς: Ο χρήστης δίνει, µε τη µορφή ενός διαγράµµατος ροής, τον αλγόριθµο που καθορίζει τη συµπεριφορά του επιθυµητού τύπου πράκτορα. Ονόµατα παραµέτρων: Ο χρήστης δίνει τα ονόµατα των παραµέτρων που απαιτούνται κατά την αρχικοποίηση, καθώς και τον τύπο δεδοµένων που αντιστοιχεί στο καθένα. Οντολογίες: Σε περίπτωση που απαιτείται αντιστοίχιση µε κάποια οντολογία, ο χρήστης καλείται να τη διαλέξει από τη λίστα που δηµιουργήθηκε από το ODT. Ακολουθίες εξόδου: Αρχεία αρχικοποίησης τύπου πράκτορα: Το πρόγραµµα δηµιουργεί τα αρχεία αρχικοποίησης που απαιτούνται για τη δηµιουργία του τύπου πράκτορα που σχεδίασε ο χρήστης. Προσάρτηση ονόµατος στη λίστα: Μετά τη δηµιουργία του τύπου πράκτορα, το όνοµά του προστίθεται στη λίστα, ώστε να µπορεί να χρησιµοποιηθεί στα µετέπειτα στάδια. Λειτουργικές απαιτήσεις: ΑΠ-2.1 Σε περίπτωση που σχεδιάζεται τύπος πράκτορα, για κάθε παράµετρο δίνεται απλώς το όνοµα και ο τύπος της (π.χ. τύπος δεδοµένων) Αιτιολ. : Οι τιµές των παραµέτρων απαιτούνται µόνο κατά τη δηµιουργία του στιγµιότυπου, οπότε και γίνεται η αρχικοποίηση. Εισαγωγή τιµών σε προηγούµενο στάδιο είναι άσκοπη, καθώς περιορίζει την ευελιξία. ΑΠ-2.2 Ο χρήστης δεν µπορεί να προχωρήσει στο επόµενο στάδιο, παρά µόνο αν έχει δώσει όλες τις παραµέτρους που απαιτούνται και αποθηκεύσει

34 34 το αρχείο. Σε διαφορετική περίπτωση, εµφανίζεται µήνυµα λάθους µε τις παραµέτρους που υπολείπονται. Αιτιολ. : Σε διαφορετική περίπτωση, ο χρήστης θα αντιµετωπίσει απρόβλεπτα προβλήµατα σε µετέπειτα στάδιο και θα είναι δύσκολο να εντοπίσει την προέλευσή τους. ΑΠ-2.3 Ο χρήστης µπορεί να αποθηκεύσει ένα ενδιάµεσο αρχείο ακόµα και χωρίς να έχει ολοκληρωθεί η εισαγωγή των παραµέτρων. Αιτιολ. : ίνεται η δυνατότητα συνέχισης ενός ηµιτελούς σχεδιασµού. Σε αντίθετη περίπτωση, ο χρήστης δεν µπορεί να κλείσει το πρόγραµµα αν δεν έχει ολοκληρώσει το σχεδιασµό. ΑΠ-2.4 Ο χρήστης µπορεί να ανοίξει ένα αποθηκευµένο αρχείο, ηµιτελές ή όχι, και να συνεχίσει τη σχεδίαση. Αιτιολ. : Η σχεδίαση της συµπεριφοράς από την αρχή και η συνέχιση της σχεδίασης πρέπει να γίνονται στο ίδιο περιβάλλον, για διευκόλυνση του χρήστη. ΑΠ-2.5 Πολλοί τύποι πρακτόρων µπορούν να µοιράζονται κάποιες παραµέτρους. Αιτιολ. : ιευκολύνει τη σχεδίαση σε περίπτωση που οι πράκτορες επικοινωνούν.

35 ATDT Το ATDT δηµιουργεί νέους πράκτορες και συσχετίζει τον καθένα µε µία ή περισσότερες συµπεριφορές. Ακολουθίες εισόδου: Τύποι πρακτόρων: Για τον καθορισµό της συµπεριφοράς του νέου πράκτορα, το ATDT διαβάζει τα αρχεία µε τους τύπους πρακτόρων που έχουν δηµιουργηθεί από το BTDT. Όνοµα και συµπεριφορές νέου πράκτορα: Το ATDT διαβάζει από το χρήστη το όνοµα του πράκτορα που πρόκειται να δηµιουργήσει, καθώς και τις συµπεριφορές στις οποίες αντιστοιχίζεται. Ακολουθίες εξόδου: Αρχείο αρχικοποίησης πράκτορα: Το πρόγραµµα δηµιουργεί τα αρχεία αρχικοποίησης που απαιτούνται για τη δηµιουργία του πράκτορα που σχεδίασε ο χρήστης. Λειτουργικές απαιτήσεις: ΑΠ-3.1 Ο χρήστης έχει τη δυνατότητα να αντιστοιχίσει πολλούς τύπους πράκτορα στον ίδιο πράκτορα. Αιτιολ. : Ο ίδιος πράκτορας µπορεί να έχει περισσότερες από µία συµπεριφορές, ανάλογα µε την περίσταση. Σε αντίθετη περίπτωση, ο σχεδιασµός θα ήταν εξαιρετικά περιοριστικός. ΑΠ-3.2 Ο χρήστης έχει τη δυνατότητα να αντιστοιχίσει πολλούς ίδιους τύπους πράκτορα στον ίδιο πράκτορα. Αιτιολ. : Η διαφορά έγκειται στο ότι µπορεί οι αρχικοί τύποι πράκτορα να είναι ίδιοι, αλλά να λαµβάνουν διαφορετικές αρχικές τιµές. ΑΠ-3.3 Ο χρήστης µπορεί να αποθηκεύσει ένα ενδιάµεσο αρχείο ακόµα και χωρίς να έχει ολοκληρωθεί η εισαγωγή των παραµέτρων. Αιτιολ. : ίνεται η δυνατότητα συνέχισης ενός ηµιτελούς σχεδιασµού. Σε αντίθετη περίπτωση, ο χρήστης δεν µπορεί να κλείσει το πρόγραµµα αν δεν έχει ολοκληρώσει το σχεδιασµό, κάτι που κρίνεται µη λειτουργικό. ΑΠ-3.4 Ο χρήστης µπορεί να ανοίξει ένα αποθηκευµένο αρχείο, ηµιτελές ή όχι, και να συνεχίσει ή να βελτιώσει τη σχεδίαση. Αιτιολ. : Η σχεδίαση της συµπεριφοράς από την αρχή και η συνέχιση της σχεδίασης πρέπει να γίνονται στο ίδιο περιβάλλον, για διευκόλυνση του χρήστη. ΑΠ-3.5 Ο χρήστης δεν µπορεί να προχωρήσει στο επόµενο στάδιο, παρά µόνο αν έχει δώσει όλες τις παραµέτρους που απαιτούνται και αποθηκεύσει το αρχείο. Σε διαφορετική περίπτωση, εµφανίζεται µήνυµα λάθους µε τις παραµέτρους που υπολείπονται.

36 36 Αιτιολ. : Σε διαφορετική περίπτωση, ο χρήστης θα αντιµετωπίσει απρόβλεπτα προβλήµατα σε µετέπειτα στάδιο και θα είναι δύσκολο να εντοπίσει την προέλευσή τους. ΑΠ-3.6 Ο χρήστης µπορεί να σχεδιάζει ταυτόχρονα πολλούς πράκτορες, χωρίς να είναι απαραίτητο να τρέχει το πρόγραµµα µια φορά για κάθε πράκτορα. Αιτιολ. : Το AA είναι µια πλατφόρµα σχεδίασης συστηµάτων πολλών πρακτόρων και θα πρέπει να διευκολύνει το χρήστη σε µια τέτοια σχεδίαση SDT Το SDT επιτρέπει στο χρήστη να δηµιουργήσει ένα «σενάριο» αλληλεπίδρασης πολλών πρακτόρων και στη συνέχεια να δηµιουργήσει στιγµιότυπα των πρακτόρων που θα λάβουν µέρος σ αυτήν την αλληλεπίδραση. Ακολουθίες εισόδου: Αρχεία αρχικοποίησης πρακτόρων: Ο χρήστης επιλέγει τους πράκτορες που θα λάβουν µέρος σ αυτό το σενάριο και το πρόγραµµα διαβάζει τα αρχεία που δηµιουργήθηκαν από το ATDT. Παράµετροι: Το πρόγραµµα καλεί το χρήστη να εισάγει τις απαραίτητες παραµέτρους για την αρχικοποίηση των επιλεγµένων πρακτόρων (π.χ. τιµές µεταβλητών) καθώς και τον τρόπο µε τον οποίο θα αλληλεπιδρούν (π.χ. ποιος πράκτορας θα επικοινωνεί µε ποιον, σε ποια χρονική στιγµή, και τι είδους µήνυµα θα στέλνει) Ακολουθίες εξόδου: Στιγµιότυπο πράκτορα: Σύµφωνα µε τις παραµέτρους που έχουν εισαχθεί, το πρόγραµµα δηµιουργεί στιγµιότυπα των επιλεγµένων πρακτόρων και τα αποθηκεύει. Πληροφόρηση του AUR: Το πρόγραµµα πληροφορεί το AUR για την ύπαρξη των νέων πρακτόρων.

37 37 Λειτουργικές απαιτήσεις: ΑΠ-4.1 Στο ίδιο σενάριο µπορούν να συµµετέχουν περισσότεροι του ενός πράκτορες. Αιτιολ. : Σε διαφορετική περίπτωση, αποκλείεται η επικοινωνία µεταξύ των πρακτόρων, κάτι που είναι από τους βασικούς στόχους του AA. ΑΠ-4.2 Στο ίδιο σενάριο µπορούν να συµµετέχουν πολλοί ίδιοι πράκτορες. Αιτιολ. : Η διαφορά έγκειται στο ότι µπορούν να λάβουν διαφορετικές αρχικές τιµές κατά τη δηµιουργία των στιγµιοτύπων τους και κατά συνέπεια να παίζουν εντελώς διαφορετικό ρόλο. ΑΠ-4.3 Ο χρήστης µπορεί να αποθηκεύσει ένα ενδιάµεσο αρχείο ακόµα και χωρίς να έχει ολοκληρωθεί η εισαγωγή των παραµέτρων. Αιτιολ. : ίνεται η δυνατότητα συνέχισης ενός ηµιτελούς σχεδιασµού. Σε αντίθετη περίπτωση, ο χρήστης δεν µπορεί να κλείσει το πρόγραµµα αν δεν έχει ολοκληρώσει το σχεδιασµό, κάτι που κρίνεται µη λειτουργικό. ΑΠ-4.4 Ο χρήστης µπορεί να ανοίξει ένα αποθηκευµένο αρχείο, ηµιτελές ή όχι, και να συνεχίσει ή να βελτιώσει τη σχεδίαση. Αιτιολ. : Η σχεδίαση της συµπεριφοράς από την αρχή και η συνέχιση της σχεδίασης πρέπει να γίνονται στο ίδιο περιβάλλον, για διευκόλυνση του χρήστη. ΑΠ-4.5 Ο χρήστης δεν µπορεί να προχωρήσει στο επόµενο στάδιο, παρά µόνο αν έχει δώσει όλες τις παραµέτρους που απαιτούνται και αποθηκεύσει το αρχείο. Σε διαφορετική περίπτωση, εµφανίζεται µήνυµα λάθους µε τις παραµέτρους που υπολείπονται. Αιτιολ. : Σε διαφορετική περίπτωση, ο χρήστης θα αντιµετωπίσει απρόβλεπτα προβλήµατα σε µετέπειτα στάδιο και θα είναι δύσκολο να εντοπίσει την προέλευσή τους Απαιτήσεις εξωτερικών διεπαφών ιεπαφή µε το χρήστη Το AF θα έχει λίστες µε διαθέσιµους τύπους πρακτόρων και διαθέσιµες οντολογίες JADE. Αυτή η διεπαφή θα παρέχει στο χρήστη τις εξής δυνατότητες: Να προσθέτει οντολογίες στη λίστα AF_OntologiesList Να προσθέτει νέους τύπους πρακτόρων στη λίστα AF_AgentTypeList Να επιλέγει τον τύπο του πράκτορα που θα δηµιουργηθεί Να θέτει τιµές σε προκαθορισµένες παραµέτρους γι αυτόν τον πράκτορα Να θέτει τιµές σε προκαθορισµένες οντολογίες Επιπρόσθετα, το AF θα αποθηκεύει ενδιάµεσα αρχεία αποτελεσµάτων, ώστε να µπορεί να δίνει στο χρήστη τη δυνατότητα να τροποποιεί έναν υπάρχοντα πράκτορα. Η διεπαφή χρήστη του AA θα δίνει επίσης τη δυνατότητα

38 38 στους χρήστες να αναγνωρίζουν, να συλλέγουν και να εισάγουν στην απαραίτητη φόρµα τις προτιµήσεις τους. Οι προτιµήσεις αυτές θα πρέπει να λαµβάνονται υπόψη από το AF, ώστε να διευκολύνουν τους χρήστες στην αποδοτική χρήση του ιεπαφή µε το υλικό εν υπάρχει άµεση αλληλεπίδραση µε το υλικό του υπολογιστή ιεπαφές µε άλλα προϊόντα λογισµικού Το Agent Factory έχει δυνατότητα επικοινωνίας µε την πλατφόρµα JADE. Για την ακρίβεια, είναι ο συνδετικός κρίκος ανάµεσα στο Agent Academy και στο JADE. Επίσης, το Agent Factory καλεί το Protégé για τη σχεδίαση µιας νέας οντολογίας ιεπαφές επικοινωνίας ιεπαφή AF AUR Το AF διαβάζει από το AUR την οντολογία για ένα δεδοµένο τύπο πράκτορα, άρα χρειάζεται πρόσβαση ανάγνωσης στις αντίστοιχες πληροφορίες. Επίσης, το AF θα πληροφορεί το AUR για τύπους πρακτόρων και σύνολα παραµέτρων πρακτόρων. Την ευθύνη για τις παραπάνω διαδικασίες θα αναλαµβάνει ο Data Acquisition Agent. ιεπαφή AF ATM Το AF θα στέλνει στο ATM µια αίτηση εκπαίδευσης ενός νεοδηµιούργητου πράκτορα. Το µήνυµα ACL θα περιέχει τον τύπο και το id του νέου πράκτορα. Ο ΑΤΜ Agent θα χρησιµοποιείται για την επικοινωνία µεταξύ AF και ΑΤΜ Μη λειτουργικές απαιτήσεις Απαιτήσεις επίδοσης εν υπάρχουν ιδιαίτερες απαιτήσεις επίδοσης. Γενικότερα, πρέπει να δοθεί ιδιαίτερη προσοχή στην ταχύτητα εκτέλεσης, καθώς όλες οι εφαρµογές σε

39 39 Java υστερούν στον τοµέα αυτό. Επίσης, η επικοινωνία µε άλλα τµήµατα του AA (π.χ. µε το AUR) πρέπει να γίνονται τακτικά, ώστε να διευκολύνεται ο κατανεµηµένος σχεδιασµός πρακτόρων και η συνεργασία πολλών σταθµών εργασίας Απαιτήσεις αξιοπιστίας Σε περίπτωση που το AF αποτύχει να επικοινωνήσει µε µια άλλη µονάδα, τα αποτελέσµατα δε θα πρέπει µε κανέναν τρόπο να χάνονται. Καλό είναι να αποθηκεύονται αυτόµατα τα αποτελέσµατα του αµέσως προηγούµενου βήµατος και να ενηµερώνεται ο χρήστης σχετικά µε το πού µπορεί να τα βρει, ώστε να µπορέσει να ξεκινήσει από το σηµείο όπου παρουσιάστηκε η βλάβη και όχι νωρίτερα Απαιτήσεις ασφάλειας εν υπάρχουν ιδιαίτερες απαιτήσεις ασφάλειας Απαιτήσεις ποιότητας λογισµικού Ο λόγος που επελέγη η Java είναι η ανεξαρτησία από το λειτουργικό σύστηµα. Αυτή η προδιαγραφή πρέπει να τηρηθεί προσεκτικά κατά την υλοποίηση και τη συγγραφή του κώδικα και να αποφεύγονται ιδιαιτερότητες του λειτουργικού συστήµατος (π.χ. αναφορά αρχείων µε απόλυτη διαδροµή, του τύπου C:\arxeio.txt). Επίσης, η διεπαφή µε το χρήστη πρέπει να γίνεται µε φιλικό τρόπο. Επειδή οι άµεσοι χρήστες του AF έχουν ήδη εµπειρία από προγραµµατισµό, το βάρος πρέπει να δοθεί στη σωστή ενηµέρωση του χρήστη για τις ενέργειες του συστήµατος και για τυχόν λάθη. Για τον ίδιο λόγο, πρέπει το σύστηµα να βασίζεται στις απαιτήσεις του χρήστη και να αποφεύγει να λαµβάνει πρωτοβουλίες. Σε περίπτωση που είναι απαραίτητο να λάβει κάποια πρωτοβουλία, πρέπει να ενηµερώνεται σχετικά ο χρήστης. 3.3 Αξιολογήσεις Την ολοκλήρωση της προηγούµενης έκδοσης του Agent Factory ακολούθησε µια σειρά αξιολογήσεων. Αυτές έγιναν από φοιτητές και προγραµµατιστές στην Ολλανδία, στην Τουρκία, στην Ισπανία και στην Ελλάδα, µεταξύ των οποίων και η συγγραφέας της διπλωµατικής. Όπως προέκυψε από

40 40 αυτές τις αξιολογήσεις, το Agent Factory υστερούσε σηµαντικά σε επίπεδο φιλικότητας προς το χρήστη, έλειπαν σηµαντικές δυνατότητες, ενώ παρουσίαζε και σηµαντικά προβλήµατα λειτουργικότητας. Μια σύνοψη των αποτελεσµάτων παρουσιάζεται στον Πίνακα 3-1. Για λεπτοµερέστερη ανάλυση, ο αναγνώστης µπορεί να ανατρέξει στο παραδοτέο 4.3 του Agent Academy [11] Περιγραφή δοκιµής Χωρίς Με Λείπει προβλ προβλ Εκκίνηση του ODT Άνοιγµα του Protégé Φόρτωµα οντολογίας Κλείσιµο του ODT Εκκίνηση του BTDT ηµιουργία διαγράµµατος συµπεριφοράς µε χρήση όλων των blocks Επεξεργασία όλων των αντικειµένων µε δεξί κλικ -> edit Αποθήκευση διαγράµµατος συµπεριφοράς (θέση;) Εναλλαγή κυκλικής εφάπαξ συµπεριφοράς Χρήση Behavior / Jess Code για δηµιουργία δείγµατος κώδικα ηµιουργία στιγµιότυπων των δηµιουργηθέντων πρακτόρων Χρήση Βοήθειας Κλείσιµο παραθύρου BTDT Άνοιγµα BTDT και φόρτωση των συµπεριφορών του χρήστη, σύγκριση Εκκίνηση του ATDT ηµιουργία νέου ταµπλό πράκτορα Προσθήκη νέου τύπου πράκτορα στο ταµπλό Επεξεργασία του τύπου πράκτορα που δηµιουργήθηκε Επανάληψη της διαδικασίας για τη δηµιουργία πράκτορα Αποθήκευση τύπου πράκτορα Χρήση Βοήθειας Κλείσιµο ATDT Άνοιγµα του ATDT, φόρτωµα των ίδιων τύπων πράκτορα, σύγκριση Εκκίνηση του SDT ηµιουργία νέου σεναρίου Προσθήκη πρακτόρων από διάφορους containers Επεξεργασία πρακτόρων στο σενάριο Αποθήκευση σεναρίου και δηµιουργία ακόµα ενός Χρήση Βοήθειας Κλείσιµο του SDT Άνοιγµα εκ νέου του SDT, φόρτωµα σεναρίων Άνοιγµα του PADT Επανάληψη βηµάτων της προηγούµενης δοκιµής Χρήση Βοήθειας Κλείσιµο του PADT Πίνακας 3-1 Αποτελέσµατα δοκιµών της πρώτης έκδοσης του AF

41 Παρατηρήσεις Η παραπάνω αξιολόγηση δείχνει ότι η προηγούµενη έκδοση του Agent Academy πρέπει να θεωρείται ένα σύστηµα για προχωρηµένους. Οι χρήστες που θέλουν να χρησιµοποιήσουν την πλατφόρµα πρέπει να εκπαιδευτούν σε βάθος, πριν µπορέσουν να χρησιµοποιήσουν το Agent Academy για να ικανοποιήσουν τις ανάγκες τους. Είναι φανερό από τα αποτελέσµατα ότι το σύστηµα έχει σοβαρά προβλήµατα λειτουργικότητας, καθώς πολλοί από τους χρήστες δεν κατάφεραν να πραγµατοποιήσουν τις δοκιµές δηµιουργίας ενός νέου πράκτορα. Τα προβλήµατα αυτά κρίνεται ότι χρήζουν άµεσης επίλυσης. Επίσης, σηµειώθηκαν σοβαρές ελλείψεις στην υλοποίηση, οι οποίες, παρότι δεν επηρεάζουν σηµαντικά τη λειτουργικότητα του συστήµατος, είναι απαραίτητο να διορθωθούν. Ανάµεσα σ αυτές τις ελλείψεις είναι τα κείµενα βοήθειας, που να καθοδηγούν το χρήστη στην ορθή χρήστη της πλατφόρµας Βέβαια, ένα µέρος των σφαλµάτων οφείλεται σε λάθη των χρηστών και όχι σε προγραµµατιστικά σφάλµατα, αλλά αυτό σηµαίνει ότι η διεπαφή χρήστη του προγράµµατος θα έπρεπε να είναι πιο φιλική. Είναι πολύ σηµαντικό να πληροφορείται ο χρήστης για τις ενέργειες που διέπραξε επιτυχώς, καθώς και για τις ενέργειες που αποµένει να γίνουν. Για παράδειγµα, η δηµιουργία ενός νέου σεναρίου και η δηµιουργία στιγµιότυπων απαιτεί πολλά βήµατα, σε πολλά από τα οποία δε φαίνεται καθαρά τι απέµεινε, ή δε φαίνεται καν ότι πρέπει να γίνουν. 3.5 Ανάλυση προβληµάτων του Agent Factory Τα πειράµατα της αξιολόγησης επαναλήφθηκαν από τη συγγραφέα, µε σκοπό να εντοπιστούν και να καταγραφούν επακριβώς τα προβλήµατα του Agent Factory. Με βοήθεια και από το παραδοτέο του AA, τα προβλήµατα µπορούν να χωριστούν κατά κύριο λόγο σε προβλήµατα λειτουργικότητας και διεπαφής χρήστη.

42 Προβλήµατα λειτουργικότητας Προβλήµατα λειτουργικότητας παρουσιάζονται, όταν το σύστηµα δεν εκτελεί κάποια λειτουργία που του ανατίθεται, ή όταν εκτελεί διαφορετικά πράγµατα από τα αναµενόµενα. Τα προβλήµατα αυτά µπορεί να προκαλούν σφάλµατα, ή απλώς να παρεµποδίζουν την εργασία του χρήστη. Για παράδειγµα, στο παράθυρο επεξεργασίας του Jess block στο BTDT, το πλήκτρο ΟΚ αποθήκευε µεν τις ρυθµίσεις, αλλά δεν έκλεινε το παράθυρο, ενώ το πλήκτρο Cancel έκλεινε το παράθυρο, χωρίς απαραίτητα να διαγράφει τις αλλαγές. Βέβαια, όπως εύκολα αντιλαµβάνεται κανείς από τα αποτελέσµατα των αξιολογήσεων, τα προβλήµατα που συναντήθηκαν δεν περιορίστηκαν σε κάτι τόσο απλό Προβλήµατα διεπαφής χρήστη Ως προβλήµατα διεπαφής χρήστη ορίζονται αυτά που δεν επηρεάζουν άµεσα τη λειτουργία του συστήµατος, αλλά εντοπίζονται στην επικοινωνία που έχει ο χρήστης µε το σύστηµα. Για παράδειγµα, ο χρήστης µπορεί να ενηµερώνεται λανθασµένα ή καθόλου για τις ενέργειες του συστήµατος, ή µπορεί να περιορίζονται οι ενέργειες που µπορεί να κάνει. Τα προβλήµατα διεπαφής χρήστη, µε τη σειρά τους, χωρίζονται σε λάθη και σε ελλείψεις. Ο διαχωρισµός αυτός έγινε επειδή τα λάθη οδηγούν το χρήστη σε λανθασµένες κινήσεις, ενώ οι ελλείψεις τού στερούν κάποιες απαραίτητες δυνατότητες. Για παράδειγµα, ένα λάθος διεπαφής χρήστη ήταν η «επιλεκτική» ενηµέρωση της λίστας µε τα assets, ενώ µια έλλειψη καλύφθηκε µε την προσθήκη επιλογής Save all tabs στο ATDT, το οποίο παράλληλα διευκρίνιζε ότι το απλό Save έσωζε µόνο την τρέχουσα καρτέλα (tab).

43 43 Κεφάλαιο 4. Μεθοδολογία προσέγγισης 4.1 Κατευθυντήριες γραµµές στην αντιµετώπιση του προβλήµατος Επειδή το Agent Factory αποτελεί τµήµα ενός µεγαλύτερου συστήµατος, δόθηκε ιδιαίτερη προσοχή κατά τη διόρθωσή του. Έγινε από την αρχή η προσπάθεια να τηρηθούν ορισµένες βασικές κατευθυντήριες γραµµές, για να συνδυαστεί το καλύτερο αποτέλεσµα µε τον ελάχιστο αριθµό εσωτερικών αλλαγών. Είναι προφανές ότι αυτό έγινε για λόγους συµβατότητας µε τα υπόλοιπα υποσυστήµατα και διευκόλυνσης του χρήστη. Κυρίως, όµως, η επιλογή αυτή έγινε για να περιοριστούν οι αλλαγές σε όσο γίνεται λιγότερες κλάσεις και να αποφευχθούν φαινόµενα «χιονοστιβάδας», όπου ένα ελάχιστο πρόβληµα επιφέρει αλλαγές σε πολλά σηµεία. Έτσι, µια αρχή είναι ο περιορισµός των αλλαγών στις κλάσεις µέσα στο πακέτο του Agent Factory (org.agentacademy.modules.af). Αυτή η επιλογή είναι ο κύριος παράγοντας περιορισµού του προαναφερθέντος φαινοµένου «χιονοστιβάδας». Επίσης, το γεγονός ότι δεν αλλάζουν οι κλάσεις εκτός του πακέτου διασαφήνισε τα όρια της διπλωµατικής εργασίας. Ένας ακόµη στόχος, ο οποίος εν µέρει απορρέει από τα παραπάνω, είναι να µην αλλάξει ο τρόπος επικοινωνίας του Agent Factory µε τα υπόλοιπα τµήµατα του Agent Academy. Αυτό έγινε, αφενός για λόγους συµβατότητας,

44 44 αφετέρου επειδή οποιαδήποτε αλλαγή θα έπρεπε να είναι αµφίδροµη, δηλαδή να ενηµερωθούν και οι κλάσεις των άλλων πακέτων. Επίσης, πολύ σηµαντικό ήταν να διατηρηθεί πλήρης συµβατότητα µεταξύ των δύο εκδόσεων, και προς τα µπρος και προς τα πίσω. Η εκλογή αυτή έγινε καθαρά για να µην περιορίζει τον τελικό χρήστη. Αυτός είναι και ο µόνος περιορισµός που τελικά δεν τηρήθηκε πλήρως, όµως έγινε σε ένα σηµείο που έτσι κι αλλιώς δε λειτουργούσε στην προηγούµενη έκδοση (βλ. περιγραφή λύσεων, παρ. 5.2). Παράλληλα, έγινε προσπάθεια, ώστε η µόνη ενέργεια που απαιτείται για την εγκατάσταση της καινούριας έκδοσης να είναι η αντικατάσταση των παλιών κλάσεων του πακέτου org.agentacademy.modules.af µε τις νέες. υστυχώς, για να ενσωµατωθούν τα κείµενα βοήθειας στο πρόγραµµα [23], απαιτήθηκε η προσθήκη ενός εξωτερικού καταλόγου και µιας βιβλιοθήκης και η τροποποίηση του αρχείου build.xml του ant [24]. Τέλος, µια που οι χρήστες είναι κατά κύριο λόγο έµπειροι και χρησιµοποιούν το Agent Factory για να αναπτύξουν µια ολοκληρωµένη εφαρµογή, αναµένεται να επιδιώκουν τον πλήρη έλεγχο του συστήµατος. Έτσι, κρίθηκε αναγκαίο να ενηµερώνονται για κάθε ενέργεια του συστήµατος, επιτυχηµένη ή αποτυχηµένη, και να ερωτούνται πριν την εκτέλεσή της. Παράλληλα, περιορίστηκαν στο ελάχιστο οι πρωτοβουλίες που λαµβάνει το πρόγραµµα, και πάλι όµως απαιτείται η συναίνεση του χρήστη.

45 Προδιαγραφές Οι προδιαγραφές αυτές είναι βασισµένες εν µέρει στα παραδοτέα του ΑΑ [9,10] αλλά επανακαθορίστηκαν µε βάση τις απαιτήσεις (παρ. 3.2) και την αναµενόµενη συµπεριφορά του συστήµατος και γράφτηκαν αναλυτικότερα Αρχιτεκτονική σχεδίαση Το AF αποτελείται από τα εξής τµήµατα: ODT (Ontology Design Tool): Σχεδιασµός νέας οντολογίας από το Protégé ή εισαγωγή ήδη υπάρχουσας BTDT (Behavior Type Design Tool): Σχεδιασµός της συµπεριφοράς του πράκτορα ATDT (Agent Type Design Tool): Συσχέτιση πράκτορα µε συµπεριφορά SDT (Scenario Design Tool): ηµιουργία στιγµιότυπου πράκτορα Αυτά τα τµήµατα επικοινωνούν µεταξύ τους µε κεντρικό έλεγχο, σύµφωνα µε το µοντέλο Call-Return. Ο λόγος αυτής της επιλογής είναι ότι η πλατφόρµα του Agent Academy αναλαµβάνει την κλήση καθενός από αυτά τα τµήµατα ξεχωριστά, κατόπιν εντολής του χρήστη. Παρόλο που το κάθε υποσύστηµα µπορεί να κληθεί αυτόνοµα, η δοµή του όλου συστήµατος είναι ακολουθιακή, µε την έννοια ότι, για να ολοκληρωθεί η σχεδίαση ενός έργου, ο χρήστης πρέπει να έχει εκτελέσει επιτυχώς καθένα από τα τµήµατα, µε την παραπάνω σειρά. Σχήµα 4-1 Επικοινωνία µεταξύ των τµηµάτων του AF Με τον ίδιο τρόπο γίνεται και η επικοινωνία του Agent Factory µε το υπόλοιπο τµήµα του Agent Academy. Για την ακρίβεια, η επικοινωνία αυτή γίνεται µέσω του AUR και του ATM. Επειδή εδώ, ανάλογα σε ποιο σηµείο

46 46 βρίσκεται ο χρήστης, η σειρά µε την οποία καλούνται οι διάφορες υπορουτίνες δεν είναι σταθερή, προτιµάται το µοντέλο διαχειριστή. Σχήµα 4-2 Επικοινωνία AF µε AUR και ATM Λειτουργίες του Agent Factory Νέα οντολογία Λειτουργία ηµιουργία οντολογίας Περιγραφή Σχεδίαση νέας οντολογίας µε χρήση του Protégé Είσοδοι Προδιαγραφές χρήστη Πηγές Χρήστης Έξοδοι Αρχείο οντολογίας, προσθήκη στη λίστα AF_Ontologies Προορισµοί Χρήση από BTDT Απαιτεί Τίποτα Προαπαιτούµενα Ύπαρξη Protégé στο σύστηµα Αποτέλεσµα Κλήση του Protégé και επιλογή του αρχείου που δηµιουργείται ως έξοδος. Προσθήκη στη λίστα. Παρενέργειες Αν δεν εντοπιστεί το Protégé, εµφανίζεται µήνυµα λάθους και η σχεδίαση µπορεί να γίνει µόνο µε τις ήδη υπάρχουσες οντολογίες.

47 Σχεδίαση συµπεριφοράς Λειτουργία Σχεδίαση συµπεριφοράς Περιγραφή Σχεδίαση νέας συµπεριφοράς ενός πράκτορα µε τη µορφή διαγράµµατος ροής Είσοδοι Προδιαγραφές χρήστη, Οντολογία Πηγές Χρήστης, Αρχείο ODT Έξοδοι Αρχείο αρχικοποίησης, προσθήκη στη λίστα Προορισµοί Χρήση από ΑTDT Απαιτεί Τίποτα Προαπαιτούµενα Υπαρκτή οντολογία (στις περισσότερες περιπτώσεις) Αποτέλεσµα ηµιουργία αρχείου που περιγράφει τη συµπεριφορά του πράκτορα καθώς και είδη τυχόν παραµέτρων που απαιτούνται Παρενέργειες ηµιουργία νέου πράκτορα Λειτουργία ηµιουργία νέου πράκτορα Περιγραφή ηµιουργία νέου πράκτορα και συσχέτισή του µε µια ή περισσότερες συµπεριφορές Είσοδοι Τύπος πράκτορα, όνοµα, συµπεριφορές Πηγές Χρήστης, Αρχείο ΒΤDT Έξοδοι Αρχείο αρχικοποίησης Προορισµοί Χρήση από SDT Απαιτεί Τίποτα Προαπαιτούµενα Αρχεία συµπεριφοράς από το BTDT Αποτέλεσµα ηµιουργία αρχείου που περιγράφει τον πράκτορα και τις συµπεριφορές που αυτός υλοποιεί. Παρενέργειες

48 ηµιουργία στιγµιότυπου Λειτουργία ηµιουργία στιγµιότυπου Περιγραφή ηµιουργία νέου στιγµιότυπου του επιθυµητού πράκτορα Είσοδοι Πράκτορας, παράµετροι Πηγές Χρήστης, Αρχείο ΑΤDT Έξοδοι Στιγµιότυπο, Πληροφόρηση AUR Προορισµοί Λειτουργία του πράκτορα από το χρήστη, Data Miner Απαιτεί Τίποτα Προαπαιτούµενα Αρχείο αρχικοποίησης πράκτορα από ATDT Αποτέλεσµα ηµιουργία και αποθήκευση στιγµιότυπου πράκτορα, πληροφόρηση του AUR για την ύπαρξη νέου πράκτορα, αποστολή του πράκτορα στον Data Miner Παρενέργειες ιαγράµµατα UML Στην παράγραφο αυτή παρουσιάζονται τα UML διαγράµµατα που περιγράφουν τις λειτουργίες του AF. Η παρουσίαση γίνεται από πάνω προς τα κάτω (top-down), αρχικά βλέποντας την εφαρµογή στο σύνολο της και στην συνέχεια εστιάζοντας στις εσωτερικές εργασίες που εκτελεί κάθε πράκτορας του συστήµατος. Το παρακάτω διάγραµµα δείχνει το χρήστη του συστήµατος, καθώς και τις λειτουργίες που απαιτούνται για τη δηµιουργία και το τρέξιµο ενός σεναρίου. Σχήµα 4-3 Use Case διάγραµµα

49 49 Ακολουθεί το διάγραµµα καταστάσεων του συστήµατος. Σχήµα 4-4 Use Case State διάγραµµα Παρακάτω φαίνονται οι κλάσεις του πακέτου org.agentacademy.modules.af, που αντιστοιχεί στο AF. Σχήµα 4-5 Το πακέτο org.agentacademy.modules.af Ακολουθούν, για κάθε λειτουργία, το διάγραµµα καταστάσεων και το διάγραµµα κλάσεων.

50 50 Σχήµα 4-6 ιάγραµµα καταστάσεων για το φόρτωµα οντολογίας Σχήµα 4-7 ιάγραµµα κλάσεων για το φόρτωµα οντολογίας

51 51 Σχήµα 4-8 ιάγραµµα καταστάσεων για τη δηµιουργία νέας συµπεριφοράς Σχήµα 4-9 ιάγραµµα κλάσεων για τη δηµιουργία νέας συµπεριφοράς

52 52 Σχήµα 4-10 ιάγραµµα καταστάσεων για τη δηµιουργία τύπου πράκτορα Σχήµα 4-11 ιάγραµµα κλάσεων για τη δηµιουργία τύπου πράκτορα

53 53 Σχήµα 4-12 ιάγραµµα καταστάσεων για τη δηµιουργία σεναρίου και στιγµιότυπων

54 Εργαλεία που χρησιµοποιήθηκαν Για την εκσφαλµάτωση και βελτίωση του Agent Factory στα πλαίσια της εργασίας αυτής χρησιµοποιήθηκαν τα εξής εργαλεία: 1. Εργαλεία Μοντελοποίησης Λογισµικού (UML, ArgoUML) [19] 2. Αντικειµενοστρεφής Προγραµµατισµός (Java, JBuilder) [20,21] 3. Υπηρεσίες Παροχής Πληροφοριών µέσω ιαδικτύου (Tomcat, Apache) 4. Συστήµατα Βάσεων εδοµένων (PostgreSQL) 5. Η πλατφόρµα JADE ανάπτυξης πρακτόρων. [4-6] 6. Η γλώσσα XML [22] 7. Κείµενα βοήθειας στη Java (Docbooc-xsl, JavaHelp) [23] 8. Σχεδίαση οντολογιών (Protégé) [18] 9. Η γλώσσα scripting JESS [17] 10. Tο εργαλείο ant [24] 11. Ο κειµενογράφος vi

55 55 Κεφάλαιο 5. Αναλυτική περιγραφή προβληµάτων και λύσεων 5.1 Περιγραφή προβληµάτων Αφού επαναλήφθηκαν οι δοκιµές των αξιολογήσεων από τη συγγραφέα, καταγράφηκαν αναλυτικά τα προβλήµατα του Agent Factory, µε σκοπό την ευκολότερη επίλυσή τους. Στην καταγραφή αυτή βοήθησε και το παραδοτέο του Agent Academy [11], καθώς σε πολλά σηµεία, κυρίως όπου εµπλέκονταν σφάλµατα χρήστη, περιέγραφε γιατί συγχέονταν οι χρήστες και ενδεχοµένως την αναµενόµενη συµπεριφορά του συστήµατος. Τα αποτελέσµατα της καταγραφής φαίνεται στον Πίνακα 5-1. Για κάθε πρόβληµα, δίνεται ο αύξων αριθµός, το υποσύστηµα του AF στο οποίο εντοπίζεται, η περιγραφή του, η κατάταξή του (Α = λειτουργικότητας, Β = λάθος διεπαφής, Γ = έλλειψη διεπαφής) και ο βαθµός σοβαρότητάς του. Ο βαθµός σοβαρότητας δίνεται σε κλίµακα από 0 έως 5, όπου το 0 υποδηλώνει κάτι εντελώς ασήµαντο, ενώ το 5 δείχνει θέµα µείζονος σηµασίας.

56 56 Α/Α Υ/Σ Περιγραφή προβλήµατος Κατά- ταξη Βαθµός Σοβαρ. 1 Όλα Τα toolbars δεν είναι πλήρη Γ 3 2 Όλα εν υπάρχουν κείµενα βοήθειας Γ 5 3 Όλα Ο χρήστης ούτε επιλέγει ούτε βλέπει τη διαδροµή αποθήκευσης 4 Όλα Ο χρήστης δεν ενηµερώνεται για την επιτυχή αποθήκευση Γ 4 Β 4 5 Όλα Ορθογραφικά λάθη Β 1 6 ODT Στο παράθυρο Load Ontology δεν υπάρχει τύπος αρχείου 7 ODT Στο παράθυρο Load Ontology, η προεπιλεγµένη διαδροµή δεν είναι ο κατάλογος µε τις οντολογίες του AA 8 ODT Ο χρήστης δεν ενηµερώνεται ότι η οντολογία αργεί να φορτώσει 9 ODT εν υποστηρίζονται αρχεία οντολογίας χωρίς κατάληξη 10 ODT Το µήνυµα σφάλµατος για τα µη έγκυρα αρχεία δεν είναι κατατοπιστικό 11 BTDT Ο χρήστης δε µαντεύει εύκολα τον τρόπο εισαγωγής νέου block (διπλό κλικ στο κουτάκι µε το +) 12 BTDT Τα περισσότερα edit dialogs των blocks χάνουν τυχόν προηγούµενες ρυθµίσεις 13 BTDT εν υπάρχει επεξήγηση για τις επιλογές που ενεργοποιούνται µόνο κατά τη δηµιουργία στιγµιότυπου 14 BTDT Στο Jess Block Edit Dialog, το OK δεν κλείνει το παράθυρο και το Cancel δε διαγράφει τις ρυθµίσεις 15 BTDT Το Action Block ψάχνει την κλάση σε λάθος διαδροµή, µε αποτέλεσµα να µην τη βρίσκει 16 BTDT Τα assets που δηµιουργεί ο χρήστης δε διαβάζονται πάντα από το σύστηµα 17 BTDT Στο Statement Block Edit Dialog εµφανίζεται ο δεύτερος τελεστέος ακόµα και χωρίς τελεστή 18 BTDT εν εµφανίζεται το παράθυρο επεξεργασίας του block αµέσως µετά την εισαγωγή του. Ο χρήστης συχνά ξεχνά να ορίσει τιµές. Γ 3 Β 3 Γ 4 A 2 Γ 4 Β 4 A 5 Γ 4 A 4 Α 4 A 5 Β 2 Γ 5 19 BTDT Τα χρώµατα είναι αντιαισθητικά B 0 20 BTDT Τα ονόµατα των blocks δεν έχουν αρχική τιµή Γ 1

57 57 Α/Α Υ/Σ Περιγραφή προβλήµατος Κατά- ταξη Βαθµός Σοβαρ. 21 BTDT εν προειδοποιεί κατά την αντικατάσταση συµπεριφοράς 22 BTDT Ο XML parser συγχέεται από το χαρακτήρα <, που εµφανίζεται στον έλεγχο ροής, µε αποτέλεσµα να µη φορτώνει καν το αρχείο 23 BTDT Κατά τη δηµιουργία στιγµιότυπου, αν δεν αποθηκευτεί η αλλαγή, σβήνεται η συµπεριφορά, η οποία όµως χρησιµοποιείται. Αυτό δηµιουργεί σφάλµα στη βάση, η οποία χάνει όλα τα δεδοµένα. Γ 3 Α 5 Α 5 24 BTDT Στο Mapping Tool δε δίνεται δυνατότητα un-match Γ 4 25 BTDT εν ανανεώνεται η λίστα µε τα global variables Α 5 26 PADT Στο PADT, δε φαίνονται τα υπάρχοντα assets Α 4 27 PADT Το PADT αφήνει δύο assets µε το ίδιο όνοµα Α 3 28 ATDT Ο χρήστης δε βρίσκει εύκολα τον τρόπο συσχέτισης συµπεριφοράς πράκτορα Γ 3 29 ATDT Οι καρτέλες του ATDT δεν κλείνουν Γ 4 30 ATDT Απαιτούνται άσκοπα δύο κινήσεις για τη δηµιουργία νέου τύπου πράκτορα, µια για τη δηµιουργία καρτέλας και µια για την εισαγωγή του πράκτορα 31 ATDT Ο χρήστης δεν καταλαβαίνει ότι το Save αποθηκεύει µόνο την τρέχουσα καρτέλα 32 ATDT εν υπάρχει επιλογή για ταυτόχρονη αποθήκευση όλων των καρτελών 33 ATDT εν προειδοποιεί για την αντικατάσταση υπάρχοντα πράκτορα 34 ATDT εν προειδοποιεί για ενδιάµεσες αποθηκεύσεις, που αντικαθιστούν υπάρχοντες πράκτορες 35 ATDT Το Mapping Tool δείχνει µόνο το τελευταίο ζεύγος µεταβλητών που έγινε match 36 SDT Κλείνοντας το παράθυρο του SDT, ρωτάει για επιβεβαίωση, αλλά το παράθυρο κλείνει ακόµα και αν απαντήσεις No 37 SDT Η διαδικασία δηµιουργίας στιγµιότυπου είναι πολύ επίπονη, ενώ τα ενδιάµεσα βήµατα δε φαίνονται 38 SDT Κατά τη δηµιουργία νέου σεναρίου, δεν ανανεωνόταν ο τίτλος του Πίνακας 5-1 Προβλήµατα του συστήµατος Γ 2 Β 4 Γ 4 Β 5 Γ 5 Γ 3 Α 3 Γ 5 Β 3

58 58 Τα προβλήµατα αυτά συνοψίζονται στον Πίνακα 5-2: Υ/Σ Κατηγορία Σηµαντικότητα Α Β Γ Κοινά ODT BTDT ATDT SDT Σύνολο Πίνακας 5-2 Σύνοψη προβληµάτων συστήµατος 5.2 Περιγραφή λύσεων Στο παρόν υποκεφάλαιο περιγράφονται συνοπτικά οι ενέργειες που έγιναν και οι λύσεις που επελέγησαν για την αντιµετώπιση καθενός από τα προβλήµατα που αναφέρονται στον Πίνακα Όλα τα Υ/Σ: Τα toolbar δεν είναι πλήρη Προστέθηκαν τα κουµπιά που έλειπαν, ώστε όλα τα toolbar να έχουν τουλάχιστον τα κουµπιά New, Open, Save, Help και About, ενώ στο ATDT προστέθηκε και το Save All. 2. Όλα τα Υ/Σ: εν υπάρχουν κείµενα βοήθειας Έγινε συγγραφή κειµένων βοήθειας, τα οποία δίνονται στο παράρτηµα. 3. Όλα τα Υ/Σ: Ο χρήστης ούτε επιλέγει ούτε βλέπει τη διαδροµή αποθήκευσης Όπου γίνεται αποθήκευση σε αρχείο, προστέθηκε το πλήκτρο Browse. Στο ATDT, όπου η αποθήκευση γίνεται µόνο στο AUR, προστέθηκε αντίστοιχο µήνυµα, για να µην αναζητά αρχεία ο χρήστης. 4. Όλα τα Υ/Σ: Ο χρήστης δεν ενηµερώνεται για την επιτυχή αποθήκευση Πολλές φορές, ο χρήστης αποθήκευε πολλές φορές, µέχρι να διαπιστώσει ότι όντως αποθηκεύεται αλλά δεν υπήρχε ενηµέρωση. Συγκεκριµένα, στο ATDT, όταν ο χρήστης ζητούσε να αποθηκεύσει έναν τύπο πράκτορα για δεύτερη φορά, το σύστηµα του ζητούσε νέο όνοµα, οπότε δηµιουργούσε την εσφαλµένη εντύπωση στο χρήστη ότι αποθήκευε τον τύπο πράκτορα πλέον

59 59 µε τη δεύτερη προσπάθεια. Όποτε γίνεται αποθήκευση, εµφανίζεται ένα παράθυρο διαλόγου, που ενηµερώνει το χρήστη για την επιτυχή αποθήκευση ή για τυχόν σφάλµα. 5. Όλα τα Υ/Σ: Υπήρχαν ορθογραφικά λάθη Τα λάθη διορθώθηκαν. 6. ODT: Στο παράθυρο Load Ontology δεν υπάρχει τύπος αρχείου Συχνά ο χρήστης δεν ήξερε καν ποια αρχεία αντιστοιχούν σε οντολογίες και δοκίµαζε. Προστέθηκε φίλτρο µε τις αντίστοιχες καταλήξεις (rdf, rdfs) 7. ODT: Στο παράθυρο Load Ontology, η προεπιλεγµένη διαδροµή δεν είναι ο κατάλογος µε τις οντολογίες του AA Ορίστηκε ο κατάλογος models\rdf ως προεπιλεγµένος, για να εντοπίζονται πιο εύκολα οι υπάρχουσες οντολογίες. 8. ODT: Ο χρήστης δεν ενηµερώνεται ότι η οντολογία αργεί να φορτώσει Κατά το φόρτωµα της οντολογίας, το παράθυρο σταµατούσε να αποκρίνεται, οπότε συχνά ο χρήστης νόµιζε ότι το σύστηµα είχε «κρεµάσει». Μέχρι να φορτώσει η οντολογία, το κουµπί Load µετονοµάζεται σε Loading, για να αποτρέψει το χρήστη από το να το πιέσει ξανά και να φορτώσει την οντολογία δύο φορές. 9. ODT: εν υποστηρίζονται αρχεία οντολογίας χωρίς κατάληξη Έγινε η απαραίτητη τροποποίηση στον κώδικα, ώστε να µην ψάχνει απαραίτητα για τελεία στο όνοµα του αρχείου. 10. ODT: Το µήνυµα σφάλµατος για τα µη έγκυρα αρχεία δεν είναι κατατοπιστικό Συχνά, ο χρήστης απέδιδε αλλού το πρόβληµα, µε απρόβλεπτα αποτελέσµατα. Εκτός από την επιλογή να δει το κείµενο του exception, το οποίο και πάλι δεν είναι κατατοπιστικό, προστέθηκε το µήνυµα Make sure this is a valid ontology file. 11. BTDT: Ο χρήστης δε µαντεύει εύκολα τον τρόπο εισαγωγής νέου block Το πρόβληµα αυτό καθιστούσε το πρόγραµµα εξαιρετικά δύσχρηστο. Εκτός από το διπλό κλικ στο κουτάκι µε το +, προστέθηκε και η επιλογή του click-

60 60 and-drag από το όνοµα του block στο κατάλληλο σηµείο, επειδή έτσι λειτουργούν τα περισσότερα σχεδιαστικά προγράµµατα (π.χ. MS Visio). 12. BTDT: Τα περισσότερα edit dialog των blocks χάνουν τυχόν προηγούµενες ρυθµίσεις Στην καλύτερη περίπτωση, αυτό οδηγούσε σε εκνευρισµό, ενώ συχνά ο χρήστης είχε την εντύπωση ότι δεν κρατιούνται πουθενά οι ρυθµίσεις του. Χρειάστηκε πολύς κόπος, ώστε τα edit dialogs να µπορούν να διαβάζουν τις ρυθµίσεις του χρήστη, µια που απαιτούνται διαφορετικές κινήσεις για κάθε τύπο block. Το πρόβληµα αυτό ήταν και το πιο χρονοβόρο στην επίλυση. 13. BTDT: εν υπάρχει επεξήγηση για τις επιλογές που ενεργοποιούνται µόνο κατά τη δηµιουργία στιγµιότυπου Ο χρήστης θεωρούσε αυτές τις επιλογές µη λειτουργικές. Η επεξήγηση αυτή προστέθηκε στο κείµενο της βοήθειας. 14. BTDT: Στο Jess Block Edit Dialog, το OK δεν κλείνει το παράθυρο και το Cancel δε διαγράφει τις ρυθµίσεις Συχνά, ο χρήστης θεωρούσε το παράθυρο µη λειτουργικό. Έγιναν οι απαραίτητες τροποποιήσεις στον κώδικα, ώστε το παράθυρο να κλείνει µε το ΟΚ και να µην αποθηκεύονται οι ρυθµίσεις µε το Cancel. 15. BTDT: Το Action Block ψάχνει την κλάση σε λάθος διαδροµή, µε αποτέλεσµα να µην τη βρίσκει Ενώ ο χρήστης επέλεγε το όνοµα της κλάσης µε το Browse, κατά το επόµενο άνοιγµα του edit dialog παρουσιαζόταν µήνυµα σφάλµατος ότι η κλάση δε βρέθηκε. Βέβαια, αυτή δε φορτωνόταν ποτέ. Έγινε η απαραίτητη τροποποίηση στον κώδικα, ώστε η αναζήτηση να γίνεται στο σωστό κατάλογο, ενώ ο εν λόγω κατάλογος έγινε προεπιλεγµένος στο Browse. 16. BTDT: Τα assets που δηµιουργεί ο χρήστης δε διαβάζονται πάντα από το σύστηµα Αυτό, εκτός από τη µη ενηµέρωση του χρήστη, καθιστούσε τα εν λόγω assets µη λειτουργικά κατά την εκτέλεση του πράκτορα, καθώς φαινόταν το όνοµά τους στο block που τα καλούσε αλλά δεν ήταν καταχωρηµένα στη λίστα του PADT. Προστέθηκε ο απαραίτητος κώδικας, ώστε τα assets του συστήµατος να ενηµερώνονται µετά από κάθε κλήση του PADT.

61 BTDT: Στο Statement Block Edit Dialog, στις πράξεις τύπου Α=Β(οp)C, εµφανίζεται ο δεύτερος τελεστέος ακόµα και χωρίς τελεστή Το πρόβληµα αυτό δεν είχε σοβαρές συνέπειες, εκτός ίσως από το ότι καθιστούσε δυσνόητο τον τρόπο λειτουργίας των τελεστών. Προστέθηκε ο απαραίτητος κώδικας, ώστε ο δεύτερος τελεστέος να αποκρύπτεται όταν ο χρήστης επιλέγει να µην υπάρχει τελεστής και να επανεµφανίζεται όταν επιλεγεί κάποιος τελεστής. 18. BTDT: εν εµφανίζεται το παράθυρο επεξεργασίας του block αµέσως µετά την εισαγωγή του. Ο χρήστης συχνά ξεχνά να ορίσει τιµές. Ορισµένες φορές, όπου οι τιµές αυτές ήταν απαραίτητο να υπάρχουν, το σφάλµα εµφανιζόταν αργότερα, συνήθως όταν ο πράκτορας έτρεχε, χωρίς βέβαια να υπάρχει τρόπος εντοπισµού της αιτίας του. Ο κώδικας τροποποιήθηκε, ώστε να εµφανίζεται το παράθυρο επεξεργασίας του block αµέσως µόλις δηµιουργηθεί. 19. BTDT: Τα χρώµατα είναι αντιαισθητικά Όλα τα blocks έγιναν γαλάζια σε άσπρο φόντο. 20. BTDT: Τα ονόµατα των blocks δεν έχουν αρχική τιµή Αν ο χρήστης ξεχνούσε να ορίσει όνοµα, υπήρχε ενδεχόµενο σύγχυσης. Το σύστηµα δεν επηρεαζόταν. Προστέθηκε ο απαραίτητος κώδικας, ώστε το προεπιλεγµένο όνοµα να είναι blockxx, όπου ΧΧ ένας αύξων αριθµός. 21. BTDT: εν προειδοποιεί κατά την αντικατάσταση συµπεριφοράς Συνήθως ο ίδιος ο χρήστης επιδιώκει ν αντικατασταθεί η συµπεριφορά, αλλά αν αυτή ήδη χρησιµοποιείται, ενδεχοµένως να οδηγήσει τους αντίστοιχους πράκτορες σε σφάλµατα. Επίσης, αν δουλεύουν πολλοί χρήστες µε την ίδια βάση, ενδέχεται κάποιος άλλος να µην καταλάβει ότι η συµπεριφορά έχει αλλάξει και να τη χρησιµοποιήσει. Προστέθηκε προειδοποιητικό µήνυµα. 22. BTDT: Ο XML parser αντιµετωπίζει πρόβληµα µε το χαρακτήρα <, που εµφανίζεται στον έλεγχο ροής, µε αποτέλεσµα να µη φορτώνει καν το αρχείο Όσες συµπεριφορές περιλάµβαναν συνθήκες ελέγχου ροής «less than» (<) ή «less than or equal» (<=), αποθηκεύονταν µεν σε αρχείο, το οποίο όµως

62 62 δεν ήταν δυνατό να φορτωθεί, ενώ δεν εµφανιζόταν κατατοπιστικό µήνυµα σφάλµατος. Πριν την αποθήκευση σε αρχείο, οι χαρακτήρες < και <= αντικαθίστανται µε lt και le αντίστοιχα. Βέβαια, τα νέα αρχεία δεν είναι συµβατά µε την παλιά έκδοση, αλλά ούτως ή άλλως δεν ήταν δυνατή η αποθήκευση αρχείου µε τις συγκεκριµένες συνθήκες στην παλιά έκδοση. 23. BTDT: Κατά τη δηµιουργία στιγµιότυπου, αν δεν αποθηκευτεί η αλλαγή, σβήνεται η συµπεριφορά, η οποία όµως χρησιµοποιείται. Αυτό δηµιουργεί σφάλµα στη βάση, η οποία χάνει όλα τα δεδοµένα. Ο µοναδικός τρόπος αντιµετώπισης αυτού του φαινοµένου που εντόπισε η συγγραφέας ήταν να σβηστεί και να επαναδηµιουργηθεί η βάση. Προστέθηκε ο απαραίτητος έλεγχος στον κώδικα, ώστε να µη σβήνει τη συµπεριφορά, αν αυτή χρησιµοποιείται (π.χ. ο χρήστης απλώς πήγε να δηµιουργήσει στιγµιότυπο και το µετάνιωσε) 24. BTDT: Στο Mapping Tool δε δίνεται δυνατότητα un-match Ο µοναδικός τρόπος να γίνουν un-match δύο µεταβλητές ήταν το κλείσιµο του Mapping Tool, άνοιγµα και πάλι (για να χάσει τις προηγούµενες ρυθµίσεις) και εκκίνηση της διαδικασίας του matching από την αρχή. Προστέθηκε το αντίστοιχο πλήκτρο. 25. BTDT: εν ανανεώνεται η λίστα µε τα global variables Συχνά, υπήρχαν στο σύστηµα global variables, τα οποία δεν µπορούσαν να χρησιµοποιηθούν, ενώ πολλές φορές εξαφανίζονταν εντελώς. Προστέθηκε κώδικας, ώστε η εν λόγω λίστα να ανανεώνεται σωστά. 26. PADT: Στο PADT, δε φαίνονται τα διαθέσιµα assets Συχνά, το πρόβληµα αυτό οδηγούσε το χρήστη στη δηµιουργία δύο assets µε το ίδιο όνοµα, µε αποτέλεσµα να µην είναι εφικτός ο διαχωρισµός τους στα επόµενα στάδια. Προστέθηκε ο απαραίτητος κώδικας, ώστε το PADT να ανανεώνει τα assets του µετά από κάθε κλήση. 27. PADT: Το PADT επιτρέπει τη δηµιουργία δύο assets µε το ίδιο όνοµα Βέβαια, το σύστηµα τα ξεχωρίζει µε βάση το ID τους, αλλά ο χρήστης βλέπει µόνο το όνοµα. Προστέθηκε έλεγχος κατά την εισαγωγή ενός νέου asset, ώστε να εντοπίζει τυχόν assets µε το ίδιο όνοµα και να αποτρέπει τη δηµιουργία τους.

63 ATDT: Ο χρήστης δε βρίσκει εύκολα τον τρόπο συσχέτισης συµπεριφοράς πράκτορα Μετά την εισαγωγή πράκτορα, έπρεπε να επιλεγεί η επιθυµητή συµπεριφορά από τη λίστα και στη συνέχεια να γίνει δεξί κλικ στο κενό. Προστέθηκε πλήκτρο Add δίπλα στη λίστα µε τις συµπεριφορές. 29. ATDT: Οι καρτέλες του ATDT δεν κλείνουν Ο χρήστης έπρεπε να δουλεύει, διατηρώντας ανοιχτές ακόµα και τις καρτέλες µε τις οποίες είχε τελειώσει. Προστέθηκε πλήκτρο Close tab, µε την απαραίτητη προειδοποίηση, σε περίπτωση που η καρτέλα κλείνει χωρίς να έχει γίνει αποθήκευση. 30. ATDT: Απαιτούνται άσκοπα δύο κινήσεις για τη δηµιουργία νέου τύπου πράκτορα, µια για τη δηµιουργία καρτέλας και µια για την εισαγωγή του πράκτορα Το πλήκτρο New Agent Tab καταργήθηκε και το πλήκτρο New Agent ανοίγει αυτόµατα νέα καρτέλα, µια που ένας πράκτορας αντιστοιχεί σε µια καρτέλα και αντίστροφα. 31. ATDT: Ο χρήστης δεν καταλαβαίνει ότι το Save αποθηκεύει µόνο την τρέχουσα καρτέλα Συχνά, αυτό τον οδηγούσε στο να κλείσει το ATDT έχοντας αποθηκεύσει µόνο έναν από τους πράκτορές του. Η διευκρίνιση έγινε µε την εισαγωγή επιλογής Save All. 32. ATDT: εν υπάρχει επιλογή για ταυτόχρονη αποθήκευση όλων των καρτελών Προστέθηκε επιλογή Save All. 33. ATDT: εν προειδοποιεί για την αντικατάσταση υπάρχοντος πράκτορα Η προειδοποίηση εµφανίζεται µόνο αφού ο χρήστης επιλέξει για δεύτερη φορά το ίδιο όνοµα. Αν όµως δεν µπει στον κόπο να διαβάσει το µήνυµα και ξαναγράψει το ίδιο όνοµα, ο πράκτορας αντικαθίσταται. Κάτι τέτοιο µπορεί να έχει ως αποτέλεσµα να καταστραφούν πράκτορες που ήδη τρέχουν. Προστέθηκε έγκαιρη προειδοποίηση, ενώ ο έλεγχος γίνεται µετά από κάθε εισαγωγή ονόµατος και όχι µόνο µετά την πρώτη.

64 ATDT: εν προειδοποιεί για ενδιάµεσες αποθηκεύσεις, που αντικαθιστούν υπάρχοντες πράκτορες Προστέθηκε status bar µε την αντίστοιχη προειδοποίηση, ώστε ο χρήστης να το βλέπει συνέχεια. 35. ATDT: Το Mapping Tool δείχνει µόνο το τελευταίο ζεύγος µεταβλητών που έγινε match Συχνά, ο χρήστης ξεχνούσε τις ρυθµίσεις του, καθώς δούλευε «στα τυφλά». Προστέθηκε στήλη, η οποία δείχνει όλα τα ζεύγη µεταβλητών. 36. SDT: Κλείνοντας το παράθυρο του SDT, ρωτάει για επιβεβαίωση, αλλά το παράθυρο κλείνει ακόµα και αν απαντήσεις No Είχε προστεθεί κώδικας, ώστε το παράθυρο να µην κλείνει αυτόµατα, παρά µόνο µετά από χειροκίνητη κλήση της αντίστοιχης συνάρτησης. Παράλληλα, είχε παγιδευτεί το γεγονός «δόθηκε εντολή για κλείσιµο του παραθύρου», ώστε να εµφανίζεται το παράθυρο επιβεβαίωσης. Η απάντηση Yes στο παράθυρο καλούσε χειροκίνητα τη συνάρτηση, αλλά το παράθυρο εξακολουθούσε να κλείνει αυτόµατα, παρά την αντίστοιχη δήλωση. Προστέθηκε η δήλωση εκ νέου, µέσα στη συνάρτηση που καλείται όταν δίνεται εντολή για κλείσιµο του παραθύρου και πριν την εµφάνιση του παραθύρου επιβεβαίωσης. 37. SDT: Η διαδικασία δηµιουργίας στιγµιότυπου είναι πολύ επίπονη, ενώ τα ενδιάµεσα βήµατα δε φαίνονται Κατά την αξιολόγηση του AA, όσοι χρήστες είχαν καταφέρει να δηµιουργήσουν στιγµιότυπο, είχαν βοήθεια από τους επιβλέποντες. Πολλές φορές, απαιτούνταν µη προφανή βήµατα, ενώ ορισµένες φορές το στιγµιότυπο µπορούσε να δηµιουργηθεί και χωρίς κάποιες ρυθµίσεις, µε αποτέλεσµα βέβαια την εσφαλµένη λειτουργία του πράκτορα. Σε κάθε βήµα, προστέθηκε γραµµή κατάστασης, που υποδεικνύει την επόµενη κίνηση. Στο άνοιγµα του BTDT, τα Send και Receive blocks, που χρειάζονται επεξεργασία, εµφανίζονται κόκκινα, ενώ µετά την επεξεργασία τους γίνονται και πάλι γαλάζια. Στο παράθυρο εισαγωγής αρχικών τιµών των assets, προστέθηκε επεξήγηση, ώστε ο χρήστης να βρίσκει ευκολότερα πώς πρέπει να βάζει τις αρχικές τιµές. Παράλληλα, µετά την αρχικοποίηση κάποιου asset, προστίθεται δίπλα του η ένδειξη ΟΚ. Τέλος, αµέσως µετά το κλείσιµο

65 65 του BTDT, γίνεται προτροπή για αποθήκευση στο ATDT, µια που δεν είναι προφανές στο χρήστη ότι απαιτείται και δεύτερη αποθήκευση. 38. SDT: Κατά τη δηµιουργία νέου σεναρίου, δεν ανανεωνόταν ο τίτλος του Ο χρήστης συχνά νόµιζε ότι το πρόγραµµα απλώς έσβηνε το προηγούµενο σενάριο και τον άφηνε να δουλεύει εκεί. Προστέθηκε κώδικας που ανανεώνει τον τίτλο.

66 66 Κεφάλαιο 6. Επικύρωση καλής λειτουργίας του AF Στο παρόν κεφάλαιο περιγράφονται οι δοκιµές που έγιναν, ώστε να διαπιστωθεί η καλή λειτουργία του AF. Αρχικά δίνεται το πλάνο ελέγχου, µε την αναλυτική περιγραφή των συνθηκών του τεστ και των δοκιµών. Στη συνέχεια, δίνονται τα αποτελέσµατα κάθε δοκιµής, µαζί µε τη βαθµολογία τους. Τέλος, γίνεται µια σύνοψη των αποτελεσµάτων, µαζί µε ορισµένα συµπεράσµατα. 6.1 Πλάνο ελέγχου Καθορισµός µηχανής (machine configuration) Ο έλεγχος καλής λειτουργίας έγινε σε δύο διαφορετικές µηχανές. Μηχανή Α: Pentium III/800MHz, 256MB RAM, MS Windows 2000 Professional, JRE 1.4.2_04, Ant 1.5.2, Tomcat 4.1, Mammoth PostgreSQL Μηχανή Β: Pentium IV/2.8GHz, 1GB RAM, Linux RedHat 9, JRE 1.4.2_04, Ant 1.5.2, Apache , PostgreSQL Κατά την πραγµατοποίηση των δοκιµών, σε κάθε δοκιµή θα αναφέρεται ποια από τις δύο µηχανές χρησιµοποιείται. Οι χρόνοι απόκρισης θα µετρηθούν και στις δύο µηχανές.

67 Υποθέσεις του τεστ Υπόθεση 1: Η έκδοση του Agent Academy που δοκιµάζεται είναι σταθερή. Υπόθεση 2: Το Agent Academy έχει εγκατασταθεί και ρυθµιστεί σωστά σε κάθε µηχάνηµα. Υπόθεση 3: Η βάση δεδοµένων PostgreSQL έχει εγκατασταθεί και λειτουργεί στο ίδιο µηχάνηµα που τρέχει την πλατφόρµα του Agent Academy και όχι µέσω δικτύου. Υπόθεση 4: Το άτοµο που θα πραγµατοποιεί τις δοκιµές έχει συγγράψει ένα µέρος του κώδικα, κατά συνέπεια γνωρίζει ήδη τη λειτουργία του Agent Factory. Υπόθεση 5: Οι δοκιµές επίδοσης θα γίνουν παράλληλα µε τις δοκιµές λειτουργίας και όχι µε τη µορφή ξεχωριστών τεστ, για να έχουµε αποτελέσµατα αντίστοιχα της πραγµατικής λειτουργίας του AF οκιµές Ο Πίνακας 6-1 περιγράφει συνοπτικά τις δοκιµές που έγιναν. Για κάθε δοκιµή, δίνεται το υποσύστηµα στο οποίο αναφέρεται, ο αριθµός της, µια σύντοµη περιγραφή της απαίτησης που δοκιµάζεται και η σηµαντικότητα της δοκιµής, σε κλίµακα από 0 έως 10.

68 68 Υ/Σ Αρ. Περιγραφή Σηµαντ. οκιµ. ΟΚΙΜΕΣ ΛΕΙΤΟΥΡΓΙΑΣ Κλήση του ODT από την κεντρική πλατφόρµα του Agent Academy, επιτυχές άνοιγµα ODT υνατότητα του ODT για κλήση του Protégé 3 10 ODT υνατότητα του ODT για επιτυχές φόρτωµα µιας οντολογίας, εµφάνιση λίστας µε τις ήδη υπάρχουσες οντολογίες υνατότητα διαγραφής οντολογίας Ειδικές τιµές: Φόρτωµα άδειου αρχείου οντολογίας υνατότητα λήψης βοήθειας από το ODT Επιτυχές κλείσιµο ODT ιατήρηση των ρυθµίσεων που έκανε ο χρήστης στο ODT Κλήση του BTDT από την κεντρική πλατφόρµα του Agent Academy, επιτυχές άνοιγµα BTDT Σχεδίαση συµπεριφοράς στο BTDT, Receive block, Send block, Jess block, Activity block, If block, While block, Statement block Επεξεργασία παραµέτρων στα blocks, αποθήκευση των ενεργειών του χρήστη Εξ ορισµού αρχικές τιµές κατά τη δηµιουργία ενός block υνατότητα αποθήκευσης της συµπεριφοράς στο AUR υνατότητα αποθήκευσης της συµπεριφοράς σε αρχείο BTDT υνατότητα φορτώµατος µιας αποθηκευµένης συµπεριφοράς από το AUR υνατότητα φορτώµατος µιας αποθηκευµένης συµπεριφοράς από αρχείο υνατότητα λήψης βοήθειας από το BTDT Ειδικές τιµές: Φόρτωµα άδειου αρχείου στο BTDT Είσοδος λογικών σχέσεων στο If block Είσοδος λογικών σχέσεων στο While block Είσοδος λογικών σχέσεων στο Statement block Κατά το κλείσιµο του BTDT, προτροπή για αποθήκευση της συµπεριφοράς σε περίπτωση που δεν έχει αποθηκευτεί Κλείσιµο παραθύρου BTDT ATDT Κλήση του ΑTDT από την κεντρική πλατφόρµα του Agent Academy, επιτυχές άνοιγµα ΑTDT. 10

69 69 Υ/Σ Αρ. Περιγραφή Σηµαντ. οκιµ ηµιουργία νέων τύπων πρακτόρων Συσχέτιση των πρακτόρων µε συµπεριφορές, συσχέτιση ενός πράκτορα µε πολλές συµπεριφορές Αποθήκευση ενός πράκτορα Αποθήκευση όλων των πρακτόρων στις ανοιχτές καρτέλες Φόρτωµα ενός agent type από το AUR Κενά ονόµατα agent types υνατότητα λήψης βοήθειας από το ΑTDT Κλείσιµο παραθύρου ΑTDT Κλήση του SDT από την κεντρική πλατφόρµα του Agent Academy, επιτυχές άνοιγµα SDT Προσθήκη πρακτόρων στο σενάριο ιαγραφή πρακτόρων από το σενάριο υνατότητα λήψης βοήθειας από το SDT υνατότητα αποθήκευσης του σεναρίου στο AUR SDT υνατότητα αποθήκευσης του σεναρίου σε αρχείο υνατότητα φορτώµατος ενός αποθηκευµένου σεναρίου από το AUR υνατότητα φορτώµατος ενός αποθηκευµένου σεναρίου από αρχείο ηµιουργία στιγµιότυπου ενός πράκτορα, καθοδήγηση εκ µέρους του προγράµµατος Ειδικές τιµές: Φόρτωµα άδειου αρχείου στο SDT Κλείσιµο παραθύρου SDT υνατότητα λήψης βοήθειας από το κεντρικό παράθυρο ODT Main BTDT ΟΚΙΜΕΣ ΕΠΙ ΟΣΗΣ Χρόνος απόκρισης και κατανάλωση πόρων κατά το άνοιγµα του ODT Χρόνος απόκρισης και κατανάλωση πόρων κατά την κλήση του Protégé Χρόνος απόκρισης και κατανάλωση πόρων κατά το φόρτωµα µιας οντολογίας Χρόνος απόκρισης και κατανάλωση πόρων κατά το άνοιγµα του BTDT Χρόνος απόκρισης και κατανάλωση πόρων κατά την αποθήκευση µιας συµπεριφοράς στο AUR

70 70 Υ/Σ Αρ. Περιγραφή Σηµαντ. οκιµ. ATDT Χρόνος απόκρισης και κατανάλωση πόρων κατά την αποθήκευση µιας συµπεριφοράς σε αρχείο Χρόνος απόκρισης και κατανάλωση πόρων κατά το φόρτωµα µιας συµπεριφοράς από το AUR Χρόνος απόκρισης και κατανάλωση πόρων κατά το φόρτωµα µιας συµπεριφοράς από αρχείο Χρόνος απόκρισης και κατανάλωση πόρων κατά το άνοιγµα του ATDT Χρόνος απόκρισης και κατανάλωση πόρων κατά το άνοιγµα του SDT. 6 SDT ODT BTDT Χρόνος απόκρισης και κατανάλωση πόρων κατά την αποθήκευση ενός σεναρίου στο AUR Χρόνος απόκρισης και κατανάλωση πόρων κατά την αποθήκευση ενός σεναρίου σε αρχείο Χρόνος απόκρισης και κατανάλωση πόρων κατά το άνοιγµα ενός σεναρίου από το AUR Χρόνος απόκρισης και κατανάλωση πόρων κατά το άνοιγµα ενός σεναρίου από αρχείο. ΟΚΙΜΕΣ ΠΙΕΣΗΣ Ευστάθεια του συστήµατος σε περίπτωση ανοίγµατος ενός µη υπαρκτού αρχείου Ευστάθεια του συστήµατος σε περίπτωση ανοίγµατος ενός αρχείου που δεν είναι οντολογία Ευστάθεια και µη διαγραφή οντολογίας σε περίπτωση πίεσης του πλήκτρου Delete selected ontology χωρίς επιλεγµένη οντολογία Ευστάθεια του συστήµατος σε περίπτωση ανοίγµατος ενός µη υπαρκτού αρχείου Ευστάθεια του συστήµατος σε περίπτωση ανοίγµατος ενός αρχείου που δεν είναι αρχείο του BTDT Μη αντίδραση του συστήµατος σε περίπτωση drag and drop σε σηµείο που δεν είναι κόµβος Μη επανεγγραφή (overwrite) υπαρχουσών συµπεριφορών χωρίς τη συναίνεση του χρήστη Ευστάθεια του Activity Block σε περίπτωση επιλογής ανύπαρκτου αρχείου Μη αποδοχή δύο assets µε το ίδιο όνοµα Χειρισµός σχέσης του τύπου Α = Β + (null). 5 ATDT Μη άνοιγµα καρτέλας σε περίπτωση επιλογής Cancel στο New Agent Tab 6

71 71 Υ/Σ Αρ. Περιγραφή Σηµαντ. οκιµ. SDT Μη αποδοχή δηµιουργίας πράκτορα που έχει ίδιο όνοµα µε έναν υπάρχοντα Μη αποδοχή αποθήκευσης πράκτορα που έχει ίδιο όνοµα µε έναν υπάρχοντα Μη άνοιγµα καρτέλας σε περίπτωση επιλογής Cancel στο Open Agent Ευστάθεια του συστήµατος σε περίπτωση ανοίγµατος ενός µη υπαρκτού αρχείου Ευστάθεια του συστήµατος σε περίπτωση ανοίγµατος ενός αρχείου που δεν είναι αρχείο του SDT Ευστάθεια του συστήµατος σε περίπτωση εισαγωγής δύο πρακτόρων µε το ίδιο όνοµα ΟΚΙΜΕΣ ΟΜΗΣ SDT ATDT BTDT ODT 4.1 υνατότητα του ODT να χειριστεί τις απαιτούµενες οντολογίες του project O3RTAA. [14] 4.2 υνατότητα του ΒΤDT να σχεδιάσει τις απαιτούµενες συµπεριφορές του project O3RTAA. 4.3 υνατότητα του ATDT να σχεδιάσει τους απαραίτητους τύπους πράκτορα του project O3RTAA. 4.4 υνατότητα του SDT να δηµιουργήσει και να τρέξει ένα σενάριο του project O3RTAA Ορθή λειτουργία των παραπάνω πρακτόρων. 10 Πίνακας 6-1 Πλάνο δοκιµών Στις επόµενες σελίδες ακολουθεί µια πιο λεπτοµερής περιγραφή των δοκιµών του Πίνακα 6-1. Συγκεκριµένα, για κάθε δοκιµή αναφέρονται: α) οι απαιτήσεις που δοκιµάζονται (ΑΠ ), β) ο ορισµός και η αποσαφήνιση των εισόδων (ΟΑΕ) και γ) το αναµενόµενο αποτέλεσµα (ΑΑ).

72 Λειτουργικές δοκιµές 1.1 ODT οκιµή ΑΠ : Κλήση του ODT από την κεντρική πλατφόρµα του Agent Academy, επιτυχές άνοιγµα ODT. ΟΑΕ: Άνοιγµα του ODT από την κεντρική πλατφόρµα του Agent Academy µε χρήση του πλήκτρου ODT και από το µενού. ΑΑ: Άνοιγµα παραθύρου ODT. οκιµή ΑΠ : υνατότητα του ODT για κλήση του Protégé ΟΑΕ: Πίεση του πλήκτρου Open Protégé από το παράθυρο του ODT. ΑΑ: Άνοιγµα του Protégé. οκιµή ΑΠ : υνατότητα του ODT για επιτυχές φόρτωµα µιας οντολογίας, εµφάνιση λίστας µε τις ήδη υπάρχουσες οντολογίες. ΟΑΕ: Πίεση του πλήκτρου Browse, επιλογή µιας οντολογίας, πίεση του πλήκτρου Load. ΑΑ: Φόρτωµα οντολογίας και εµφάνιση του ονόµατός της στη λίστα Loaded Ontologies. οκιµή ΑΠ : υνατότητα διαγραφής οντολογίας. ΟΑΕ: Επιλογή µιας οντολογίας από τη λίστα Loaded Ontologies και πίεση του πλήκτρου Delete selected ontology. ΑΑ: ιαγραφή της οντολογίας από το AUR και από τη λίστα Loaded Ontologies. οκιµή ΑΠ : Ειδικές τιµές: Φόρτωµα άδειου αρχείου οντολογίας. ΟΑΕ: Πίεση του πλήκτρου Browse, επιλογή ενός άδειου αρχείου και πίεση του πλήκτρου Load.

73 73 ΑΑ: Μήνυµα σφάλµατος που προειδοποιεί το χρήστη ότι το αρχείο δεν είναι έγκυρο. οκιµή ΑΠ : υνατότητα λήψης βοήθειας από το ODT. ΟΑΕ: Επιλογή Help από το µενού ή επιλογή του αντίστοιχου πλήκτρου στο toolbar. ΑΑ: Εµφάνιση παραθύρου βοήθειας. οκιµή ΑΠ : Επιτυχές κλείσιµο ODT ΟΑΕ: Πίεση του πλήκτρου που κλείνει το ODT ΑΑ: Κλείσιµο παραθύρου οκιµή ΑΠ : ιατήρηση των ρυθµίσεων που έκανε ο χρήστης στο ODT ΟΑΕ: Άνοιγµα και πάλι του ODT από την κεντρική πλατφόρµα ΑΑ: Το παράθυρο ανοίγει και η λίστα Loaded Ontologies συµφωνεί µε τις αλλαγές που έκανε ο χρήστης. 1.2 BTDT οκιµή ΑΠ : Κλήση του BTDT από την κεντρική πλατφόρµα του Agent Academy, επιτυχές άνοιγµα BTDT. ΟΑΕ: Άνοιγµα του BTDT από την κεντρική πλατφόρµα του Agent Academy µε χρήση του πλήκτρου BTDT και από το µενού. ΑΑ: Άνοιγµα παραθύρου BTDT. οκιµή ΑΠ : Σχεδίαση συµπεριφοράς στο BTDT, Receive block, Send block, Jess block, Activity block, If block, While block, Statement block. ΟΑΕ: Εισαγωγή στο γράφο τουλάχιστον ενός block από κάθε τύπο, και µε click and drag και µε διπλό κλικ στο [+]. Εισαγωγή παραµέτρων στο διάλογο που ακολουθεί.

74 74 ΑΑ: Επιτυχής εισαγωγή του block στο επιθυµητό σηµείο και εµφάνιση του ονόµατός του. οκιµή ΑΠ : Επεξεργασία παραµέτρων στα blocks, αποθήκευση των ενεργειών του χρήστη. Εξ ορισµού αρχικές τιµές κατά τη δηµιουργία ενός block. ΟΑΕ: Εµφάνιση του διαλόγου επεξεργασίας του κάθε block, µε δεξί κλικ και Edit ή µε διπλό κλικ. Πραγµατοποίηση κάποιων αλλαγών και πίεση του πλήκτρου OK. ΑΑ: Κατά το άνοιγµα του παραθύρου επεξεργασίας, φαίνονται οι ρυθµίσεις που είχε κάνει ο χρήστης στο προηγούµενο βήµα. Κάθε επιλογή µέσα στο αποδεκτό πεδίο τιµών γίνεται δεκτή. οκιµή ΑΠ : Εξ ορισµού αρχικές τιµές κατά τη δηµιουργία ενός block. ΟΑΕ: Στη δοκιµή 1.11, επισκόπηση των αρχικών τιµών. ΑΑ: Όπου έχει νόηµα η εισαγωγή µιας αρχικής τιµής (π.χ. όνοµα block, επιλογή από λίστα), υπάρχει κάποια προεπιλεγµένη τιµή. οκιµή ΑΠ : υνατότητα αποθήκευσης της συµπεριφοράς στο AUR. ΟΑΕ: Πίεση πλήκτρου Save, εισαγωγή επιθυµητού ονόµατος. ΑΑ: Η συµπεριφορά αποθηκεύεται και ο χρήστης ειδοποιείται µε σχετικό µήνυµα. οκιµή ΑΠ : υνατότητα αποθήκευσης της συµπεριφοράς σε αρχείο. ΟΑΕ: Πίεση πλήκτρου Save, εισαγωγή επιθυµητού ονόµατος, επιλογή Save also to file. ΑΑ: Η συµπεριφορά αποθηκεύεται και ο χρήστης ειδοποιείται µε σχετικό µήνυµα. οκιµή ΑΠ : υνατότητα φορτώµατος µιας αποθηκευµένης συµπεριφοράς από το AUR.

75 75 ΟΑΕ: Πίεση πλήκτρου Load, επιλογή της συµπεριφοράς από τη λίστα και πίεση ΟΚ. Επισκόπηση γραφήµατος. εξί κλικ σε κάθε block και επιλογή Edit. ΑΑ: Η συµπεριφορά φορτώνεται επιτυχώς. Το γράφηµα είναι ίδιο µ αυτό που είχε σχεδιάσει ο χρήστης. Οι επιλογές του κάθε block φαίνονται κατά το Edit. οκιµή ΑΠ : υνατότητα φορτώµατος µιας αποθηκευµένης συµπεριφοράς από αρχείο. ΟΑΕ: Πίεση πλήκτρου Load, πίεση πλήκτρου Browse, επιλογή επιθυµητού αρχείου συµπεριφοράς και πίεση ΟΚ. Επισκόπηση γραφήµατος. εξί κλικ σε κάθε block και επιλογή Edit. ΑΑ: Η συµπεριφορά φορτώνεται επιτυχώς. Το γράφηµα είναι ίδιο µ αυτό που είχε σχεδιάσει ο χρήστης. Οι επιλογές του κάθε block φαίνονται κατά το Edit. οκιµή ΑΠ : υνατότητα λήψης βοήθειας από το BTDT. ΟΑΕ: Επιλογή Help από το µενού ή επιλογή του αντίστοιχου πλήκτρου στο toolbar. ΑΑ: Εµφάνιση παραθύρου βοήθειας. οκιµή ΑΠ : Ειδικές τιµές: Φόρτωµα άδειου αρχείου στο BTDT ΟΑΕ: Πάτηµα πλήκτρου Load, επιλογή ανοίγµατος από αρχείο, επιλογή κενού αρχείου. ΑΑ: Προειδοποιητικό µήνυµα ότι το αρχείο δεν είναι έγκυρο. οκιµή ΑΠ : Είσοδοι λογικών σχέσεων στο If block. ΟΑΕ: Εισαγωγή του εν λόγω block και δοκιµές µε σωστές και λάθος σχέσεις. ΑΑ: Οι σωστές σχέσεις γίνονται αποδεκτές και οι λάθος όχι.

76 76 οκιµή ΑΠ : Είσοδοι λογικών σχέσεων στο While block. ΟΑΕ: Εισαγωγή του εν λόγω block και δοκιµές µε σωστές και λάθος σχέσεις. ΑΑ: Οι σωστές σχέσεις γίνονται αποδεκτές και οι λάθος όχι. οκιµή ΑΠ : Είσοδοι λογικών σχέσεων στο Statement block. ΟΑΕ: Εισαγωγή του εν λόγω block και δοκιµές µε σωστές και λάθος σχέσεις. ΑΑ: Οι σωστές σχέσεις γίνονται αποδεκτές και οι λάθος όχι. οκιµή ΑΠ : Κατά το κλείσιµο του BTDT, προτροπή για αποθήκευση της συµπεριφοράς σε περίπτωση που δεν έχει αποθηκευτεί. ΟΑΕ: Χωρίς να έχει γίνει αποθήκευση από το παραπάνω βήµα, πίεση πλήκτρου για κλείσιµο παραθύρου. ΑΑ: Εµφάνιση διαλόγου επιβεβαίωσης. οκιµή ΑΠ : Κλείσιµο παραθύρου BTDT. ΟΑΕ: Πίεση πλήκτρου για κλείσιµο του παραθύρου. ΑΑ: Το παράθυρο κλείνει. 1.3 ATDT οκιµή ΑΠ : Κλήση του ΑTDT από την κεντρική πλατφόρµα του Agent Academy, επιτυχές άνοιγµα ΑTDT. ΟΑΕ: Άνοιγµα του ΑTDT από την κεντρική πλατφόρµα του Agent Academy µε χρήση του πλήκτρου ΑTDT και από το µενού. ΑΑ: Άνοιγµα παραθύρου ΑTDT. οκιµή ΑΠ : ηµιουργία νέων τύπων πράκτορα. ΟΑΕ: ηµιουργία πολλών καρτελών πρακτόρων µε πίεση του αντίστοιχου πλήκτρου, εισαγωγή ονοµάτων.

77 77 ΑΑ: ηµιουργούνται οι αντίστοιχες καρτέλες. Η καθεµιά περιέχει έναν κενό πράκτορα (χωρίς να έχει συσχετιστεί µε κάποια συµπεριφορά). οκιµή ΑΠ : Συσχέτιση των πρακτόρων µε συµπεριφορές, συσχέτιση ενός πράκτορα µε πολλές συµπεριφορές. ΟΑΕ: Εισαγωγή συµπεριφορών στους πράκτορες µε επιλογή της επιθυµητής συµπεριφοράς από τη λίστα και στη συνέχεια κλικ στο Add ή δεξί κλικ στο κενό. ΑΑ: Οι πράκτορες συσχετίζονται µε τις αντίστοιχες συµπεριφορές, οι οποίες εµφανίζονται και στο ταµπλό (panel). οκιµή ΑΠ : Αποθήκευση ενός πράκτορα. ΟΑΕ: Επιλογή Save από το µενού ή πίεση του αντίστοιχου πλήκτρου στο toolbar. ΑΑ: Ο πράκτορας αποθηκεύεται στο AUR και ο χρήστης ειδοποιείται µε σχετικό µήνυµα. οκιµή ΑΠ : Αποθήκευση όλων των πρακτόρων στις ανοιχτές καρτέλες. ΟΑΕ: Επιλογή Save All από το µενού ή πίεση του αντίστοιχου πλήκτρου στο toolbar. ΑΑ: Οι πράκτορες αποθηκεύονται στο AUR. Σε περίπτωση που είναι ήδη αποθηκευµένοι, ο χρήστης προτρέπεται να εισάγει νέο όνοµα. Στο τέλος, ο χρήστης ειδοποιείται µε σχετικό µήνυµα. οκιµή ΑΠ : Φόρτωµα ενός agent type από το AUR. ΟΑΕ: Επιλογή Load από το µενού ή πίεση του αντίστοιχου πλήκτρου στο toolbar, επιλογή του επιθυµητού agent type. ΑΑ: Ο πράκτορας φορτώνεται σε µια νέα καρτέλα. Φαίνεται το όνοµά του και οι συµπεριφορές µε τις οποίες έχει συσχετιστεί.

78 78 οκιµή ΑΠ : Κενά ονόµατα agent types. ΟΑΕ: Αποθήκευση ενός agent type µε κενό όνοµα. ΑΑ: Το όνοµα γίνεται αποδεκτό και το σύστηµα το χειρίζεται όπως τα άλλα ονόµατα (το αποθηκεύει, το ανοίγει, δε δέχεται δεύτερο πράκτορα µε κενό όνοµα). οκιµή ΑΠ : υνατότητα λήψης βοήθειας από το ΑTDT. ΟΑΕ: Επιλογή Help από το µενού ή επιλογή του αντίστοιχου πλήκτρου στο toolbar. ΑΑ: Εµφάνιση παραθύρου βοήθειας. οκιµή ΑΠ : Κλείσιµο παραθύρου ΑTDT. ΟΑΕ: Πίεση πλήκτρου για κλείσιµο του παραθύρου. ΑΑ: Το παράθυρο κλείνει. 1.4 SDT οκιµή ΑΠ : Κλήση του SDT από την κεντρική πλατφόρµα του Agent Academy, επιτυχές άνοιγµα SDT. ΟΑΕ: Άνοιγµα του SDT από την κεντρική πλατφόρµα του Agent Academy µε χρήση του πλήκτρου SDT και από το µενού. ΑΑ: Άνοιγµα παραθύρου SDT, εµφάνιση ενός κενού σεναρίου. οκιµή ΑΠ : Προσθήκη πρακτόρων στο σενάριο. ΟΑΕ: εξί κλικ στο κενό, επιλογή Add Agent, επιλογή του επιθυµητού Agent Type, εισαγωγή ονόµατος. ΑΑ: Ο επιλεγµένος πράκτορας προστίθεται στο σενάριο και φαίνεται στο ταµπλό.

79 79 οκιµή ΑΠ : ιαγραφή πρακτόρων από το σενάριο. ΟΑΕ: εξί κλικ στο όνοµα ενός πράκτορα και επιλογή delete. ΑΑ: Ο επιλεγµένος πράκτορας διαγράφεται από το σενάριο και από το ταµπλό. οκιµή ΑΠ : υνατότητα λήψης βοήθειας από το SDT. ΟΑΕ: Επιλογή Help από το µενού ή επιλογή του αντίστοιχου πλήκτρου στο toolbar. ΑΑ: Εµφάνιση παραθύρου βοήθειας. οκιµή ΑΠ : υνατότητα αποθήκευσης του σεναρίου στο AUR. ΟΑΕ: Πίεση πλήκτρου Save, εισαγωγή επιθυµητού ονόµατος. ΑΑ: Το σενάριο αποθηκεύεται και ο χρήστης ειδοποιείται µε σχετικό µήνυµα. οκιµή ΑΠ : υνατότητα αποθήκευσης του σεναρίου σε αρχείο. ΟΑΕ: Πίεση πλήκτρου Save, εισαγωγή επιθυµητού ονόµατος, επιλογή Save also to file. ΑΑ: Το σενάριο αποθηκεύεται και ο χρήστης ειδοποιείται µε σχετικό µήνυµα. οκιµή ΑΠ : υνατότητα φορτώµατος ενός αποθηκευµένου σεναρίου από το AUR. ΟΑΕ: Πίεση πλήκτρου Load, επιλογή του σεναρίου από τη λίστα και πίεση ΟΚ. Επισκόπηση σεναρίου. ΑΑ: Το σενάριο φορτώνεται επιτυχώς και είναι ίδιο µ αυτό που είχε σχεδιάσει ο χρήστης. οκιµή ΑΠ : υνατότητα φορτώµατος ενός αποθηκευµένου σεναρίου από αρχείο. ΟΑΕ: Πίεση πλήκτρου Load, πίεση πλήκτρου Browse, επιλογή επιθυµητού αρχείου σεναρίου και πίεση ΟΚ. Επισκόπηση σεναρίου.

80 80 ΑΑ: Το σενάριο φορτώνεται επιτυχώς και είναι ίδιο µ αυτό που είχε σχεδιάσει ο χρήστης. οκιµή ΑΠ : ηµιουργία στιγµιότυπου ενός πράκτορα, καθοδήγηση εκ µέρους του προγράµµατος. ΟΑΕ: Ο χρήστης δηµιουργεί το στιγµιότυπο ενός πράκτορα ακολουθώντας τις οδηγίες. ΑΑ: Ο χρήστης είναι σε θέση να δηµιουργήσει το στιγµιότυπο. Ο πράκτορας τρέχει επιτυχώς. οκιµή ΑΠ : Ειδικές τιµές: Φόρτωµα άδειου αρχείου στο SDT ΟΑΕ: Πάτηµα πλήκτρου Load, επιλογή ανοίγµατος από αρχείο, επιλογή κενού αρχείου. ΑΑ: Προειδοποιητικό µήνυµα ότι το αρχείο δεν είναι έγκυρο. οκιµή ΑΠ : Κλείσιµο παραθύρου SDT. ΟΑΕ: Πίεση πλήκτρου για κλείσιµο του παραθύρου. ΑΑ: Το παράθυρο κλείνει. 1.5 Κεντρικό παράθυρο οκιµή ΑΠ : υνατότητα λήψης βοήθειας από το κεντρικό παράθυρο. ΟΑΕ: Επιλογή Help από το µενού. ΑΑ: Εµφάνιση παραθύρου βοήθειας οκιµές επίδοσης 2.1 ODT οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά το άνοιγµα του ODT. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή

81 81 ΑΑ: Το ODT ανοίγει σε χρόνο µικρότερο των 2 sec, το σύστηµα δεν «κρεµάει». οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά την κλήση του Protégé. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή ΑΑ: Το Protégé καλείται σε χρόνο µικρότερο των 2 sec, το σύστηµα δεν «κρεµάει». οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά το φόρτωµα µιας οντολογίας. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή ΑΑ: Η οντολογία φορτώνεται σε χρόνο µικρότερο των 10 sec, ο χρήστης προειδοποιείται για την καθυστέρηση, το σύστηµα δεν «κρεµάει». 2.2 BTDT οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά το άνοιγµα του BTDT. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή ΑΑ: Το BTDT ανοίγει σε χρόνο µικρότερο των 2 sec, το σύστηµα δεν «κρεµάει». οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά την αποθήκευση µιας συµπεριφοράς στο AUR. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή ΑΑ: Η συµπεριφορά αποθηκεύεται σε χρόνο µικρότερο των 2 sec, το σύστηµα δεν «κρεµάει». οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά την αποθήκευση µιας συµπεριφοράς σε αρχείο. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή

82 82 ΑΑ: Η συµπεριφορά αποθηκεύεται σε χρόνο µικρότερο των 2 sec, το σύστηµα δεν «κρεµάει». οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά το φόρτωµα µιας συµπεριφοράς από το AUR. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή ΑΑ: Η συµπεριφορά φορτώνεται σε χρόνο µικρότερο των 2 sec, το σύστηµα δεν «κρεµάει». οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά το φόρτωµα µιας συµπεριφοράς από αρχείο. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή ΑΑ: Η συµπεριφορά φορτώνεται σε χρόνο µικρότερο των 2 sec, το σύστηµα δεν «κρεµάει». 2.3 ATDT οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά το άνοιγµα του ATDT. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή ΑΑ: To ATDT ανοίγει σε χρόνο µικρότερο των 2 sec, το σύστηµα δεν «κρεµάει». 2.4 SDT οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά το άνοιγµα του SDT. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή ΑΑ: Το SDT ανοίγει σε χρόνο µικρότερο των 2 sec, το σύστηµα δεν «κρεµάει».

83 83 οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά την αποθήκευση ενός σεναρίου στο AUR. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή ΑΑ: Το σενάριο αποθηκεύεται σε χρόνο µικρότερο των 2 sec, το σύστηµα δεν «κρεµάει». οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά την αποθήκευση ενός σεναρίου σε αρχείο. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή ΑΑ: Το σενάριο αποθηκεύεται σε χρόνο µικρότερο των 2 sec, το σύστηµα δεν «κρεµάει». οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά το άνοιγµα ενός σεναρίου από το AUR. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή ΑΑ: Το σενάριο ανοίγει σε χρόνο µικρότερο των 2 sec, το σύστηµα δεν «κρεµάει». οκιµή ΑΠ : Χρόνος απόκρισης και κατανάλωση πόρων κατά το άνοιγµα ενός σεναρίου από αρχείο. ΟΑΕ: Μέτρηση της επίδοσης στη δοκιµή ΑΑ: Το σενάριο ανοίγει σε χρόνο µικρότερο των 2 sec, το σύστηµα δεν «κρεµάει» οκιµές πίεσης 3.1 ODT οκιµή ΑΠ : Ευστάθεια του συστήµατος σε περίπτωση ανοίγµατος ενός µη υπαρκτού αρχείου.

84 84 ΟΑΕ: Πληκτρολόγηση ενός µη υπαρκτού ονόµατος αρχείου στο πεδίο µε το όνοµα της οντολογίας, πίεση Load. ΑΑ: Το σύστηµα προειδοποιεί το χρήστη ότι το αρχείο δεν είναι έγκυρο. οκιµή ΑΠ : Ευστάθεια του συστήµατος σε περίπτωση ανοίγµατος ενός αρχείου που δεν είναι οντολογία. ΟΑΕ: Πίεση πλήκτρου Browse, επιλογή ενός αρχείου που δεν είναι οντολογία, πίεση Load. ΑΑ: Το σύστηµα προειδοποιεί το χρήστη ότι το αρχείο δεν είναι έγκυρο. οκιµή ΑΠ : Ευστάθεια και µη διαγραφή οντολογίας σε περίπτωση πίεσης του πλήκτρου Delete selected ontology χωρίς επιλεγµένη οντολογία. ΟΑΕ: Χωρίς να είναι επιλεγµένη καµιά οντολογία, πίεση πλήκτρου Delete selected ontology. ΑΑ: Το σύστηµα δεν «κρεµάει» και δε σβήνει καµιά οντολογία. 3.2 ΒΤDT οκιµή ΑΠ : Ευστάθεια του συστήµατος σε περίπτωση ανοίγµατος ενός µη υπαρκτού αρχείου. ΟΑΕ: Πληκτρολόγηση ενός µη υπαρκτού ονόµατος αρχείου στο πεδίο µε το όνοµα του αρχείου, πίεση Load. ΑΑ: Το σύστηµα προειδοποιεί το χρήστη ότι το αρχείο δεν είναι έγκυρο. οκιµή ΑΠ : Ευστάθεια του συστήµατος σε περίπτωση ανοίγµατος ενός αρχείου που δεν είναι αρχείο του BTDT. ΟΑΕ: Πίεση πλήκτρου Browse, επιλογή ενός αρχείου που δεν είναι αρχείο συµπεριφοράς, πίεση Load. ΑΑ: Το σύστηµα προειδοποιεί το χρήστη ότι το αρχείο δεν είναι έγκυρο.

85 85 οκιµή ΑΠ : Μη αντίδραση του συστήµατος σε περίπτωση drag and drop σε σηµείο που δεν είναι κόµβος. ΟΑΕ: Επιλογή ενός block από τη λίστα αριστερά, drag and drop σε ένα σηµείο εκτός των κόµβων. ΑΑ: Καµία αντίδραση. οκιµή ΑΠ : Μη επανεγγραφή (overwrite) υπαρχουσών συµπεριφορών χωρίς τη συναίνεση του χρήστη. ΟΑΕ: Πίεση πλήκτρου αποθήκευσης, πληκτρολόγηση του ονόµατος µιας υπάρχουσας συµπεριφοράς, πίεση Save. ΑΑ: Προτροπή για επανεγγραφή της υπάρχουσας συµπεριφοράς. οκιµή ΑΠ : Ευστάθεια του Activity Block σε περίπτωση επιλογής ανύπαρκτου αρχείου. ΟΑΕ: Επεξεργασία ενός activity block, πληκτρολόγηση ενός ανύπαρκτου ονόµατος αρχείου στο πεδίο, πίεση ΟΚ. ΑΑ: Προειδοποίηση ότι δε βρέθηκε η κλάση, αλλά αποδοχή του ονόµατος (για λόγους φορητότητας). οκιµή ΑΠ : Μη αποδοχή δύο assets µε το ίδιο όνοµα. ΟΑΕ: Στο PADT, εισαγωγή δύο assets µε το ίδιο όνοµα. ΑΑ: Απόρριψη του δεύτερου asset. οκιµή ΑΠ : Χειρισµός σχέσης του τύπου Α = Β + (null). ΟΑΕ: Εισαγωγή της παραπάνω σχέσης στο statement block, µε επιλογή ενός τελεστή αλλά χωρίς επιλογή δεύτερου τελεστέου. ΑΑ: Απόρριψη του τελεστή.

86 ATDT οκιµή ΑΠ : Μη άνοιγµα καρτέλας σε περίπτωση επιλογής Cancel στο New Agent Tab ΟΑΕ: Άνοιγµα ATDT, πίεση κουµπιού New Agent Tab, στη συνέχεια Cancel ΑΑ: εν ανοίγει καρτέλα νέου πράκτορα. οκιµή ΑΠ : Μη αποδοχή δηµιουργίας πράκτορα που έχει ίδιο όνοµα µε έναν υπάρχοντα ΟΑΕ: Πίεση κουµπιού New Agent Tab, εισαγωγή ονόµατος ίδιου µε ενός αποθηκευµένου πράκτορα ΑΑ: Μη αποδοχή του ονόµατος. οκιµή ΑΠ : Μη αποδοχή αποθήκευσης πράκτορα που έχει ίδιο όνοµα µε έναν υπάρχοντα ΟΑΕ: Άνοιγµα ενός αποθηκευµένου πράκτορα, πίεση πλήκτρου Save ΑΑ: Μη αποδοχή του ονόµατος. οκιµή ΑΠ : Μη άνοιγµα καρτέλας σε περίπτωση επιλογής Cancel στο Open Agent ΟΑΕ: Πίεση πλήκτρου για άνοιγµα ενός πράκτορα, επιλογή Cancel ΑΑ: εν ανοίγει καρτέλα πράκτορα. 3.4 SDT οκιµή ΑΠ : Ευστάθεια του συστήµατος σε περίπτωση ανοίγµατος ενός µη υπαρκτού αρχείου. ΟΑΕ: Άνοιγµα SDT, πίεση πλήκτρου για άνοιγµα σεναρίου, πίεση Browse, εισαγωγή ονόµατος µη υπαρκτού αρχείου ΑΑ: Προειδοποιητικό µήνυµα ότι το αρχείο δεν υπάρχει, ευστάθεια. οκιµή 3.4.2

87 87 ΑΠ : Ευστάθεια του συστήµατος σε περίπτωση ανοίγµατος ενός αρχείου που δεν είναι αρχείο του SDT. ΟΑΕ: Πίεση πλήκτρου για άνοιγµα σεναρίου, πίεση Browse, επιλογή ενός αρχείου που δεν είναι αρχείο του SDT. ΑΑ: Προειδοποιητικό µήνυµα ότι το αρχείο δεν είναι έγκυρο, ευστάθεια. οκιµή ΑΠ : Ευστάθεια του συστήµατος σε περίπτωση εισαγωγής δύο πρακτόρων µε το ίδιο όνοµα ΟΑΕ: ηµιουργία νέου σεναρίου, εισαγωγή δύο πρακτόρων που έχουν ίδιο όνοµα ΑΑ: Το σύστηµα µπορεί να τους χειριστεί οκιµές δοµής Οι δοκιµές αυτές αφορούν τη δηµιουργία του συστήµατος O 3 RTAA, που εκτιµά την ποιότητα του αέρα, χρησιµοποιώντας δεδοµένα που προέρχονται από ένα µετεωρολογικό σταθµό. Ένα ΠΠΣ επιβλέπει τις µετρήσεις που προέρχονται από διάφορους αισθητήρες, κάνει µια εκτίµηση της ποιότητας του αέρα και, αν χρειάζεται, στέλνει ειδοποιήσεις στους κατάλληλους παραλήπτες. Η αρχιτεκτονική του συστήµατος παρουσιάζεται στο Σχήµα 6-1. Η πληροφορία ρέει από τους αισθητήρες (στα αριστερά του σχήµατος) στους χρήστες (στα δεξιά) διαµέσου τριών επιπέδων πρακτόρων. Οι µετρήσεις της ποιότητας του αέρα φτάνουν στο σύστηµα από τους αισθητήρες. Οι diagnosis agent τις διαβάζουν και, αφού ελέγξουν την αξιοπιστία τους, τους παραδίδουν στο επίπεδο management. Ο alarm agent δέχεται τις ελεγµένες µετρήσεις και καθορίζει αν θα πρέπει να αποσταλεί κάποια ειδοποίηση. Οι µετρήσεις αποθηκεύονται στη βάση δεδοµένων από τον database agent. Τυχόν ειδοποιήσεις στέλνονται στον distribution agent, ο οποίος τις παραδίδει µε την κατάλληλη µορφή στους αντίστοιχους τελικούς χρήστες.

88 88 Σχήµα 6-1 Η αρχιτεκτονική του O 3 RTAA Για ευκολία στην υλοποίηση, καθώς δεν ήταν κρίσιµη η πλήρης λειτουργία του, έγιναν ορισµένες απλοποιήσεις. Έτσι, το σύστηµα που υλοποιήθηκε περιέχει: α) sensor agents που διαβάζουν την τρέχουσα τιµή του όζοντος από ένα αρχείο που αντιστοιχεί σε µετρήσεις από αισθητήρες, β) distribution agents που ελέγχουν αν η µέτρηση είναι έγκυρη και, αν δεν είναι, κάνουν µια εκτίµηση της τιµής της, και γ) alarm agents που εµφανίζουν την τρέχουσα µέτρηση σε ένα παράθυρο. [14] οκιµή 4.1 ΑΠ : υνατότητα του ODT να χειριστεί τις απαιτούµενες οντολογίες του project O 3 RTAA. ΟΑΕ: Φόρτωµα της αντίστοιχης οντολογίας από το ODT. ΑΑ: Η οντολογία φορτώνεται επιτυχώς. οκιµή 4.2 ΑΠ : υνατότητα του ΒΤDT να σχεδιάσει τις απαιτούµενες συµπεριφορές του project O 3 RTAA.